Advertising Network Resource Partition (NRP) Policy in BGP
draft-dong-idr-bgp-nrp-policy-01
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 , KaZhang , Liyan Gong | ||
| 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-nrp-policy-01
IDR J. Dong
Internet-Draft K. Zhang
Intended status: Standards Track Huawei Technologies
Expires: 24 April 2025 L. Gong
China Mobile
21 October 2024
Advertising Network Resource Partition (NRP) Policy in BGP
draft-dong-idr-bgp-nrp-policy-01
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 24 April 2025.
Dong, et al. Expires 24 April 2025 [Page 1]
Internet-Draft BGP NRP Policy October 2024
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 Extensions for NRP Policy Advertisement . . . . . . . . . 3
2.1. BGP NRP Policy NLRI . . . . . . . . . . . . . . . . . . . 4
2.2. NRP Policy Attribute . . . . . . . . . . . . . . . . . . 5
3. NRP Policy Operations . . . . . . . . . . . . . . . . . . . . 6
3.1. Advertisement of NRP Policy . . . . . . . . . . . . . . . 6
3.2. Reception of NRP Policy . . . . . . . . . . . . . . . . . 6
3.3. Propagation of NRP Policy . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
Dong, et al. Expires 24 April 2025 [Page 2]
Internet-Draft BGP NRP Policy October 2024
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.
Dong, et al. Expires 24 April 2025 [Page 3]
Internet-Draft BGP NRP Policy October 2024
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].
Dong, et al. Expires 24 April 2025 [Page 4]
Internet-Draft BGP NRP Policy October 2024
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.
+================+========================+========+
| TLV Code Point | Description | Length |
+================+========================+========+
| 1089 | Maximum Link Bandwidth | 4 |
+----------------+------------------------+--------+
| TBD | NRP Hierarchy | 4 |
+----------------+------------------------+--------+
Table 1: BGP-LS Attribute TLVs used for NRP Policy
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.
Dong, et al. Expires 24 April 2025 [Page 5]
Internet-Draft BGP NRP Policy October 2024
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.1. Advertisement of NRP Policy
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.
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.
Dong, et al. Expires 24 April 2025 [Page 6]
Internet-Draft BGP NRP Policy October 2024
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.
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| TBD1 | NRP Policy | This document |
+-------+-------------+---------------+
Table 2: BGP SAFI Code Point
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, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
Dong, et al. Expires 24 April 2025 [Page 7]
Internet-Draft BGP NRP Policy 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>.
[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>.
[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>.
[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, 23 April 2024,
<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, 4 March 2024,
<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, January 2006,
<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.,
Dong, et al. Expires 24 April 2025 [Page 8]
Internet-Draft BGP NRP Policy October 2024
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, 28 May
2024, <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
Email: jie.dong@huawei.com
Ka Zhang
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Email: zhangka@huawei.com
Liyan Gong
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China
Email: gongliyan@chinamobile.com
Dong, et al. Expires 24 April 2025 [Page 9]