Generic Metric for the AIGP attribute
draft-ssangli-idr-bgp-generic-metric-aigp-01

Document Type Active Internet-Draft (individual)
Authors Srihari Sangli  , Shraddha Hegde  , Reshma Das  , Bruno Decraene 
Last updated 2021-07-26
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
IDR                                                            S. Sangli
Internet-Draft                                                  S. Hegde
Intended status: Standards Track                                  R. Das
Expires: 27 January 2022                           Juniper Networks Inc.
                                                             B. Decraene
                                                                  Orange
                                                            26 July 2021

                 Generic Metric for the AIGP attribute
              draft-ssangli-idr-bgp-generic-metric-aigp-01

Abstract

   This document defines extensions to the AIGP attribute to carry
   Generic Metric sub-types.  This is applicable when multiple domains
   exchange BGP routing information.  The extension will aid in intent-
   based end-to-end path selection.

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 27 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Sangli, et al.           Expires 27 January 2022                [Page 1]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Multiple Metric types . . . . . . . . . . . . . . . . . . . .   4
   4.  Issues with RFC7311 . . . . . . . . . . . . . . . . . . . . .   5
   5.  Generic Metric TLV  . . . . . . . . . . . . . . . . . . . . .   6
   6.  Usage of Generic-Metric TLV . . . . . . . . . . . . . . . . .   6
   7.  Updates to Decision Procedure . . . . . . . . . . . . . . . .   8
   8.  Use-case: Different Metrics across Domains  . . . . . . . . .   9
   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  10
   10. Contiguity Compliance . . . . . . . . . . . . . . . . . . . .  11
   11. Backward Compatibility  . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     15.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Large Networks belonging to an enterprise may consist of nodes in the
   order of thousands and may span across multiple IGP domains where
   each domain can run separate IGPs or levels/areas.  BGP may be used
   to interconnect such IGP domains, with one or more IGP domains within
   an Autonomous System.  The enterprise network can have multiple
   Autonomous Systems and BGP may be employed to provide connectivity
   between these domains.  Furthermore, BGP can be used to provide
   routing over a large number of such independent administrative
   domains.

   The traffic types have evolved over years and operators have resorted
   to defining different metric types within a IGP domain (ISIS or OSPF)
   for IGP path computation.  An operator may want to create an end-to-
   end path that satisfy certain intent.  The intent could be to create
   end-to-end path that minimizes one of the metric-types.  Some metrics
   can be assigned administratively by an operator and they are

Sangli, et al.           Expires 27 January 2022                [Page 2]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   described in the base ISIS, OSPF specifications.  Other metrics, for
   example, are the Traffic Engineering Default Metric defined in
   [RFC5305] and [RFC3630], Min Unidirectional delay metric defined in
   [RFC8570] and [RFC7471].  There may be other metrics such as jitter,
   reliability, fiscal cost, etc. that an operator may wish to express
   as the cost of a link.  The procedures mentioned in the above
   specifications describe the IGP path computation within IGP domains.

   With the advent of 5G applications and Network Slicing applications,
   an operator may wish to provision end-to-end paths across multiple
   domains to cater to traffic constraints.  This is also known as
   intent-based inter-domain routing and there are certain architectures
   being developed as described in
   [I-D.hegde-spring-seamless-sr-architecture] and
   [I-D.dskc-bess-bgp-car-problem-statement].  The Clasful Transport
   Planes as described in
   [I-D.kaliraj-idr-bgp-classful-transport-planes] and Color-Based
   Routing as described in [I-D.dskc-bess-bgp-car] describe how end-to-
   end intent-based paths can be established.  The proposal described in
   this document can be used in conjunction with such architectures.

   When multiple domains are interconnected via BGP, protocol extensions
   for advertising best-external path and/or ADDPATH as described in
   [RFC7911] are employed to take advantage of network connectivity thus
   providing alternate paths.  The Color-Based Routing and Classful
   Transport Planes routing proposals describe approaches that result in
   alternate paths for a reaching one destination.  During the BGP best
   path computation, the step(e) as per section 9.1.2.2 of [RFC4271],
   the interior cost of a route as determined via the IGP metric value
   can be used to break the tie.  In a network spanning multiple IGP
   domains, the AIGP TLV encoded within the AIGP attribute described in
   [RFC7311] can be used to compute the AIGP-enhanced interior cost to
   be used in the decision process for selecting the best path as
   documented in section 2 of [RFC7311].  The [RFC7311] specifies how
   AIGP TLV can carry the accumulated IGP metric value.

   There is a need to synchronize the metric-type values carried between
   IGP and BGP in order to avoid operational overhead of translation
   between them.  The existing AIGP TLV carries a TLV type and metric-
   value where TLV type does not map to IGP metric-types defined in the
   IGP metric-type registry.  Hence there is a need to provide a generic
   metric template to embed the IGP metric-type values within the AIGP
   attribute.  This document extends the AIGP attribute for carrying
   Generic-Metric TLV and the well-defined sub metric types.  This
   document also provides procedures for handling Generic-Metric during
   the BGP best path computation.

Sangli, et al.           Expires 27 January 2022                [Page 3]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

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

3.  Multiple Metric types

   Consider the network as shown in Figure 1.  The network has multiple
   domains.  Each domain runs a separate IGP instance.  Within each
   domain iBGP sessions are established between the PE routers. eBGP
   sessions are established between the Border Routers across domains.
   An operator wishes to compute end-to-end path optimized for a metric-
   type delay.  Each domain will be enabled to compute the IGP paths
   based on metric-type delay.  Such values should also be propagated to
   the adjacent domains for effective end-to-end path computation.

              ------IBGP-----EBGP------IBGP------EBGP------IBGP-----
              |             |     |             |     |             |

              +-------------+     +-------------+     +-------------+
              |             |     |             |     |             |
              |          ASBR1+--+ASBR2      ASBR3+--+ASBR4         |
              |             | . . |             | . . |             |
           PE1+   Domain1   |  .  |   Domain2   |  .  |   Domain3   +PE2
              |             | . . |             | . . |             |
              |          ASBR5+--+ASBR6      ASBR7+--+ASBR8         |
              |             |     |             |     |             |
              +-------------+     +-------------+     +-------------+

              |----ISIS1----|     |----ISIS2----|     |----ISIS3----|

                        Figure 1: WAN Network

   The AIGP TLV in the AIGP attribute as specified in [RFC7311] supports
   the IGP default metric.  If all domains use IGP cost as the metric,
   then one can compute the end-to-end path with shortest IGP cost.
   However if an operator wishes to compute the end-to-end path with
   metric other than IGP cost, we need additional extensions to the AIGP
   attribute for carry the metric-types and metric values.

Sangli, et al.           Expires 27 January 2022                [Page 4]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   The [I-D.ietf-lsr-flex-algo-bw-con] proposes a generic metric type
   that can embed multiple metric types within it.  It supports both
   standard metric-types and user-defined metric-types.  This document
   leverages the generic-metric draft and proposes extensions to the
   AIGP attribute to carry Generic Metric TLV as specified below.

4.  Issues with RFC7311

   The following procedures are not clearly described in [RFC7311].

   *  The section 3 describes "When an AIGP attribute is created, it
      SHOULD contain no more than one AIGP TLV.  However, if it contains
      more than one AIGP TLV, only the first one is used as described in
      Sections 3.4 and 4.  In the remainder of this document, we will
      use the term value of the AIGP TLV to mean the value of the first
      AIGP TLV in the AIGP attribute.  Any other AIGP TLVs in the AIGP
      attribute MUST be passed along unchanged if the AIGP attribute is
      passed along."

   *  ....One MUST interpret that more than one TLV of a particular type
      (i.e.  AIGP TLV metric-type 1) can be present in the update and
      only the first occurance MUST be analysed.  All other TLVs (type 2
      or type 3 etc.)  MUST be passed along unchanged if AIGP attribute
      is passed along.

   *  The section 3.2 describes "Note that an AIGP attribute MUST NOT be
      considered to be malformed because it contains more than one TLV
      of a given type or because it contains TLVs of unknown types."

   *  ....One MUST interpret that opaque TLVs (TLVs with type 2 or type
      3 for example) MUST be passed along if ADVERTISE_AIGP_ATTRIBUTE
      has been enabled to a neighbor.

   *  Section 3.3 describes "The AIGP attribute MUST NOT be sent on any
      BGP session for which AIGP_SESSION is disabled."

   *  ....While maintaining the non-transitivity is important, it is
      also important to provide accumulated cost end-to-end across
      domains.  If there are more than one TLVs in the AIGP attribute,
      it becomes important to define the behavior of which TLV gets
      updated and sent across domains.

   *  The rules for route redistribution is not clearly described.

Sangli, et al.           Expires 27 January 2022                [Page 5]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   *  ....When a BGP route is redistributed, should AIGP metric-value be
      used directly as the cost in IGP or should there be a policy to
      modify AIGP metric-value before redistributing the route into IGP.
      It is important to define the behavior of route redistribution
      metric conversion when redistribution occurs on multiple domains
      along the path.

5.  Generic Metric TLV

   This document proposes a new TLV : Generic-Metric TLV in the AIGP
   attribute.  This will carry the metric type and metric value used in
   the network.  The format is shown below.

        0                 1                   2                   3
        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 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type    |             Length            |  metric-type  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |              metric-value                                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................

                        Figure 2: Generic-Metric TLV

      Generic-Metric TLV Type (1 octet): Code point to be assigned by
      IANA

      Generic-Metric TLV Length (2 octets): 12

      Generic-Metric TLV Value (9 octets): 2 sub-fields as shown below:

      1. metric-type (1 octet): Value from IGP metric-type registry.

      2. metric-value (8 octets): Value range (0 - 0xffffffffffffffff)

6.  Usage of Generic-Metric TLV

      1.  When a BGP speaker wishes to generate AIGP attribute with
      Generic-Metric TLV for a prefix, it MUST perform the following
      procedures.

      -  The procedures specified in [RFC7311] section 3.4 should be
         followed that describes creation of attribute, modifications by
         the originator and non-originator of the route.

      -  Repeated metric changes may cause large number of BGP updates
         to get generated and be propagated throughout the network.  In
         order to avoid that, a configurable threshold is defined.  If

Sangli, et al.           Expires 27 January 2022                [Page 6]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

         the difference between the new metric-value and the advertised
         metric-value is less than the configured threshold, the update
         MAY be suppressed.  If the new metric-value is above the
         configured threshold, a new BGP update containing the new
         metric-value SHOULD be advertised.

      -  If the domain uses a metric type other than IGP cost for the
         IGP path computation, the BGP speaker MAY add Generic-Metric
         TLV to the AIGP attribute before advertising to a neighboring
         BGP speaker.

      -  The metric-type sub-field in the Generic-Metric TLV will carry
         the value indicating the type of the metric as specified in the
         IGP metric-type registry.

      -  The value of the metric or cost to reach the prefix being
         advertised will be encoded in the metric-value sub-field.  This
         is the cost or the distance to the destination prefix from the
         advertising BGP speaker which sets itself as the next hop as
         described in section 3.4 of [RFC7311].

      -  Procedures for defining the cost to reach a next hop for
         various metric-types is outside the scope of this document.

      2.  When a BGP speaker wishes to send a BGP update attaching the
      AIGP attribute, it must validate if that session has been enabled
      for sending the AIGP attribute as per procedures mentioned in
      [RFC7311].

      3.  When a BGP speaker receives a BGP update that has a route to T
      with next hop N and has the AIGP attribute with Generic-Metric TLV
      it MUST perform the following procedures.

      -  It must validate if that session has been enabled to receive
         the AIGP attribute as per rules mentioned in [RFC7311].

      -  If the BGP speaker does not recognize the Generic-Metric TLV or
         type of metric encoded in metric-type subfield of the TLV, then
         the BGP speaker will ignore the Generic-Metric TLV and follow
         the BGP decision procedure as specified in [RFC7311].

      -  If the metric-type of the path used for resolving the next hop
         N matches with the metric-type of Generic-Metric TLV of the
         AIGP attribute, then the metric-value sub-field MUST be used in
         the AIGP-enhanced interior cost computation as specified in the
         next section.

Sangli, et al.           Expires 27 January 2022                [Page 7]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

      -  If the metric-type of the path used for resolving the next hop
         N does not match with the metric-type of Generic-Metric TLV of
         the AIGP attribute, then the BGP speaker may normalize cost of
         the path used for resolving the next hop.  A policy may be used
         to provide the metric normalization.

7.  Updates to Decision Procedure

   This section follows the approach as laid out in [RFC7311] to select
   the best path when the route has AIGP attribute with Generic-Metric
   TLV.  The domain that the router R belongs to, has enabled metric-
   types different from IGP cost.  The following describes procedures in
   addition to general procedure described in section 4 of [RFC7311].

   When R receives a route T with next hop N and the AIGP attribute with
   Generic-Metric TLV, and the metric-type sub-field matches with the
   type of the metric of the path used for resolving the next hop N, the
   AIGP-enhanced interior cost should be computed as below.

      Let m be the cost to reach the next hop N that IGP uses for its
      path computation as described in [RFC7311].

   If the type of the metric of the path used for resolving the next hop
   N does not match the metric-type sub-field of the Generic-Metric TLV,
   the cost of the path to reach next hop N may be normalized.  The
   normalized metric value can be zero, maximum metric value or scaled
   up (multiple of a positive number).

      Let m be the normalized value of the cost to reach the next hop N
      that IGP uses for its path computation as described in [RFC7311].

   The AIGP-enhanced interior cost computation as described below will
   be used in the decision process as described in [RFC7311].

      Let A be the value of the value of the metric-value sub-field of
      the Generic-Metric TLV.

      The AIGP-enhanced interior cost will be A+m as described in
      [RFC7311].

   A path with Generic-Metric TLV and a path with AIGP TLV cannot be
   compared.  To enable end-to-end path selection based on intent, the
   with Generic-Metric TLV MUST be chosen over path with AIGP TLV.  The
   implementation should allow a local policy to specify the preference.

Sangli, et al.           Expires 27 January 2022                [Page 8]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   A path with Generic-Metric TLV of metric-type 'a' cannot be compared
   with a path with Generic-Metric TLV of metric-type 'b'.  The path
   with lower metric-type MUST be chosen as best between two paths with
   Generic-Metric TLV.

8.  Use-case: Different Metrics across Domains

                                   +--------------+
                                   |   Domain2    |
                                   |              |
                             ......+ASBR21  ASBR22+....
                             .     |              |   .
              +------------+ .     |  igp-metric  |   . +--------------+
              |  Domain1   | .     +--------------+   . |    Domain4   |
              |            | .                        . |              |
              |      ASBR11+..                        ..+ASBR41        |
              +PE1         |                            |           PE2+
              |      ASBR12+..                        ..+ASBR42        |
              |            | .                        . |              |
              | IGP-metric | .                        . | delay-metric |
              +------------+ .     +--------------+   . +--------------+
                             .     |   Domain3    |   .
                             .     |              |   .
                             ......+ASBR31  ASBR32+....
                                   |              |
                                   | delay-metric |
                                   +--------------+

              Figure 3: Different metric across network

   Each domain is a separate Autonomous System.  Within each domain,
   ASBR and PE form iBGP peering.  The IGP within each domain uses
   domain specific metric.  Domain3 and Domain4 use delay as the metric
   while Domain1 and Domain2 use IGP cost as the metric.  ASBRs across
   domains form eBGP peering.  The use-case is to find delay-based end-
   to-end path from Domain1 to Domain4.

   This can be achieved by the advertising router to add the AIGP
   attribute with metric type 1 that represents delay metric.  In the
   above network diagram, ASBR41 (and ASBR42) will advertise prefix
   PE2-loopback with Generic-Metric TLV with delay as metric-type.  The
   metric-value sub-field of the Generic-Metric TLV will represent the
   cost to reach PE2's loopback end-point from the advertising router as
   they will do next hop self.

Sangli, et al.           Expires 27 January 2022                [Page 9]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   In Domain3, when ASRB32 advertises the prefix PE2-loopback within the
   local domain, it may add cost to the metric-value, the value
   representing the delay introduced by the DMZ link between ASRB32 to
   ASBR42.  When ASRBR31 advertises the prefix PE2-lookback, it will
   perform the following procedures.

      1.  Compute the delay d of the path to reach ASBR32 from which it
      has chosen the best path.

      2.  Add the above d value to the metric-value sub-field of the
      Generic-Metric TLV.

   In Domain2 however, the local metric type IGP cost.  The ASBR22 may
   follow the procedure similar to ASBR32 and add the delay value
   corresponding to the DMZ link between ASBR22 and ASBR41 before
   advertising the path internally in Domain2.  When ASBR21 computes the
   AIGP-enhanced interior cost, as mentioned before, it may normalize
   the igp cost to reach ASBR22 and may add the normalized value to the
   delay-metric.  In the above network example, the delay cost from
   ASBR21 to ASBR22 is negligible and hence delay-metric value will be
   unchanged.

   The procedures for AIGP-enhanced interior cost computation at ASBR11
   (and ASBR12) will follow DMZ delay computation procedure described
   above.  PE1 will have two paths to reach PE2-loopback: P1 via ASBR11
   (and domain2) and P2 via ASBR12 (and domain3), each having respective
   AIGP-enhanced interior cost representing end-to-end delay.  The BGP
   decision process described in Section 7 will result in delay
   optimized end-to-end path for PE2-loopback on PE1 that can be used to
   resolve the service prefixes.

9.  Deployment Considerations

   It can be noted that a domain may normalize the metric-value of the
   metric-type of the path used to resolve next hop to the metric-type
   present in the Generic-Metric TLV.  The idea is to propagate the cost
   of reaching the prefix through the domain while maintaining the
   metric-type chosen by the originating router and domain.  The
   normalization of metric types to the one carried in the AIGP
   attribute can be done via policy.  Definition of such policies and
   how they can be enforced is outside the scope of this document.  In
   topologies where there is a common router between adjacent domains
   that do iBGP peering, the Border router can provide the
   normalization.

   It is important to maintain the property of IGP cost to a destination
   decrease as one gets closer to the destination.  The AIGP-enhanced
   interior cost should not be allowed to decrease through the metric

Sangli, et al.           Expires 27 January 2022               [Page 10]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   normalization.  When adjacent domains use different metric types, the
   ASBR that connects two domains is better suited to pass on the metric
   values by setting itself as next hop.

   All routers of a domain MUST compute the AIGP-enhanced interior cost
   as described above to be used during decision process.  Within a
   domain, if one router R1 applies AIGP-enhanced interior cost while R2
   does not, it may lead to routing loop unless some sort of tunnelling
   technology viz MPLS, SRv6, IP, etc. is adopted to reach the next hop.
   In a network where any tunnelling technology is used, one can
   incrementally deploy the Generic-Metric functionality.  In a network
   without any tunnelling technology, it is recommended that all routers
   MUST support Generic-Metric based AIGP-enhanced interior cost
   computation.

   The contiguity of the AIGP domain across multiple IGP or AS domains
   is important to maintain end-to-end path of a certain intent.  A
   router that does not recognize Generic-Metric TLV, may add AIGP TLV
   and pass on the BGP route with just AIGP TLV.  This results in AIGP
   attribute having both TLVs.  The router making decision only on
   Generic-Metric TLV may chose sub-optimal paths.

   In certain networks, routes may be redistributed between BGP and IGP,
   usually controlled via a policy.  When a route is propagated across
   domains, a router should use AIGP metric-value of Generic-Metric TLV,
   optionally modified via the local policy as the IGP cost during route
   redistribution in to IGP.  The local policy should apply metric
   normalization or translation based on metric-type of Generic-Metric
   TLV and the metric-type adopted in the IGP.

10.  Contiguity Compliance

   AIGP attribute is optional and non-transitive, however new TLV might
   not be interpreted and/or updated by routers along the path.  For
   computing the end-to-end path based on an intent, it is essential to
   maintain contiguity of AIGP domain for the metric-type.  The
   mechanism will be addressed in the future version of this document.

11.  Backward Compatibility

   When a BGP speaker receives an update with the AIGP attribute it may
   have Generic-Metric TLV.  If the BGP speaker understands the AIGP
   attribute but does not understand the Generic-Metric TLV, it will
   process the AIGP attribute as per [RFC7311].  However when it needs
   to advertise the prefix to its peers it will pass on the AIGP
   attribute with all the TLVs including the unknown Generic-Metric TLV
   as per [RFC7311].  If a BGP speaker does not understand the Generic-
   Metric TLV, it may chose sub-optimal BGP path.

Sangli, et al.           Expires 27 January 2022               [Page 11]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

12.  Security Considerations

   This document does not introduce any new security considerations
   beyond those already specified in [RFC4271], [RFC7311].

13.  IANA Considerations

   IANA is requested to assign a code point for Generic Metric TLV.  The
   metric-type field refers to the IGP metric-type registry defined in
   [I-D.ietf-lsr-flex-algo-bw-con]

14.  Acknowledgements

   The authors would like to thank John Scudder, Jeff Haas, Robert
   Raszuk, and Kaliraj Vairavakkalai for careful review and suggestions.

15.  References

15.1.  Normative References

   [I-D.dskc-bess-bgp-car]
              Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
              Steinberg, D., Jalil, L., Su, Y., Guichard, J., Patel, K.,
              and H. Wang, "BGP Color-Aware Routing (CAR)", Work in
              Progress, Internet-Draft, draft-dskc-bess-bgp-car-02, 11
              May 2021, <https://www.ietf.org/archive/id/draft-dskc-
              bess-bgp-car-02.txt>.

   [I-D.dskc-bess-bgp-car-problem-statement]
              Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
              Decraene, B., Steinberg, D., Jalil, L., Guichard, J.,
              Patel, K., and W. Henderickx, "BGP Color-Aware Routing
              Problem Statement", Work in Progress, Internet-Draft,
              draft-dskc-bess-bgp-car-problem-statement-03, 23 May 2021,
              <https://www.ietf.org/archive/id/draft-dskc-bess-bgp-car-
              problem-statement-03.txt>.

   [I-D.hegde-spring-seamless-sr-architecture]
              Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A.,
              Uttaro, J., Jalil, L., Khaddam, M., and A. Alston,
              "Seamless Segment Routing Architecture", Work in Progress,
              Internet-Draft, draft-hegde-spring-seamless-sr-
              architecture-00, 22 February 2021,
              <https://www.ietf.org/archive/id/draft-hegde-spring-
              seamless-sr-architecture-00.txt>.

Sangli, et al.           Expires 27 January 2022               [Page 12]
Internet-Draft      Generic Metric for AIGP attribute          July 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", Work in Progress, Internet-
              Draft, draft-ietf-lsr-flex-algo-bw-con-01, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-
              bw-con-01.txt>.

   [I-D.kaliraj-idr-bgp-classful-transport-planes]
              Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
              Mishra, G., Khaddam, M., Xu, X., and R. J. Szarecki, "BGP
              Classful Transport Planes", Work in Progress, Internet-
              Draft, draft-kaliraj-idr-bgp-classful-transport-planes-10,
              12 July 2021, <https://www.ietf.org/archive/id/draft-
              kaliraj-idr-bgp-classful-transport-planes-10.txt>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

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

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

15.2.  Informative References

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

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

Sangli, et al.           Expires 27 January 2022               [Page 13]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
              <https://www.rfc-editor.org/info/rfc4659>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

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

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

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

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/info/rfc8277>.

   [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

   Srihari Sangli
   Juniper Networks Inc.
   Exora Business Park
   Bangalore 560103

Sangli, et al.           Expires 27 January 2022               [Page 14]
Internet-Draft      Generic Metric for AIGP attribute          July 2021

   KA
   India

   Email: ssangli@juniper.net

   Shraddha Hegde
   Juniper Networks Inc.
   Exora Business Park
   Bangalore 560103
   KA
   India

   Email: shraddha@juniper.net

   Reshma Das
   Juniper Networks Inc.
   1133 Innovation Way
   Sunnyvale, CA 94089
   United States of America

   Email: dreshma@juniper.net

   Bruno Decraene
   Orange
   France

   Email: bruno.decraene@orange.com

Sangli, et al.           Expires 27 January 2022               [Page 15]