BGP Link State Extensions for Scalable Network Resource Partition
draft-dong-idr-bgp-ls-scalable-nrp-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jie Dong , Yongqing Zhu , Zehua Hu , Liyan Gong , Jun Ge , KaZhang | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dong-idr-bgp-ls-scalable-nrp-02
IDR J. Dong
Internet-Draft Huawei Technologies
Intended status: Standards Track Y. Zhu
Expires: 24 April 2025 Z. Hu
China Telecom
L. Gong
China Mobile
J. Ge
K. Zhang
Huawei Technologies
21 October 2024
BGP Link State Extensions for Scalable Network Resource Partition
draft-dong-idr-bgp-ls-scalable-nrp-02
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/.
Dong, et al. Expires 24 April 2025 [Page 1]
Internet-Draft BGP-LS for Scalable NRP October 2024
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 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-LS Extensions for NRP Information Advertisement . . . . . 3
2.1. BGP-LS NRP Link NLRI . . . . . . . . . . . . . . . . . . 4
2.1.1. NRP Descriptors Sub-TLVs . . . . . . . . . . . . . . 5
2.2. NRP Attribute TLVs . . . . . . . . . . . . . . . . . . . 6
2.2.1. NRP-Hierarchy TLV . . . . . . . . . . . . . . . . . . 6
2.2.2. Parent NRP ID TLV . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Dong, et al. Expires 24 April 2025 [Page 2]
Internet-Draft BGP-LS for Scalable NRP October 2024
[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.
Dong, et al. Expires 24 April 2025 [Page 3]
Internet-Draft BGP-LS for Scalable NRP October 2024
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.
2.1. BGP-LS NRP Link NLRI
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:
Dong, et al. Expires 24 April 2025 [Page 4]
Internet-Draft BGP-LS for Scalable NRP October 2024
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 1: Encoding of NRP-Link NLRI
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.
2.1.1. NRP Descriptors Sub-TLVs
In this document, one NRP Descriptors sub-TLV is defined as below:
+====================+=============+========+
| Sub-TLV Code Point | Description | Length |
+====================+=============+========+
| TBD3 | NRP ID | 4 |
+--------------------+-------------+--------+
Table 1: NRP Descriptor Sub-TLVs
NRP ID: A 32-bit network-wide unique identifier, which is used to
identify an NRP the link is associated with.
Dong, et al. Expires 24 April 2025 [Page 5]
Internet-Draft BGP-LS for Scalable NRP October 2024
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 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.
+================+========================+========+
| TLV Code Point | Description | Length |
+================+========================+========+
| 1089 | Maximum Link Bandwidth | 4 |
+----------------+------------------------+--------+
| TBD4 | NRP Hierarchy | 1 |
+----------------+------------------------+--------+
| TBD5 | Parent NRP ID | 1 |
+----------------+------------------------+--------+
Table 2: NRP Attribute TLVs
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.
Dong, et al. Expires 24 April 2025 [Page 6]
Internet-Draft BGP-LS for Scalable NRP October 2024
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.
Dong, et al. Expires 24 April 2025 [Page 7]
Internet-Draft BGP-LS for Scalable NRP October 2024
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.
+======+===============+===============+
| Type | NLRI Type | Reference |
+======+===============+===============+
| TBD1 | NRP Link NLRI | This document |
+------+---------------+---------------+
Table 3: NRP NLRI Type
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 |
+----------------+-----------------+---------------+
Table 4: NRP related TLV/Sub-TLVs
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, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
Dong, et al. Expires 24 April 2025 [Page 8]
Internet-Draft BGP-LS for Scalable NRP 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, <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, December 2023,
<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, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Jie Dong
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Email: jie.dong@huawei.com
Yongqing Zhu
China Telecom
Guangzhou
China
Email: zhuyq8@chinatelecom.cn
Zehua Hu
China Telecom
Guangzhou
China
Email: huzh2@chinatelecom.cn
Dong, et al. Expires 24 April 2025 [Page 9]
Internet-Draft BGP-LS for Scalable NRP October 2024
Liyan Gong
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China
Email: gongliyan@chinamobile.com
Jun Ge
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Email: jack.gejun@huawei.com
Ka Zhang
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Email: zhangka@huawei.com
Dong, et al. Expires 24 April 2025 [Page 10]