[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