Internet-Draft BGP NRP Policy July 2024
Dong & Zhang Expires 9 January 2025 [Page]
Workgroup:
IDR
Internet-Draft:
draft-dong-idr-bgp-nrp-policy-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Dong
Huawei Technologies
K. Zhang
Huawei Technologies

Advertising Network Resource Partition (NRP) Policy in BGP

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 9 January 2025.

Table of Contents

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 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.

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].

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.

Table 1: BGP-LS Attribute TLVs used for NRP Policy
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.

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.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.

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.

Table 2: BGP SAFI Code Point
Value Description Reference
TBD1 NRP Policy This document

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, , <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>.
[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>.
[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>.
[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, , <https://datatracker.ietf.org/doc/html/draft-dong-idr-bgp-ls-scalable-nrp-01>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm-02>.
[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.

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., 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, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-04>.

Authors' Addresses

Jie Dong
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Ka Zhang
Huawei Technologies
No. 156 Beiqing Road
Beijing
China