| < 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/ | ||||