[Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

[JP Vasseur <[e-mail]>]

> Dear WG,
> 
> Please find below the changes in the revision 10 of PCEP. Special thanks to
> Adrian who made a very detailed review.
> 
> 
> 1) Lots of edits, clarifications, ....
> 2) Figure 1 was a bit ambiguous, thus we slightly changed it to reflect the
> fact that the first message sent after the establishment of a PCEP session is
> always an Open message as stated in several sections including the FSM.
> 3) We clarified in the FSM that in OpenWait state, the reception of a non Open
> object triggered an error condition
> 4) Clarification:
> OLD: Error-Type=1 Error-value=1: reception of a malformed message
> NEW: Error-Type=1 Error-value=1: reception of an invalid Open message or
>                   a non Open message.
> 5) figure 6: example of PCErr has been changed (Policy violation => non
> supported object).
> 6) Clarification on PCErr
> OLD TEXT: PCEP Error messages are sent when a protocol error condition is met
> (e.g. unknown object, non supported object, policy violation, ...).
> 
> NEW TEXT: The PCEP Error message (also referred to as a PCErr message) is sent
> in several situations: when a protocol error condition is met or when the
> request is not compliant with the PCEP specification (e.g., reception of a
> malformed message, reception of a message with a mandatory missing object,
> policy violation, unexpected message, unknown request reference, ...).
> 
> 7) BNF Change for PCEReq
> 
> OLD:
> <PCReq Message>::= <Common Header>
>                    [<SVEC-list>]
>                    <request-list>
> 
> where:
>    <svec-list>::=<SVEC>[<svec-list>]
>    <request-list>::=<request>[<request-list>]
>    
>    <request>::= <RP>
>                 <END-POINTS>
>                 [<LSPA>]
>                 [<BANDWIDTH>]
>                 [<BANDWIDTH>]
>                 [<metric-list>]
>                 [<RRO>]
>                 [<IRO>]
>                 [<LOAD-BALANCING>]
> where: 
> 
> <metric-list>::=<METRIC>[<metric-list>]
> 
> NEW:
> <PCReq Message>::= <Common Header>
>                    [<SVEC-list>]
>                    <request-list>
> 
> where:
>    <svec-list>::=<SVEC>[<svec-list>]
>    <request-list>::=<request>[<request-list>]
>    
>    <request>::= <RP>
>                 <END-POINTS>
>                 [<LSPA>]
>                 [<BANDWIDTH>]
>                 [<metric-list>]
>                 [<RRO>[<BANDWIDTH>]]
>                 [<IRO>]
>                 [<LOAD-BALANCING>]
> where: 
> 
> <metric-list>::=<METRIC>[<metric-list>]
> 
> 8) Text added in section 6.8: If more than one CLOSE object is present, the
> first MUST be processed and subsequent objects ignored.
> 
> 9) In several places:
> 
> OLD: Unassigned flags MUST be set to zero on transmission.
> 
> OLD: Unassigned flags MUST be set to zero on transmission and MUST be ignored
> on receipt.
> 
> 10) Keepalive timer=0 condition.
> 
> OLD: DeadTimer (8 bits): specifies the amount of time after the expiration of
> which the PCEP peer can declare the session with the sender of the Open
> message down if no PCEP message has been received. The DeadTimer MUST be set
> to 0 if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4
> times the value of the Keepalive.
> 
> NEW:
> DeadTimer (8 bits): specifies the amount of time after the expiration of which
> the PCEP peer can declare the session with the sender of the Open message down
> if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and
> MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the
> DeadTimer is 4 times the value of the Keepalive.
> 
> 
> 11) SID: Text added: " There is one SID number in each direction."
> 
> 12) 
> 
> OLD: The PCNtf message MUST carry at least one NOTIFICATION object and may
> contain several NOTIFICATION objects
> 
> NEW: The PCNtf message MUST carry at least one NOTIFICATION object and MAY
> contain several NOTIFICATION objects
> 
> 13) Clarification
> 
> The PCEP Error message (also referred to as a PCErr message) is sent in
> several situations: when a protocol error condition is met or when the request
> is not compliant with the PCEP specification (e.g., reception of a malformed
> message, reception of a message with a mandatory missing object,  policy
> violation, unexpected message, unknown request reference, ...).
> 
> 14) BNF of PCErr fixed
> 
> Suppose I want to report three error conditions:
>    a. Requests 1 and 2 with errors p and q
>    b. Unassociated errors r and s
>    c. Request 3 with error t
>    If I report them in this order, it will appear that errors r and s
>    apply only to requests 1 and 2
>    I am forced to report condition b before conditions a or c.
> 
> 
> BNF of PCErr fixed:
> 
> OLD
> 
> <PCErr Message> ::= <Common Header>
>                     <error-list>
>                     [<Open>]
>                  
> <error-list>::=<error>[<error-list>]
> <error>::=[<request-id-list>]
>            <error-obj-list>
>           
> <request-id-list>::=<RP>[<request-id-list>]
> 
> <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
> 
> NEW
> 
> <PCErr Message> ::= <Common Header>
>                        ( <error-object-list> [<Open>] ) | <error>
>                        [<error-list>]
> 
>    <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
>    <error>::=[<request-id-list>]
>               <error-obj-list>
>    <request-id-list>::=<RP>[<request-id-list>]
>    <error-list>::=<error>[<error-list>]
> 
> 
> 15) Clarification
> 
> OLD:
> 
>  o  P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
>       specify in a PCReq message sent to a PCE whether the object must
>       be taken into account by the PCE during path computation or is
>       just optional.  When the P flag is set, the object MUST be taken
>       into account by the PCE. Conversely, when the P flag is cleared,
>       the object is optional and the PCE is free to ignore it if not
>       supported.
> 
> NEW:
> 
>  o  P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
>       specify in a PCReq message sent to a PCE whether the object must
>       be taken into account by the PCE during path computation or is
>       just optional.  When the P flag is set, the object MUST be taken
>       into account by the PCE. Conversely, when the P flag is cleared,
>       the object is optional and the PCE is free to ignore it.
> 
> Could be because not supported, or easier to handle the request this way, ...
> 
> 16) Slightly new format for the RP object:
> 
> OLD:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Reserved   |               Flags               |O|B|R| Pri |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Request-ID-number                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    //                      Optional TLV(s)                        //
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> NEW:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Flags                      |O|B|R| Pri |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Request-ID-number                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    //                      Optional TLV(s)                        //
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> 
> 17) 
> 
> OLD: The ability of a PCE to support request prioritization may be dynamically
> discovered by the PCCs by means of PCE capability discovery.
> 
> NEW: The ability of a PCE to support request prioritization MAY be dynamically
> discovered by the PCCs by means of PCE capability discovery.
> 
> 18)
> 
> In the case of a reoptimization, text has been added to indicate that the RRO
> but also the BANDWIDTH of the existing TE LSP MUST be supplied.
> 
> 19) 
> 
> OLD:
> The same Request-ID-number may be used for path computation requests sent to
> different PCEs.
> 
> NEW:
> The same Request-ID-number MAY be used for path computation requests sent to
> different PCEs.
> 
> 20)
> 
> A registry has been created in the IANA section for the Nature of Issue field
> (NI) present in the NO-PATH object.
> 
> 21) 
> 
> Flags/Field in the NO-PATH object.
> 
> OLD
> When the C bit is set, the NI field value MUST be 0x00.
> 
> NEW
> The C flag has no meaning and is ignored unless the NI field is set to 0x00
> 
> 22) 
> 
> A registry has been created in the IANA section for T fied (Type) and the Flag
> field of the METRIC Object.
> 
> 23)
> 
> A registry has been created in the IANA section for Flag field of the RP
> Object 
> 
> 24) Text changed for the METRIC object.
> 
> OLD
> 
>    In a PCReq message the presence of multiple METRIC objects can be
>    used to specify a multi-parameters (e.g. a metric may be a constraint
>    or a parameter to minimize/maximize) objective function or multiple
>    bounds for different constraints where at most one METRIC object must
>    be used to indicate the metric to optimize (B-flag is cleared): the
>    other METRIC object MUST be used to reflect bound constraints (B-Flag
>    is set).  If a PCReq message is received that contains two METRIC
>    objects with the B flag set, the receiving peer MUST send a PCErr
>    message with Error-type=10 and Error-value=2.
> 
> Adrian> The two paragraphs above are on the same material but may contradict.
>    You need to allow:
>    - multiple objects each with a different metric type
>    - declare a rule if there are two with the same type
>    Why would you allow two with the same type one with the B flag set
>    and one without? You cannot both minimize and only minimize below a
>    bound.
> 
> JP> You can ... "Find the minimum TE cost but it has to be below X
> (constraint).
> 
>    Conversely, why do you prohibit a slution that minimizes more than
>    one metric? Of course, sometimes that can't be solved (conflicting
>    constraints), but sometimes it can be used to select between equal
>    cost paths. The way to resolve the contention, is to give the metrics
>    priorities, but that is cutting into the objective function
>    definitions. Therefore, the correct answer is to allow multiple
>    metric objects with the B flag set, and allow the objective function
>    to decide whether to reject the case, or to process it.
> 
> JP> Yes indeed. Furthermore we could have more than two METRIC
> object with the B Flag set (multiple bounds) and we could have the same
> METRIC object twice with different values for the B-Flag.
> 
> NEW TEXT:
> 
> We removed: " In a PCReq message the presence of multiple METRIC objects can
> be used to specify a multi-parameters (e.g. a metric may be a constraint or a
> parameter to minimize/maximize) objective function or multiple bounds for
> different constraints where at most one METRIC object must be used to indicate
> the metric to optimize (B-flag is cleared): the other METRIC object MUST be
> used to reflect bound constraints (B-Flag is set). If a PCReq message is
> received that contains two METRIC objects with the B flag set, the receiving
> peer MUST send a PCErr message with Error-type=10 and Error-value=2."
> 
> We added: "The presence of two METRIC objects of the same type with a
> different value of the B-Flag in a PCEReq message is allowed. Furthermore, it
> is also allowed to insert in a PCReq message two METRIC objects with the same
> type that have both their B-Flag cleared: in this case, an objective function
> must be used by the PCE to solve a multi-parameter constraint problem."
> 
> The following Error-value has been removed:
> 
> 10         Reception of an invalid object
>                Error-value=2: reception of a PCReq message with two METRIC
>                objects with B-flag set.
> 
> 25)
> 
> We have renamed RRO: Route Record Object => Reported Route Object
> 
> 26)
> 
> Clarification added:
> 
> OLD: Subobjects The IRO is made of sub-object(s) identical to the ones
>    defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs.
> 
> NEW: Subobjects The IRO is made of sub-object(s) identical to the ones
>    defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject type
> is identical to the subobject type defined in the related documents.
> 
> 27) Text Changed:
> 
>    In Section 7.13 (SVEC) we had: " When a PCE receives a path computation
>    request that cannot be satisfied (for example because the PCReq
>    message contains an object with the P bit set that is not supported),
>    the PCE sends a PCErr message for this request (see Section 7.2, the
>    PCE MUST cancel the whole set of related path computation requests
>    and MUST send a PCErr message with Error-Type="Synchronized path
>    computation request missing"."
> 
> Then in section 7.14:
> 
>          Notification-type=1 - Pending Request cancelled
>          Notification-value=2: PCE cancels a set of pending request(s).
>          A Notification-type=1, Notification-value=2 indicates that the
>          PCE wants to inform a PCC of the cancellation of a set of
>          pending request(s).  Such event could be triggered because of
>          PCE overloaded state or because of missing path computation
>          requests that are part the set of synchronized path computation
>          requests.
> 
> In case of a missing request listed in the SVEC we want to rely on a PCErr
> only.
> 
> Furthermore we have defined another Notificaton-Type for PCE Overloaded state
> (Notification-type=2: Overloaded PCE).
> 
> So we changed the text in the following way:
> 
> OLD: 
> o  Notification-type=1: Pending Request cancelled
> Notification-value=2: PCE cancels a set of pending request(s).
> A Notification-type=1, Notification-value=2 indicates that the
> PCE wants to inform a PCC of the cancellation of a set of
> pending request(s).  Such event could be triggered because of
> PCE overloaded state or because of missing path computation
> requests that are part the set of synchronized path computation
> requests.  A NOTIFICATION object with Notification-type=1,
> Notification-value=2 is carried within a PCNtf message sent by
> a PCE to a PCC.  The RP object corresponding to the cancelled
> request MUST also be present in the PCNtf message.  Multiple RP
> objects may be carried within the PCNtf message in which case
> the notification applies to all of them.  If such notification
> is received by a PCE from a PCC, the PCE MUST silently ignore
> the notification and no errors should be generated.
> 
> NEW:
> o  Notification-type=1: Pending Request cancelled
> Notification-value=2: PCE cancels a set of pending requests. A
> Notification-type=1, Notification-value=2 indicates that the PCE wants to
> inform a PCC of the cancellation of a set of pending requests. A NOTIFICATION
> object with Notification-type=1, Notification-value=2 is carried within a
> PCNtf message sent by a PCE to a PCC. The RP object corresponding to the
> cancelled request MUST also be present in the PCNtf message. Multiple RP
> objects may be carried within the PCNtf message in which case the notification
> applies to all of them. If such notification is received by a PCE from a PCC,
> the PCE MUST silently ignore the notification and no errors should be
> generated.
> 
> Indeed for the SVEC case, we use PCErr, and for the PCE overloaded case, we
> use Notification-type=2, Notification-value=1.
> 
> 28)  MUST => SHOULD
> 
> OLD:
> Notification-value=2: A Notification-type=2, Notification-value=2 indicates
> that the PCE is no longer in congested state and is available to process new
> path computation requests. An implementation MUST make sure that a PCE sends
> such notification to every PCC to which a Notification message (with
> Notification-type=2, Notification-value=1) has been sent unless an
> OVERLOADED-DURATION TLV has been included in the corresponding message and the
> PCE wishes to wait for the expiration of that period of time before receiving
> new requests. 
> 
> NEW: 
> Notification-value=2: A Notification-type=2, Notification-value=2 indicates
> that the PCE is no longer in congested state and is available to process new
> path computation requests. An implementation SHOULD make sure that a PCE sends
> such notification to every PCC to which a Notification message (with
> Notification-type=2, Notification-value=1) has been sent unless an
> OVERLOADED-DURATION TLV has been included in the corresponding message and the
> PCE wishes to wait for the expiration of that period of time before receiving
> new requests. 
> 
> A PCE may intentionally not willing to share its cleared overloaded state to
> some PCCS. 
> 
> 29)
> 
> We removed (see RFC5088 and RFC5089):
> 
> Alternatively, PCE may decide to signal its (non) overloaded
>          state using a IGP-based notification mechanism as defined in
>          [I-D.ietf-pce-disco-proto-isis]and
>          [I-D.ietf-pce-disco-proto-ospf].  A PCE may also decide to
>          signal its overloaded state using PCEP and its no longer
>          overloaded state using an IGP-based notification and vice-
>          versa.
> 
> 30)
> 
> OLD:
> 10         Reception of a malformed object
>               Error-value=1: reception of an object with P flag not set
>                              although the P-flag must be set according to
>                              this specification.
>                Error-value=2: reception of a PCReq message with two METRIC
>                               objects with B-flag set.
> 
> NEW:
> 10         Reception of an invalid object
>                Error-value=1: reception of an object with P flag not set
>                               although the P-flag must be set according to
>                               this specification.
>                
> 
> 31) Text Added in the IANA section:
> 
> The allocation policy for each new registry is by IETF Consensus: new values
> are assigned through the IETF consensus process (see [RFC2434]). Specifically,
> new assignments are made via RFCs approved by the IESG. Typically, the IESG
> will seek input on prospective assignments from appropriate persons (e.g., a
> relevant Working Group if one exists).
> 
> 
> Thanks.
> 
> JP, JL et al.
> 
> 
> ------ Forwarded Message
>> From: <[e-mail]>
>> Reply-To: <[e-mail]>
>> Date: Mon, 11 Feb 2008 12:15:02 -0800 (PST)
>> To: <[e-mail]>
>> Cc: <[e-mail]>
>> Subject: I-D Action:draft-ietf-pce-pcep-10.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Path Computation Element Working Group of
>> the 
>> IETF.
>> 
>> 
>> Title           : Path Computation Element (PCE) Communication Protocol
>> (PCEP)
>> Author(s)       : A. Ayyangar, et al.
>> Filename        : draft-ietf-pce-pcep-10.txt
>> Pages           : 76
>> Date            : 2008-02-11
>> 
>> This document specifies the Path Computation Element Communication
>> Protocol (PCEP) for communications between a Path Computation Client
>> (PCC) and a Path Computation Element (PCE), or between two PCEs.
>> Such interactions include path computation requests and path
>> computation replies as well as notifications of specific states
>> related to the use of a PCE in the context of Multiprotocol Label
>> Switching (MPLS) and Generalized (GMPLS) Traffic Engineering.  PCEP
>> is designed to be flexible and extensible so as to easily allow for
>> the addition of further messages and objects, should further
>> requirements be expressed in the future.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-10.txt
>> 
>> To remove yourself from the I-D Announcement list, send a message to
>> [e-mail] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>> 
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-ietf-pce-pcep-10.txt".
>> 
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> Internet-Drafts can also be obtained by e-mail.
>> 
>> Send a message to:
>> [e-mail].
>> In the body type:
>> "FILE /internet-drafts/draft-ietf-pce-pcep-10.txt".
>> 
>> NOTE:   The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility.  To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command.  To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2008-02-11120708.I-D\@ietf.org>
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> http://www.ietf.org/mailman/listinfo/i-d-announce
> 
> ------ End of Forwarded Message

------ End of Forwarded Message

_______________________________________________
Pce mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pce