Internet-Draft | BGP NRP Policy | July 2024 |
Dong & Zhang | Expires 9 January 2025 | [Page] |
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.¶
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 9 January 2025.¶
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.¶
[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 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.¶
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.¶
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.¶
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:¶
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].¶
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.¶
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 |
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
The security considerations in [RFC4271] and [RFC9552] apply to this document.¶
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 |
The authors would like to thank XXX for the review and discussion of this document.¶