Network                                                     Shaofu. Peng
Internet-Draft                                                  Bin. Tan
Intended status: Standards Track                         ZTE Corporation
Expires: July 1, 2022                                  December 28, 2021


                    BGP Metric Credit Based Routing
                  draft-peng-idr-bgp-metric-credit-00

Abstract

   This document defines an optional metric related BGP path attribute
   that can be advertised with BGP intent routes, to provide more clear
   intent information used for the next-hop resolution.

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 July 1, 2022.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Peng & Tan                Expires July 1, 2022                  [Page 1]


Internet-Draft              BGP Metric Credit              December 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Extensions for BGP Route Metric . . . . . . . . . . . . . . .   4
     2.1.  Extensions for Metric Type and Metric . . . . . . . . . .   4
     2.2.  Extensions for Metric Credit  . . . . . . . . . . . . . .   4
   3.  Process of Received Metric Credit . . . . . . . . . . . . . .   6
     3.1.  Only Total Metric Credit Provided . . . . . . . . . . . .   6
     3.2.  Metric Credit Piece Provided  . . . . . . . . . . . . . .   7
     3.3.  Select Underlay Path According to Suggested Metric Credit   7
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Example of Intent with Average Metric Credit  . . . . . .   8
     4.2.  Example of Intent with Metric Credit Piece  . . . . . . .  10
     4.3.  Example of Intent Shared by Multiple Path . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   In large-scale networks across multiple domains, BGP can be used to
   advertise intent route and provide end-to-end intent aware path.
   According to corresponding intent information, a BGP intent route
   selects the expected underlay path for the next hop resolution.  The
   underlay path may be an MPLS-TE tunnel, an SR policy, an IGP Flex-
   algo route, or a direct link, established segment by segment based on
   the same intent.

   There are many methods to make BGP carry intent information during
   route advertisement.

      [I-D.zhou-idr-inter-domain-lcu] describe a simple method, termed
      as BGP-LU color, combined with [RFC7911], to create multiple BGP-
      LU color path to the same destination, using color as intent
      identifier.

      [I-D.kaliraj-idr-bgp-classful-transport-planes] defines new
      "Classful Transport" SAFI NLRI and "Transport Class" Route Target
      extended community, to advertise intent based routes with related
      Transport Class identifier as intent identifier.

      [I-D.dskc-bess-bgp-car] defines new "BGP CAR" SAFI NLRI that
      contains a Color field as intent identifier to advertise intent
      based routes.




Peng & Tan                Expires July 1, 2022                  [Page 2]


Internet-Draft              BGP Metric Credit              December 2021


      [I-D.lp-lsr-bgp-algorithm] introduces Algorithm Extended Community
      to advertise BGP algorithm routes, using algorithm as intent
      identifier.

   Once a BGP speaker received an intent route advertised from neighbor,
   it will check the related intent template in local.  The intent
   template could be a Color template, a Flex-algorithm Definition, or
   some other modules.  The intent template contains a set of
   constraints, such as the reserved bandwidth to be provided in the
   path, the boundary minimum and maximum delay, the boundary delay
   jitter, the boundary packet loss rates, including or excluding
   specific nodes or links, limiting the calculation of the path in a
   specific virtual network, and so on.  The detailed intent information
   itself are not recommended to be directly carried in the advertised
   route.

   On the ingress PE node in the network, a BGP intent route to the
   egress PE will be selected according to the service SLA.  The intent
   template configured on the ingress PE node is generally consistent
   with the service SLA.  However this does not mean that the intent
   template configured on the intermediate nodes should also be
   consistent with the service SLA.  For example, the SLA of the service
   is to "provide a path with an upper delay boundary of 100ms from
   ingress PE to egress PE".  In this case, the upper delay of 100ms
   refers to end-to-end delay constraint, not for each segment.  A
   possible method is to include different delay constraints in the
   intent template configured on different BGP speakers along the path.
   However, this static configuration method has shortcomings, because
   an intent template is not necessarily bound to a specific end-to-end
   path and may be used for multiple paths.

   It can be seen that the information contained in the intent template
   is not enough to represent the complete intent.  This often occurs on
   cumulable metric attributes.

   This document describes extensions to carry the metric credit
   information in the BGP route advertisement, as a supplement to the
   intent template, so that the BGP speaker receiving the BGP intent
   route can establish (or select) the underlay path to the downstream
   BGP speaker with more accurate intent indication.

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.



Peng & Tan                Expires July 1, 2022                  [Page 3]


Internet-Draft              BGP Metric Credit              December 2021


2.  Extensions for BGP Route Metric

   This section describes some extensions related to metric, so that
   when BGP speaker advertise intent route to upstream neighbors, it
   carries optional metric type, metric, and metric credit information.

2.1.  Extensions for Metric Type and Metric

   [RFC7311] defines AIGP Attribute to represent basic IGP default
   metric type and its cumulative value.
   [I-D.ssangli-idr-bgp-generic-metric-aigp] defines extensions to the
   AIGP attribute to carry Generic Metric sub-types, to meet more metric
   types, such as Min Unidirectional delay metric defined in [RFC8570],
   TE Default Metric defined in [RFC5305], Bandwidth Metric defined in
   [I-D.ietf-lsr-flex-algo-bw-con], etc.

   This document reuse the above definitions.

2.2.  Extensions for Metric Credit

   A new path attribute type (TBD): METRIC-CREDIT attribute, is
   introduced in this document.  It is an optional non-transitive
   attribute, which is used to specify end-to-end total metric credit,
   estimated BGP hop counts, and metric credit piece information.

   The format of attribute value is shown below.

  +----------------------------------------------------+
  | Count of Sources (1 octet)                         |
  +----------------------------------------------------+
  | Flags (1 octet)                                    | <--- 1st Source
  +----------------------------------------------------+
  // Network Address of Source (variable)             //
  +----------------------------------------------------+
  | Total Metric Credit for Source (4 octets)          |
  +----------------------------------------------------+
  | Estimated BGP Hops Count for Source (1 octet)      |
  +----------------------------------------------------+
  // Current Hop Number (1 octet)                     //
  +----------------------------------------------------+
  // Metric Credit Piece [Hops Count] (variable)      //
  +----------------------------------------------------+
  //   ...  For other Sources     ...                 // <--- 2nd Source
  +----------------------------------------------------+

               Figure 1: Metric Credit Path Attribute Format





Peng & Tan                Expires July 1, 2022                  [Page 4]


Internet-Draft              BGP Metric Credit              December 2021


   Count of Sources (1 octet): Indicates how many sources (i.e. ingress
   PE) have corresponding metric credit information.

   Flags (1 octet): Currently three flags are defined.

                    0 1 2 3 4 5 6 7
                   +-+-+-+-+-+-+-+-+
                   |S|F|P|         |
                   +-+-+-+-+-+-+-+-+

                                 Figure 2

      S-Flag: Source Address Flag.  The Network Address of Source field
      is included when S-Flag is set, and not included when unset.

      F-Flag: Address Family Flag.  Indicate the address family of the
      Network Address of Source field. 0 for 32 bits IPv4 address, 1 for
      128 bits IPv6 address.

      P-Flag: Piece Flag.  Indicates whether specific metric credit
      piece information (Current Hop Number field and Metric Credit
      Piece [] field) is included.

   Network Address of Source (variable octets): Represents the IP
   address of the source.  When S-flag is 0, this field does not exist;
   When S-flag is 1 and F-flag is 0, this field is a 32-bits IPv4
   address; When S-flag is 1 and F-flag is 1, this field is a 128-bits
   IPv6 address.  If this field does not exist, it means that the metric
   credit information is independent of the specific source.  This
   generally occurs in the scenario that want to control the
   establishment of intent paths according to the metric credit in
   coarse granularity.  For example, in a small administrative domain,
   when the egress PE advertise BGP intent routes to multiple ingress
   PEs, only a single unified metric credit information for all source
   is carried.

   Total Metric Credit for Source (4 octets): Represents the total
   metric credit from a specific ingress PE (or any source, when the
   Network Address of Source field does not exist) to egress PE.

   Estimated BGP Hops Count for Source (1 octet): Represents the
   estimated number of BGP hops from a specific ingress PE (or any
   source, when the Network Address of Source field does not exist) to
   egress PE.  Only those BGP speakers who modified BGP next hop to self
   when receiving BGP intent route are counted.

   Current Hop Number (1 octet): Represents the current index of the
   array Metric Credit Piece[].  Note that when P-flag is 0, the



Peng & Tan                Expires July 1, 2022                  [Page 5]


Internet-Draft              BGP Metric Credit              December 2021


   "Current Hop Number" and "Metric Credit Piece[]" fields do not exist.
   In the BGP intent route advertisement originated from egress PE, the
   initial value of Current Hop Number is 0; When the BGP intent route
   advertisement received by an upstream BGP speaker and the BGP speaker
   modifies the BGP next hop to self, it read the item from the array
   Metric Credit Piece[] using Current Hop Number as index, to obtain
   the metric credit piece that is available from the current BGP
   speaker to the neighbor of the downstream BGP speaker.  When the BGP
   speaker continue to advertise the route to the upstream BGP speaker
   neighbor and modify BGP next hop to self, it increase the Current Hop
   Number by 1.  Note that when using Current Hop Number as index to
   read items from the array Metric Credit Piece[], it must avoid array
   out of bounds.

   Metric Credit Piece[] (variable octets): Is an array.  The number of
   items is specified by Estimated BGP Hops Count for Source.  Each item
   occupies 3 bytes (in microseconds) for each BGP speaker along the
   intent path.  There are strict restrictions on the use of Metric
   Credit Piece[], i.e., BGP intent route must be advertised to a
   specific ingress PE hop by hop in strict accordance with the
   propagated path expected by egress PE.  When an exception occurs,
   e.g., a BGP speaker finds that the Current Hop Number value in the
   received BGP intent route is greater than or equal to the Estimated
   BGP Hops Count for Source value, then it must stop using Metric
   Credit Piece[] for BGP next hop resolution.

3.  Process of Received Metric Credit

   When a BGP speaker receives BGP intent route with metric credit
   information from neighbors, it obtains the intent identififer from
   the route advertisement, looks up the intent template locally to
   obtain the detailed intent information, and selects underlay path
   according to the intent information.

   The metric credit attribute information contained in the route
   advertisement can provide a suggested metric credit value for this
   BGP speaker to select underlay path destinated to the downstream
   neighbor BGP speaker.

3.1.  Only Total Metric Credit Provided

   If the metric credit attribute only contains the total metric credit
   related to the source, but does not contain the explicit metric
   credit piece information, then for each source:

      Let metric_residual_value = "Total Metric Credit for Source" -
      "metric of AIGP Attribute"




Peng & Tan                Expires July 1, 2022                  [Page 6]


Internet-Draft              BGP Metric Credit              December 2021


      Let average_metric_credit_value = "Total Metric Credit for Source"
      / "Estimated BGP Hops Count for Source"

      The suggested metric credit for the current segment is the minimum
      value of metric_residual_value (note: negative values need to be
      excluded) and average_metric_credit_value for all sources.

3.2.  Metric Credit Piece Provided

   If the BGP intent route advertisement also contains explicit metric
   credit piece information, then:

      Let explicit_metric_credit_piece_value = Metric Credit
      Piece[Current Hop Number]

      The suggested metric credit for the current segment is the minimum
      value of metric_residual_value (note: negative values need to be
      excluded) and explicit_metric_credit_piece_value for all sources.

   It is recommonded that this option is mainly used in the case that
   only a single source related metric credit piece information is
   included in the intent route that is advertised to a single ingress
   PE.  Multiple source related metric credit piece information may
   bring conflicts and cause inaccurate suggested metric credit.

   To include explicit BGP speaker list in the route advertisement and
   specify metric credit piece for each segment, will be described in
   the next version.

3.3.  Select Underlay Path According to Suggested Metric Credit

   The purpose of suggested metric credit is to restrict that the
   cumulative metric of the resolved underlay path cannot exceed the
   expected value.  However, in some cases, if the BGP speaker finds
   that there is no underlay path that can meet the suggested value,
   this constraint can be relaxed appropriately by local policy.

   For the BGP intent route installed on the received BGP speaker, the
   metric value is updated to the metric of AIGP attribute plus the
   cumulative metric of the underlay path for the corresponding metric
   type.

4.  Examples








Peng & Tan                Expires July 1, 2022                  [Page 7]


Internet-Draft              BGP Metric Credit              December 2021


4.1.  Example of Intent with Average Metric Credit

   As shown in Figure 3, it contains two IGP domains.  BGP neighbors are
   established between PE1 and ABR, ABR and PE2, to advertise BGP intent
   routes.  Egress PE2 advertise its loopback route, loopback-PE2, to
   ABR through BGP, and carries intent identifier and metric credit
   attribute.


          +---------P1---------+    +---------P4---------+
         /          |           \  /          |           \
        PE1---------P2----------ABR-----------P5----------PE2
         \          |           /  \          |           /
          +---------P3---------+    +---------P6---------+

        |<---- IGP domain 1 ---->||<---- IGP domain 2 ---->|

        TE-path-11: PE1-P1-ABR   TE-path-12: ABR-P4-PE2
        TE-path-21: PE1-P3-ABR   TE-path-22: ABR-P6-PE2

                    Figure 3: Inter-area Intent Routing

   There are two services to communicate between ingress PE1 and egress
   PE2.  The intent of the first service is that the end-to-end total
   delay of the transport path used shall not exceed 10ms, for the
   intent of the second service, it is 100ms.  Since two intent aware
   paths need to be instantiated between the same source/destination for
   two services, in general, two intent identifiers, intent-1000 and
   intent-2000, need to be configured on the egress PE2.

   The intent-1000 template may have the following configuration:

      metric-type: Unidirectional Link Delay (ms)

      total-metric-credit: 10 (ms)

      metric-credit enabled

   The intent-2000 template may have the following configuration:

      metric-type: Unidirectional Link Delay (ms)

      total-metric-credit: 100 (ms)

      metric-credit enabled

   The above intent template are also configured in other BGP speakers
   (i.e., ABR and PE1).  However, it should be noted that since the



Peng & Tan                Expires July 1, 2022                  [Page 8]


Internet-Draft              BGP Metric Credit              December 2021


   intent template contains the metric credit enabled command, these BGP
   speakers, for the matched intent routes that are not originated from
   themselvs, will not select the underlay path to the downstream BGP
   speaker neighbor only according to the total metric contained in the
   intent template.  Instead, they should obtain the suggested metric
   credit from the received BGP intent route, and then select the
   appropriate underlay path that meets the suggested metric credit.

   The total metric credit included in the intent template is mainly
   used for egress PE2 to generate metric credit information that is
   encoded in the originated intent route.  Other BGP speakers (non
   initiator) cannot directly use it to select underlay paths.

   PE2 advertises two BGP intent routes, <prefix = loopback-PE2, intent-
   id = 1000> and <prefix = loopback-PE2, intent-id = 2000>, which are
   advertised to ABR respectively.  The BGP next hop in the advertised
   route is set to PE2.

   The metric related information encoded in <prefix = loopback-PE2,
   intent-id = 1000> is:

      metric-type: Unidirectional Link Delay

      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1

         S-Flag = 1, F-Flag = 0, P-Flag = 0

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 10

         Estimated BGP Hops Count for Source: 2

   Similarly, the metric related information encoded in <prefix =
   loopback-PE2, intent-id = 2000> is:

      metric-type: Unidirectional Link Delay

      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1




Peng & Tan                Expires July 1, 2022                  [Page 9]


Internet-Draft              BGP Metric Credit              December 2021


         S-Flag = 1, F-Flag = 0, P-Flag = 0

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 100

         Estimated BGP Hops Count for Source: 2

   After receiving the first route advetisement, ABR knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor PE2 is 5ms, i.e., the average metric credit 5, the residual
   metric credit 10, taking the minimum one, then select an ultra-low
   delay path not exceeding 5ms to progress PE2, assuming TE path-12 in
   Figure 3.

   After receiving the second route advetisement, ABR knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor PE2 is 50ms, i.e., the average metric credit 50, the
   residual metric credit 100, taking the minimum one, then select a low
   delay path not exceeding 50ms to progress PE2, assuming TE path-22 in
   Figure 3.

   ABR continues to advertise the above two BGP intent routes to the
   upstream BGP speaker neighbor PE1, where the metric is accumulated by
   the selected underlay path, the BGP next hop is modified to ABR, and
   the metric credit information is unchanged.

   After receiving the first route advetisement, PE1 knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor ABR is 5ms, i.e., the average metric credit 5, the residual
   metric credit 6, taking the minimum one, then select an ultra-low
   delay path to ABR, assuming TE path-11 in Figure 3.

   After receiving the second route advetisement, PE1 knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor ABR is 50ms, i.e., the average metric credit 50, the
   residual metric credit 60, taking the minimum one, then select a low
   delay path to ABR, assuming TE path-12 in Figure 3.

4.2.  Example of Intent with Metric Credit Piece

   Based on the first example, assume that two IGP domains are managed
   by a single provider, which is familiar with the performance of the
   network, and the propagated path of BGP intent route is clear, then,
   intent template may include explicit metric credit piece information.

   Thus the intent routes originated from PE2 will contain more
   information related with metric credit piece.



Peng & Tan                Expires July 1, 2022                 [Page 10]


Internet-Draft              BGP Metric Credit              December 2021


   The metric related information encoded in <prefix = loopback-PE2,
   intent-id = 1000> is:

      metric-type: Unidirectional Link Delay

      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1

         S-Flag = 1, F-Flag = 0, P-Flag = 1

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 10

         Estimated BGP Hops Count for Source: 2

         Current Hop Number: 0

         Metric Credit Piece [2]: [0] = 4, [1] = 6

   Similarly, the metric related information encoded in <prefix =
   loopback-PE2, intent-id = 2000> is:

      metric-type: Unidirectional Link Delay

      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1

         S-Flag = 1, F-Flag = 0, P-Flag = 1

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 100

         Estimated BGP Hops Count for Source: 2

         Current Hop Number: 0

         Metric Credit Piece [2]: [0] = 40, [1] = 60

   After receiving the first route advetisement, ABR knows that the
   suggested metric credit from itself to the downstream BGP speaker



Peng & Tan                Expires July 1, 2022                 [Page 11]


Internet-Draft              BGP Metric Credit              December 2021


   neighbor ABR is 4ms, i.e., the explicit metric credit piece 4, the
   residual metric credit 10, taking the minimum one, then select an
   ultra-low delay path to PE2, assuming TE path-12 in Figure 3.

   After receiving the second route advetisement, ABR knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor ABR is 40ms, i.e., the explicit metric credit piece 40, the
   residual metric credit 100, taking the minimum one, then select a low
   delay path to PE2, assuming TE path-22 in Figure 3.

   ABR continues to advertise the above two BGP intent routes to the
   upstream BGP speaker neighbor PE1, where the metric is accumulated by
   the selected underlay path, the BGP next hop is modified to ABR, and
   the Current Hop Number is incremented by 1.

   After receiving the first route advetisement, PE1 knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor ABR is 6ms, i.e., the explicit metric credit piece 6, the
   residual metric credit 6, taking the minimum one, then select an
   ultra-low delay path to ABR, assuming TE path-11 in Figure 3.

   After receiving the second route advetisement, PE1 knows that the
   suggested metric credit from itself to the downstream BGP speaker
   neighbor ABR is 60ms, i.e., the explicit metric credit piece 60, the
   residual metric credit 60, taking the minimum one, then select a low
   delay path to ABR, assuming TE path-12 in Figure 3.

4.3.  Example of Intent Shared by Multiple Path

   As shown in Figure 4, it contains three AS.  BGP neighbors are
   established between PE1 and ASBR1, ASBR1 and ASBR2, ASBR1 and ASBR3,
   ASBR2 and PE2, ASBR3 and PE3, to advertise BGP intent routes carrying
   intent identifier and metric credit attribute.


















Peng & Tan                Expires July 1, 2022                 [Page 12]


Internet-Draft              BGP Metric Credit              December 2021


    +---------P1---------+            +--------P4---------+
   /          |           \          /         |           \
 PE1---------P2----------ASBR1---ASBR2---------P5----------PE2
   \          |           /  \       \         |           /
    +---------P3---------+    \       +--------P6---------+
                               \
                                \
                                 \      +---------P7---------+
                                  \    /          |           \
                                   +--ASBR3-------P8----------PE3
                                       \          |           /
                                        +---------P9---------+
 TE-path-11:PE1-P1-ASBR1 TE-path-12:ASBR1-ASBR2 TE-path-13: ASBR2-P4-PE2
 TE-path-21:PE1-P3-ASBR1 TE-path-22:ASBR1-ASBR3 TE-path-23: ASBR3-P7-PE3

                     Figure 4: Inter-AS Intent Routing

   In this example, the same type of service needs to communicate
   between PE1 and PE2, PE1 and pE3.  The intent of this type of service
   is the specific value related to the end-to-end total delay and
   distance of the transport path used.

   PE2 and pE3 will respectively config the intent templates with the
   same intent identifier, e.g., intent-1000.

   The intent-1000 template configured on PE2 have the following
   configuration:

      metric-type: Unidirectional Link Delay (ms)

      total-metric-credit: 200 (ms)

      metric-credit enabled

   The intent-1000 template also configured on PE3 have the following
   configuration:

      metric-type: Unidirectional Link Delay (ms)

      total-metric-credit: 300 (ms)

      metric-credit enabled

   PE2 advertises BGP intent route, <prefix = loopback-PE2, intent-id =
   1000>, which is advertised to ASBR2.  The metric related information
   encoded is:

      metric-type: Unidirectional Link Delay



Peng & Tan                Expires July 1, 2022                 [Page 13]


Internet-Draft              BGP Metric Credit              December 2021


      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1

         S-Flag = 1, F-Flag = 0, P-Flag = 0

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 200

         Estimated BGP Hops Count for Source: 3

   Similarly, PE3 advertises BGP intent route, <prefix = loopback-PE3,
   intent-id = 1000>, which is advertised to ASBR3.  The metric related
   information encoded is:

      metric-type: Unidirectional Link Delay

      metric: assume an initial value of 0

      metric-credit information:

         Count of Sources: 1

         S-Flag = 1, F-Flag = 0, P-Flag = 0

         Network Address of Source: loopback-PE1

         Total Metric Credit for Source: 300

         Estimated BGP Hops Count for Source: 3

   Then, ASBR2 and ASBR3 will use the suggested metric credit 66 and
   100, taking minimum value from residual metric credit and average
   metric credit, to select the transport path for <prefix = loopback-
   PE2, intent-id = 1000> and <prefix = loopback-PE3, intent-id = 1000>
   respectively, assuming TE path-13 with cumulated metric 60 and TE
   path-23 with cumulated metric 100 in Figure 4.

   Similarly, ASBR1 will also use suggested metric credit 66 and 100, to
   select the transport path for <prefix = loopback-PE2, intent-id =
   1000> and <prefix = loopback-PE3, intent-id = 1000> respectively,
   assuming TE path-12 with cumulated metric 10 and TE path-22 with
   cumulated metric 10 in Figure 4.





Peng & Tan                Expires July 1, 2022                 [Page 14]


Internet-Draft              BGP Metric Credit              December 2021


   Similarly, PE1 will also use suggested metric credit 66 and 100, to
   select the transport path for <prefix = loopback-PE2, intent-id =
   1000> and <prefix = loopback-PE3, intent-id = 1000> respectively,
   assuming TE path-11 with cumulated metric 60 and TE path-21 with
   cumulated metric 100 in Figure 4.

5.  IANA Considerations

   This document request the METRIC_CREDIT entry to the "BGP Path
   Attributes" registry:

         +=======+=========================+================+
         | Value | Code                    |    Reference   |
         +=======+=========================+================+
         | TBD   | METRIC_CREDIT           | This Document  |
         +-------+-------------------------+----------------+

6.  Security Considerations

   TBD

7.  Acknowledgements

   TBD

8.  Normative References

   [I-D.dskc-bess-bgp-car]
              Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
              Steinberg, D., Jalil, L., Su, Y., Decraene, B., Guichard,
              J., Patel, K., and H. Wang, "BGP Color-Aware Routing
              (CAR)", draft-dskc-bess-bgp-car-03 (work in progress),
              October 2021.

   [I-D.ietf-lsr-flex-algo-bw-con]
              Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak,
              P., and T. Li, "Flexible Algorithms: Bandwidth, Delay,
              Metrics and Constraints", draft-ietf-lsr-flex-algo-bw-
              con-01 (work in progress), July 2021.

   [I-D.kaliraj-idr-bgp-classful-transport-planes]
              Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
              Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D.
              J. Gowda, "BGP Classful Transport Planes", draft-kaliraj-
              idr-bgp-classful-transport-planes-12 (work in progress),
              August 2021.





Peng & Tan                Expires July 1, 2022                 [Page 15]


Internet-Draft              BGP Metric Credit              December 2021


   [I-D.lp-lsr-bgp-algorithm]
              Yao, L. and P. Shaofu, "Advertisement of Algorithm in
              BGP", draft-lp-lsr-bgp-algorithm-00 (work in progress),
              March 2021.

   [I-D.ssangli-idr-bgp-generic-metric-aigp]
              Sangli, S., Hegde, S., Das, R., and B. Decraene, "Generic
              Metric for the AIGP attribute", draft-ssangli-idr-bgp-
              generic-metric-aigp-01 (work in progress), July 2021.

   [I-D.zhou-idr-inter-domain-lcu]
              Chen, R., Dai, C., and S. Peng, "Inter-domain Network
              Slicing via BGP-LU", draft-zhou-idr-inter-domain-lcu-02
              (work in progress), January 2021.

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

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC7311]  Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
              "The Accumulated IGP Metric Attribute for BGP", RFC 7311,
              DOI 10.17487/RFC7311, August 2014,
              <https://www.rfc-editor.org/info/rfc7311>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.

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

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

Authors' Addresses







Peng & Tan                Expires July 1, 2022                 [Page 16]


Internet-Draft              BGP Metric Credit              December 2021


   Shaofu Peng
   ZTE Corporation
   China

   Email: peng.shaofu@zte.com.cn


   Bin Tan
   ZTE Corporation
   China

   Email: tan.bin@zte.com.cn







































Peng & Tan                Expires July 1, 2022                 [Page 17]