[Pce] Quesitons about OF draft

["Adrian Farrel" <adrian at olddog.co.uk>]

Hi,

A bunch of nits and a couple of technical question.

Cheers,
Adrian

Please run idnits (http://tools.ietf.org/tools/idnits/) and clean up
any issues shown.
===
Abstract
s/series/set/
s/criteria(s)/criteria/
s/may support one or multiple/may support one or more/
===
Abstract
   ...it is desired for a Path Computation Client (PCC) to
   automatically discover the set of objective functions supported by a
   PCE. Furthermore, it may be useful for a PCC to specify in a path
   computation request the required objective function to be used...
I think you might present the requirements in a slightly different
order. For example:
   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.
===
Abstract
   Thus the aim of this
   document is to define extensions to the PCE communication Protocol
   (PCEP) in order to allow a PCC to discover the set of objective
   functions supported by a PCE as well as to allow a PCC to indicate in
   a path computation request the required objective function and a PCE
   to indicate in a path computation reply the objective function that
   was used for path computation.
Can we break this up to make it a bit easier to read and start a new
paragraph? For example:
   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.
===
 1. Terminology
The indentation of all of the section headers is broken.
You need to have the Introduction as section 1. This means more than
just re-ordering the sections as any acronyms in the Introduction will
need to be expanded.
===
1. Terminology
s/criteria(s)/criteria/
===
2. Introduction
s/A PCE serves/A PCE services/
s/criteria(s)/criteria/
s/candidate path(s)/candidate paths/
s/non synchronized/non-synchronized/
s/It defines PCEP extensions allowing a PCE advertising a list/It defines 
PCEP extensions allowing a PCE to advertise a list/
s/extensions so as to carry/extensions to carry/
s/It thus complements/It complements/
s/parameters should rather be discovered/parameters should be discovered/
s/Objective functions pertain to this second/Objective functions are in this 
second/
s/section 3/Section 3/
s/the list of objective functions that it supports/to list the objective 
functions that it supports/
s/section 4/Section 4/
s/applied by a PCE or in a PCRep/applied by a PCE, or in a PCRep/
===
3.1. OF-List TLV
s/The OSPF OF-List TLV/The PCEP OF-List TLV/  (!)
In the figure, indent the bit numbering by one more space.
In your figure, I suggst you label the final two bytes "padding".
c/(see IANA section)/(see Section 6)/
===
3.2. Elements of procedure
s/A PCE MAY include and OF-List/A PCE MAY include an OF-List/

   The OF-List TLV MUST NOT appear more than once
   in an OPEN object.
Say what happens if more than one is present. I assume you class this
as an invalid Open message and would reject the PCEP session
establishment.

s/The absence of the OF-List TLV in an OPEN object must/The absence of the 
OF-List TLV in an OPEN object MUST/
===
4. Objective Function in PCEP Path Computation request and reply
   messages

Please capitalise the section heading.

At the end of section 4.2 you say that the OF object must not be used in
association with the No-Path object. I have comments about that later,
but if that remains the case, you should mention it in this section.

OLD
   A new flag is defined in the RP object, so as to indicate in a PCReq
   message that the PCE MUST provide in the PCRep message the objective
   function that was used during path computation.
NEW
   A new flag is defined in the RP object. The flag is used in a PCReq
   message to indicate that the PCE MUST include an OF object in the
   PCRep message to indicate the objective function that was used during
   path computation.

s/Also new//Also, new/
s/error type and value//error types and values/
===
4.1. OF Object
s/The OF Object-Types/The OF Object-Type/

Indent the bit number in the figure.

s/(see IANA section)/(see Section 6) /

   Optional TLVs may be defined so as to encode objective function
   parameters.
Perhaps say "in the future"?
===
4.1.1. Elements of Procedure

   To request the use of a specific objective function to be used by the
   PCE a PCC MUST include an OF object in the PCReq message.
This use of RFC2119 "MUST" is likely (on the basis of recent experience)
to cause confusion during IESG review. It is actually a conditional
"MUST", but could be misinterpretted. I think you can safely rephrase
as...
   To request the use of a specific objective function by the PCE, a PCC
   includes an OF object in the PCReq message.

OLD
   [PCEP] specifies a bit flag referred to as the P bit in a PCEP
   common header that can be set by a PCC to enforce a PCE to take into
   account the related information during the path computation.
NEW
   [PCEP] specifies a bit flag, referred to as the P bit, carried in the
   common PCEP object header. The P bit is set by a PCC to mandate that
   a PCE must take the information carried in the object into account
   during the path computation.


   If the
   objective function is mandatory (required objective function), the P
   bit in the OF object MUST be set, else if it is optional (desired
   objective function) the P bit MUST be cleared.
I would prefer to see this text reversed so that we describe the
behavior of the PCE if the bit is set/clear. As you have it at the
moment you are mandating the PCC behavior based on its desires. Either
you should not use RFC 2119 language, or you should re-word according to
how you want the PCE to behave. How about:
   If the P bit is set in the OF object, the objective function is
   mandatory (required objective function) and the PCE MUST use the
   objective function during path computation. If the P bit is clear in
   the OF object, the objective function is optional (desired objective
   function) and the PEC SHOULD apply the function if it is supported,
   but MAY choose to apply a different objective function according to
   local capablities and policy.


        - If the OF object is unknown/unsupported, the PCE MUST follow
          procedures defined in [PCEP], that is if the P bit is set, it
          sends a PCErr message with error type unknown/unsupported
          object (type 3 and 4) and the related path computation request
          MUST be discarded.
You need to describe the error-value to use.

        - If the objective function is unknown / unsupported and the P
          bit is set, the PCE MUST send a PCErr message with a new PCEP
          error type "objective function error" and error value
          "unknown/unsupported objective function" (defined in this
          document), and the related path computation request MUST be
          discarded.
My understanding of our discussion about the PCEP spec was that you
intended to have generic error-types and error-values. This would be a
case for using Error-type 3/4: Unknown/Not supported Object and Error-
value=4: Unrecognized/Unsupported parameter.

===
4.2. Carrying the OF object in a PCEP message

Please capitalise the section heading.

   The OF object MAY be carried within a PCReq message. An OF object
   specifying an objective function that applies to a set of
   synchronized path computation requests MUST be carried just after the
   corresponding SVEC object
Again, there is a conditional "MUST" here. You need to say, "If an
objective function is to be applied to a set... .. the OF object MUST be
carried..."


   An OF object specifying an objective function that applies to an
   individual path computation request (non synchronized case) MUST
   follow the RP object for which it applies.
1. Your BNF shows it following, but not immediately following. I guess
   that this is exactly what you meant to write.
   Wouldn't it be better to put <OF> next to <metric-list> ?
2. I don't like the fact that the OF is sometimes here, sometimes there.
   You need to facilitate several different cases.
   a. Message contains just one request with an OF to apply
   b. Message contains several unsynchronized requests each with an OF
   c. Message contains several synchronized requests with an OF to apply
      to the set of computations
   d. Message contains several synchronized requests with an OF to apply
      to the set of computations, and the message contains one or more
      unsynchronized requests each with an OF to apply.
   It seems to me that your handling of the synchronized requests is a
   problem because it appears that you can have a separate OF for each
   request in the set, but have no way to say the OF that applies to the
   whole set.
   So, I think you need...
     <PCReq Message>::= <Common Header>
                         [ [<OF>] <SVEC-list>]
                         <request-list>
      where:
         <svec-list>::=<SVEC>
                       [<svec-list>]

         <request-list>::=<request>[<request-list>]

         <request>::= <RP>
                      <END-POINTS>
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<OF>]
                      [<metric-list>]
                      [<RRO>]
                      [<IRO>]
                      [<LOAD-BALANCING>]

   Further, this allows that you to have an OF per requests, and an
   additional OF to cover the set of synchronized requests.


Now, you also have...
      <metric-list>::=<METRIC>[<metric-list>]
This is lifted from [PCEP] and is fine. But don't you also need a
metric list for the synchronized OF?
This would yield...
     <PCReq Message>::= <Common Header>
                         [ [<OF>] [<metric-list>] <SVEC-list>]
                         <request-list>



   When the PCE wants to indicate to the PCC the objective function that
   was used for the synchronized computation of a set of paths, the
   PCRep message MUST include the corresponding SVEC object directly
   followed by the OF object
Again, the conditional use of "MUST" is confusing. Since the previous
paragraph includes "MAY", I think you can use:
s/PCRep message MUST include/PCRep message includes/


   The format of the PCRep message is updated as follows:
Same issues as for the PCReq.

And similarly, aren't some of the metrics you need to report applicable
to the set rather than the individual path? For example, minimize the
cost of the set of paths - report the cost of the set.

s/<SVEC-list>/<svec-list>/


    Note: The OF object MUST NOT be associated to a negative reply, i.e.
    a reply with a NO-PATH object.
I can see that you have other ways of conveying a negative response
related to the OF (unknown, unsupported), or the specific issues
resulting from trying to use the OF (metric, etc.).
Now, suppose the request desires (not requires) an OF, and the response
says No-Path. Shouldn't the response also say which OF was used to
produce this result?

===
4.3. New RP object flag

Please capitalise the section heading.

s/does not follow the recommendation/does not follow the request/

   Objective Function (OF) flag (1 bit): 0x200 (bit number 16)
Currently, PCEP is numbering these bits form the other ned, so this is
bit 10.

s/this indicates that the PCE has to/this indicates that the PCE MUST/

===
4.3.1. Elements of procedure

Please capitalise the section heading.

s/it MUST set/it sets/
s/the PCE has to proceed as follows/the PCE proceeds as follows/

===
5. Objective Functions definition

Please capitalise the section heading.

s/be the IGP metric the TE metric or any/be the IGP metric, the TE metric, 
or any/

===
6.1. PCE Objective Function registry
s/registry/Sub-Registry/

   The guidelines (using terms defined in [RFC2434]) for the
   assignment of objective function code point values are as follows:

/Function code value in the range 1-32767/Function code values in the range 
1-32767/

===
6.2. PCEP code points

Please capitalise the section heading.
===
6.2.3. PCEP Error values

Please capitalise the section heading.

See comment for section 4.1.1
===
6.2.4. RP Object flag

Please capitalise the section heading.
===
7.                    Security Considerations

Ecessive tabs!
===
8.2. Information and Data Models

   The PCEP MIB Module defined in [PCEP-MIB] MUST be extended to include
   Objective Functions.
MUST or SHOULD?
===
8.5. Requirements on other protocols

Please capitalise the section heading.
===
8.6. Impact on network operations

Please capitalise the section heading.
===
10.1. Normative references

Please capitalise the section heading.

   [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
   RFC 2740, December 1999.
Unused reference

   [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
   Extensions to OSPF Version 2", RFC 3630, September 2003.
Unused reference

   [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic
   Engineering", RFC 3784, June 2004.
Unused reference
===
10.2. Informative references

Please capitalise the section heading.

   RFC4674, October 2006.

===
11. Author's Addresses:
s/Author's Addresses:Authors' Addresses/
===


_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce