Subject: Re: [Pce] Quesitons about OF draft

From: <[email-masked]>
Date: Wed, 23 Apr 2008 08:16:46 +0200

Hi Adrian

Thanks for these comments

Please see inline 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Adrian Farrel
> Envoyé : mardi 1 avril 2008 15:45
> À : [email-masked]
> Objet : [Pce] Quesitons about OF draft
> 
> 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.

OK will be done

> ===
> 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.

OK

> ===
> 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.

OK

> ===
>  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.

OK

> ===
> 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)/
> ===

OK

> 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.

Yes in that case the session must be rejected. This will be mentionned.

> 
> 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.

OK

> 
> 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"?

OK

> ===
> 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.

OK

> 
> 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.

OK

> 
> 
>         - 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.

OK

> 
>         - 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.

OK

> 
> ===
> 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..."

OK

> 
> 
>    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> ?

I agree, this will be done

> 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.

Not really.

>    So, I think you need...
>      <PCReq Message>::= <Common Header>
>                          [ [<OF>] <SVEC-list>]
>                          <request-list>

No. Recall that an SVEC comprises a set of synchronized requests.
A SVEC list is a list of SVEC, that is a list of sets of synchronized requests.
We need to be able to specify an OF for each SVEC...
So I think our proposed encoding is the right one.

>       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.

This is already what we have.

> 
> 
> 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>

Right, this will be added

> 
> 
> 
>    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.

OK will be added

> 
> 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), 

If the OF is not supported this is not a negative response, this is an error.

> 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?

Strictly speaking the reason for no path is never an objective function, the reason is a constraint.

> 
> ===
> 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?

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/ ===

Thanks a lot Adrian for this detailed review

We will submit soon a new version accounting for these comments.

Regards,

JL

> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
> 
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Apr 2008 12:35:25 +0100

Hi Jean-Louis,

Many thanks for agreement on so many points.

I have cut this down to just the open points. Please see in line.

Cheers,
Adrian

>> I don't like the fact that the OF is sometimes here, sometimes
>> there.
>>    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.
>
> Not really.

:-)

> So I think our proposed encoding is the right one.

Soooo.
I was assuming that you may need:
- an OF to apply to the set of synchornized requests
- an OF to apply to each of the requests

What you appear to have is:
- an OF to apply to each synchronized request
  through the OF in the SVEC-list
- an OF to apply to each of the requests
  through the OF in the request

It seems to me that you do not have the ability to supply a meta-OF that applies to the whole SVEC-list, but you have two separate ways to supply an OF for each request.

> This is already what we have.

Well, I moved OF next to metric-list.

> Right, this will be added

Unclear whether you are accepting my assumption that metric-list should be applied to the whole SVEC-list. If so, how is this different from the OF?

> Strictly speaking the reason for no path is never an
> objective function, the reason is a constraint.

Yes, that is very true.

But, nevertheless, isn't it helpful to report the OF that was used?

---

From: <[email-masked]>
Date: Sat, 26 Apr 2008 09:27:27 +0200

Hi Adrian,

>- an OF to apply to each of the requests
 
Yes this is what we need. Maybe we need to clarify the terminology, here by "set of synchronized requests" we mean the set of requests listed in a SVEC.
 
>  through the OF in the SVEC-list
 
That is it applies to the set of synchronized requests listed in an SVEC object.

>to supply an OF for each request.
 
We have the ability to supply an OF for the set of requests listed in an SVEC object, and to supply an OF for each request. This is what is required.

>Well, I moved OF next to metric-list.
 
OK, we will do this
 
>Unclear whether you are accepting my assumption that metric-list should be applied to the whole SVEC-list. If so, how is this different from >the OF?
it should be applied to an SVEC, so we should have 
 
<svec-list> ::=<SVEC>
                        [<OF>]
                        [<metric-list>]
                        [<svec-list>]

 
>But, nevertheless, isn't it helpful to report the OF that was used?
 
We used to have it in an earlier version. Fabien asked to remove it and indeed we did not find any good reason to keep it.
Knowing the OF that was used would not really help the PCC as there is no path whatever the OF applied....
 
Kind Regards
 
JL

 

________________________________

	De : Adrian Farrel [mailto:[email-masked]] 
	Envoyé : mercredi 23 avril 2008 13:35
	À : LE ROUX Jean-Louis RD-SIRP-LAN; [email-masked]
	Objet : Re: [Pce] Quesitons about OF draft

	Hi Jean-Louis,

	 
	Cheers,
	Adrian

	:-)

	Soooo.

	 

	 

	Yes, that is very true.