Subject: [Pce] PCEP Rev -08

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Jul 2007 16:27:45 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Jul 2007 15:41:35 -0400

Hi,

Just noticed that I did not indicate another change related to the NO- 
PATH object. We added a new field used to
report the nature of the issue. Two values are currently defined:
	0x00: No path satisfying the set of constraints could be found
	0x01: PCE chain broken

Then as before the optional NO-PATH-VECTOR TLV can be added for more  
detailed information.

Thanks.

JP.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: July 6, 2007 4:27:45 PM EDT
> To: [email-masked]
> Cc: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@orange- 
> ftgroup.com>, Adrian Farrel <[email-masked]>
> Subject: PCEP Rev -08
>
> Dear WG,
>
> 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.
>
> 2) In section 4 and section 6.3, note added to mention that  
> Keepalive messages are optional,
>
> 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
>
> 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
>
> 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".
>
> - 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:
>
> using a IGP-based notification mechanism as defined in draft-ietf- 
> pce-disco-proto-isis-06.txt and in draft-ietf-pce-disco-proto- 
> 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