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