IDR J. Dong Internet-Draft K. Zhang Intended status: Standards Track Huawei Technologies Expires: 24 April 2025 L. Gong China Mobile 21 October 2024 Advertising Network Resource Partition (NRP) Policy in BGP draft-dong-idr-bgp-nrp-policy-01 Abstract A Network Resource Partition (NRP) is a subset of the network resources and the associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services or RFC 9543 network slice services. For the instantiation of an NRP, NRP- specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy. This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality. 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 24 April 2025. Dong, et al. Expires 24 April 2025 [Page 1] Internet-Draft BGP NRP Policy October 2024 Copyright Notice Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. BGP Extensions for NRP Policy Advertisement . . . . . . . . . 3 2.1. BGP NRP Policy NLRI . . . . . . . . . . . . . . . . . . . 4 2.2. NRP Policy Attribute . . . . . . . . . . . . . . . . . . 5 3. NRP Policy Operations . . . . . . . . . . . . . . . . . . . . 6 3.1. Advertisement of NRP Policy . . . . . . . . . . . . . . . 6 3.2. Reception of NRP Policy . . . . . . . . . . . . . . . . . 6 3.3. Propagation of NRP Policy . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction [RFC9543] discusses the general framework, the components, and interfaces for requesting and operating network slices using IETF technologies. [RFC9543] also introduces the concept of the Network Resource Partition (NRP), which is a subset of the buffer/queuing/ scheduling resources and associated policies on each of a connected set of links in the underlay network. An NRP can be to support one or a group of RFC 9543 network slice services. [I-D.ietf-teas-enhanced-vpn] specifies the framework of NRP-based enhanced VPNs and describes the candidate component technologies in different network planes and network layers. Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support Dong, et al. Expires 24 April 2025 [Page 2] Internet-Draft BGP NRP Policy October 2024 customers requirements on connectivity services with these enhanced characteristics. RFC 9543 Network Slice is considered as one target use case of enhanced VPNs. An NRP could be used as the underlay of one or a group of enhanced VPN services. To meet the requirement of network slice or enhanced VPN services, a number of NRPs can be created, each with a subset of network resources allocated on network nodes and links in a customized topology of the physical network. The NRP-specific resource and policy information need to be advertised to the set of network nodes involved in the NRP, so that the NRP-specific state can be created, and NRP-specific behavior can be enabled. Such information may be advertised by a network controller, a BGP route reflector, or a BGP speaker which is responsible for the NRP instantiation. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy [I-D.ietf-teas-ns-ip-mpls]. This document specifies the BGP extensions for advertising NRP Policy to the set of network nodes and links. The NRP information is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of BGP Link-State (BGP-LS) Address Family, this allows to reuse the TLVs defined for BGP-LS without impacting the base BGP and BGP-LS functionality. 1.1. 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. 2. BGP Extensions for NRP Policy Advertisement According to [RFC9543], each NRP consists of a subset of network resources and the associated policies on a set of links in the underlay network. BGP-LS [RFC9552] defines the mechanisms for the advertisement of Node, Link, and Prefix NLRI types and their associated attributes via BGP. The NRP-specific resource and policy information can be described as NRP-specific node and link attributes. This document introduces a BGP subsequent address family (SAFI) called "NRP Policy" for the BGP-LS address family. The SAFI value is TBD1. The encoding of the NRP Policy NLRI and the associated attributes are described in the following sub-sections. Dong, et al. Expires 24 April 2025 [Page 3] Internet-Draft BGP NRP Policy October 2024 2.1. BGP NRP Policy NLRI The format of the BGP-LS NLRI is reused for the NRP Policy NLRI. And the encoding of BGP-LS NLRI type "NRP-link" as defined in [I-D.dong-idr-bgp-ls-scalable-nrp] is reused for the NRP Policy Link NLRI. The definition of other NRLI Types for NRP Policy NLRI is for further study. The format of NRP Policy Link NLRI is shown as below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NLRI Type | Total NLRI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NRP Policy NLRI (variable) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Encoding of NRP-Policy NLRI 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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | + (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NRP Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Encoding of NRP-Policy Link NLRI The encoding and semantics of Protocol-ID, Identifier, Local Node Descriptors, Remote Node Descriptors and the Link Descriptors are the same as defined in [RFC9552]. Dong, et al. Expires 24 April 2025 [Page 4] Internet-Draft BGP NRP Policy October 2024 The NRP Descriptors TLV as defined in [I-D.dong-idr-bgp-ls-scalable-nrp] is reused in the NRP Policy NLRI. It contains descriptors of the NRP which the link participates in. This is a mandatory TLV for NRP-Policy Link NLRI. The length of this TLV is variable. The value contains one or more NRP Descriptor sub- TLVs defined in [I-D.dong-idr-bgp-ls-scalable-nrp]. Among the NRP Descriptors Sub-TLVs, the NRP ID sub-TLV is mandatory in the NRP Descriptors. There MUST be only one instance of NRP ID Sub-TLV present in the NRP Descriptors. 2.2. NRP Policy Attribute The BGP-LS Attribute, when associated with an NRP Policy NLRI, is used for the advertisement of the information of the NRP Policy. The NRP Attribute TLVs as defined in [I-D.dong-idr-bgp-ls-scalable-nrp] are reused for the advertisement of NRP Policy information. Specifically, the following NRP Attribute TLVs can be carried in BGP- LS Attribute which is associated with an NRP Policy NLRI. +================+========================+========+ | TLV Code Point | Description | Length | +================+========================+========+ | 1089 | Maximum Link Bandwidth | 4 | +----------------+------------------------+--------+ | TBD | NRP Hierarchy | 4 | +----------------+------------------------+--------+ Table 1: BGP-LS Attribute TLVs used for NRP Policy The Maximum Link Bandwidth TLV as defined in [RFC9552] is used as an NRP Policy Attribute TLV to indicate the set of link bandwidth to be allocated to an NRP. It is mandatory in the BGP-LS Attribute which is associated with an NRP-Policy NLRI. The NRP Hierarchy Attribute TLV as defined in [I-D.dong-idr-bgp-ls-scalable-nrp] is used to indicate the Hierarchy of the NRP. When an NRP is derived from another NRP (called parent NRP), the Parent NRP ID TLV as defined in [I-D.dong-idr-bgp-ls-scalable-nrp]is used to carry the identifier of the parent NRP. Other link attributes MAY also be used as NRP Policy Link Attribute TLVs. The details are for further study. Dong, et al. Expires 24 April 2025 [Page 5] Internet-Draft BGP NRP Policy October 2024 3. NRP Policy Operations This section describes the operation of BGP based NRP Policy. BGP is used for the origination and propagation of the NRP Policy information, while the installation and use of NRP Policy are out of the scope of BGP. 3.1. Advertisement of NRP Policy The NRP Policy information used for NRP instantiation can be computed by a network controller, or derived from the NRP Policy information received from a network slice controller, and originated by a BGP speaker. The NRP Policy information for each network node involved in the NRP could be different. In order to control the target nodes to receive a specific NRP Policy NLRI, one or more Node Target extended communities [I-D.ietf-idr-node-target-ext-comm] SHOULD be attached to the NRP Policy NLRI, where each node target identifies the intended nodes for the advertised NRP Policy information. If the originator has direct BGP peer relationship with an target node of the NRP Policy, the NRP Policy NLRI can be advertised directly to the node, in such a case, the node target extended community MAY not be attached, and the NO_ADVERTISE community MUST be attached. 3.2. Reception of NRP Policy On reception of an NRP Policy NLRI, a BGP speaker first determines if the NRP Policy is valid and eligible. An NRP Policy is considered valid and eligible if the following checks are passed. a. The NRP Policy NLRI and the associated BGP-LS Attribute pass the syntactic validation as described in Section 8.2.2 of [RFC9552]}. b. The BGP Update message of NRP Policy NLRI contains either a node target extended community which identifies the local node, or a NO_ADVERTISE community. c. The NRP Policy Link NLRI identifies a local interface of the network node. d. The bandwidth value of the Maximum link bandwidth TLV in the BGP-LS Attribute is smaller than the unreserved bandwidth of the interface. If the NRP Policy Link NLRI is considered valid and eligible, the BGP speaker performs the decision process for selection of the best route. The selected best route of NRP Policy Link NLRI is used to instantiate the NRP-specific state and behavior on the selected interface of the network node. Dong, et al. Expires 24 April 2025 [Page 6] Internet-Draft BGP NRP Policy October 2024 If one or more node targets are present and none of them matches the local BGP identifier, then the NRP Policy NLRI is not usable on the receiver node. 3.3. Propagation of NRP Policy NRP Policy NLRIs that have the NO_ADVERTISE community attached to them MUST NOT be propagated further. The propagation of NRP Policy NLRIs which are attached with one or more node target extended communities SHOULD follow the rules as specified in [I-D.ietf-idr-node-target-ext-comm]. 4. Security Considerations The security considerations in [RFC4271] and [RFC9552] apply to this document. 5. IANA Considerations IANA is requested to assign a new code point for SAFI "NRP Policy" under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. +=======+=============+===============+ | Value | Description | Reference | +=======+=============+===============+ | TBD1 | NRP Policy | This document | +-------+-------------+---------------+ Table 2: BGP SAFI Code Point 6. Acknowledgements The authors would like to thank XXX for the review and discussion of this document. 7. References 7.1. Normative References [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . Dong, et al. Expires 24 April 2025 [Page 7] Internet-Draft BGP NRP Policy October 2024 [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-20, 14 June 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, . [I-D.dong-idr-bgp-ls-scalable-nrp] Dong, J., Zhu, Y., Hu, Z., Ge, J., and KaZhang, "BGP Link State Extensions for Scalable Network Resource Partition", Work in Progress, Internet-Draft, draft-dong-idr-bgp-ls- scalable-nrp-01, 23 April 2024, . [I-D.ietf-idr-node-target-ext-comm] Dong, J., Zhuang, S., Van de Velde, G., and J. Tantsura, "BGP Extended Community for Identifying the Target Nodes", Work in Progress, Internet-Draft, draft-ietf-idr-node- target-ext-comm-02, 4 March 2024, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . 7.2. Informative References [I-D.ietf-teas-ns-ip-mpls] Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, D., Halpern, J. M., Peng, S., Chen, R., Liu, X., Dong, et al. Expires 24 April 2025 [Page 8] Internet-Draft BGP NRP Policy October 2024 Contreras, L. M., Rokui, R., and L. Jalil, "Realizing Network Slices in IP/MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May 2024, . Authors' Addresses Jie Dong Huawei Technologies No. 156 Beiqing Road Beijing China Email: jie.dong@huawei.com Ka Zhang Huawei Technologies No. 156 Beiqing Road Beijing China Email: zhangka@huawei.com Liyan Gong China Mobile No. 32 Xuanwumenxi Ave., Xicheng District Beijing China Email: gongliyan@chinamobile.com Dong, et al. Expires 24 April 2025 [Page 9]