[Pce] PCEP Rev -08
JP Vasseur <jvasseur@cisco.com> Fri, 06 July 2007 20:28 UTC
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uPg-0003BW-4D; Fri, 06 Jul 2007 16:28:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uPe-0003BR-LQ for pce@ietf.org; Fri, 06 Jul 2007 16:28:22 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6uPa-0005Pg-2E for pce@ietf.org; Fri, 06 Jul 2007 16:28:22 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 16:28:18 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FABdCjkZAZnmf/2dsb2JhbACCLzU
X-IronPort-AV: i="4.16,509,1175486400"; d="scan'208,217"; a="125409070:sNHT54671874"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l66KSHLq016083; Fri, 6 Jul 2007 16:28:17 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l66KSH6a029072; Fri, 6 Jul 2007 20:28:17 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 16:28:17 -0400
Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 16:28:16 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
To: pce@ietf.org
Message-Id: <05CA233A-A902-4C1A-AF13-5EB4C08DEFA0@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
Date: Fri, 06 Jul 2007 16:27:45 -0400
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 06 Jul 2007 20:28:16.0521 (UTC) FILETIME=[2F122F90:01C7C00C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11732; t=1183753697; x=1184617697; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20PCEP=20Rev=20-08 |Sender:=20 |To:=20pce@ietf.org; bh=Y/NV41KdbanHhY5iFEurFHjQnW8qjGQNJ7E/k9VJtzg=; b=z/kvpg9ROu4auoje2E1VqQklb/evBCgJNOlHjyjgj5v/ANEJDkSdmZ1QvZIDnofBT5nS+oqS 1SK5hOio6shji+bJL7u6fzXFaIWHnf3sqjBa3cT/m52we0yp+WjtoBAb;
Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.1 (/)
X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d
Cc:
Subject: [Pce] PCEP Rev -08
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1720489060=="
Errors-To: pce-bounces@lists.ietf.org
Dear WG, PCEP Rev -08 has just been posted. There are currently 9 implementations of PCEP. The protocol is stable and we're moving towards the last set of revisions, so do not hesitate to provide feed-back. The plan is probably to have 1-2 more revisions before asking for LC. Please find below the changes made in PCEP Rev -08. 1) RFC2119 language removed from the "Architectural Protocol Overview" section, 2) In section 4 and section 6.3, note added to mention that Keepalive messages are optional, 3) Terminology: use of the term "Overloaded PCE" rather than "Congested PCE" to be consistent with the PCE Discovery IDs 4) Section 6 Similarly to the previous case, if such constraint cannot be taken into account by the PCE, this should trigger an Error message. Changed for "... this MUST trigger ..." 5) PCReq BNF corrected to allow for 2 BANDWIDTH objects (potentially required during a reoptimization event in case of bandwidth changes). 6) The BNF of the PCReq message has been fixed since in its previous form the PCRep message has to comprise an ERO even in the case of negative reply if the PCE wanted to provide the list of unsatisfied constraints. 7) The text related to the DeadTimer (section 7.2) has been slightly reworded for clarity + example added. 8) Section 7.3.2: OLD If the O bit of the RP message carried within a PCReq message is cleared and local policy has been configured on the PCE to not provide explicit path(s) (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-type is "Policy Violation" and Error-value is "O bit set". NEW If the O bit of the RP message carried within a PCReq message is cleared and local policy has been configured on the PCE to not provide explicit path(s) (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-type is "Policy Violation" and Error-value is "O bit cleared". 9) Section 7.7 (text added in bold) - There MUST be at most one instance of the METRIC object for each metric type with the same B flag value - In a PCRep message, unless not allowed by PCE policy, at least one METRIC object MUST be present that reports the computed path cost in particular if the C bit of the METRIC object was set in the corresponding path computation request (the B-flag MUST be cleared); optionally the PCRep message MAY contain additional METRIC objects that correspond to bound constraints, in which case the metric-value MUST be equal to the corresponding path metric cost (the B-flag MUST be set). If no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object to indicate the constraint metric that could be satisfied. 10) Section 7.13 New text: Alternatively, PCE may decide to signal its (non) overloaded state using a IGP-based notification mechanism as defined in draft-ietf-pce- disco-proto-isis-06.txt and in draft-ietf-pce-disco-proto- ospf-06.txt. A PC E may also decide to signal its overloaded state using PCEP and its no longer overloaded state using an IGP-based notification and vice-versa. 11) Section 7.16 Reason 3: PCEP session characteristics negotiation failure has been removed since we now send a PCErr message in case of session characteristic negotiation failure. 12) Changes to the FSM * The values of the OpenWait variable have been changed to allow for max 1 failed attempts * Minor change to when the OpenWait and KeepWait timer are started (when entering a new state rather than leaving a state) * Edits 13) Appendix A has been removed 14) CLOSE Object has been added to the IANA section 15) New Error-Type=1, Error-value=8: PCEP version not supported 16) References Informational RFCs were reference as normative => informative Reference to RFC2406 updated to RFC4303 17) Various typos, editorial nits. Thanks. JP.
_______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce
- [Pce] PCEP Rev -08 JP Vasseur
- [Pce] Fwd: PCEP Rev -08 JP Vasseur