Network Working Group C. Li Internet-Draft M. Chen Intended status: Experimental J. Dong Expires: December 22, 2018 Z. Li D. Dhody Huawei Technologies June 20, 2018 PCE Controlled ID Space draft-li-pce-controlled-id-space-00 Abstract The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths in SR networks. Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and delete PCE-initiated LSPs itself. A PCE-based central controller (PCECC) simplify the processing of a distributed control plane by blending it with elements of Software-Defined Networking (SDN) and without necessarily completely replacing it. In some use cases, such as PCECC, Binding Segment Identifier (SID), SR Path Identification, there is a requirement for a stateful PCE to make allocation of labels, SID, Path-ID respectively. These use cases require for the PCE to be aware of the various identifier space from which to make allocations on behalf of PCC. This documents specify a mechanism for a PCC to inform the PCE of the identifier space under its control via PCEP. The identifier could be MPLS label, SID, Path ID or another future identifier to be allocated by a PCE. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Li, et al. Expires December 22, 2018 [Page 1] Internet-Draft PCE Controlled ID Space June 2018 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 22, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 3.3. Path ID Allocation . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 5.1.2. SRv6-PATH-ID-CONTROL-SPACE TLV . . . . . . . . . . . 8 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Li, et al. Expires December 22, 2018 [Page 2] Internet-Draft PCE Controlled ID Space June 2018 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction [RFC5440] defines the stateless Path Computation Element communication Protocol (PCEP) for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. For supporting stateful operations, [RFC8231] specifies a set of extensions to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657]. Furthermore, [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. [RFC8283] introduces the architecture for PCE as a central controller, it examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. Also, [I-D.zhao-pce-pcep-extension-for-pce-controller] specifies the procedures and PCEP protocol extensions for using the PCE as the central controller, where LSPs are calculated/setup/initiated and label forwarding entries are downloaded through extending PCEP. However, the document assumes that label range to be used by a PCE is known and set on both PCEP peers. This extension adds the capability to advertise the range via a PCEP extension. Similarly, [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers (SR SID distribution in this case), in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network. However, the document assumes that label range to be used by a PCE is known and set on both PCEP peers. This extension adds the capability to advertise the range (from SRGB or SRLB of the node) via a PCEP extension. [I-D.li-pce-sr-path-segment] defines a procedure for path ID in PCEP for SR by defining the PATH-ID TLV. The path ID can be a path segment in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or a path ID in SRv6 [I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can identify an SR path. This document specify the extension to support advertisement of the various ID space to the PCE to control. Li, et al. Expires December 22, 2018 [Page 3] Internet-Draft PCE Controlled ID Space June 2018 The usecase are described in Section 3. The ID space range information can be advertised via the TLVs in the Open message. The detailed procedures will be described in Section 4, and the objects' format will be introduced in Section 5. 2. Terminology This memo makes use of the terms defined in [RFC5440], [RFC8231], [RFC8283] and [I-D.ietf-spring-segment-routing]. 3. Use cases 3.1. PCE-based Central Control A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the path while leveraging the existing PCE technologies as much as possible. [I-D.zhao-pce-pcep-extension-for-pce-controller] describe a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCE- based controller will take responsibility for managing some part of the MPLS label space for each of the routers that it controls as described in section 3.1.2. of [RFC8283]. A mechanism for a PCC to inform the PCE of such a label space to control is needed within PCEP. [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that allow a stateful PCE to compute, update or initiate SR-TE paths. [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the mechanism for PCECC to allocate and provision the node/prefix/ adjacency label (SID) via PCEP. To make such allocation PCE needs to be aware of the label space from Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [I-D.ietf-spring-segment-routing] of the node that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS mechanism. Li, et al. Expires December 22, 2018 [Page 4] Internet-Draft PCE Controlled ID Space June 2018 3.2. Binding SID Allocation The headend of an SR Policy binds a binding SID to its policy [I-D.ietf-spring-segment-routing]. The instantiation of which may involve a list of SIDs. Currently binding SID are allocated by the node, but there is an inherent advantage in the binding SID to be allocated by a PCE to allow SR policies to be dynamically created, updated according to the network status and operations. Therefore, a PCE needs to obtain the authority and control to allocate binding SID actively from the PCC's label space as described in above use case. 3.3. Path ID Allocation Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. For identifying an SR path, [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is referred to as Path Segment, and [I-D.li-spring-passive-pm-for-srv6-np] introduces the path ID in SRv6. [I-D.li-pce-sr-path-segment] defines a procedure for path ID in PCEP for SR. It describes a mode in which PCE could allocate path ID and inform the ingress and egress PCC. To make such an allocation a PCE needs to be aware of the path ID space under its control. A mechanism for a PCC to inform the PCE of such a path ID space is needed within PCEP. 4. Overview During PCEP Initialization Phase, Open messages are exchanged between PCCs and PCEs. The OPEN object may also contain a set of TLVs used to convey capabilities in the Open message. The ID could be a MPLS label, SRv6 path ID or any other future ID space for PCE to allocate. A PCC can include a corresponding ID-CONTROL-SPACE TLVs, in the OPEN Object to inform the corresponding ID space information that it wants the PCE to control. This TLV MUST NOT be included by the PCE and MUST be ignored on receipt by a PCC. This is an optional TLV, the PCE could be aware of the ID space from some other means outside of PCEP. For delegating multiple types of ID space, multiple TLVs corresponding to each ID type MUST be included in a Open message. Each TLV (corresponding to each ID type) SHOULD be included only once in a Open Message. On receipt, only the first instance is processed and others MUST be ignored. The ID type can be MPLS label, SRv6 path ID [I-D.li-spring-passive-pm-for-srv6-np] or other ID. The following ID-CONTROL-SPACE TLVs are defined in this document - Li, et al. Expires December 22, 2018 [Page 5] Internet-Draft PCE Controlled ID Space June 2018 o LABEL-CONTROL-SPACE - for MPLS Labels (including for SR-MPLS) o SRv6-PATH-ID-CONTROL-SPACE - for SRv6 Path ID The procedure of ID space control to PCE is shown below: +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | | Open msg (LABEL-CONTROL-SPACE, and/or | | SRv6-PATH-ID-CONTROL-SPACE) | |-------- | | \ Open msg | | \ -----------------------------| | \/ | | /\ | | / ---------------------------->| | / | |<------ Keepalive | | ----------------------------| |Keepalive / | |-------- / | | \/ | | /\ | |<------ ------------------------------>| | | Figure 1: ID space control to PCE If the ID space control procedure is successful, the PCE will return a KeepAlive message to the PCC. If there is any error in processing the corresponding TLV, an Error (PCErr) message will be sent to the PCC with Error-Type=1 (PCEP session establishment failure) and Error- value=TBD (ID space control failure). After this process, a stateful PCE can learn the PCE controlled ID spaces of a node (PCC) under its control. A PCE can then allocate IDs within the control ID space. For example, a PCE can actively allocate labels and download forwarding instructions for the PCECC LSP as described in [I-D.zhao-pce-pcep-extension-for-pce-controller]. A PCE can also allocate labels from SRGB/SRLB for PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr], binding segments, and path segments [I-D.cheng-spring-mpls-path-segment]. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS mechanism. Similarly a PCE can allocate SRv6 Path ID Li, et al. Expires December 22, 2018 [Page 6] Internet-Draft PCE Controlled ID Space June 2018 [I-D.li-spring-passive-pm-for-srv6-np] according to the SRv6 Path ID space under its control. 5. Objects 5.1. Open Object For advertising the PCE controlled ID space to a PCE, this document defines several TLVs within the Open object. 5.1.1. LABEL-CONTROL-SPACE TLV For a PCC to inform the label space under the PCE control, this document defines a new LABEL-CONTROL-SPACE TLV. The LABEL-CONTROL-SPACE TLV is an optional TLV for use in the OPEN object, and its format is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start (1) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (1) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start (n) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (n) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LABEL-CONTROL-SPACE TLV The type (16 bits) of the TLV is TBA. The length field (16 bits) and has a variable value. Flags (32 bits): Following flags are currently defined o A-flag: All space flag, set when all the label space is delegated to a PCE. When A-flag is set, the pair of Start and End SHOULD Li, et al. Expires December 22, 2018 [Page 7] Internet-Draft PCE Controlled ID Space June 2018 NOT appear unless the PCC needs to notify the entire ID space to a PCE. The unassigned bits of Flags field MUST be set to 0 on transmission and MUST be ignored on receipt. Start(i) (24 bits): indicates the beginning of the label block i. Range(i) (24 bits): indicates the range of the label block i. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. The number of label blocks can be calculated according to value of the length field in the TLV. A stateful PCE can actively allocate labels and download forwarding instructions for the PCECC LSP as described in [I-D.zhao-pce-pcep-extension-for-pce-controller]. A PCE can also allocate labels from SRGB/SRLB for PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr] and binding segments can be selected for the PCE controlled space. Also, Path segment [I-D.cheng-spring-mpls-path-segment] can be allocated by a stateful PCE in a similar same way as described in [I-D.li-pce-sr-path- segment]. 5.1.2. SRv6-PATH-ID-CONTROL-SPACE TLV For a PCC to inform the SRv6 path ID space under the PCE control, this document defines a new SRv6-PATH-ID-CONTROL-SPACE TLV. The SRv6-PATH-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN object, and its format is shown in the following figure: Li, et al. Expires December 22, 2018 [Page 8] Internet-Draft PCE Controlled ID Space June 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SRv6-PATH-ID-CONTROL-SPACE TLV The type (16 bits) of the TLV is TBA. The length field (16 bits) and has a variable value. Flags (32 bits): is of same format as LABEL-CONTROL-SPACE TLV. Any bits assigned in the LABEL-CONTROL-SPACE TLV are also applicable for this. Start(i) (32 bits): indicates the beginning of the SRv6 Path ID block i. Range(i) (32 bits): indicates the range of the SRv6 Path ID block i. The number of Path ID blocks can be calculated according to the length field in the TLV. Given the controlled ID spaces, a stateful PCE can actively allocate path IDs to SRv6 paths from the controlled ID spaces as described in [I-D.li-pce-sr-path-segment]. 6. Other Considerations In case of multiple PCEs, a PCC MAY decide to give control over different ID space to each instance of the PCE. In case a PCC includes the same ID space to multiple PCEs, the PCE SHOULD use synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to avoid allocating the same ID. Li, et al. Expires December 22, 2018 [Page 9] Internet-Draft PCE Controlled ID Space June 2018 7. IANA Considerations TBA. 8. Security Considerations TBA. 9. Acknowledgements TBA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, . Li, et al. Expires December 22, 2018 [Page 10] Internet-Draft PCE Controlled ID Space June 2018 10.2. Informative References [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-11 (work in progress), November 2017. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.zhao-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", draft- zhao-pce-pcep-extension-for-pce-controller-08 (work in progress), June 2018. [I-D.zhao-pce-pcep-extension-pce-controller-sr] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work in progress), June 2018. [I-D.litkowski-pce-state-sync] Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Stateful Path Computation Element communication procedures", draft-litkowski-pce-state-sync-03 (work in progress), April 2018. [I-D.cheng-spring-mpls-path-segment] Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. Zhan, "Path Segment in MPLS Based Sement Routing Network", draft-cheng-spring-mpls-path-segment-01 (work in progress), March 2018. Li, et al. Expires December 22, 2018 [Page 11] Internet-Draft PCE Controlled ID Space June 2018 [I-D.li-spring-passive-pm-for-srv6-np] Li, C. and M. Chen, "Passive Performance Measurement for SRv6 Network Programming", draft-li-spring-passive-pm-for- srv6-np-00 (work in progress), March 2018. Authors' Addresses Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China EMail: chengli13@huawei.com Mach(Guoyi) Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China EMail: Mach.chen@huawei.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China EMail: jie.dong@huawei.com Zhenbin Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China EMail: lizhenbin@huawei.com Li, et al. Expires December 22, 2018 [Page 12] Internet-Draft PCE Controlled ID Space June 2018 Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Li, et al. Expires December 22, 2018 [Page 13]