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

I also added the Diffs.

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

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