Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
draft-ietf-pce-of-06

[Ballot comment]
Section 4., paragraph 4:
>    - residual bandwidth on link L is denoted r(L)
>    - maximum reservable bandwidth on link L is denoted R(L).

  I assume that r(L) is the residual bandwidth that is available for
  reservation and not the instantaneous available capacity on a link,
  correct?


Section 5., paragraph 3:
>      Type 5 (suggested value to be assigned by IANA) : Load of the most
>      loaded link.

  Similar to my previous comment, does load here refer to the
  (normalized) amount of reserved capacity, or to actual instantaneous
  load levels? If the latter, what are the timing/accuracy bounds on
  that information, and how are they guaranteed?


  Document needs to be spell-checked.

[Ballot discuss]
Section 4., paragraph 7:
>    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.

  DISCUSS: I may be missing something, but this definition looks iffy.
  It subtracts the normalized value "r(Lpi) / R(Lpi)" from the absolute
  value "R(Lpi)" - what's the unit/meaning of the resulting value? Do
  you maybe mean "((R(Lpi) - r(Lpi)) / R(Lpi)"? In that case, the name
  should reflect that this is the "normalized MLP". Or is the intent
  that "load" implies normalization?

[Ballot comment]
Abstract:

The abstract is fairly long and seems to be more an introduction than a abstract.

Section 6.1:

One of the data entries of the PCE Objective Function registry is Defining RFC. Considering that you have FCFS policy that allow any registrations then "Defining RFC" may not be the best column name. Reference and contact Person seems to be what should be present. Where Contact Person for the Consensus part is not required, but Reference is, and the the FCFS where Reference is recommended(?) and Contact is required.

I would also note that IETF consensus does not longer exist as policy in RFC 5226, it is called IETF Review instead.

IANA comments:

Action 1 (Section 6.1):

Upon approval of this document, the IANA will create the
registry "PCE Objective Functions" at
http://www.iana.org/assignments/pcep/pcep.xhtml

Registration Procedures:
- Function code values 1 through 1023 are to be assigned by IANA
using the "IETF Consensus" policy.
- Function code values 1024 through 32767 are to be assigned by
IANA, using the "First Come First Served" policy.

Initial contents of this registry will be:

Code Point Function Name Reference
---------- ------------- -----------
0 Reserved [RFC-pce-of-05]
1 MCP [RFC-pce-of-05]
2 MLP [RFC-pce-of-05]
3 MBP [RFC-pce-of-05]
4 MBC [RFC-pce-of-05]
5 MLL [RFC-pce-of-05]
6 MCC [RFC-pce-of-05]
7-32767 Unassigned
32768-65535 Private Use [RFC-pce-of-05]


Action 2 (Section 6.2.1):

Upon approval of this document, IANA will make the following
assignments in the "PCEP Objects" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Object Class Name Reference
-------------+------------------------------------+--------------
TBD(21) OF [RFC-pce-of-05]
Object-Type
1 Objective Function [RFC-pce-of-05]
2-15 Unassigned


Action 3 (Section 6.2.2):

Upon approval of this document, IANA will make the following
assignment in the "PCEP TLV Type Indicators" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

TLV Type Meaning Reference
----------+---------------------------------------+---------
TBD(4) OF-List [RFC-pce-of-05]


Action 4 (Section 6.2.3):

Upon approval of this document, IANA will make the following
assignment in the "PCEP-ERROR Object Error Types and Values"
registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Error Type Meaning Reference
----------+----------------------------------------------+---------
TBD(5) Policy violation [RFC-pce-of-05]

Error-value=0-2: Unassigned

Error-value=3: objective function not [RFC-pce-of-05]
allowed (request rejected)

Error-value=4: OF bit of the RP object [RFC-pce-of-05]
set (request rejected)

Error-value=5-255: Unassigned


Action 5 (Section 6.2.4):

Upon approval of this document, IANA will make the following
assignment in the "RP Object Flag Field" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Bit | Name | Description | Reference
-----------+----------+-----------------------+---------------
TBD(16) | OF | Objective Function | [RFC-pce-of-05]


Action 6 (Section 6.2.5):

Upon approval of this document, IANA will make the following
assignments in the "METRIC Object T Field" registry at
http://www.iana.org/assignments/pcep/pcep.xhtml

Value | Name | Reference
------------+---------------------------------+---------------
TBD(4) | Aggregate bandwidth consumption | [RFC-pce-of-05]
TBD(5) | Load of the most loaded link | [RFC-pce-of-05]
TBD(6) | Cumulative IGP cost | [RFC-pce-of-05]
TBD(7) | Cumulative TE cost | [RFC-pce-of-05]


We understand the above to be the only IANA Actions for this document.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

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.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

No IPR disclosures filed.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

See answer to (1.b).

No discontent expressed.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

A reference

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

The document requests extensions to the PCEP IANA registerises that are
still not fully created as PCEP is still in the IESG review process.
However, the IANA section looks good.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

A reference to draft-farrel-rtg-common-bnf is included to scope the BNF
used.

No tool has been used for verification.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.

  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 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
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

Good support and discussion in early stages of the I-D.
Special review and approval commissioned to confirm WG support.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

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.