draft-ietf-pce-enhanced-errors-02.txt   draft-ietf-pce-enhanced-errors-03.txt 
PCE Working Group H. Pouyllau PCE Working Group H. Pouyllau
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track R. Theillaud Intended status: Standards Track R. Theillaud
Expires: January 4, 2017 Marben Products Expires: September 1, 2018 Marben Products
J. Meuric J. Meuric
France Telecom Orange France Telecom Orange
X. Zhang (Editor) H. Zheng (Editor)
X. Zhang
Huawei Technologies Huawei Technologies
July 3, 2016 February 28, 2018
Extensions to the Path Computation Element Communication Protocol for Extensions to the Path Computation Element Communication Protocol for
Enhanced Errors and Notifications Enhanced Errors and Notifications
draft-ietf-pce-enhanced-errors-02.txt draft-ietf-pce-enhanced-errors-03.txt
Abstract Abstract
his document defines new error and notification TLVs for the PCE This document defines new error and notification TLVs for the PCE
Communication Protocol (PCEP) [RFC5440]. It identifies the possible Communication Protocol (PCEP) [RFC5440]. It identifies the possible
PCEP behaviors in case of error or notification. Thus, this draft PCEP behaviors in case of error or notification. Thus, this draft
defines types of errors and notifications and how they are disclosed defines types of errors and notifications and how they are disclosed
to other PCEs in order to support predefined PCEP behaviors. to other PCEs in order to support predefined PCEP behaviors.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2017. This Internet-Draft will expire on September 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 32 skipping to change at page 2, line 33
4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6
5. PCEP Extensions for Error and Notification Handling . . . . . 6 5. PCEP Extensions for Error and Notification Handling . . . . . 6
5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7
5.3. Notification type TLV . . . . . . . . . . . . . . . . . . . 7 5.3. Notification type TLV . . . . . . . . . . . . . . . . . . . 7
5.4. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 5.4. Behaviors and TLV combinations . . . . . . . . . . . . . . 8
5.5. Propagation Restrictions Objects . . . . . . . . . . . . . 9 5.5. Propagation Restrictions Objects . . . . . . . . . . . . . 9
5.5.1. Time-To-Live Object (TTL) . . . . . . . . . . . . . . . . 10 5.5.1. Time-To-Live Object (TTL) . . . . . . . . . . . . . . . . 10
5.5.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 10 5.5.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 10
5.5.3. Rules Applied to Existing Errors and Notifications . . . 12 5.5.3. Rules Applied to Existing Errors and Notifications . . . 12
6. Error and Notification Scenarios . . . . . . . . . . . . . . 15 6. Error and Notification Scenarios . . . . . . . . . . . . . . 16
6.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15 6.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 16
6.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16 6.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 17
6.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 16 6.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 17
6.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17 6.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 18
6.5. Notification Behavior Type 1 . . . . . . . . . . . . . . . 18 6.5. Notification Behavior Type 1 . . . . . . . . . . . . . . . 19
6.6. Notification Behavior Type 2 . . . . . . . . . . . . . . . 18 6.6. Notification Behavior Type 2 . . . . . . . . . . . . . . . 19
6.7. Notification Behavior Type 3 . . . . . . . . . . . . . . . 19 6.7. Notification Behavior Type 3 . . . . . . . . . . . . . . . 20
6.8. Notification Behavior Type 4 . . . . . . . . . . . . . . . 19 6.8. Notification Behavior Type 4 . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 21
8.2. New DLO object . . . . . . . . . . . . . . . . . . . . . . 20 8.2. New DLO object . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informational References . . . . . . . . . . . . . . . . . 22 9.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Terminology 1. Terminology
PCE terminology is defined in [RFC4655]. PCE terminology is defined in [RFC4655].
PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a
PCE). PCE).
Source PCC: the PCC, for a given path computation query, initiating Source PCC: the PCC, for a given path computation query, initiating
the first PCEP request, which may then trigger a chain of successive the first PCEP request, which may then trigger a chain of successive
skipping to change at page 3, line 29 skipping to change at page 3, line 29
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Introduction 3. Introduction
The PCE Communication Protocol [RFC5440] is designed to be flexible The PCE Communication Protocol [RFC5440] is designed to be flexible
and extensible in order to allow future evolutions or specific and extensible in order to allow future evolutions or specific
constraint support such as proposed in constraint support such as proposed in [RFC7470]. Crossing different
[I-D.ietf-pce-vendor-constraints]. Crossing different PCE PCE implementations (e.g. from different providers or due to
implementations (e.g. from different providers or due to different different releases), a PCEP request may encounter unknown errors or
releases), a PCEP request may encounter unknown errors or
notification messages. In such a case, the PCEP RFC [RFC5440] notification messages. In such a case, the PCEP RFC [RFC5440]
specifies to send a specific error code to the PCEP peer. specifies to send a specific error code to the PCEP peer.
In the context of path computation crossing different routing domains In the context of path computation crossing different routing domains
or autonomous systems, the number of different PCE system or autonomous systems, the number of different PCE system
specificities is potentially high, thus possibly leading to divergent specificities is potentially high, thus possibly leading to divergent
and unstable situations. Such phenomenon can also occur in and unstable situations. Such phenomenon can also occur in
homogeneous cases since PCE systems have their own policies that can homogeneous cases since PCE systems have their own policies that can
introduce differences in requests treatment even for requests having introduce differences in requests treatment even for requests having
the same destination. In order to generalize PCEP behaviors in the the same destination. In order to generalize PCEP behaviors in the
case of heterogeneous PCE systems, new objects have to be defined. case of heterogeneous PCE systems, new objects have to be defined.
Dealing with heterogeneity is a major challenge considering PCE Dealing with heterogeneity is a major challenge considering PCE
applicability, particularly in multi-domain contexts. Thus, applicability, particularly in multi-layer and multi-domain contexts.
extending such error codes and PCEP behaviors accordingly would Thus, extending such error codes and PCEP behaviors accordingly would
improve interoperability among different PCEP implementations and improve interoperability among different PCEP implementations and
would solve some of these unstable issues. However, some of them would solve some of these issues. However, some of them would still
would still remain (e.g. the divergences in request treatment remain (e.g. the divergences in request treatment introduced by
introduced by different policies). different policies).
The purpose of this draft is to identify and specify new optional The purpose of this draft is to identify and specify new optional
TLVs and objects in order to generalize PCEP behaviors. TLVs and objects in order to generalize PCEP behaviors.
3.1. Examples 3.1. Examples
The two following scenarios underline the need for a normalization of The two following scenarios underline the need for a normalization of
the PCEP behaviors according to existing error or notification types. the PCEP behaviors according to existing error or notification types.
3.1.1. Error use-case 3.1.1. Error use-case
skipping to change at page 10, line 32 skipping to change at page 10, line 30
5.5.2. DIFFUSION-LIST Object (DLO) 5.5.2. DIFFUSION-LIST Object (DLO)
The DIFFUSION-LIST Object can be carried within a PCErr and a PCNtf The DIFFUSION-LIST Object can be carried within a PCErr and a PCNtf
message and can either be used in a message sent by a PCC to a PCE or message and can either be used in a message sent by a PCC to a PCE or
vice versa. The DLO MAY be used with propagated errors (TLV vice versa. The DLO MAY be used with propagated errors (TLV
"Propagation"at value 1 in PCEP-ERROR object) and request-specific "Propagation"at value 1 in PCEP-ERROR object) and request-specific
propagated notifications (i.e., "Notification Behavior Type 4"). propagated notifications (i.e., "Notification Behavior Type 4").
Furtheremore, it MUST be used with non request-specific propagated Furtheremore, it MUST be used with non request-specific propagated
notifications (i.e., "Notification Behavior Type 3"). notifications (i.e., "Notification Behavior Type 3").
DIFFUSION-LIST Object-Class is 25. DIFFUSION-LIST Object-Class is TBD (Suggested 41).
DIFFUSION-LIST Object-Type is 1. DIFFUSION-LIST Object-Type is 1.
The format of the DIFFUSION-LIST object body is as follows: The format of the DIFFUSION-LIST object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Target-type | | Reserved | Flags | Target-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 11 skipping to change at page 12, line 9
for any forwarded messages. Hence, a PCE SHOULD avoid forwarding the for any forwarded messages. Hence, a PCE SHOULD avoid forwarding the
same message repeated to the same set of peers. Finally, when an same message repeated to the same set of peers. Finally, when an
address is loose, the forwarding SHOULD be restrained indicating what address is loose, the forwarding SHOULD be restrained indicating what
type of PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a type of PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a
Target-Type is specified. Target-Type is specified.
5.5.3. Rules Applied to Existing Errors and Notifications 5.5.3. Rules Applied to Existing Errors and Notifications
Many existing normative references states on error definitions (see Many existing normative references states on error definitions (see
for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557], for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557],
[RFC5886], [RFC6006]). According to the definitions provided in this [RFC5886], [RFC6006], [RFC8231], [RFC8232],[RFC8253], [RFC8281],
document, the follwoing rules are applicable: [RFC8306], [I-D.ietf-pce-lsp-setup-type],
[I-D.ietf-pce-association-group]). According to the definitions
provided in this document, the follwoing rules are applicable:
Error-type 1, described in [RFC5440], relates to PCEP session Error-type 1, described in [RFC5440], relates to PCEP session
establishement failures. All errors of this type are local (not establishement failures. All errors of this type are local (not
to be propagated). Hence, if a "Propagation" TLV is added to the to be propagated). Hence, if a "Propagation" TLV is added to the
error message it MUST be set to value 0. Error-values 1,2,6,7 error message it MUST be set to value 0. Error-values 1,2,6,7
have a high level of criticality. Hence, if the "Error- have a high level of criticality. Hence, if the "Error-
criticality" TLV is included within a PCErr message of type 1 and criticality" TLV is included within a PCErr message of type 1 and
value 1,2,6 or 7, it MUST have a value of 2. value 1,2,6 or 7, it MUST have a value of 2.
Error-type 2,3,4, "Capability not supported", "Unknown object" and Error-type 2,3,4, "Capability not supported", "Unknown object" and
skipping to change at page 14, line 39 skipping to change at page 14, line 39
be cancelled. But, as messages are fragmented, it is natural to be cancelled. But, as messages are fragmented, it is natural to
think that the PCE should wait at least a bit for further think that the PCE should wait at least a bit for further
messages. The "Error-criticality" TLV MAY be included in such messages. The "Error-criticality" TLV MAY be included in such
error messages and is particularly adapted to differ the semantic error messages and is particularly adapted to differ the semantic
of the same error-type message: if it is included with a value of of the same error-type message: if it is included with a value of
0 then the PCE will still wait for further fragmented messages, 0 then the PCE will still wait for further fragmented messages,
when this waiting time ends, the TLV can be included with a value when this waiting time ends, the TLV can be included with a value
of 1 in order to finally cancel the request. The "Propagation" of 1 in order to finally cancel the request. The "Propagation"
TLV MAY also be used with such errors. TLV MAY also be used with such errors.
Error-type 19 of "Invalid Operation" is described in [RFC8231] and
[RFC8281], which implies a wrong capability description for PCEP
session. In this case, the PCErr message MUST be returned to PCC,
and this message should contain a "Propagation" TLV and a
DIFFUSION-LIST object with a Target-Type of 0 or 2. The "Error-
criticality" TLV should be set to 2 in order to guanrantee the
termination of PCEP session.
Error-type 20 of "LSP State Synchronization Error" is described in
[RFC8231] and [RFC8232], which cannot successfully sync up the LSP
states. In this case, the "Error-criticality" TLV should be set
to 2 in order to guanrantee the termination of PCEP session. The
"Propagation" TLV MAY also be used with such errors.
Error-type 21 of "Invalid traffic engineering path setup type" is
described in [I-D.ietf-pce-lsp-setup-type] . Such errors failed to
find a matched path setup type and the PCEP sessions MUST be
closed. In this case, the "Error-criticality" TLV should be set
to 2 in order to guanrantee the termination of PCEP session. The
"Propagation" TLV MAY also be used with such errors.
Error-type 23 of "Bad parameter value" is described in [RFC8281] .
Such errors occur when there is a conflict in path name of C flag
not set for PCE initiation. In this case, the "Error-criticality"
TLV may be set to either 0 or 1 to indicate whether the request is
still valid, with the PCEP session open. The "Propagation" TLV
MAY also be used with such errors.
Error-type 24 of "LSP instantiation error" is described in
[RFC8281] . Such errors occur when PCC detects problems when
establishing the path, the message MUST relay to the PCE,
therefore the "Propogation" TLV must be contained. The "Error-
criticality" TLV may be set to either 0 or 1 to indicate whether
the request is still valid, with the PCEP session open.
Error-type 25 of "PCEP StartTLS failure" is described in
[RFC8253]. Such errors indicate the security issue in transport
layer. In this case, the "Error-criticality" TLV should be set to
2 in order to close the PCEP session. The "Propagation" TLV MAY
also be used with such errors, depending on the detailed security
conditions.
Error-type 26 of "Association Error " is described in
[I-D.ietf-pce-association-group] . Such errors occur when there is
problem for LSP association. In this case, the "Error-
criticality" TLV should be set to either 0 or 1 to indicate
whether the request is still valid, with the PCEP session open.
The "Propagation" TLV MAY also be used with such errors.
Among the existing normative references, only the [RFC5440] defines Among the existing normative references, only the [RFC5440] defines
some notification-types and values. The recommendations with respect some notification-types and values. The recommendations with respect
to the TLVs definitions provided in this document are the followings: to the TLVs definitions provided in this document are the followings:
Notitification-type=1, Notification-value=1 or 2: a PCC, Notitification-type=1, Notification-value=1 or 2: a PCC,
respectively a PCE, cancels a set of pending requests, such a respectively a PCE, cancels a set of pending requests, such a
notification SHOULD be propagated to the list of PCEP peers which notification SHOULD be propagated to the list of PCEP peers which
were implied in the path computation requests. Hence, the were implied in the path computation requests. Hence, the
NOTIFICATION object SHOULD contains the "Propagation" TLV with NOTIFICATION object SHOULD contains the "Propagation" TLV with
value 1 and the "Notification Type" TLV with value 1, together value 1 and the "Notification Type" TLV with value 1, together
skipping to change at page 20, line 28 skipping to change at page 21, line 28
IANA is requested to make an allocation from the sub-registry as IANA is requested to make an allocation from the sub-registry as
follows. The values here are suggested for use by IANA. follows. The values here are suggested for use by IANA.
8.1. PCEP TLV Type Indicators 8.1. PCEP TLV Type Indicators
As described in Section 5.5 the newly defined TLVs allows a PCE to As described in Section 5.5 the newly defined TLVs allows a PCE to
enforce specific error and notification behaviors within PCEP-ERROR enforce specific error and notification behaviors within PCEP-ERROR
and NOTIFICATION objects. IANA is requested to make the following and NOTIFICATION objects. IANA is requested to make the following
allocations from the "PCEP TLV Type Indicators" sub-registry. allocations from the "PCEP TLV Type Indicators" sub-registry.
Value Description Reference Value Description Reference
7 Propagation this document TBD(suggest 33) Propagation this document
8 Error-criticality this document TBD(suggest 34) Error-criticality this document
9 Notification type this document TBD(suggest 35) Notification type this document
8.2. New DLO object 8.2. New DLO object
Object-class Value Object-Type and Name Reference Object-class Value Object-Type and Name Reference
25 1: Diffusion list object this document TBD(suggest 41) 1: Diffusion list object this document
Target-Type Value Meaning Reference Target-Type Value Meaning Reference
0 Any PCEP peers this document 0 Any PCEP peers this document
1 PCEs but excludes 1 PCEs but excludes
PCC-only peers this document PCC-only peers this document
2 PCEs and PCCs this document 2 PCEs and PCCs this document
with which a session with which a session
is still opened is still opened
skipping to change at page 21, line 29 skipping to change at page 22, line 29
2: IPv6 prefix this document 2: IPv6 prefix this document
4: Unnumbered Interface ID this document 4: Unnumbered Interface ID this document
5: OSPF Area ID this document 5: OSPF Area ID this document
32: Autonomous system number this document 32: Autonomous system number this document
33: Explicit Exclusion Route subobject (EXRS) this document 33: Explicit Exclusion Route subobject (EXRS) this document
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-04 (work in progress), August
2017.
[I-D.ietf-pce-lsp-setup-type]
Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying path setup type in PCEP messages",
draft-ietf-pce-lsp-setup-type-08 (work in progress),
January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC) "A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009, DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>. <https://www.rfc-editor.org/info/rfc5441>.
[RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K. [RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K.
Kumaki, "Diffserv-Aware Class-Type Object for the Path Kumaki, "Diffserv-Aware Class-Type Object for the Path
Computation Element Communication Protocol", RFC 5455, Computation Element Communication Protocol", RFC 5455,
DOI 10.17487/RFC5455, March 2009, DOI 10.17487/RFC5455, March 2009,
<http://www.rfc-editor.org/info/rfc5455>. <https://www.rfc-editor.org/info/rfc5455>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>. 2009, <https://www.rfc-editor.org/info/rfc5521>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009, DOI 10.17487/RFC5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>. <https://www.rfc-editor.org/info/rfc5541>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <http://www.rfc-editor.org/info/rfc5557>. July 2009, <https://www.rfc-editor.org/info/rfc5557>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<http://www.rfc-editor.org/info/rfc5886>. <https://www.rfc-editor.org/info/rfc5886>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
<http://www.rfc-editor.org/info/rfc6006>. <https://www.rfc-editor.org/info/rfc6006>.
9.2. Informational References [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[I-D.ietf-pce-vendor-constraints] [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
Zhang, F., Farrel, A., and G. Bernstein, "Conveying and D. Dhody, "Optimizations of Label Switched Path State
Vendor-Specific Constraints in the Path Computation Synchronization Procedures for a Stateful PCE", RFC 8232,
Element Protocol", draft-ietf-pce-vendor-constraints-05 DOI 10.17487/RFC8232, September 2017,
(work in progress), December 2011. <https://www.rfc-editor.org/info/rfc8232>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.
9.2. Informational References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
Authors' Addresses [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
Authors' Addresses
Helia Pouyllau Helia Pouyllau
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
NOZAY 91620 NOZAY 91620
FRANCE FRANCE
Phone: + 33 (0)1 30 77 63 11 Phone: + 33 (0)1 30 77 63 11
Email: helia.pouyllau@alcatel-lucent.com Email: helia.pouyllau@alcatel-lucent.com
Remi Theillaud Remi Theillaud
skipping to change at page 23, line 33 skipping to change at page 25, line 30
Email: remi.theillaud@marben-products.com Email: remi.theillaud@marben-products.com
Julien Meuric Julien Meuric
France Telecom Orange France Telecom Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
FRANCE FRANCE
Email: julien.meuric@orange-ftgroup.com Email: julien.meuric@orange-ftgroup.com
Xian Zhang (Editor) Haomian Zheng (Editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base Bantian, Longgang District F3-1B, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhenghaomian@huawei.com
Xian Zhang
Huawei Technologies
G1-2, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
 End of changes. 37 change blocks. 
62 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/