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

From: JP Vasseur <[email-masked]>
Date: Mon, 11 Feb 2008 18:03:11 -0500

> 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: <[email-masked]>
>> Reply-To: <[email-masked]>
>> Date: Mon, 11 Feb 2008 12:15:02 -0800 (PST)
>> To: <[email-masked]>
>> Cc: <[email-masked]>
>> 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
>> [email-masked] 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:
>> [email-masked].
>> 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
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/i-d-announce
> 
> ------ End of Forwarded Message

------ End of Forwarded Message

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

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Wed, 20 Feb 2008 17:08:28 +0100

Hi JP,

Here are few comments on version 10 of PCEP.

4.2.5

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

FV: If I understand correctly receipt of a malformed message is no longer an
example of PCEP error message. Malformed message is only notify using a
Close message reason 3.
If I'm correct Figure 6 should also be modified.

-----------------------------

7.8.  METRIC Object

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.

FV: I think it should be 

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
   
   **DIFFERENT** types 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.

------------------------------

PCEP Finite State Machine

Maybe I'm a little late for this comment but I'm wondering what is the
purpose of ConnectRetry timer. 
TCP already takes care of retransmissions.
Besides with a connect timer of 60s and ConnectMaxRetry of 5 it can take
like 30minutes before actually notify the PCC application that the PCEP
session establishment fails. Isn't it to long?

I would suggest at least to state that the ConnectRetry mechanism is
optional and make the connect and ConnectMaxRetry parameter configurable.

------------------------------

Requesting protecting LSP.

During implementation we went into a case where we want to establish a
working and a protecting LSP (link or node diverse).
With current specification it means we have to create 2 identical requests
associated with a SVEC.

It seems a little bit complex for such simple and regular case. Besides it
entails some unnecessary PCEP message overhead because of the duplicate
information.

I think it would make sense to add a TLV in RP object to request 1 (or more)
link/SRLG/node diverse protecting path(s).
The 2 (or n) result paths can then be inserted associated to the same RP
object in the PCRep since it is already authorized by PCRep BNF format.
Note that it may require another TLV (or a new bit) in the RP of the PCRep 
to distinguish between working and protecting path in the case that a PCC 
request a protecting path for a request that also contains a Load Balancing
object.

Note that this would partially solved some issue raised by
draft-nishioka-pce-svec-list-01.txt.

Best regards
Fabien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de JP
Vasseur
Envoyé : mardi 12 février 2008 00:03
À : [email-masked]
Objet : [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Thu, 21 Feb 2008 14:36:55 +0100

Hi JP,

Another quick comment on PCEPv10

section 7.5

The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in
section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying
the TLV length (length of the value portion in bytes) followed by a fixed
length value field of 32-bit flags field.

TYPE: To be assigned by IANA (suggested value=1)
LENGTH: 1
VALUE: 32-bit flags field

LENGTH is 4 not 1.

Best regards
Fabien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Fabien
VERHAEGHE
Envoyé : mercredi 20 février 2008 17:08
À : 'JP Vasseur'; [email-masked]
Objet : Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

Hi JP,

4.2.5

7.8.  METRIC Object

FV: I think it should be 

Best regards
Fabien

---

From: JP Vasseur <[email-masked]>
Date: Thu, 21 Feb 2008 14:01:44 -0500

Hi Fabien,

Thanks for your review - Comments in line,

> From: Fabien VERHAEGHE <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Wed, 20 Feb 2008 17:08:28 +0100
> To: 'JP Vasseur' <[email-masked]>, <[email-masked]>
> Subject: RE: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
> 
> Hi JP,
> 
> example of PCEP error message.

It is, as mentioned in the text above.

 Malformed message is only notify using a
> If I'm correct Figure 6 should also be modified.

JP> Good catch indeed, thanks.

I think that we still need the ConnecRetry mechanism on top of TCP. Whether
it should be configurable is debatable. We should be careful not to add too
many configurable timers when using a value other than the default is not
likely though.

Other opinions?

The issue with that approach is that the constraints for the primary and
secondary paths MUST be identical and there are circumstances where this is
not desirable. Thus, we need a more generic mechanism to handle those common
cases. Should the parameters be identical, do you think that the "overhead"
is so important to justify the introduction of another mechanism?

> request a protecting path for a request that also contains a Load Balancing

Which makes the processing even more complex.

If OK with I think that it is preferable to keep the current simple and
generic mechanism here.

Thanks.

JP.

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Mon, 25 Feb 2008 13:01:05 +0100

Hi JP 

Thanks for the reply.
See inline...

> De : JP Vasseur [mailto:[email-masked]]
> Envoyé : jeudi 21 février 2008 20:02
> À : [email-masked]; [email-masked]

Sorry but I'm not sure to understand your answer.
Can you confirm that we no longer send PCErr message upon receipt of a
malformed message once the session is up? 
We just send a close message reason 3.

> >    **DIFFERENT** types that have both their B-Flag cleared: in this
case,
> an

Well my opinion is that there is no interop issue in making the parameters
configurable and the whole mechanism optional.
So I guess it is really an implementation choice.
I would personally just have liked to see this mention in the draft.
But I don't see letting the text as it is as a big issue.

> is so important to justify the introduction of another mechanism?

I did not mean to replace the whole SVEC mechanism by the new proposed TLV
cause I agree with you that it is good to have such generic mechanism.

I just wanted to bring the attention to the WG about the extra overhead
problem cause I find it personally weird to duplicate the information for
such regular case.

I may be wrong but it seems to me that most of the time working and
protecting path will have the same characteristics.
So if you imagine PCE application that always request both a working and a
protecting path (e.g. PBT) you will actually double the bandwidth used by
PCEP Path Request.
And it can be more significant in case of P2MP or GCO for instance where
PCEP message may be quite large.

Anyway if the WG is Ok with that I'm obviously fine too.

> >> Please find below the changes in the revision 10 of PCEP. Special
> thanks
> > to
> >> fact that the first message sent after the establishment of a PCEP
> session
> > is
> >> 3) We clarified in the FSM that in OpenWait state, the reception of a
> non
> > Open
> >> OLD TEXT: PCEP Error messages are sent when a protocol error condition
> is
> > met
> >> NEW TEXT: The PCEP Error message (also referred to as a PCErr message)
> is
> > sent
> >> OLD: DeadTimer (8 bits): specifies the amount of time after the
> expiration
> > of
> >> 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
> >> 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
> >> Could be because not supported, or easier to handle the request this
> way,
> > ...
> >>
> >> In the case of a reoptimization, text has been added to indicate that
> the
> > RRO
> >> 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 T fied (Type) and
> the
> > Flag
> >> 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
> >> the metric to optimize (B-flag is cleared): the other METRIC object
> MUST
> > be
> >> different value of the B-Flag in a PCEReq message is allowed.
> Furthermore,
> > it
> > same
> >>    defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO
> subobject
> > type
> >> applies to all of them. If such notification is received by a PCE from
> a
> > PCC,
> >> Indeed for the SVEC case, we use PCErr, and for the PCE overloaded
case,
> > we
> >> that the PCE is no longer in congested state and is available to
> process
> > new
> >> OVERLOADED-DURATION TLV has been included in the corresponding message
> and
> > the
> >> 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
> >> OVERLOADED-DURATION TLV has been included in the corresponding message
> and
> > the
> >> A PCE may intentionally not willing to share its cleared overloaded
> state
> > to
> >> some PCCS.
> >>
> >> 29)
> >>
> >> will seek input on prospective assignments from appropriate persons
> (e.g.,
> > a
> >>> This draft is a work item of the Path Computation Element Working
> Group
> > of
> >>> the
> >>> IETF.
> >>>
> >>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 25 Feb 2008 20:24:04 -0800

Hi Fabien,

See in line and thanks for the series of useful comments that you have
provided during the protocol specification.

> Date: Mon, 25 Feb 2008 13:01:05 +0100

JP> We only clarified that PCErr were not only sent in case of protocol
errors. Back to your example, nothing has been changed:

* During the session establishment *

   If a malformed message is received, the receiving PCEP peer MUST send
   a PCErr message with Error-type=1, Error-value=1.

where:

Error-Type    Meaning
   1          PCEP session establishment failure
              Error-value=1: reception of an invalid Open message or
                             a non Open message.

* As you said, when the PCEP Session is UP *

As mentioned in the FSM:

   If a malformed message is received, the system terminates the PCEP
   session according to the procedure defined in Section 6.8, releases
   the PCEP resources for that PCEP peer, closes the TCP connection and
   moves to the Idle State.

We're in sync, in this case (PCEP Session UP), we only send a CLOSE.

The example " e.g., reception of a malformed message" is not a good one
indeed, good catch. Text changed:

OLD:
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, ...).  The Message-Type field of the PCEP
   common header is set to 6 (To be confirmed by IANA).

NEW:
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.,
   capability not supported, reception of a message with a
   mandatory missing object, policy violation, unexpected message,
   unknown request reference, ...).  The Message-Type field of the PCEP
   common header is set to 6 (To be confirmed by IANA).

> But I don't see letting the text as it is as a big issue.

The idea was to not impose the make these parameters configurable. According
to the spec they are architectural constants.

> cause I agree with you that it is good to have such generic mechanism.

Understood.

> protecting path will have the same characteristics.

That REALLY depends but I do not think that this is always the case for
sure.

> protecting path (e.g. PBT) you will actually double the bandwidth used by

With is not really an issue compared to the bandwidth used for protection in
the network ;-))

> Anyway if the WG is Ok with that I'm obviously fine too.

And I'm not saying that this would not help in some cases but .... Because
we have a generic mechanism that covers both cases, with little overhead, I
am always leaning toward the simplest most generic mechanism as opposed to
two ways to so the same thing in some cases. If it turns out that this
creates too much overhead in specific situation (e.g, large P2MP TE LSPS
with protection, ...), if needed, the extensions could be defined in another
document.

Agree?

Thanks for the careful review.

Cheers.

JP.

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Thu, 28 Feb 2008 11:03:55 +0100

Hi JP,

Thanks for the clarifications.

Best regards
Fabien

> Envoyé : mardi 26 février 2008 05:24
> À : [email-masked]
> Cc : [email-masked]
> >>> It seems a little bit complex for such simple and regular case.
> Besides
> >> it
> >> secondary paths MUST be identical and there are circumstances where
> this
> >> is
> >>>> 2) Figure 1 was a bit ambiguous, thus we slightly changed it to
> reflect
> >>> the
> >>>> 8) Text added in section 6.8: If more than one CLOSE object is
> present,
> >>> the
> >>>> if no PCEP message has been received. The DeadTimer SHOULD be set to
> 0
> >> and
> >>>> OLD: The PCNtf message MUST carry at least one NOTIFICATION object
> and
> >> may
> >>>> NEW: The PCNtf message MUST carry at least one NOTIFICATION object
> and
> >> MAY
> in
> >>>> several situations: when a protocol error condition is met or when
> the
> >>> request
> >>>> A registry has been created in the IANA section for the Nature of
> Issue
> >>> field
> >>>> The C flag has no meaning and is ignored unless the NI field is set
> to
> >>> 0x00
> >>>>
> >>>> 22)
> >>>>
> >>>> Furthermore we have defined another Notificaton-Type for PCE
> Overloaded
> >>> state
> >>>> Notification-type=1, Notification-value=2 indicates that the PCE
> wants
> >> to
> >>>> object with Notification-type=1, Notification-value=2 is carried
> within
> >> a
> >>>> path computation requests. An implementation MUST make sure that a
> PCE
> >>> sends
> >>>>                              although the P-flag must be set
> according
> >> to
> >>>>                              this specification.
> >>>>                               although the P-flag must be set
> according
> >> to
> >>>>                               this specification.
> >>>>
> >>>>
> >>>> new assignments are made via RFCs approved by the IESG. Typically,
> the
> >>> IESG

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