| < draft-ietf-pce-pcep-extension-native-ip-17.txt | draft-ietf-pce-pcep-extension-native-ip-18.txt > | |||
|---|---|---|---|---|
| PCE Working Group A. Wang | PCE Working Group A. Wang | |||
| Internet-Draft China Telecom | Internet-Draft China Telecom | |||
| Intended status: Standards Track B. Khasanov | Intended status: Standards Track B. Khasanov | |||
| Expires: 11 August 2022 Yandex LLC | Expires: 22 September 2022 Yandex LLC | |||
| S. Fang | S. Fang | |||
| R. Tan | R. Tan | |||
| Huawei Technologies,Co.,Ltd | Huawei Technologies,Co.,Ltd | |||
| C. Zhu | C. Zhu | |||
| ZTE Corporation | ZTE Corporation | |||
| 7 February 2022 | 21 March 2022 | |||
| PCEP Extension for Native IP Network | PCEP Extension for Native IP Network | |||
| draft-ietf-pce-pcep-extension-native-ip-17 | draft-ietf-pce-pcep-extension-native-ip-18 | |||
| Abstract | Abstract | |||
| This document defines the Path Computation Element Communication | This document defines the Path Computation Element Communication | |||
| Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) | Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) | |||
| based application in Native IP network. The scenario and framework | based application in Native IP network. The scenario and framework | |||
| of CCDR in native IP is described in [RFC8735] and [RFC8821]. This | of CCDR in native IP is described in [RFC8735] and [RFC8821]. This | |||
| draft describes the key information that is transferred between Path | draft describes the key information that is transferred between Path | |||
| Computation Element (PCE) and Path Computation Clients (PCC) to | Computation Element (PCE) and Path Computation Clients (PCC) to | |||
| accomplish the End to End (E2E) traffic assurance in Native IP | accomplish the End to End (E2E) traffic assurance in Native IP | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| 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 11 August 2022. | This Internet-Draft will expire on 22 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 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 | |||
| skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
| 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14 | 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14 | 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 15 | 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 15 | |||
| 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 | 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 | |||
| 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 20 | 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 20 | |||
| 8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 | 8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 | |||
| 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 | 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 | |||
| 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 | 11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 | |||
| 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 | 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 | |||
| 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 | |||
| 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 13.1. Proof of Concept based on ODL . . . . . . . . . . . . . 24 | |||
| 14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 24 | 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | |||
| 14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 24 | 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 25 | 15.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 25 | |||
| 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 | 15.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 25 | |||
| 15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 15.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 25 | |||
| 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 | 15.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 | |||
| 17. Normative References . . . . . . . . . . . . . . . . . . . . 26 | 16. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 | 17. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 18. Normative References . . . . . . . . . . . . . . . . . . . . 27 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 1. Introduction | 1. Introduction | |||
| Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- | Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- | |||
| TE) requires the corresponding network devices support Multiprotocol | TE) requires the corresponding network devices support Multiprotocol | |||
| Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label | Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label | |||
| Distribution Protocol (LDP) technologies to assure the End-to-End | Distribution Protocol (LDP) technologies to assure the End-to-End | |||
| (E2E) traffic performance. In Segment Routing either IGP extensions | (E2E) traffic performance. In Segment Routing either IGP extensions | |||
| or BGP are used to steer a packet through an SR Policy instantiated | or BGP are used to steer a packet through an SR Policy instantiated | |||
| as an ordered list of instructions called "segments". But in native | as an ordered list of instructions called "segments". But in native | |||
| skipping to change at page 24, line 22 ¶ | skipping to change at page 24, line 22 ¶ | |||
| If the established BGP session is broken after some time, the PCC | If the established BGP session is broken after some time, the PCC | |||
| should also report such error via PCErr message with Err-type=TBD6 | should also report such error via PCErr message with Err-type=TBD6 | |||
| and error value(Error-value=TBD11, Existing BGP session is broken). | and error value(Error-value=TBD11, Existing BGP session is broken). | |||
| Upon receiving such PCErr message, the PCE should clear the prefixes | Upon receiving such PCErr message, the PCE should clear the prefixes | |||
| advertisement on the previous BGP session, clear the explicit peer | advertisement on the previous BGP session, clear the explicit peer | |||
| route to the previous peer address; select other Local_IP/Peer_IP | route to the previous peer address; select other Local_IP/Peer_IP | |||
| pair to establish the new BGP session, deploy the explicit peer route | pair to establish the new BGP session, deploy the explicit peer route | |||
| to the new peer address, and advertises the prefixes on the new BGP | to the new peer address, and advertises the prefixes on the new BGP | |||
| session. | session. | |||
| 13. Security Considerations | 13. Implementation Status | |||
| [Note to the RFC Editor - remove this section before publication, as | ||||
| well as remove the reference to RFC 7942.] | ||||
| This section records the status of known implementations of the | ||||
| protocol defined by this specification at the time of posting of this | ||||
| Internet-Draft, and is based on a proposal described in [RFC7942]. | ||||
| The description of implementations in this section is intended to | ||||
| assist the IETF in its decision processes in progressing drafts to | ||||
| RFCs. Please note that the listing of any individual implementation | ||||
| here does not imply endorsement by the IETF. Furthermore, no effort | ||||
| has been spent to verify the information presented here that was | ||||
| supplied by IETF contributors. This is not intended as, and must not | ||||
| be construed to be, a catalog of available implementations or their | ||||
| features. Readers are advised to note that other implementations may | ||||
| exist. | ||||
| According to [RFC7942], "this will allow reviewers and working groups | ||||
| to assign due consideration to documents that have the benefit of | ||||
| running code, which may serve as evidence of valuable experimentation | ||||
| and feedback that have made the implemented protocols more mature. | ||||
| It is up to the individual working groups to use this information as | ||||
| they see fit". | ||||
| 13.1. Proof of Concept based on ODL | ||||
| .At the time of posting the -18 version of this document, there are | ||||
| no known implementations of this mechanism. A proof of concept for | ||||
| the overall design has been verified using another SBI protocol on | ||||
| the Open DayLight (ODL) controller. | ||||
| 14. Security Considerations | ||||
| The setup of BGP sessions, prefix advertisement, and explicit peer | The setup of BGP sessions, prefix advertisement, and explicit peer | |||
| route establishment are all controlled by the PCE. See [RFC4271] and | route establishment are all controlled by the PCE. See [RFC4271] and | |||
| [RFC4272] for BGP security considerations. Security consideration | [RFC4272] for BGP security considerations. Security consideration | |||
| part in [RFC5440] and [RFC8231] should be considered. To prevent a | part in [RFC5440] and [RFC8231] should be considered. To prevent a | |||
| bogus PCE sending harmful messages to the network nodes, the network | bogus PCE sending harmful messages to the network nodes, the network | |||
| devices should authenticate the validity of the PCE and ensure a | devices should authenticate the validity of the PCE and ensure a | |||
| secure communication channel between them. Mechanisms described in | secure communication channel between them. Mechanisms described in | |||
| [RFC8253] should be used. | [RFC8253] should be used. | |||
| 14. IANA Considerations | 15. IANA Considerations | |||
| 14.1. Path Setup Type Registry | 15.1. Path Setup Type Registry | |||
| [RFC8408] created a sub-registry within the "Path Computation Element | [RFC8408] created a sub-registry within the "Path Computation Element | |||
| Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". | Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". | |||
| IANA is requested to allocate a new code point within this registry, | IANA is requested to allocate a new code point within this registry, | |||
| as follows: | as follows: | |||
| Value Description Reference | Value Description Reference | |||
| TBD1 Native IP TE Path This document | TBD1 Native IP TE Path This document | |||
| 14.2. PCECC-CAPABILITY sub-TLV's Flag field | 15.2. PCECC-CAPABILITY sub-TLV's Flag field | |||
| [RFC9050] created a sub-registry within the "Path Computation Element | [RFC9050] created a sub-registry within the "Path Computation Element | |||
| Protocol (PCEP) Numbers" registry to manage the value of the PCECC- | Protocol (PCEP) Numbers" registry to manage the value of the PCECC- | |||
| CAPABILITY sub-TLV's 32-bits Flag field. IANA is requested to | CAPABILITY sub-TLV's 32-bits Flag field. IANA is requested to | |||
| allocate a new bit position within this registry, as follows: | allocate a new bit position within this registry, as follows: | |||
| Value Description Reference | Value Description Reference | |||
| TBD2(N) NATIVE-IP-TE-CAPABILITY This document | TBD2(N) NATIVE-IP-TE-CAPABILITY This document | |||
| 14.3. PCEP Object Types | 15.3. PCEP Object Types | |||
| IANA is requested to allocate new registry for the PCEP Object Type: | IANA is requested to allocate new registry for the PCEP Object Type: | |||
| Object-Class Value Name Reference | Object-Class Value Name Reference | |||
| 44 CCI Object This document | 44 CCI Object This document | |||
| Object-Type | Object-Type | |||
| TBD13: Native IP | TBD13: Native IP | |||
| TBD14 BGP Peer Info This document | TBD14 BGP Peer Info This document | |||
| Object-Type | Object-Type | |||
| skipping to change at page 25, line 32 ¶ | skipping to change at page 26, line 25 ¶ | |||
| TBD15 Explicit Peer Route This document | TBD15 Explicit Peer Route This document | |||
| Object-Type | Object-Type | |||
| 1: IPv4 address | 1: IPv4 address | |||
| 2: IPv6 address | 2: IPv6 address | |||
| TBD16 Peer Prefix Advertisement This document | TBD16 Peer Prefix Advertisement This document | |||
| Object-Type | Object-Type | |||
| 1: IPv4 address | 1: IPv4 address | |||
| 2: IPv6 address | 2: IPv6 address | |||
| 14.4. PCEP-Error Object | 15.4. PCEP-Error Object | |||
| IANA is requested to allocate new error types and error values within | IANA is requested to allocate new error types and error values within | |||
| the "PCEP-ERROR Object Error Types and Values" sub-registry of the | the "PCEP-ERROR Object Error Types and Values" sub-registry of the | |||
| PCEP Numbers registry for the following errors:: | PCEP Numbers registry for the following errors:: | |||
| Error-Type Meaning Error-value Reference | Error-Type Meaning Error-value Reference | |||
| 6 Mandatory Object missing | 6 Mandatory Object missing | |||
| TBD4:Native IP object missing This document | TBD4:Native IP object missing This document | |||
| 10 Reception of an invalid object | 10 Reception of an invalid object | |||
| skipping to change at page 26, line 26 ¶ | skipping to change at page 27, line 5 ¶ | |||
| TBD7:Peer AS not match | TBD7:Peer AS not match | |||
| TBD8:Peer IP can't be reached | TBD8:Peer IP can't be reached | |||
| TBD9:Local IP is in use | TBD9:Local IP is in use | |||
| TBD10:Remote IP is in use | TBD10:Remote IP is in use | |||
| TBD11:Exist BGP session broken | TBD11:Exist BGP session broken | |||
| TBD12:Explicit Peer Route Error | TBD12:Explicit Peer Route Error | |||
| TBD17:EPR/BPI Peer Info mismatch | TBD17:EPR/BPI Peer Info mismatch | |||
| TBD18:BPI/PPA Address Family mismatch | TBD18:BPI/PPA Address Family mismatch | |||
| TBD19:PPA/BPI Peer Info mismatch | TBD19:PPA/BPI Peer Info mismatch | |||
| 15. Contributor | 16. Contributor | |||
| Dhruv Dhody has contributed the contents of this draft. | Dhruv Dhody has contributed the contents of this draft. | |||
| 16. Acknowledgement | 17. Acknowledgement | |||
| Thanks Mike Koldychev, Susan Hares, Siva Sivabalan, Adam Simpson for | Thanks Mike Koldychev, Susan Hares, Siva Sivabalan, Adam Simpson for | |||
| his valuable suggestions and comments. | his valuable suggestions and comments. | |||
| 17. Normative References | 18. 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>. | |||
| [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
| and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
| Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, | Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, | |||
| <https://www.rfc-editor.org/info/rfc3209>. | <https://www.rfc-editor.org/info/rfc3209>. | |||
| End of changes. 14 change blocks. | ||||
| 23 lines changed or deleted | 57 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/ | ||||