[Pce] Fwd: PCEP Rev -08

[JP Vasseur <[e-mail]>]

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 <[e-mail]>
> Date: July 6, 2007 4:27:45 PM EDT
> To: [e-mail]
> Cc: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@orange- 
> ftgroup.com>, Adrian Farrel <[e-mail]>
> Subject: PCEP Rev -08
>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce