Internet-Draft BGP-LS for Scalable NRP October 2024
Dong, et al. Expires 24 April 2025 [Page]
Workgroup:
IDR
Internet-Draft:
draft-dong-idr-bgp-ls-scalable-nrp-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Dong
Huawei Technologies
Y. Zhu
China Telecom
Z. Hu
China Telecom
L. Gong
China Mobile
J. Ge
Huawei Technologies
K. Zhang
Huawei Technologies

BGP Link State Extensions for Scalable Network Resource Partition

Abstract

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.

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.

Table of Contents

1. Introduction

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.

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-LS Extensions for NRP Information Advertisement

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:

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.

2.2. NRP Attribute TLVs

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.

Table 2: 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.

2.2.1. NRP-Hierarchy TLV

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   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoding of NRP Hierarchy TLV

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|             |
+-+-+-+-+-+-+-+-+
Figure 3: Flags Field of NRP Hierarchy TLV

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.

2.2.2. Parent NRP ID TLV

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                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Encoding of Parent NRP ID TLV

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.

3. Security Considerations

This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9552].

4. IANA Considerations

IANA is requested to assign a new code point for "NRP-Link NLRI" under the "BGP-LS NLRI Types" Registry.

Table 3: NRP NLRI Type
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.

Table 4: NRP related TLV/Sub-TLVs
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

5. Acknowledgements

The authors would like to thank Mengkai Zhao and Tianle Zhang for the review and discussion of this document.

6. 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, , <https://www.rfc-editor.org/info/rfc9543>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-20>.
[RFC9552]
Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, , <https://www.rfc-editor.org/info/rfc9552>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Jie Dong
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Yongqing Zhu
China Telecom
Guangzhou
China
Zehua Hu
China Telecom
Guangzhou
China
Liyan Gong
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China
Jun Ge
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Ka Zhang
Huawei Technologies
No. 156 Beiqing Road
Beijing
China