Skip to main content

BGP Link State Extensions for Scalable Network Resource Partition
draft-dong-idr-bgp-ls-scalable-nrp-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Jie Dong , Yongqing Zhu , Zehua Hu , Jun Ge , KaZhang
Last updated 2024-03-04
RFC stream (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-00
IDR                                                              J. Dong
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                  Y. Zhu
Expires: 5 September 2024                                          Z. Hu
                                                           China Telecom
                                                                   J. Ge
                                                                K. Zhang
                                                     Huawei Technologies
                                                            4 March 2024

   BGP Link State Extensions for Scalable Network Resource Partition
                 draft-dong-idr-bgp-ls-scalable-nrp-00

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 5 September 2024                [Page 1]
Internet-Draft           BGP-LS for Scalable NRP              March 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 5 September 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-LS Extensions for NRP Information Advertisement . . . . .   3
     2.1.  BGP-LS NRP Link NLRI  . . . . . . . . . . . . . . . . . .   5
       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 . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   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.  [I-D.ietf-teas-ietf-network-slices]
   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 5 September 2024                [Page 2]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

   [I-D.ietf-teas-ietf-network-slices] 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.

Dong, et al.            Expires 5 September 2024                [Page 3]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

   According to [I-D.ietf-teas-ietf-network-slices], 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.

Dong, et al.            Expires 5 September 2024                [Page 4]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

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:

     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, Remote Node Descriptors and the Link Descriptors are the
   same as defined in [RFC9552].

   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

Dong, et al.            Expires 5 September 2024                [Page 5]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

   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.

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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hierarchy   |
   +-+-+-+-+-+-+-+-+

Dong, et al.            Expires 5 September 2024                [Page 6]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

                  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.

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

Dong, et al.            Expires 5 September 2024                [Page 7]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

                 +======+===============+===============+
                 | 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

   [I-D.ietf-teas-ietf-network-slices]
              Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
              K., Contreras, L. M., and J. Tantsura, "A Framework for
              Network Slices in Networks Built from IETF Technologies",
              Work in Progress, Internet-Draft, draft-ietf-teas-ietf-
              network-slices-25, 14 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slices-25>.

   [I-D.ietf-teas-enhanced-vpn]
              Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
              Framework for NRP-based Enhanced Virtual Private Network",
              Work in Progress, Internet-Draft, draft-ietf-teas-
              enhanced-vpn-17, 25 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              enhanced-vpn-17>.

Dong, et al.            Expires 5 September 2024                [Page 8]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

   [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

   Jun Ge
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: jack.gejun@huawei.com

Dong, et al.            Expires 5 September 2024                [Page 9]
Internet-Draft           BGP-LS for Scalable NRP              March 2024

   Ka Zhang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: zhangka@huawei.com

Dong, et al.            Expires 5 September 2024               [Page 10]