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 PROTECTED]>
Date: July 6, 2007 4:27:45 PM EDT
To: [EMAIL PROTECTED]
Cc: LE ROUX Jean-Louis RD-CORE-LAN <[EMAIL PROTECTED]
ftgroup.com>, Adrian Farrel <[EMAIL PROTECTED]>
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
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
