Subject: [Pce] Protocol Action: 'Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 25 Mar 2009 10:18:39 -0700 (PDT)

The IESG has approved the following document:

- 'Encoding of Objective Functions in the Path Computation Element 
   Communication Protocol (PCEP) '
   <draft-ietf-pce-of-06.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-of-06.txt

Technical Summary

   The computation of one or a set of Traffic Engineering Label 
   Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS)
   and Generalized MPLS (GMPLS) networks, is subject to a set of one
   or more specific optimization criteria, referred to as objective 
   functions (e.g. minimum cost path, widest path, etc.).

   In the Path Computation Element (PCE) architecture, a Path
   Computation Client (PCC) may want a path to be computed for one or
   more TE LSPs according to a specific objective function. Thus, the
   PCC needs the ability to instruct the PCE to use the correct 
   objective function. Furthermore, it is possible that not all PCEs  
   support the same set of objective functions, therefore it is useful
   for the PCC to be able to automatically discover the set of objective
   functions supported by each PCE.

   This document defines extensions to the PCE communication Protocol
   (PCEP) to allow a PCE to indicate the set of objective functions it
   supports. Extensions are also defined so that a PCC can indicate in
   a path computation request the required objective function, and so
   that a PCE can report in a path computation reply the objective
   function that was used for path computation.

Working Group Summary

   No controversy reported (see PROTO writeup by Adrian Farrel). The 
   I-D had a good level of review and discussion when it was first 
   introduced. However, the last year has been quiet and the working
   group last call produced no comments. To be sure that there was
   support, the working group was asked to provide explicit review
   and approval. A number of participants responded supporting 
   publication. 

Document Quality

   A private survey has revealed several implementations of the 
   PCEP extensions defined in this document. Furthermore, there 
   are several further extensions in the pipeline that make use
   of these extensions to enable new applications of PCE. The 
   document was updated in response to IETF last call comments. 

Personnel

   Adrian Farrel is the Document Shepherd for this document.  Ross
   Callon is the Responsible Area Director.  

RFC Editor Note

  Section 4., paragraph 7:

  OLD
    Objective Function Code: 2 (suggested value, to be assigned by IANA)
    Name: Minimum Load Path (MLP)
    Description: Find a path P such that
             ( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized.

  NEW
    Objective Function Code: 2 (suggested value, to be assigned by IANA)
    Name: Minimum Load Path (MLP)
    Description: Find a path P such that
             ( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.

  Section 6.1

  OLD
     - Function code values 1 through 1023 are to be assigned by IANA
       using the "IETF Consensus" policy.

  NEW
     - Function code values 1 through 1023 are to be assigned by IANA
       using the "IETF Review" policy.

  Section 6.1

  OLD
    Six objective functions are defined in Section 4 of this document
    and should be assigned by IANA:

    Code Point           Name                    Defining RFC

  NEW
    Six objective functions are defined in Section 4 of this document
    and should be assigned by IANA:

    Code Point           Name                    Reference