< draft-ietf-pce-segment-routing-policy-cp-06.txt   draft-ietf-pce-segment-routing-policy-cp-07.txt >
PCE Working Group M. Koldychev PCE Working Group M. Koldychev
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: 25 April 2022 Ciena Corporation Expires: 21 October 2022 Ciena Corporation
C. Barth C. Barth
Juniper Networks, Inc. Juniper Networks, Inc.
S. Peng S. Peng
Huawei Technologies Huawei Technologies
H. Bidgoli H. Bidgoli
Nokia Nokia
October 2021 April 2022
PCEP extension to support Segment Routing Policy Candidate Paths PCEP extension to support Segment Routing Policy Candidate Paths
draft-ietf-pce-segment-routing-policy-cp-06 draft-ietf-pce-segment-routing-policy-cp-07
Abstract Abstract
This document introduces a mechanism to specify a Segment Routing This document introduces a mechanism to specify a Segment Routing
(SR) policy, as a collection of SR candidate paths. An SR policy is (SR) policy, as a collection of SR candidate paths. An SR policy is
identified by <headend, color, endpoint> tuple. An SR policy can identified by <headend, color, endpoint> tuple. An SR policy can
contain one or more candidate paths where each candidate path is contain one or more candidate paths where each candidate path is
identified in PCEP by its uniquely assigned PLSP-ID. This document identified in PCEP by its uniquely assigned PLSP-ID. This document
proposes extension to PCEP to support association among candidate proposes extension to PCEP to support association among candidate
paths of a given SR policy. The mechanism proposed in this document paths of a given SR policy. The mechanism proposed in this document
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 4 April 2022. This Internet-Draft will expire on 3 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Group Candidate Paths belonging to the same SR policy . . 5 3.1. Group Candidate Paths belonging to the same SR policy . . 5
3.2. Instantiation of SR policy candidate paths . . . . . . . 5 3.2. Instantiation of SR policy candidate paths . . . . . . . 5
3.3. Avoid computing lower preference candidate paths . . . . 5 3.3. Avoid computing lower preference candidate paths . . . . 5
3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 6 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.2.1. SR Policy Name TLV . . . . . . . . . . . . . . . . . 10 5.2.1. SR Policy Name TLV . . . . . . . . . . . . . . . . . 10
5.2.2. SR Policy Candidate Path Identifiers TLV . . . . . . 11 5.2.2. SR Policy Candidate Path Identifiers TLV . . . . . . 11
5.2.3. SR Policy Candidate Path Name TLV . . . . . . . . . . 12 5.2.3. SR Policy Candidate Path Name TLV . . . . . . . . . . 12
5.2.4. SR Policy Candidate Path Preference TLV . . . . . . . 12 5.2.4. SR Policy Candidate Path Preference TLV . . . . . . . 12
6. Generic Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 6. Generic Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
6.1. Computation Priority TLV . . . . . . . . . . . . . . . . 13 6.1. Computation Priority TLV . . . . . . . . . . . . . . . . 13
6.2. Explicit Null Label Policy (ENLP) TLV . . . . . . . . . . 13 6.2. Explicit Null Label Policy (ENLP) TLV . . . . . . . . . . 13
6.3. Invalidation TLV . . . . . . . . . . . . . . . . . . . . 14 6.3. Invalidation TLV . . . . . . . . . . . . . . . . . . . . 14
6.4. Specified-BSID-only . . . . . . . . . . . . . . . . . . . 15 6.4. Specified-BSID-only . . . . . . . . . . . . . . . . . . . 15
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. PCC Initiated SR Policy with single candidate-path . . . 15 7.1. PCC Initiated SR Policy with single candidate-path . . . 16
7.2. PCC Initiated SR Policy with multiple candidate-paths . . 16 7.2. PCC Initiated SR Policy with multiple candidate-paths . . 16
7.3. PCE Initiated SR Policy with single candidate-path . . . 16 7.3. PCE Initiated SR Policy with single candidate-path . . . 17
7.4. PCE Initiated SR Policy with multiple candidate-paths . . 17 7.4. PCE Initiated SR Policy with multiple candidate-paths . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Association Type . . . . . . . . . . . . . . . . . . . . 17 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 18
8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18
8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 18 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. TE-PATH-BINDING TLV Flag field . . . . . . . . . . . . . 19 8.4. TE-PATH-BINDING TLV Flag field . . . . . . . . . . . . . 19
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
9.1. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Path Computation Element (PCE) Communication Protocol (PCEP) Path Computation Element (PCE) Communication Protocol (PCEP)
[RFC5440] enables the communication between a Path Computation Client [RFC5440] enables the communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs based (PCC) and a Path Computation Element (PCE), or between two PCEs based
on the PCE architecture [RFC4655]. on the PCE architecture [RFC4655].
skipping to change at page 14, line 25 skipping to change at page 14, line 25
Type: TBD2 for "ENLP" TLV. Type: TBD2 for "ENLP" TLV.
Length: 4. Length: 4.
ENLP (Explicit NULL Label Policy): same values as in Section 2.4.5 of ENLP (Explicit NULL Label Policy): same values as in Section 2.4.5 of
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy].
6.3. Invalidation TLV 6.3. Invalidation TLV
The INVALIDATION TLV is an optional TLV for the LSP object. It is The INVALIDATION TLV is an optional TLV for the LSP object. It is
used to specify LSP behavior when the LSP is operationally down, in used to control traffic streering into the LSP during the time when
particular to facilitate the "Drop upon invalid" behavior, specified the LSP is operationally down/invalid. In the context of SR Policy,
in Section 8.2 of [I-D.ietf-spring-segment-routing-policy]. this TLV facilitate the "Drop upon invalid" behavior, specified in
Section 8.2 of [I-D.ietf-spring-segment-routing-policy]. Normally,
if the LSP is down/invalid then traffic that is originally destined
for that LSP is steered somewhere else, such as via IGP or via
another LSP. The "Drop upon invalid" behavior specifies that such
traffic MUST NOT be re-routed and has to be dropped at the head-end.
While in the "Drop upon invalid" state, the LSP operational state is
"UP", as indicated by the O-flag in the LSP object. However the ERO
object is empty, indicating that traffic is being dropped.
In addition to the above, this TLV can also be used by the PCC to
report to the PCE various reasons for LSP being invalidated.
Invalidation reasons are represented by a set of flags.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |V|P|F|U|
+-+-+-+-+-+-+-+-+
Figure 8: Invalidation Reasons Flags
* U: Unknown - does not fit into any other categories below.
* P: Path computation failure - no path was computed for the LSP.
* F: First-hop resolution failure - head-end first hop resolution
has failed.
* V: Verification failure - OAM/PM/BFD path verification has
indicated a breakage.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config | State | MBZ | | Inval Reason | Drop Upon | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The INVALIDATION TLV format Figure 9: The INVALIDATION TLV format
Type: TBD3 for "INVALIDATION" TLV. Type: TBD3 for "INVALIDATION" TLV.
Length: 4. Length: 4.
Config: specifies the action to take when the LSP becomes invalid: Inval Reason: contains "Invalidation Reasons Flags" which encode the
reason(s) why the LSP is currently invalidated. This field can be
* 0: (default) bring down the LSP and forward traffic somewhere else set to non-zero values only by the PCC, it MUST be set to 0 by the
(i.e., IGP, etc.). PCE and ignored by the PCC.
* 1: drop traffic when the LSP is invalid.
* 2-255: Reserved.
State: specifies the current state of the LSP:
* 0: (default) traffic is not being dropped.
* 1: traffic is being dropped, due to LSP being down and "Drop upon
invalid" being set.
* 2-255: Reserved.
The "State" field only has meaning when sent from PCC to the PCE in Drop Upon: contains "Invalidation Reasons Flags" for conditions that
PCRpt messages, it is set to 0 when sent from PCE to PCC. The SHOULD cause the LSP to drop traffic. This field can be set to non-
"Config" field is valid in both directions on the PCEP session, i.e., zero values by both PCC and PCE. This field MAY be set to all 1's
from PCC in PCRpt and from PCE in PCUpd and PCInit messages. (0xFF) to indicate that the LSP is to go into Drop upon invalid state
for any reason. I.e., when the PCE does not wish to distinguish any
reason for LSP invalidation and just simply wants it to always "Drop
upon invalid" for any reason.
6.4. Specified-BSID-only 6.4. Specified-BSID-only
Specified-BSID-only functionality is defined in Section 6.2.3 of Specified-BSID-only functionality is defined in Section 6.2.3 of
[I-D.ietf-spring-segment-routing-policy]. When specified-BSID-only [I-D.ietf-spring-segment-routing-policy]. When specified-BSID-only
is enabled for a particular binding SID, it means that the given is enabled for a particular binding SID, it means that the given
binding SID is required to be allocated and programmed for the LSP to binding SID is required to be allocated and programmed for the LSP to
be operationally up. If the binding SID cannot be allocated or be operationally up. If the binding SID cannot be allocated or
programmed for some reason, then the LSP must stay down. programmed for some reason, then the LSP must stay down.
skipping to change at page 17, line 16 skipping to change at page 17, line 37
object. object.
2. PCC uses the PLSP-ID from the LSP object to find the candidate 2. PCC uses the PLSP-ID from the LSP object to find the candidate
path and delete it. If this is the last candidate path under the path and delete it. If this is the last candidate path under the
SR policy, then the containing SR policy is deleted as well. SR policy, then the containing SR policy is deleted as well.
7.4. PCE Initiated SR Policy with multiple candidate-paths 7.4. PCE Initiated SR Policy with multiple candidate-paths
A candidate-path is created using the following steps: A candidate-path is created using the following steps:
1. PCE sends a separate PCInitiate message for every candidate path 1. PCE SHOULD send a separate PCInitiate message for every candidate
that it wants to create, or it sends multiple LSP objects within path that it wants to create, or it MAY send multiple LSP objects
a single PCInitiate message. The SRPAT ASSOCIATION is sent for within a single PCInitiate message. The SRPAT ASSOCIATION is
every LSP in the PCInitiate message. The Association Source and sent for every LSP in the PCInitiate message. The Association
the Association ID are set as described in Section 5.1. Source and the Association ID are set as described in
Section 5.1.
2. PCC creates multiple candidate paths under the same SR policy, 2. PCC creates multiple candidate paths under the same SR policy,
identified by Color and Endpoint. identified by Color and Endpoint.
3. PCC sends a PCRpt message back to the PCE to report the newly 3. PCC sends a PCRpt message back to the PCE to report the newly
created Candidate Path. The PCRpt message contains the SRPAT created Candidate Path. The PCRpt message contains the SRPAT
ASSOCIATION. The Association Source and the Association ID are ASSOCIATION. The Association Source and the Association ID are
set as described in Section 5.1. set as described in Section 5.1.
A candidate path is deleted using the following steps: A candidate path is deleted using the following steps:
skipping to change at page 21, line 10 skipping to change at page 21, line 24
can also be derived from the SR Database, but association provides a can also be derived from the SR Database, but association provides a
much easier grouping of related LSPs and messages. The SRPAT much easier grouping of related LSPs and messages. The SRPAT
ASSOCIATION could provide an adversary with the opportunity to ASSOCIATION could provide an adversary with the opportunity to
eavesdrop on the relationship between the LSPs. Thus securing the eavesdrop on the relationship between the LSPs. Thus securing the
PCEP session using Transport Layer Security (TLS) [RFC8253], as per PCEP session using Transport Layer Security (TLS) [RFC8253], as per
the recommendations and best current practices in [RFC7525], is the recommendations and best current practices in [RFC7525], is
RECOMMENDED. RECOMMENDED.
11. Acknowledgement 11. Acknowledgement
Would like to thank Stephane Litkowski, Praveen Kumar and Tom Petch Would like to thank Stephane Litkowski, Boris Khasanov, Praveen Kumar
for review comments. and Tom Petch for review and suggestions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 22, line 4 skipping to change at page 22, line 20
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment- Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-13, 28 May 2021, routing-policy-22, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring- <https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-13.txt>. segment-routing-policy-22.txt>.
[I-D.ietf-idr-segment-routing-te-policy] [I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment Jain, D., and S. Lin, "Advertising Segment Routing
Routing Policies in BGP", Work in Progress, Internet- Policies in BGP", Work in Progress, Internet-Draft, draft-
Draft, draft-ietf-idr-segment-routing-te-policy-13, 7 June ietf-idr-segment-routing-te-policy-17, 14 April 2022,
2021, <https://www.ietf.org/archive/id/draft-ietf-idr- <https://www.ietf.org/archive/id/draft-ietf-idr-segment-
segment-routing-te-policy-13.txt>. routing-te-policy-17.txt>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
[I-D.koldychev-pce-operational] [I-D.koldychev-pce-operational]
Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and
H. Kotni, "PCEP Operational Clarification", Work in H. Kotni, "PCEP Operational Clarification", Work in
Progress, Internet-Draft, draft-koldychev-pce-operational- Progress, Internet-Draft, draft-koldychev-pce-operational-
04, 19 August 2021, <https://www.ietf.org/archive/id/ 05, 19 February 2022, <https://www.ietf.org/archive/id/
draft-koldychev-pce-operational-04.txt>. draft-koldychev-pce-operational-05.txt>.
[I-D.koldychev-pce-multipath] [I-D.koldychev-pce-multipath]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for
Signaling Multipath Information", Work in Progress, Signaling Multipath Information", Work in Progress,
Internet-Draft, draft-koldychev-pce-multipath-05, 16 Internet-Draft, draft-koldychev-pce-multipath-05, 16
February 2021, <https://www.ietf.org/archive/id/draft- February 2021, <https://www.ietf.org/archive/id/draft-
koldychev-pce-multipath-05.txt>. koldychev-pce-multipath-05.txt>.
12.2. Informative References 12.2. Informative References
skipping to change at page 23, line 21 skipping to change at page 23, line 36
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Li, C., Negi, M., Sivabalan, S., Koldychev, M., Li, C., Negi, M., Sivabalan, S., Koldychev, M.,
Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment
Routing leveraging the IPv6 data plane", Work in Progress, Routing leveraging the IPv6 data plane", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-13, 1
May 2021, <https://www.ietf.org/internet-drafts/draft- April 2022, <https://www.ietf.org/internet-drafts/draft-
ietf-pce-segment-routing-ipv6-09.txt>. ietf-pce-segment-routing-ipv6-13.txt>.
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
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
 End of changes. 25 change blocks. 
62 lines changed or deleted 81 lines changed or added

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