| Internet-Draft | BGP-LS for Scalable NRP | October 2024 |
| Dong, et al. | Expires 24 April 2025 | [Page] |
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. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and 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. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation.¶
This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information.¶
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.¶
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.¶
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. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. [RFC9543] discusses the general framework, the components, and interfaces for requesting and operating network slices using IETF technologies. Network slice is considered as one target use case of enhanced VPNs.¶
[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 associated with a logical network topology to select or specify the set of links and nodes involved. [I-D.ietf-teas-enhanced-vpn] specifies the framework of NRP-based enhanced VPN and describes the candidate component technologies in different network planes and network layers. An NRP could be used as the underlay to meet the requirement of one or a group of enhanced VPN services. To meet the requirement of 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 information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. When an NRP spans multiple IGP areas or multiple Autonomous Systems (ASes), BGP-LS [RFC9552] is needed to advertise the NRP information in each IGP area or AS to the network controller, so that the network controller could use the collected information to build the view of inter-area or inter-AS NRPs.¶
This document specifies the BGP-LS mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information.¶
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.¶
BGP-LS [RFC9552] defines the mechanisms for advertisement of Node, Link, and Prefix Link-State NLRI types and their associated attributes via BGP.¶
According to [RFC9543], each NRP consists of a set of dedicated or shared network resources on a connected set of links in the underlay network. Thus a NRP can be defined as the combination of a set of network attributes of network nodes and links, which include the topology attribute, resources attributes, etc.¶
NRP is usually created based on the partitioning of network resources of network links, there are two possible ways for the advertisement of NRP-specific information.¶
The first approach is to advertise the NRP information as link attributes of the layer-3 link using existing BGP-LS Link NLRI. However, this approach may have some scalability problem when the number of NRPs on a layer-3 link becomes large. First of all, the amount of NRP information associated with the link would increase in proportion to the number of NRPs the link participates in, and in some cases the NRP information may not be able to be accommodated in one BGP Update message. Secondly, for a specific link, when the information of only one NRP changes, the link NLRI and all the link attributes and all the associated NRP attributes need to be updated. This would result in unnecessary route advertisement.¶
The second approach is to introduce dedicated BGP-LS NLRI type for the advertisement of NRP-specific information. This way, the information associated with each NRP can be advertised and updated separately. This can alleviate the burden of the problems with the first approach.¶
Thus for better scalability, this document proposes the BGP-LS extensions and mechanisms of the second approach. The NRP information pertaining to a link is advertised via a new BGP-LS NLRI and the associated BGP-LS Attribute as follows:¶
The NRP Identification information and the identifiers of its associated link is carried using a new BGP-LS NRP Link NLRI.¶
The attributes of the NRP on the associated link are carried as TLVs of the associated BGP-LS Attribute.¶
This document focuses on the advertisement of NRP-specific information on the associated network links. The advertisement of NRP-specific information on the associated network nodes are for further study.¶
A new BGP-LS NLRI type called "NRP-link" is defined for advertisement NRP-specific link information. The NLRI-Type is to be assigned by IANA (TBD1). Its format 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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | + (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NRP Descriptors TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding and semantics of Protocol-ID, Identifier, Local Node Descriptors and Remote Node Descriptors are the same as defined in [RFC9552]. If interface and neighbor addresses, either IPv4 or IPv6, are present, then the interface/neighbor address TLVs MUST be included in the Link Descriptors. If the link borrows the address from another interface, then both the Link Local/Remote Identifiers and the interface/neighbor address TLVs MUST be included.¶
The NRP Descriptors TLV contains descriptors of the NRP which the link is associated with. This is a mandatory TLV for NRP-Link NLRIs. The type is to be assigned by IANA (TBD2). The length of this TLV is variable. The value contains one or more NRP Descriptor sub-TLVs defined in Section 2.1.1.¶
In this document, one NRP Descriptors sub-TLV is defined as below:¶
| Sub-TLV Code Point | Description | Length |
|---|---|---|
| TBD3 | NRP ID | 4 |
NRP ID: A 32-bit network-wide unique identifier, which is used to identify an NRP the link is associated with.¶
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 NRP Attribute TLVs are a set of TLVs that may be encoded in the BGP-LS Attribute associated with an NRP-Link NLRI.¶
The following NRP Attribute TLVs can be carried as NRP attribute TLVs.¶
| TLV Code Point | Description | Length |
|---|---|---|
| 1089 | Maximum Link Bandwidth | 4 |
| TBD4 | NRP Hierarchy | 1 |
| TBD5 | Parent NRP ID | 1 |
The Maximum Link Bandwidth TLV as defined in [RFC9552] is used as an NRP Link Attribute TLV to indicate the amount of link bandwidth allocated to an NRP. It is mandatory in BGP-LS Attribute which is associated with an NRP-Link NLRI.¶
Other link attributes MAY also be used as NRP Link Attribute TLVs. The details are for further study.¶
A new NRP Attribute TLV is defined to carry the NRP Hierarchy information. The format of the NRP Hierarchy TLV is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Hierarchy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): TBD4.¶
Length (16 bits): Length of the value field in octets. The value is 1.¶
Flags: 8-bit flags field. The most significant flag is defined in this document. The rest of the flags SHOULD be set to 0 on transmission and MUST be ignored on receipt.¶
+-+-+-+-+-+-+-+-+ |S| | +-+-+-+-+-+-+-+-+
S flag: Secondary NRP. When the S flag is set to 1, it indicates the link of the NRP reuses the interface IP address and L3 control session from its primary link.¶
Hierarchy: Indicates the level to which the NRP belongs. When the value is 1, the NRP is a first-level NRP on the associated link. When the value is 2, the NRP is a second-level NRP on the associated link. By default, two levels of NRPs can be supported.¶
When an NRP is derived from another NRP (called parent NRP), the Parent NRP ID TLV is used to carry the identifier of the parent NRP. The format of the Parent NRP ID TLV is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parent NRP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16 bits): TBD5.¶
Length (16 bits): Length of the value field in octets. The value is 4.¶
Parent NRP ID: The NRP ID of the parent NRP.¶
This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9552].¶
IANA is requested to assign a new code point for "NRP-Link NLRI" under the "BGP-LS NLRI Types" Registry.¶
| Type | NLRI Type | Reference |
|---|---|---|
| TBD1 | NRP Link NLRI | This document |
IANA is requested to assign the following new code points for under the "BGP-LS NLRI and Attribute TLVs" Registry.¶
| TLV Code Point | Description | Reference |
|---|---|---|
| TBD2 | NRP Descriptors | This document |
| TBD3 | NRP ID | This document |
| TBD4 | NRP Hierarchy | This document |
| TBD5 | Parent NRP ID | This document |
The authors would like to thank Mengkai Zhao and Tianle Zhang for the review and discussion of this document.¶