PCE Working Group Y. Lee Internet-Draft Samsung Intended status: Standards Track H. Zheng Expires: April 22, 2021 Huawei Technologies D. Ceccarelli Ericsson October 19, 2020 Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks draft-ietf-pce-vn-association-03 Abstract This document describes how to extend Path Computation Element (PCE) Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, to further associate sets of LSPs with a higher-level structure such as a virtual network (VN) requested by clients or applications. This extended association mechanism can be used to facilitate virtual network control using PCE architecture. 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 April 22, 2021. Copyright Notice Copyright (c) 2020 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 Lee, et al. Expires April 22, 2021 [Page 1] Internet-Draft PCE VN Association October 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6 5. Applicability to H-PCE architecture . . . . . . . . . . . . . 7 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. Association Object Type Indicator . . . . . . . . . . . . 9 8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9 8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 10 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 9.1. Control of Function and Policy . . . . . . . . . . . . . 10 9.2. Information and Data Models . . . . . . . . . . . . . . . 10 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 11 9.6. Impact On Network Operations . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction 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. [RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. [RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also Lee, et al. Expires April 22, 2021 [Page 2] Internet-Draft PCE VN Association October 2020 the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance and teardown of PCE- initiated LSPs under the stateful PCE model. [RFC8697] introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define association between sets of LSPs or between a set of LSPs and a set of attributes. [RFC8453] describes various Virtual Network (VN) operations initiated by a customer/application. In this context, there is a need for associating a set of LSPs with a VN "construct" to facilitate VN operations in PCE architecture. This association allows the PCEs to identify which LSPs belong to a certain VN. The PCE could then use this association to optimize all LSPs belonging to the VN together. The PCE could further take VN specific actions on the LSPs such as relaxation of constraints, policy actions, setting default behavior etc. [RFC8637] examines the PCE and ACTN architecture and describes how the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] describes a hierarchy of stateful PCEs with Parent PCE coordinating multi-domain path computation function between Child PCE(s) and thus making it the base for PCE applicability for ACTN. In this text child PCE would be same as Provisioning Network Controller (PNC), and the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453]. This document specifies a PCEP extension to associate a set of LSPs based on Virtual Network (VN) (or customer). A Virtual Network (VN) is a customer view of the TE network. Depending on the agreement between client and provider various VN operations and VN views are possible as described in [RFC8453]. 1.1. Requirement 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. Lee, et al. Expires April 22, 2021 [Page 3] Internet-Draft PCE VN Association October 2020 2. Terminology The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] and [RFC8453]. 3. Operation Overview As per [RFC8697], LSPs are associated with other LSPs with which they interact by adding them to a common association group. An association group based on VN is useful for various optimizations that should be applied by considering all the LSPs in the association. This includes, but not limited to - o Path Computation: When computing path for a LSP, the impact of this LSP, on the other LSPs belonging to the same VN is useful to analyze. The aim would be optimize overall VN and all LSPs, rather than a single LSP. Also, the optimization criteria such as minimize the load of the most loaded link (MLL) [RFC5541] and other could be applied for all the LSP belonging to the same VN, identified by the VN association. o Path Re-Optimization: The child PCE or the parent PCE would like to use advanced path computation algorithm and optimization technique that consider all the LSPs belonging to a VN/customer and optimize them all together during the re-optimization. This association is useful in PCEP session between parent PCE (MDSC) and child PCE (PNC). When computing the path, the child PCE (PNC) refer to the VN association in the request from the parent PCE (MDSC) and maps the VN to the associated LSPs and the network resources. Based on this information, operator policy and various constraints, the path is computed and replied to the parent PCE (MDSC). The VN association information could be included as a part of response as well. The figure describes a typical VN operations using PCEP for illustration purpose. It is worth noting that in a multi-domain scenario, the different domain is controlled by different child PCEs. In order to set up the end-to-end tunnel, multiple segments need to be stitched, by the border nodes in each domain who receives the instruction from their child PCE (PNC). Lee, et al. Expires April 22, 2021 [Page 4] Internet-Draft PCE VN Association October 2020 ****** ..........*MDSC*.............................. . ****** .. MPI . . . . PCEP . . . . PCInitiate LSPx . . . . with VNAG = 10 . . . . . . . . . . . . . v v v . ****** ****** ****** . *PNC1* *PNC2* *PNC4* . ****** ****** ****** . +---------------+ +---------------+ +---------------+ . |A |----| |----| C| . | | | | | | . |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . +------------B13+ +---------------+ +B43------------+ . / . ****** / . *PNC3*<............/..................... ****** / +---------------+/ B31 B34 | | |DOMAIN 3 B| +---------------+ MDSC -> Parent PCE PNC -> Child PCE MPI -> PCEP In this draft, this grouping is used to define associations between a set of LSPs and a virtual network, a new association group is defined below - o VN Association Group (VNAG) One new Association type is defined as described in the Association object - o Association type = TBD1 ("VN Association") for VNAG The scope and handling of VNAG identifier is similar to the generic association identifier defined in [RFC8697] . In this document VNAG object refers to an Association Object with the Association type set to "VNAG". Lee, et al. Expires April 22, 2021 [Page 5] Internet-Draft PCE VN Association October 2020 Local polices on the PCE MAY define the computational and optimization behavior for the LSPs in the VN. An LSP MUST NOT belong to more than one VNAG. If an implementation encounters more than one VNAG, it MUST consider the first occurrence and ignore the others. [RFC8697] specify the mechanism for the capability advertisement of the association types supported by a PCEP speaker by defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the association type described in this document (i.e. VN Association Type) MUST be done before using the policy association. Thus the PCEP speaker MUST include the VN Association Type (TBD1) in the ASSOC-Type-List TLV before using the VNAG in the PCEP messages. This Association-Type is dynamic in nature and created by the Parent PCE (MDSC) for the LSPs belonging to the same VN or customer. These associations are conveyed via PCEP messages to the PCEP peer. Operator-configured Association Range MUST NOT be set for this association-type and MUST be ignored. 4. Extensions to PCEP The format of VNAG is as per the ASSOCIATION object [RFC8697]. This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific information. o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor specific behavioral information, described in [RFC7470]. The format of VIRTUAL-NETWORK-TLV is as follows. 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=TBD2 | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Virtual Network Name // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The VIRTUAL-NETWORK-TLV formats Type: TBD2 (to be allocated by IANA) Lee, et al. Expires April 22, 2021 [Page 6] Internet-Draft PCE VN Association October 2020 Length: Variable Length Virtual Network Name (variable): an unique symbolic name for the VN. It SHOULD be a string of printable ASCII characters, without a NULL terminator. The VN name is a human-readable string that identifies a VN and can be specified with the association information. An implementation could use the VN name to maintain a mapping to the VN association group and the LSPs associated with the VN. The VN name MAY be specified by an operator or auto-generated by the PCEP speaker. The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it MUST send a PCErr message with Error-Type=6 (mandatory object missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close the session. The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 5. Applicability to H-PCE architecture The ability to compute shortest constrained TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can be used for computing end-to-end paths for inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). Within the hierarchical PCE architecture, the parent PCE is used to compute a multi-domain path based on the domain connectivity information. A child PCE may be responsible for a single domain or multiple domains, it is used to compute the intra- domain path based on its domain topology information. [RFC8751] introduces general considerations for stateful PCE(s) in hierarchical PCE architecture. In particular, the behavior changes and additions to the existing stateful PCE mechanisms in the context of a H-PCE architecture. In Stateful H-PCE architecture, the Parent PCE receives a virtual network creation request by its client over its Northbound API. This VN is uniquely identified by an Association ID in VNAG as well as the VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the network in a single domain or across multiple domains. As the Parent PCE computes the optimum E2E paths for each tunnel in VN, it MUST associate each LSP with the VN to which it belongs. Parent PCE sends a PCInitiate Message with this association information in the VNAG Object (See Section 4 for details). This in Lee, et al. Expires April 22, 2021 [Page 7] Internet-Draft PCE VN Association October 2020 effect binds an LSP that is to be instantiated at the child PCE with the VN. Whenever changes occur with the instantiated LSP in a domain network, the domain child PCE reports the changes using a PCRpt Message in which the VNAG Object indicates the relationship between the LSP and the VN. Whenever an update occurs with VNs in the Parent PCE (via the client's request), the parent PCE sends an PCUpd Message to inform each affected child PCE of this change. The Child PCE could then use this association to optimize all LSPs belonging to the same VN association together. The Child PCE could further take VN specific actions on the LSPs such as relaxation of constraints, policy actions, setting default behavior etc. The parent PCE could also maintain all E2E LSP or per-domain path segments under a single VN association. 6. 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". Lee, et al. Expires April 22, 2021 [Page 8] Internet-Draft PCE VN Association October 2020 6.1. Huawei's Proof of Concept based on ONOS The PCE function was developed in the ONOS open source platform. This extension was implemented on a private version as a proof of concept to ACTN. o Organization: Huawei o Implementation: Huawei's PoC based on ONOS o Description: PCEP as a southbound plugin was added to ONOS. To support ACTN, this extension in PCEP is used. Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol o Maturity Level: Prototype o Coverage: Full o Contact: satishk@huawei.com 7. Security Considerations This document defines one new type for association, which do not add any new security concerns beyond those discussed in [RFC5440], [RFC8231] and [RFC8697] in itself. Some deployments may find the Virtual Network Name and the VN associations as extra sensitive; and thus should employ suitable PCEP security mechanisms like TCP-AO [RFC5925] or [RFC8253]. 8. IANA Considerations 8.1. Association Object Type Indicator This document defines a new association type, originally defined in [RFC8697], for path protection. IANA is requested to make the assignment of a new value for the sub-registry "ASSOCIATION Type Field" (request to be created in [RFC8697]), as follows: Value Name Reference TBD1 VN Association Type [This I.D.] 8.2. PCEP TLV Type Indicator This document defines a new TLV for carrying additional information of LSPs within a path protection association group. IANA is Lee, et al. Expires April 22, 2021 [Page 9] Internet-Draft PCE VN Association October 2020 requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows: Value Name Reference TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 8.3. PCEP Error This document defines new Error-Type and Error-Value related to path protection association. IANA is requested to allocate new error values within the "PCEP-ERROR Object Error Types and Values" sub- registry of the PCEP Numbers registry, as follows: Error-Type Meaning 6 Mandatory Object missing Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This I.D.] 9. Manageability Considerations 9.1. Control of Function and Policy An operator MUST BE allowed to mark LSPs that belong to the same VN. This could also be done automatically based on the VN configuration. 9.2. Information and Data Models The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the association between LSPs including VN association. 9.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 9.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. Lee, et al. Expires April 22, 2021 [Page 10] Internet-Draft PCE VN Association October 2020 9.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 9.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440]. 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, . [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, . Lee, et al. Expires April 22, 2021 [Page 11] Internet-Draft PCE VN Association October 2020 10.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, July 2019, . [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . Lee, et al. Expires April 22, 2021 [Page 12] Internet-Draft PCE VN Association October 2020 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, March 2020, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-14 (work in progress), July 2020. Appendix A. Contributors Dhruv Dhody Huawei Technologies Divyashree Technopark, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Qin Wu Huawei Technologies China Email: bill.wu@huawei.com Xian Zhang Huawei Technologies China Email: zhang.xian@huawei.com Authors' Addresses Young Lee Samsung Seoul South Korea Email: younglee.tx@gmail.com Lee, et al. Expires April 22, 2021 [Page 13] Internet-Draft PCE VN Association October 2020 Haomian Zheng Huawei Technologies H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan, Guangdong 523808 China Email: zhenghaomian@huawei.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden Email: daniele.ceccarelli@ericsson.com Lee, et al. Expires April 22, 2021 [Page 14]