< draft-dhody-pce-stateful-pce-optional-03.txt   draft-dhody-pce-stateful-pce-optional-04.txt >
PCE Working Group C. Li PCE Working Group C. Li
Internet-Draft H. Zheng Internet-Draft H. Zheng
Updates: 8231 (if approved) Huawei Technologies Updates: 8231 (if approved) Huawei Technologies
Intended status: Standards Track S. Litkowski Intended status: Standards Track S. Litkowski
Expires: September 6, 2019 Orange Expires: January 8, 2020 Orange
March 5, 2019 July 7, 2019
Extension for Stateful PCE to allow Optional Processing of PCEP Objects. Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
draft-dhody-pce-stateful-pce-optional-03 draft-dhody-pce-stateful-pce-optional-04
Abstract Abstract
This document introduces a mechanism to mark some Path Computation This document introduces a mechanism to mark some Path Computation
Element (PCE) Communication Protocol (PCEP) objects as optional Element (PCE) Communication Protocol (PCEP) objects as optional
during PCEP messages exchange for the Stateful PCE model to allow during PCEP messages exchange for the Stateful PCE model to allow
relaxing some constraints. relaxing some constraints.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 https://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 September 6, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 4
3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4 3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4
3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 5 3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 5
3.2.1. The PCRpt message . . . . . . . . . . . . . . . . . . 5 3.2.1. The PCRpt message . . . . . . . . . . . . . . . . . . 5
3.2.2. The PCUpd message and the PCInitiate message . . . . 5 3.2.2. The PCUpd message and the PCInitiate message . . . . 5
3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 5 3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 5
3.3.1. The PCUpd message . . . . . . . . . . . . . . . . . . 5 3.3.1. The PCUpd message . . . . . . . . . . . . . . . . . . 6
3.3.2. The PCRpt message . . . . . . . . . . . . . . . . . . 6 3.3.2. The PCRpt message . . . . . . . . . . . . . . . . . . 6
3.3.3. The PCInitiate message . . . . . . . . . . . . . . . 6 3.3.3. The PCInitiate message . . . . . . . . . . . . . . . 6
3.4. Delegation . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Delegation . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Unknown Object Handling . . . . . . . . . . . . . . . . . 6 3.5. Unknown Object Handling . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 7 5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 7 6. Manageability Considerations . . . . . . . . . . . . . . . . 7
6.1. Control of Function and Policy . . . . . . . . . . . . . 7 6.1. Control of Function and Policy . . . . . . . . . . . . . 7
6.2. Information and Data Models . . . . . . . . . . . . . . . 7 6.2. Information and Data Models . . . . . . . . . . . . . . . 8
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 8
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 8
6.6. Impact On Network Operations . . . . . . . . . . . . . . 8 6.6. Impact On Network Operations . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 8 skipping to change at page 3, line 8
two PCEs based on the PCE architecture [RFC4655]. two PCEs based on the PCE architecture [RFC4655].
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
extensions to PCEP to enable active control of Multiprotocol Label extensions to PCEP to enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS)
tunnels. [RFC8281] describes the setup and teardown of PCE-initiated tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for a dynamic network. configuration on the PCC, thus allowing for a dynamic network.
[RFC5440] defined P flag (Processing-Rule) as part of Common Object [RFC5440] defined P flag (Processing-Rule) as part of Common Object
Header to allow a PCC to specify in a PCReq message sent to a PCE Header to allow a PCC to specify in a Path Computation Request
whether the object must be taken into account by the PCE during path (PCReq) message sent to a PCE whether the object must be taken into
computation or is just optional. The I flag (Ignore) is used by a account by the PCE during path computation or is just optional. The
PCE in a PCRep message to indicate to a PCC whether or not an I flag (Ignore) is used by a PCE in a Path Computation Reply (PCRep)
optional object was processed. Stateful PCE [RFC8231] specified that message to indicate to a PCC whether or not an optional object was
P and I flags of the PCEP objects defined in [RFC8231] is to be set processed. Stateful PCE [RFC8231] specified that P and I flags of
to 0 on transmission and ignored on receipt since they are the PCEP objects defined in [RFC8231] is to be set to zero on
exclusively related to path computation requests. The behavior for P transmission and ignored on receipt since they are exclusively
and I flag in other objects defined in [RFC5440] and other extension related to path computation requests. The behavior for P and I flag
was not specified. This document clarifies how the P and I flag in other messages defined in [RFC5440] and other extension was not
could be used in the stateful PCE model to identify optional objects specified. This document clarifies how the P and I flag could be
in the Path Computation State Report (PCRpt) [RFC8231], the Path used in the stateful PCE model to identify optional objects in the
Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate Path Computation State Report (PCRpt) [RFC8231], the Path Computation
Request (PCInitiate) [RFC8281] message. Update Request (PCUpd) [RFC8231], and the LSP Initiate Request
(PCInitiate) [RFC8281] message.
This document updates [RFC8231] with respect to usage of P and I flag This document updates [RFC8231] with respect to usage of P and I flag
as well as the handling of unknown objects in the stateful PCEP as well as the handling of unknown objects in the stateful PCEP
message exchange. message exchange.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 4, line 44 skipping to change at page 4, line 44
initialization phase, as follows. When the PCEP session is created, initialization phase, as follows. When the PCEP session is created,
it sends an Open message with an OPEN object that contains the it sends an Open message with an OPEN object that contains the
STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag,
the R (RELAX) flag, is introduced to this TLV to indicate support for the R (RELAX) flag, is introduced to this TLV to indicate support for
relaxing the processing of some objects via the use of P and I flag relaxing the processing of some objects via the use of P and I flag
in the PCEP common object header. in the PCEP common object header.
R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
indicates that the PCEP Speaker is willing to send and receive PCEP indicates that the PCEP Speaker is willing to send and receive PCEP
objects with handling of P and I flags in the PCEP common object objects with handling of P and I flags in the PCEP common object
header. In case the bit is unset, it indicates that the PCEP Speaker header for stateful PCE messages. In case the bit is unset, it
would not handle P and I flags in the PCEP common object header. indicates that the PCEP Speaker would not handle P and I flags in the
PCEP common object header for stateful PCE messages.
The R flag must be set by both a PCC and a PCE for handling of P and The R flag MUST be set by both a PCC and a PCE to indicate support
I flag in the PCEP common object header to allow relaxing some for handling of P and I flag in the PCEP common object header to
constraints by marking objects as optional to process. If the PCEP allow relaxing some constraints by marking objects as optional to
speaker that did not set R flag but receives PCEP objects with P or I process. If the PCEP speaker that did not set R flag but receives
bit set, would behave as per the processing rule in [RFC8231]. PCEP objects with P or I bit set, MUST behave as per the processing
rule in [RFC8231] i.e., the bits are simply ignored.
3.2. Handling of P flag 3.2. Handling of P flag
3.2.1. The PCRpt message 3.2.1. The PCRpt message
The P flag in the PCRpt message [RFC8231] allows a PCC to specify to The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
a PCE whether the object must be taken into account by the PCE a PCE whether the object must be taken into account by the PCE
(during path computation or re-optimization) or is just optional. (during path computation or re-optimization) or is just optional.
When the P flag is set in PCRpt message, the object MUST be taken When the P flag is set in PCRpt message received on a PCEP session on
into account by the PCE. Conversely, when the P flag is cleared, the which R bit was set by both peers, the object MUST be taken into
account by the PCE. Conversely, when the P flag is cleared, the
object is optional and the PCE is free to ignore it. The P flag for object is optional and the PCE is free to ignore it. The P flag for
the mandatory objects LSP and ERO (intended path) MUST be set in the the mandatory objects LSP and ERO (intended path) MUST be set in the
PCRpt message. If the mandatory object is received with the P flag PCRpt message. If the mandatory object is received with the P flag
set incorrectly according to the rules stated above, the receiving set incorrectly according to the rules stated above, the receiving
peer MUST send a PCErr message with Error-Type=10 (Reception of an peer MUST send a PCErr message with Error-Type=10 (Reception of an
invalid object) and Error-value=1 (reception of an object with P flag invalid object) and Error-value=1 (reception of an object with P flag
not set). By default, the PCC SHOULD set the P flag, unless a local not set). By default, the PCC SHOULD set the P flag, unless a local
configuration or local policy indicates that some constraints configuration or local policy indicates that some constraints
(corresponding PCEP objects) can be marked as optional and could be (corresponding PCEP objects) can be marked as optional and could be
ignored by the PCE. ignored by the PCE.
3.2.2. The PCUpd message and the PCInitiate message 3.2.2. The PCUpd message and the PCInitiate message
The P flag in the PCUpd message [RFC8231] and the PCInitiate message The P flag in the PCUpd message [RFC8231] and the PCInitiate message
[RFC8281] allows a PCE to specify to a PCC whether the object must be [RFC8281] allows a PCE to specify to a PCC whether the object must be
taken into account by the PCC (during path setup) or is just taken into account by the PCC (during path setup) or is just
optional. When the P flag is set in PCUpd/PCInitiate, the object optional. When the P flag is set in PCUpd/PCInitiate message
MUST be taken into account by the PCC. Conversely, when the P flag received on a PCEP session on which R bit was set by both peers, the
is cleared, the object is optional and the PCC is free to ignore it. object MUST be taken into account by the PCC. Conversely, when the P
The P flag for the mandatory objects SRP, LSP and ERO (intended path) flag is cleared, the object is optional and the PCC is free to ignore
MUST be set in the PCUpd message. If the mandatory object is it. The P flag for the mandatory objects SRP, LSP and ERO MUST be
set in the PCUpd/PCInitiate message. If the mandatory object is
received with the P flag set incorrectly according to the rules received with the P flag set incorrectly according to the rules
stated above, the receiving peer MUST send a PCErr message with stated above, the receiving peer MUST send a PCErr message with
Error-Type=10 (Reception of an invalid object) and Error-value=1 Error-Type=10 (Reception of an invalid object) and Error-value=1
(reception of an object with P flag not set). By default, the PCE (reception of an object with P flag not set). By default, the PCE
SHOULD set the P flag, unless a local configuration or local policy SHOULD set the P flag, unless a local configuration or local policy
indicates that some constraints (corresponding PCEP objects) can be indicates that some constraints (corresponding PCEP objects) can be
marked as optional and could be ignored by the PCC. marked as optional and could be ignored by the PCC.
3.3. Handling of I flag 3.3. Handling of I flag
3.3.1. The PCUpd message 3.3.1. The PCUpd message
The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
a PCC whether or not an optional object was processed. The PCE MAY a PCC whether or not an optional object was processed. The PCE MAY
include the ignored optional object in its update request and set the include the ignored optional object in its update request and set the
I flag to indicate that the optional object was ignored. When the I I flag to indicate that the optional object was ignored. When the I
flag is cleared, the PCE indicates that the optional object was flag is cleared, the PCE indicates that the optional object was
processed. processed.
3.3.2. The PCRpt message 3.3.2. The PCRpt message
skipping to change at page 6, line 32 skipping to change at page 6, line 40
3.4. Delegation 3.4. Delegation
Delegation is an operation to grant a PCE temporary rights to modify Delegation is an operation to grant a PCE temporary rights to modify
a subset of LSP parameters on one or more LSPs of a PCC as described a subset of LSP parameters on one or more LSPs of a PCC as described
in [RFC8051]. Note that for the delegated LSPs, the PCE can update in [RFC8051]. Note that for the delegated LSPs, the PCE can update
and mark some object as ignored even when the PCC had set the P flag and mark some object as ignored even when the PCC had set the P flag
during delegation. Similarly, the PCE can update and mark some during delegation. Similarly, the PCE can update and mark some
object as a must to process even when the PCC had not set the P flag object as a must to process even when the PCC had not set the P flag
during delegation. during delegation.
The PCC MUST confirm this by sending the PCRpt message with the P The PCC MUST acknowledge this by sending the PCRpt message with the P
flag set as per the PCE expectation for the corresponding object. In flag set as per the PCE expectation for the corresponding object. In
case PCC cannot except this, it would reach as per the processing case PCC cannot except this, it would react as per the processing
rules in [RFC8231]. rules of unacceptable update in [RFC8231].
3.5. Unknown Object Handling 3.5. Unknown Object Handling
This document updates the handling of unknown objects in stateful This document updates the handling of unknown objects in stateful
PCEP messages as per the setting of P flag in the common object PCEP messages as per the setting of P flag in the common object
header in a similar way as [RFC5440], i.e. if a PCEP speaker does not header in a similar way as [RFC5440], i.e. if a PCEP speaker does not
understand an object with the P flag set or understands the object understand an object with the P flag set or understands the object
but decides to ignore the object, the entire stateful PCEP message but decides to ignore the object, the entire stateful PCEP message
MUST be rejected and the PCE MUST send a PCErr message with Error- MUST be rejected and the PCE MUST send a PCErr message with Error-
Type="Unknown Object" or "Not supported Object" [RFC5440]. In case Type="Unknown Object" or "Not supported Object" [RFC5440]. In case
skipping to change at page 7, line 14 skipping to change at page 7, line 22
4. Security Considerations 4. Security Considerations
This documents clarifies how the already existing P and I flag in This documents clarifies how the already existing P and I flag in
PCEP common object header could be used during stateful PCEP PCEP common object header could be used during stateful PCEP
exchanges. It updates the unknown object error handling in stateful exchanges. It updates the unknown object error handling in stateful
PCEP message exchange. These changes on its own do not add any new PCEP message exchange. These changes on its own do not add any new
security concerns. The security considerations identified in security concerns. The security considerations identified in
[RFC5440], [RFC8231], and [RFC8281]. [RFC5440], [RFC8231], and [RFC8281].
As stated in [RFC6952], PCEP implementations SHOULD support the TCP- As per [RFC8231], it is RECOMMENDED that these PCEP extensions only
AO [RFC5925] and not use TCP MD5 because of TCP MD5's known be activated on authenticated and encrypted sessions across PCEs and
vulnerabilities and weakness. PCEP also support Transport Layer PCCs belonging to the same administrative authority, using Transport
Security (TLS) [RFC8253] as per the recommendations and best current Layer Security (TLS) [RFC8253] as per the recommendations and best
practices in [RFC7525]. current practices in [RFC7525] (unless explicitly set aside in
[RFC8253]).
5. IANA Considerations 5. IANA Considerations
5.1. STATEFUL-PCE-CAPABILITY TLV 5.1. STATEFUL-PCE-CAPABILITY TLV
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA
created a registry to manage the value of the STATEFUL-PCE-CAPABILITY created a "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to
TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE- manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field.
CAPABILITY TLV Flag Field registry, as follows: IANA is requested to allocate a new bit in the subregistry, as
follows:
Bit Description Reference Bit Description Reference
------------------------------------------------- -------------------------------------------------
TBD1 RELAX bit [This I.D.] TBD1 RELAX bit [This-I.D.]
6. Manageability Considerations 6. Manageability Considerations
6.1. Control of Function and Policy 6.1. Control of Function and Policy
An operator MUST be allowed to configure the capability to support An operator MUST be allowed to configure the capability to support
relaxation of constraints in the stateful PCEP message exchange. relaxation of constraints in the stateful PCEP message exchange.
They SHOULD also allow configuration of related LSP constraints (or They SHOULD also allow configuration of related LSP constraints (or
parameters) that are optional to process. parameters) that are optional to process.
6.2. Information and Data Models 6.2. Information and Data Models
An implementation SHOULD allow the operator to view the capability An implementation SHOULD allow the operator to view the capability
defined in this document. To serve this purpose, the PCEP YANG defined in this document. To serve this purpose, the PCEP YANG
module [I-D.ietf-pce-pcep-yang] could be extended. module [I-D.ietf-pce-pcep-yang] could be extended in future.
6.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
6.4. Verify Correct Operations 6.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
skipping to change at page 9, line 12 skipping to change at page 9, line 22
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
8.2. Informative References 8.2. Informative 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,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-09 (work in progress), October 2018. yang-12 (work in progress), July 2019.
[I-D.ietf-pce-association-group] [I-D.ietf-pce-association-group]
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "PCEP Extensions for Dhody, D., and Y. Tanaka, "PCEP Extensions for
Establishing Relationships Between Sets of LSPs", draft- Establishing Relationships Between Sets of LSPs", draft-
ietf-pce-association-group-07 (work in progress), December ietf-pce-association-group-09 (work in progress), April
2018. 2019.
[I-D.ietf-pce-association-diversity] [I-D.ietf-pce-association-diversity]
Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
extension for signaling LSP diversity constraint", draft- Extension for LSP Diversity Constraint Signaling", draft-
ietf-pce-association-diversity-06 (work in progress), ietf-pce-association-diversity-08 (work in progress), July
February 2019. 2019.
Appendix A. Contributors Appendix A. Contributors
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
 End of changes. 21 change blocks. 
66 lines changed or deleted 62 lines changed or added

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