[Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
JP Vasseur <jvasseur@cisco.com> Thu, 21 February 2008 16:49 UTC
Return-Path: <pce-bounces@ietf.org>
X-Original-To: ietfarch-pce-archive@core3.amsl.com
Delivered-To: ietfarch-pce-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A15428CA86; Thu, 21 Feb 2008 08:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrjRjwIdYGNt; Thu, 21 Feb 2008 08:49:44 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D67A28C958; Thu, 21 Feb 2008 08:49:42 -0800 (PST)
X-Original-To: pce@core3.amsl.com
Delivered-To: pce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95CC28C3E7 for <pce@core3.amsl.com>; Mon, 11 Feb 2008 12:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W3--3OQ-h8l for <pce@core3.amsl.com>; Mon, 11 Feb 2008 12:31:02 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3117228C5DF for <pce@ietf.org>; Mon, 11 Feb 2008 12:30:48 -0800 (PST)
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Feb 2008 15:32:13 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1BKW66c027357 for <pce@ietf.org>; Mon, 11 Feb 2008 15:32:06 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1BKVhIW027536 for <pce@ietf.org>; Mon, 11 Feb 2008 20:32:06 GMT
Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 15:31:50 -0500
Received: from 10.86.104.178 ([10.86.104.178]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Feb 2008 20:31:01 +0000
User-Agent: Microsoft-Entourage/11.3.6.070618
Date: Mon, 11 Feb 2008 15:30:56 -0500
From: JP Vasseur <jvasseur@cisco.com>
To: pce@ietf.org
Message-ID: <C3D61AB1.2642C%jvasseur@cisco.com>
Thread-Topic: I-D Action:draft-ietf-pce-pcep-10.txt
Thread-Index: Achs7QEBP2y3ldjgEdyfQwANk8WjQA==
In-Reply-To: <20080211201502.1346228C234@core3.amsl.com>
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3285588658_4159770"
X-OriginalArrivalTime: 11 Feb 2008 20:31:50.0504 (UTC) FILETIME=[217E6680:01C86CED]
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Mailman-Approved-At: Thu, 21 Feb 2008 08:49:38 -0800
Subject: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
Sender: pce-bounces@ietf.org
Errors-To: pce-bounces@ietf.org
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: <Internet-Drafts@ietf.org> > Reply-To: <internet-drafts@ietf.org> > Date: Mon, 11 Feb 2008 12:15:02 -0800 (PST) > To: <i-d-announce@ietf.org> > Cc: <pce@ietf.org> > 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 > i-d-announce-request@ietf.org 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: > mailserv@ietf.org. > 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 > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce ------ End of Forwarded Message
_______________________________________________ Pce mailing list Pce@ietf.org http://www.ietf.org/mailman/listinfo/pce
- [Pce] I-D Action:draft-ietf-pce-pcep-10.txt Internet-Drafts
- [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt JP Vasseur
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… Fabien VERHAEGHE
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… Fabien VERHAEGHE
- [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt JP Vasseur
- [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt JP Vasseur
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… JP Vasseur
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… Fabien VERHAEGHE
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… JP Vasseur
- Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.t… Fabien VERHAEGHE