Internet DRAFT - draft-hr-spring-intentaware-routing-using-color

draft-hr-spring-intentaware-routing-using-color







SPRING                                                          S. Hegde
Internet-Draft                                     Juniper Networks Inc.
Intended status: Informational                                    D. Rao
Expires: 25 April 2024                                     Cisco Systems
                                                               J. Uttaro
                                                 Independent Contributor
                                                             A. Bogdanov
                                                                      BT
                                                                L. Jalil
                                                                 Verizon
                                                         23 October 2023


  Problem statement for Inter-domain Intent-aware Routing using Color
           draft-hr-spring-intentaware-routing-using-color-03

Abstract

   This draft describes the scope, set of use-cases and requirements for
   a distributed routing based solution to establish end-to-end intent-
   aware paths spanning multi-domain packet networks.  The document
   focuses on BGP given its predominant use in inter-domain routing
   deployments, however the requirements may also apply to other
   solutions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 25 April 2024.




Hegde, et al.             Expires 25 April 2024                 [Page 1]

Internet-Draft      Intent-aware Routing using Color        October 2023


Copyright Notice

   Copyright (c) 2023 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Objectives  . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Typical large scale network deployment scenarios  . . . . . .   4
     2.1.  5G access networks  . . . . . . . . . . . . . . . . . . .   4
     2.2.  WAN networks for Content distribution . . . . . . . . . .   5
     2.3.  Data Center Inter-connect Networks  . . . . . . . . . . .   6
   3.  Use Cases for Inter-domain Intent-based Transport . . . . . .   7
     3.1.  Inter-domain Data Sovereignty . . . . . . . . . . . . . .   7
     3.2.  Inter-domain Low-Latency Services . . . . . . . . . . . .   8
     3.3.  Inter-domain Service Function Chaining  . . . . . . . . .   8
     3.4.  Inter-domain Multicast Use cases  . . . . . . . . . . . .   9
   4.  Deployment use cases  . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Network Domains under different administration  . . . . .   9
   5.  Intent-Aware Routing Framework  . . . . . . . . . . . . . . .  10
     5.1.  Intent  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Color . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Colored Service Route . . . . . . . . . . . . . . . . . .  11
     5.4.  Intent-Aware Route using Color  . . . . . . . . . . . . .  11
     5.5.  Service Route Automated Steering on intent-aware route
           using color . . . . . . . . . . . . . . . . . . . . . . .  11
     5.6.  Inter-Domain intent-aware routing using colors with SR
           Policy  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.7.  Motivation for a BGP-based intent-aware routing solution
           using colors  . . . . . . . . . . . . . . . . . . . . . .  11
     5.8.  BGP Intent-Aware Routing using Color  . . . . . . . . . .  12
     5.9.  Architectural consistency among intent-aware routing
           solutions using colors  . . . . . . . . . . . . . . . . .  12
   6.  Technical Requirements  . . . . . . . . . . . . . . . . . . .  14
     6.1.  Intent Requirements . . . . . . . . . . . . . . . . . . .  14
       6.1.1.  Transport Network Intent Requirements . . . . . . . .  15
       6.1.2.  VPN (Service Layer) Network Intent Requirements . . .  23
       6.1.3.  Multicast Intent Requirements . . . . . . . . . . . .  29



Hegde, et al.             Expires 25 April 2024                 [Page 2]

Internet-Draft      Intent-aware Routing using Color        October 2023


     6.2.  Traffic Steering Requirements . . . . . . . . . . . . . .  29
     6.3.  Deployment Requirements . . . . . . . . . . . . . . . . .  30
       6.3.1.  Multi-domain deployment designs . . . . . . . . . . .  30
       6.3.2.  Scalability Requirements  . . . . . . . . . . . . . .  38
       6.3.3.  Network Availability Requirements . . . . . . . . . .  40
       6.3.4.  BGP Protocol Requirements . . . . . . . . . . . . . .  41
       6.3.5.  OAM Requirements  . . . . . . . . . . . . . . . . . .  43
   7.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  43
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  43
   11. Co-authors  . . . . . . . . . . . . . . . . . . . . . . . . .  44
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  46
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     13.2.  Informative References . . . . . . . . . . . . . . . . .  46
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50

1.  Introduction

   Evolving trends in wireless access technology, cloud applications,
   virtualization, and network consolidation all contribute to the
   increasing demands being placed on a common packet network.  In order
   to meet these demands, a given network will need to scale
   horizontally in terms of its bandwidth, absolute number of nodes, and
   geographical extent.  The same network will need to extend vertically
   in terms of the different services and variety of intent that it
   needs to simultaneously support.

   In order to operate networks with large numbers of devices, network
   operators organize networks into multiple smaller network domains.
   Each network domain typically runs an IGP which has complete
   visibility within its own domain, but limited visibility outside of
   its domain.  Network operators will continue to use multiple domains
   to scale horizontally.  In MPLS based networks BGP-LU (RFC8277) has
   been widely deployed for providing reachability across multiple
   domains.

   The evolving network requirements (e.g. 5G, native cloud) in such a
   multi-domain network requires the establishment of paths that span
   multiple domains or AS's while maintaining specific transport
   characteristics or intent (e.g. bandwidth, latency).  There is also a
   need to provide flexible, scalable, and reliable end-to-end
   connectivity for multiple services across the network domains.







Hegde, et al.             Expires 25 April 2024                 [Page 3]

Internet-Draft      Intent-aware Routing using Color        October 2023


1.1.  Objectives

   This document describes requirements for scalable, intent-aware
   reachability across multiple domains.

   The base problem that it focuses on is the BGP-based delivery of an
   intent across several transport domains, however the requirements may
   also apply to other distributed solutions.

   The problem space is then widened to include any intent (including
   Network Function Virtualization (NFV) chains and their location), any
   data plane and the application of intent-based routing to the
   Service/VPN routes.

   It is intended that the requirements enable the design of technology
   and protocol extensions that address the widest application, while
   ensuring consistency and compatibility with existing deployed
   solutions.

2.  Typical large scale network deployment scenarios

   This section describes a few typical deployment scenarios that
   involve large-scale multi-domain network designs and use of various
   topology, IGP and BGP routing models.  While the examples use
   specific types of deployments for illustration, neither the use-cases
   nor the network designs are limited to any particular provider
   deployment.

2.1.  5G access networks

   Service Provider networks can contain many nodes distributed over a
   large geographic area. 5G networks can include as many as one million
   nodes, with the majority of those being radio access nodes.  Radio
   and access nodes may be constrained by their memory and processing
   capabilities.

   Such transport networks use multiple domains to support scalability.
   For this analysis, we consider a representative network design with
   four level of hierarchy: access domains, pre-aggregation domains,
   aggregation domains and a core.  (See Figure 1).  The separation of
   domains internal to the service provider can be performed by using
   either IGP or BGP.









Hegde, et al.             Expires 25 April 2024                 [Page 4]

Internet-Draft      Intent-aware Routing using Color        October 2023


                 +-------+   +-------+   +------+   +------+
                 |       |   |       |   |      |   |      |
              +--+ P-AGG1+---+ AGG1  +---+ ABR1 +---+ LSR1 +--> to ABR
             /   |       |  /|       |   |      |   |      |
      +----+/    +-------+\/ +-------+   +------+  /+------+
      | AN |              /\                     \/
      +----+\    +-------+  \+-------+   +------+/\ +------+
             \   |       |   |       |   |      |  \|      |
              +--+ P-AGG2+---+ AGG2  +---+ ABR2 +---+ LSR2 +--> to ABR
                 |       |   |       |   |      |   |      |
                 +-------+   +-------+   +------+   +------+

      ISIS L1       ISIS L2                   ISIS L2

      |-Access-|--Aggregation Domain--|---------Core-----------------|


                            Figure 1: 5G network

   5G networks support a variety of service use cases that may require
   end to-end network slicing.  In certain cases, the end-to-end
   connectivity requires the ability to forward over intent-aware paths,
   such as paths delivering low-delay.  The inter-domain routing
   solution should support the establishment of end to end paths that
   address specific intent requirements, as well as support multiple
   such paths to address slicing requirements.

2.2.  WAN networks for Content distribution

   Networks built for providing delivery of content are geographically
   distributed by design to provide connectivity in multiple regions and
   sharing of data across regions.

   As these WAN networks grow beyond several thousand nodes, they are
   divided into multiple IGP domains for scale and reliability.  An
   illustration is provided in in Figure 2.















Hegde, et al.             Expires 25 April 2024                 [Page 5]

Internet-Draft      Intent-aware Routing using Color        October 2023


                 +-------+     +-------+     +-------+
                 |       |     |       |     |       |
                 |     ABR1  ABR2    ABR3   ABR4     |
                 |       |     |       |     |       |
              PE1+   D1  +-----+  D2   +-----+   D3  +PE2
                 |       |     |       |     |       |
                 |     ABR11  ABR22  ABR33  ABR44    |
                 |       |     |       |     |       |
                 +-------+     +-------+     +-------+


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


                 Figure 2: Content distribution WAN Example

   These large WAN networks often cross national boundaries.  In order
   to meet data sovereignty requirements, operators need to maintain
   strict control over end-to-end traffic-engineered (TE) paths.  A
   distributed inter-domain solution should be able to create highly
   constrained inter domain TE paths in a scalable manner.

   Some deployments may use a controller to acquire the topologies of
   multiple domains and build end-to-end constrained paths.  This
   approach can be scaled with hierarchical controllers.  However, there
   is still a risk of a loss of network connectivity to one or more
   controllers, which could lead to a failure to satisfy the strict
   requirements of data sovereignty.  The network should be able to have
   pre-established TE paths end-to-end that don't rely on controllers,
   to address these failure scenarios.

2.3.  Data Center Inter-connect Networks

   Distributed data centers are playing an increasingly important role
   in providing access to information and applications.  Geographically
   diverse data centers are usually connected via a high speed, reliable
   and secure DC WAN core network.

   One variation of a DCI topology is shown in .Figure 3.












Hegde, et al.             Expires 25 April 2024                 [Page 6]

Internet-Draft      Intent-aware Routing using Color        October 2023


                 +-------+     +-------+     +-------+
                 |     ASBR1 ASBR2 ASBR3   ASBR4     |
                 |       |     | DC WAN|     |       |
              PE1+  DC1  +-----+  CORE +-----+  DC2  +PE2
                 |    ASBR11  ASBR22 ASBR33 ASBR44   |
                 |       |     |       |     |       |
                 +-------+     +-------+     +-------+


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


                           Figure 3: DCI Network

   In many DC WAN deployments, applications require end-to-end path
   diversity and end-to-end low latency paths.

   Another consideration in DC WAN deployments is the choice of
   encapsulation technologies.  Some deployments use the same tunneling
   mechanism within the DC and DCI networks, while other deployments use
   different mechanisms in each.  It is important for a solution to
   provide flexibility in choice of tunneling mechanisms across domains.

3.  Use Cases for Inter-domain Intent-based Transport

   The use cases for inter-domain intent-based packet transport
   described in this section are intended to provide motivation for the
   requirements that follow.  They apply to all the different deployment
   scenarios described above.

3.1.  Inter-domain Data Sovereignty




















Hegde, et al.             Expires 25 April 2024                 [Page 7]

Internet-Draft      Intent-aware Routing using Color        October 2023


                 +-----------+     +-----------+     +-----------+
                 |           |     |  +-+  AS2 |     |           |
                 |           A1+--+A2 | |      A3+--+A4          |
              PE1+    AS1    |     |  |Z|      |     |     AS3   +PE3
                 |           A5+--+A6 | |      A7+--+A8          |
                 |           |     |  +-+      |     |           |
                 +--A13--A15-+     +-A17--A19--+     +-----------+
                    |     |           |    |
                    |     |           |    |
                    |     |           |    |
                 +--A14--A16-+     +-A18--A20--+
                 |           |     |           |
                 |          A9+--+A10          |
              PE4+   AS4     |     |   AS5     |
                 |          A11+-+A12          |
                 |           |     |           |
                 +-----------+     +-----------+


                       Figure 4: Multi domain Network

   Figure 4 depicts an example of a WAN with multiple ASes, where each
   AS serves a continent.  Certain traffic from PE1 (in AS1) to PE3 (in
   AS3) must not traverse country Z in AS2.  However, all paths from AS1
   to AS3 traverse AS 2.  The inter-domain solution should provide end-
   to-end path creation that traverses AS 2 but avoids country Z.

   In other networks, the domain to avoid may encompass an entire AS.

3.2.  Inter-domain Low-Latency Services

   Service provider networks running L2 and L3VPNs carry traffic for
   particular VPNs on low-latency paths that traverse multiple domains.

3.3.  Inter-domain Service Function Chaining

   RFC7665 defines service function chaining as an ordered set of
   service functions and automated steering of traffic through this set
   of service functions.  There could be a variety of service functions
   such as firewalls, parental control, CGNAT etc.  In 5G networks these
   functions may be completely virtualized or could be a mix of
   virtualized functions and physical appliances.  It is required that
   the inter-domain solution caters to the service function chaining
   requirements.  The service functions may be virtualized and spread
   across different data centers attached to different domains.






Hegde, et al.             Expires 25 April 2024                 [Page 8]

Internet-Draft      Intent-aware Routing using Color        October 2023


3.4.  Inter-domain Multicast Use cases

   Multicast services such as IPTV and multicast VPN also need to be
   supported across a multi-domain service provider network.


                 +---------+---------+---------+
                 |         |         |         |
                 S1       ABR1      ABR2       R1
                 | Metro1  |  Core   |  Metro2 |
                 |         |         |         |
                 S2       ABR11     ABR22      R2
                 |         |         |         |
                 +---------+---------+---------+


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


                       Figure 5: Multicast use cases

   Figure 5 shows a simplified multi-domain network supporting
   multicast.  Multicast sources S1 and S2 are in a different domain
   from the receivers R1 and R2.  The solution should support
   establishment of intent-aware multicast distribution trees (P
   tunnels) across the domains and steer customer multicast streams on
   it.  It should maintain the scaling properties of a multi-domain
   architecture by avoiding leaking of RPF routing state into the IGP
   domains.

4.  Deployment use cases

4.1.  Network Domains under different administration

                +-----------+                +-----------+
                |           ASBR1           ASBR2        |
                |           |                |           |
             PE1+  AS1      +----------------+    AS2    +PE2
                |           ASBR11          ASBR22       |
                |           |                |           |
                +-----------+                +-----------+


            Figure 6: Networks with inconsistent intent mappings







Hegde, et al.             Expires 25 April 2024                 [Page 9]

Internet-Draft      Intent-aware Routing using Color        October 2023


   In diagram Figure 5 above, AS1 and AS2 may be operating as closely
   coordinated but independent administrative domains, and still require
   end-to-end paths across the two ASes to deliver services.  This
   scenario could be a result of a merger.  It is possible that AS1 and
   AS2 may have assigned different values for the same intent.

   In some cases, organizations may continue to use option A or option B
   [RFC4364] style interconnectivity in which case the inter-domain
   solution should satisfy intent of the path on inter-domain links for
   the service prefixes.  In other cases, organizations may prefer to
   use option C style connectivity from PE1 to PE2.

   An inter-domain solution should provide effective mechanisms to
   translate intent across domains without requiring renumbering of the
   intent mapping.

5.  Intent-Aware Routing Framework

   This section describes the basic concepts, terminologies and
   architectural principles that define intent-aware routing and the
   protocols and technologies that currently support it.  The goal of
   this section is to establish the requirement for consistency with
   existing deployed solutions and describe the framework for it.

   The figure below is used as reference.

                    +-----------------------------------+
                    |----+                         +----|
                    | E1 |                         | E2 |- V/v with C
                    |----+                         +----|
                    +-----------------------------------+


       Figure 7: Intent-aware routing using color reference topology

5.1.  Intent

   Intent in routing may be any combination of the following behaviors:

   *  Topology path selection (e.g. minimize metric, avoid resource)

   *  NFV service insertion (e.g. service chain steering)

   *  Per-hop behavior (e.g.  QoS for 5G slice)

   An intent-aware routed path may be within a single network domain or
   across multiple domains.




Hegde, et al.             Expires 25 April 2024                [Page 10]

Internet-Draft      Intent-aware Routing using Color        October 2023


5.2.  Color

   Color is a 32-bit numerical value that is associated with an intent,
   as defined in [RFC9256]

5.3.  Colored Service Route

   An Egress PE E2 colors a BGP service (e.g.  VPN) route V/v to
   indicate the particular intent that E2 requests for the traffic bound
   to V/v.  The color (C) is encoded as a BGP Color Extended community
   [RFC9012].

5.4.  Intent-Aware Route using Color

   (C, E2) represents a intent-aware route to E2 which satisfies the
   intent associated with color C.

   Multiple technologies already provide intent-aware paths in solutions
   that are widely deployed.

   *  SR Policy [RFC9256]

   *  IGP Flex-Algo [RFC9350]

   In the context of large-scale SR-MPLS networks, SR Policy is
   applicable to both intra-domain and inter-domain deployments; whereas
   IGP Flex-Algo is better suited to intra-domain scenarios.

5.5.  Service Route Automated Steering on intent-aware route using color

   An ingress PE E1 automatically steers V-destined packets onto a
   intent-aware path bound to (C, E2).  If several such paths exist, a
   preference scheme is used to select the best path: E.g.  IGP Flex-
   Algo first, then SR Policy.

5.6.  Inter-Domain intent-aware routing using colors with SR Policy

   If E1 and E2 are in different domains, E1 may request an SR-PCE in
   its domain for a path to (C, E2).  The SR-PCE (or a set of them)
   computes the end-to-end path and installs it at E1 as an SR Policy.
   The end-to-end intent-aware path may seamlessly cross multiple
   domains.

5.7.  Motivation for a BGP-based intent-aware routing solution using
      colors

   While the following requirements may be covered with an SR Policy
   solution, an operator may prefer a BGP-based solution due to:



Hegde, et al.             Expires 25 April 2024                [Page 11]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  Operational familiarity and expectation of incremental evolution
      from an existing Seamless-MPLS/BGP-LU inter-domain deployment
      [I-D.ietf-mpls-seamless-mpls]

   *  Expectation of higher scale with BGP

   *  Expectation of a familiar operational trust model between BGP
      domains (peering policy)

5.8.  BGP Intent-Aware Routing using Color

   A BGP Intent-Aware Routing solution signals intent-aware routes to
   reach a given destination (e.g.  E2).  (C, E2) represents a BGP hop-
   by-hop distributed route that builds an inter-domain intent-aware
   path to E2 for color C.

5.9.  Architectural consistency among intent-aware routing solutions
      using colors

   As seen above, multiple technologies exist that provide intent aware
   routing in a network.  A BGP based solution must be compliant with
   the existing principles that apply to them.

   A deployment model that provides consistency is as follows:

   *  Service routes are colored using BGP Color Extended-Community to
      request intent [RFC9256]

      -  V/v via E, colored with C

   *  Colored service routes are automatically steered on an appropriate
      intent-aware path using color

      -  V/v via E with C is steered via (E, C)

      -  (E, C) provided by any intent-aware technology or protocol

   *  Intent-aware routes may resolve recursively via other intent-aware
      routes

      -  (E, C) via N recursively resolves via (N, C)

   Here is a brief example that illustrates these principles.








Hegde, et al.             Expires 25 April 2024                [Page 12]

Internet-Draft      Intent-aware Routing using Color        October 2023


  +----------------+  +----------------+  +----------------+
  |                |  |                |  |                | V/v with C1
  |----+          +----+              +----+          +----|/
  | E1 |          | N1 |              | N2 |          | E2 |\
  |----+          +----+              +----+          +----| W/w with C2
  |                |  |                |  |                |
  |    Domain 1    |  |    Domain 2    |  |    Domain 3    |
  +----------------+  +----------------+  +----------------+


  Figure 8: Inter-domain intent-aware routing using color reference
                               topology

   In the figure above, all the nodes are part of an inter-domain
   network under a single authority and with a consistent color-to-
   intent mapping:

   *  Color C1 is mapped to "low delay"

      -  Flex-Algo FA1 is mapped to "low delay" and hence to C1 in each
         domain

   *  Color C2 is mapped to "low delay and avoid resource R"

      -  Flex-Algo FA2 is mapped to "low delay and avoid resource R" and
         hence to C2 in each domain

   E1 receives two BGP colored service routes from E2:

      -  V/v with BGP Color Extended community C1

      -  W/w with BGP Color Extended community C2

   E1 has the following inter-domain intent-aware paths using color:

   *  (E2, C1) provided by BGP which recursively resolves via intra-
      domain intent-aware paths:

      -  (N1, C1) provided by IGP FA1 in Domain1

      -  (N2, C1) provided by SR Policy bound to color C1 in Domain2

   *  (E2, C2) provided by SR Policy

   E1 automatically steers the received colored service routes as
   follows:

      -  V/v via (E2, C1) provided by BGP intent-aware route using color



Hegde, et al.             Expires 25 April 2024                [Page 13]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  W/w via (E2, C2) provided by SR Policy

   The example illustrates the benefits provided by leveraging the
   architectural principles:

   *  Seamless co-existence of multiple intent-aware technologies, e.g.
      BGP and SR Policy

      -  V/v is steered on BGP intent-aware path

      -  W/w is steered on SR Policy intent-aware path

   *  Seamless and complementary interworking between different intent-
      aware technologies

      -  V/v is steered on a BGP intent-aware path that is itself
         resolved within domain 2 onto an SR Policy bound to the color
         of V/v

   *  Another benefit that can be extrapolated from the example is that
      intent-aware routes from different technologies may serve as
      alternative paths for the same intent.

6.  Technical Requirements

6.1.  Intent Requirements

   The BGP Intent-Aware routing solution must support the following
   intents bound to a color:

   *  Minimization of a cost metric vs a latency metric

      -  Minimization of different metric types, static and dynamic

   *  Exclusion/Inclusion of SRLG and/or Link Affinity and/or minimum
      MTU/number of hops

   *  Bandwidth management

   *  In the inter-domain context, exclusion/inclusion of entire
      domains, and border routers

   *  Inclusion of one or several virtual network function chains

      -  Located in a regional domain and/or core domain, in a DC

   *  Localization of the virtual network function chains




Hegde, et al.             Expires 25 April 2024                [Page 14]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  Some functions may be desired in the regional DC or vice versa

   Subsequent sections elaborate on these requirements.

6.1.1.  Transport Network Intent Requirements

   The requirements described in this document are mostly applicable to
   network under a single administrative domain that are organized into
   multiple network domains.  The requirements are also applicable to
   multi-AS networks with closely cooperating administration.

   The network diagram below illustrates the reference network topology
   used in this section

         +-----+                +-----+                  +-----+
    .....|S-RR1|  ............. |S-RR2|  ............... |S-RR3|  ...
    :    +-----+                +-----+                  +-----+    :
    :                                                               :
    :                                                               :
    :                                                               :
 +--:--------------+       +-----------------+       +--------------:--+
 |  :              |       |                 |       |              :  |
 |  :              |-------|                 |-------|              :  |
 |  :          +---|  D=20 |---+         +---|  D=25 |---+          :  |
 |  :          |121|-------|211|         |231|-------|321|          :  |
 |  :          +---| \   / |---+         +---| \   / |---+          :  |
 |----+            |  \ /  |                 |  \ /  |            +----|
 |PE11|            |   V   |                 |   V   |            |PE31|
 |----+            |  / \  |                 |  / \  |            +----|
 |             +---| /   \ |---+         +---| /   \ |---+             |
 |----+        |122|-------|212|         |232|-------|322|        +----|
 |PE12|        +---|  D=15 |---+         +---|  D=10 |---+        |PE32|
 |----+            |       |                 |       |            +----|
 |    Domain 1     |       |    Domain 2     |       |    Domain 3     |
 +-----------------+       +-----------------+       +-----------------+


  Figure 9: Transport Network Intent Requirements Reference Diagram

   The following network design assumptions apply to the reference
   topology above, as an example:

   *  Independent ISIS/OSPF SR instance in each domain.

   *  eBGP peering link between ASBRs (121-211, 121-212, 122-211,
      122-212, 231-321, 231-322, 232-321 and 232-322).

   *  Peering links have equal cost metric.



Hegde, et al.             Expires 25 April 2024                [Page 15]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  Peering links have delay configured or measured as shown by "D".
      D=50 for cross peering links.

   *  The cross links between ASBRs share the same risk.

   *  The top parallel link between 121-211 shares same risk with the
      link 122-212.

   *  The top parallel link between 231-321 shares same risk with the
      link 232-322.

   *  VPN service is running from PE31, PE32 to PE11, PE12 via service
      RRs (S-RRn in figure).

   Intent-aware inter-domain routing information to end point E with
   intent C is represented using (C,E).  The notation used is a
   representation of the intent-aware route using color, and does not
   indicate a specific protocol encoding.

   The following sections illustrate requirements and provide detailed
   examples for several intent types.

6.1.1.1.  Minimization of end-to-end metric

   Various metric types can be advertised within an IGP domain and
   minimum metric paths can be computed within IGP domain, with Flex-
   Algo [RFC9350] for instance.

   The BGP solution should allow the establishment of inter-domain
   intent-aware paths with low values of a metric type, accumulated over
   the end-to-end path.

   In the reference topology of Figure 9

      -  Each domain has Algo 0 and Flex Algo 128

      -  Algo 0 is for minimum cost metric(cost optimized).

      -  Flex Algo 128 definition is for minimum delay (low latency).

   *  Cost Optimized end-to-end path

      -  Color C1 - Minimum cost intent.

      -  Intent-aware route for C1 sets up path(s) between PEs for end-
         to-end minimum cost.





Hegde, et al.             Expires 25 April 2024                [Page 16]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  These paths traverse over intra-domain Algo 0 in each domain
         and account for the peering link cost between ASBRs.

      -  Example: PE11 learns (C1, PE31) intent-aware route via several
         equal paths:

         o  One such path is through FA0 to node 121, links 121-211, FA0
            to 231, link 231-321, FA0 to PE31

         o  Another such path is through FA0 to node 122, link 122-212,
            FA0 to 232, link 232-322, FA0 to PE31.

            +  PE11 may load-balance among these paths

      -  On PE11, VPN routes from PE31 colored with C1 are steered via
         (C1, PE31) intent-aware route.

   *  Latency Optimized End-to-end path

      -  Color C2 - Minimum latency intent.

      -  BGP Intent-aware route for C2 advertises path(s) between PEs
         for end-to-end minimum delay.

      -  These paths traverse over intra-domain Flex-Algo 128 in each
         domain and account for the peering link delay between ASBRs.

      -  Example: PE11 learns (C2, PE31) intent-aware route and best
         path is through FA128 to node 122, link 122-212, FA128 to 232,
         link 232-322, FA128 to PE31.

      -  On PE11, VPN routes from PE31 colored with C2 are steered via
         (C2, PE31) intent-aware route.

6.1.1.2.  Exclusion/inclusion of link affinity

   The Intent-aware BGP routing solution should allow the establishment
   of inter-domain paths that satisfy link affinity inclusion/exclusion
   constraints.  The link affinity constraints should also be satisfied
   for inter-domain links, such as those between ASBRs.

   Using the reference topology of Figure 7 for the example below:

   *  Color C3 - Intent to Minimize cost metric and avoid purple links

   *  Each domain has Flex Algo 129 and some links have purple affinity.





Hegde, et al.             Expires 25 April 2024                [Page 17]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  Flex Algo 129 definition is set to minimum cost metric and avoid
      purple links (within domain).

   *  Peering cross links are colored purple by policy.

   *  BGP intent-aware route for C3 sets up paths between PEs for
      minimum end-to-end cost and avoiding purple link affinity.

   *  These paths traverse over intra domain Flex Algo 129 in each
      domain and accounts for peering link cost between ASBR and
      avoiding purple links.

   *  Example: PE11 learns (C3, PE31) intent-aware route via 2 paths.

      -  First path is through FA 129 to node 121, link 121-211, FA129
         to 231, link 231-321, FA129 to PE31.

      -  Second path is through FA129 to node 122, link 122-212, FA129
         to 232, link 232-322, FA129 to PE31.

   *  On PE11, VPN routes from PE31 colored with C3 are steered via (C3,
      PE31) intent-aware route.

6.1.1.3.  Exclusion/inclusion of nodes

   Support creating an inter-domain path that includes or excludes a
   certain set of nodes in each domain.

   Mechanisms used to achieve the node inclusion/exclusion constraints
   within different domains should be independent.

   For example, an RSVP-based domain may use link affinities to achieve
   node exclusion constraints, while an SR-based domain may use Flex-
   Algo, which natively supports excluding nodes.

   The example below describes the details for Figure 9

   *  Color C4 - Intent to Minimize cost metric and avoid nodes

      -  Each domain has Flex Algo 129 and Flex-Algo 129 is not enabled
         on nodes 121,211,231,321

      -  Flex Algo 129 definition is set to minimum cost metric

   *  Intent-aware route for C4 sets up paths between PEs for minimum
      end-to-end cost and avoiding specific nodes.





Hegde, et al.             Expires 25 April 2024                [Page 18]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  These paths traverse over intra domain Flex Algo 129 in each
      domain and accounts for peering link cost between ASBR and
      avoiding specific nodes.

   *  Example: PE11 learns (C4, PE31) intent-aware route via 1 path.

      -  The path is through FA129 to node 122, link 122-212, FA129 to
         232,link 232-322, FA129 to PE31.

   *  On PE11, VPN routes colored with C4 are steered via (C4, PE31)
      intent-aware route.

6.1.1.4.  Diverse Paths

   Support the creation of node- and link-diverse inter-domain paths.

   The intra-domain portion of the end-to-end paths should make use of
   existing mechanisms for computing and instantiating diverse paths
   within a domain.

   Inter-domain links (such as those connecting ASBRs) should also be
   taken into account for diverse inter-domain paths.

   Support creation of inter-domain diverse paths that avoid shared risk
   links.

   The example below describes the details for Figure 8

   *  Color C5 and C6 - Intent to create diverse paths avoiding common
      node, link and shared risk

      -  Each domain has SRLG aware diverse path built as below

      -  Domain 1: Color C5 -> PE11,121

      -  Color C6 -> PE12,122

      -  Domain 2: Color C5 -> 211,231

      -  Color C6 -> 212,232

      -  Domain 3: Color C5 -> 321,PE31

      -  Color C6 -> 322,PE32

      -  Shared risk among inter-domain links is as described in the
         topology description




Hegde, et al.             Expires 25 April 2024                [Page 19]

Internet-Draft      Intent-aware Routing using Color        October 2023


         o  Intent-aware diverse paths represented by C5 and C6 setup in
            each domain

         o  Local policies on inter-domain links to avoid common shared
            risk for intent C5 and C6

         o  Example: PE11 learns (C5, PE31) intent-aware route via 1
            path.

      -  The path is through PE11,121-211 (bottom link), 231-321 (bottom
         link), PE31

         o  Example: PE12 learns (C6, PE32) intent-aware route via1
            path.

      -  The path is through PE12,122,212, 232,322, PE32

   *  On PE11, VPN routes colored with C5 are steered via (C5, PE31)
      Intent-aware route.

   *  On PE12, VPN routes colored with C6 are steered via (C6, PE32)
      intent-aware route.

6.1.1.5.  Applicability of intent to a subset of domains

   Support creation of paths with certain intents applicable to only a
   subset of domains.

   No constraint specific state on internal nodes where intent is not
   applicable.

   The example below describes the details for Figure 9

   *  Color C7 to exclude purple links

      -  Purple links exist only in domain 2

      -  Intra-domain Intent-aware paths in domain 2 via 211,231

      -  Intra-domain paths for C7 not created in Domain 1 and Domain 3

   *  On PE11, VPN routes colored with C7 are steered via (C7, PE31)
      intent-aware route.

      -  Intent-aware route (C7,PE31) uses best effort paths in Domain1
         and Domain3





Hegde, et al.             Expires 25 April 2024                [Page 20]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  Intent-aware route (C7,PE31) uses intra-domain intent-aware
         path C7 in Domain2

6.1.1.6.  Exclusion/inclusion of domain


         +-----+                +-----+                 +-----+
     ....|S-RR1|..............  |S-RR2| ..............  |S-RR3| ....
     :   +-----+                +-----+                 +-----+     :
     :                                                              :
     :                      +----------------+                      :
     :                      |                |                      :
  +--:--------------+       |---+        +---|       +--------------:--+
  |  :              |   |---|211|        |241|---|   |              :  |
  |  :              |   |   |---+        +---|   |   |              :  |
  |  :          +---|   |   |    Domain 2    |   |   |---+          :  |
  |  :          |121|---|   +----------------+   |---|421|          :  |
  |  :          +---|                                |---+          :  |
  |----+            |                                |            +----|
  |PE11|            |                                |            |PE41|
  |----+            |                                |            +----|
  |             +---|                                |---+             |
  |             |131|---|   +----------------+   |---|431|             |
  |             +---|   |   |                |   |   |---+             |
  |                 |   |   |---+        +---|   |   |                 |
  |    Domain 1     |   |---|311|        |341|---|   |      Domain 4   |
  +-----------------+       |---+        +---|       +-----------------+
                            |   Domain 3     |
                            +----------------+



                 Figure 10: Domain Exclusion Diagram

   Color C4 - Avoid sending selected traffic via Domain 3

   *  VPN routes advertised from PEs with Color C4

   *  Intent-aware route for Color C4 should only set up paths between
      PE11 and PE41 that exclude Domain 3

6.1.1.7.  Virtual network function chains in local and core domains









Hegde, et al.             Expires 25 April 2024                [Page 21]

Internet-Draft      Intent-aware Routing using Color        October 2023


          ____                      ____
         /    \                    /    \
        | NFV1 |                  | NFV2 |
         \    /                    \    /
  +---------------------+  +--------------------+  +-------------------+
  |      |E11|          |  |       |E21|        |  |                   |
  |      +---+          |  |       +---+        |  |                   |
  |                     |  |                    |  |                   |
  |                     |  |                    |  |                   |
  |----+              +------+                +------+            +----|
  |PE11|              | 121  |                | 231  |            |PE31|
  |----+              +------+                +------+            +----|
  |                     |  |                    |  |                   |
  |                     |  |                    |  |                   |
  |                     |  |                    |  |                   |
  |                     |  |                    |  |                   |
  |      Domain 1       |  |      Domain 2      |  |     Domain 3      |
  +---------------------+  +--------------------+  +-------------------+


                   Figure 11: Transport NFV Diagram

   *  Color intent

      -  C5 - Routing via min-cost paths

      -  C6 - Routing via a local NFV service chain situated at E11

      -  C7 - Routing via a centrally located NFV service chain situated
         at E21

   *  Forwarding of packets from PE11 towards PE31:

      -  (C5, PE31) mapped packets are sent via nodes 121, 231 to PE31

      -  (C6, PE31) mapped packets are sent to E11 and then post-
         service chain, via 121, 231 to PE31

      -  (C7, PE31) mapped packets are sent via 121 to E21 and then
         post-service chain, via 231 to PE31

   E11 and E21 MAY be involved in inter-domain signaling in order to
   send service traffic towards PEs in remote domains.  Different
   functions may be collocated at the same network node.  (For example,
   PE functionality and NFV attachment functionality may be collocated.)






Hegde, et al.             Expires 25 April 2024                [Page 22]

Internet-Draft      Intent-aware Routing using Color        October 2023


6.1.2.  VPN (Service Layer) Network Intent Requirements

   This section describes requirements and reference use-cases for
   extending intent-aware routing to the VPN (Service) layer.

   The solution should:

   *  Extend the signaling of intent awareness end-to-end to the
      customer domain: CE site to CE site across provider networks.
      Specific goals are to:

      -  Provide ability for a CE to select paths through specific PEs
         for a given intent

         o  Example-1: Certain intent in transport not available via
            specific PEs

         o  Example-2: Certain CE-PE connection does not support
            specific intent

         o  Example-3: Customer Site access via certain CE node does not
            support specific intent.  For instance, link connecting a
            specific CE to a DC hosting loss-sensitive service may have
            better quality than a link from another CE

      -  Provide ability for a CE node to send traffic indicating a
         specific intent (via suitable encapsulation) to the PE for
         optimal steering.

         o  Provide ability for a PE node to apply filtering and other
            security mechanisms and authentication for the incoming
            encapsulated packets

         o  Provide ability for a PE node to apply traffic policing and
            shaping mechanisms to the received encapsulated packets.

         o  The PE-CE link and the transport domains can be in different
            color domains.

      -  Intent-aware routing may extend further into customer networks
         towards the network edge, closer to applications that originate
         traffic









Hegde, et al.             Expires 25 April 2024                [Page 23]

Internet-Draft      Intent-aware Routing using Color        October 2023


         o  Applications or hosts that do not participate in routing can
            indicate the intent desired for an emitted traffic flow by
            setting appropriate DSCP values in the packet header.  This
            enables the ingress intent-aware routing device to perform
            the necessary classification and traffic steering
            (Section 6.2)

   *  Support intent aware routing for multiple service (VPN)
      interworking models

      -  IBGP and Inter-AS Option C models are inherently supported
         since they natively extend from PE to PE.  Additional models to
         be supported are:

         o  Inter-AS Option A

         o  Inter-AS Option B

         o  GW based interworking (L3VPN, EVPN)

      -  Co-existence with legacy PEs and CEs in a L3VPN network

         o  Intent-aware routing capable PEs co-exist with other PEs
            that are not capable

         o  Intent-aware routing capable PEs simultaneously interact
            with both capable CEs and legacy CEs
























Hegde, et al.             Expires 25 April 2024                [Page 24]

Internet-Draft      Intent-aware Routing using Color        October 2023


          The network diagram below illustrates the reference network
          topology used in this section for VPN Intent-aware routing
          using Color

         +-------------------+           +-------------------+
         |   ....|S-RR|....  |           |  ....|S-RR|.....  |
         |   :   +----+   :  |           |  :   +----+    :  |
         |   :    :  :    :  |           |  :    :  :     :  |
         |----+   :  :   +---|   D=20    |---+   :  :   +----|
        /|PE11|   :  :   |121|-----------|211|   :  :   |PE21|\
  D=25/  |----+   :  :   +---| X       X |---+   :  :   +----|  \ D=25
    /    |        :  :       |   X   X   |       :  :        |    \ V/24
 CE1     |        :  :       |     X D=50|       :  :        |     CE2
    X    |        :  :       |   X   X   |       :  :        |    X
 D=15 X  |----+   :  :   +---| X       X |---+   :  :   +----|   X D=10
        X|PE12|...:  :...|2122|-----------|2132|...:  :...|PE22|X
         |----+          +---|   D=10    |---+          +----|
         |                   |           |                   |
         |     AS 1          |           |     AS 2          |
         +-------------------+           +-------------------+


       Figure 12: VPN (Service) intent routing reference topology

   The following network design assumptions apply to the reference
   topology above, as an example:

   *  eBGP peering link between VPN ASBRs 121-211, 121-212, 122-211,
      122-212

   *  VPN service runs between PEs in each AS via service RRs to local
      VPN ASBRs.  Between ASBRs, its VPN IAS-Option-B i.e. next hop
      self.

   *  CE1 is dual homed to PE11,PE12.  CE2 is dual homed to PE21, PE22.

   *  Peering links have equal cost metric

   *  Peering links have delay configured or measured as shown by "D"

   The following sections illustrate a few examples of intent use-cases
   applicable to VPN routes.









Hegde, et al.             Expires 25 April 2024                [Page 25]

Internet-Draft      Intent-aware Routing using Color        October 2023


6.1.2.1.  Minimization of end-to-end metric

   This use-case extends the transport use-case from Minimization of
   end-to-end metric section to further to establish e2e paths with low
   values of a metric type between CEs attached to different PEs,
   additionally taking the metrics on the PE-CE links and inter-ASBR
   links into account.

   *  In the reference topology of VPN service intent topology, each AS
      has Flex Algo 0 and 128.  Flex Algo 0 is for minimumcost metric
      (cost optimized) while Flex Algo 128 definition is for minimum
      delay (low latency)

   *  Cost Optimized end-to-end (CE-CE) path

      -  Color C1 - Minimum cost intent.

      -  On CE1, flows requiring cost optimized paths to V/24 are
         steered over (C1, V/24) intent-aware route using color.

         o  This needs BGP intent-aware route between PE-CE for V/24
            prefix and color C1 awareness.

         o  It also needs BGP VPN Intent-aware route between PEs and
            ASBRs for V/24 prefix with VPN RD and color C1 awareness
            (C1, RD:V/24)

         o  CE1 may learn (C1, V/24) route through several equal cost
            paths.  For example:

            +  One path is through link CE1-PE11, FA0 to 121, link
               121-211, FA0 to PE21 and link PE21-CE2.

            +  Another such path is through CE1-PE12, FA0 to node 122,
               link 122-212, FA0 to PE22, link PE22-CE2.

         o  CE1 may load-balance among these paths

   *  Latency optimized end-to-end (CE-CE) path

      -  Color C2 - Minimum latency intent

      -  On CE1, flows requiring low latency paths to prefix V/24 are
         steered over (C2, V/24) intent-aware route using color.

         o  This needs BGP intent-aware route between PE-CE for V/24
            prefix and color C2 awareness.




Hegde, et al.             Expires 25 April 2024                [Page 26]

Internet-Draft      Intent-aware Routing using Color        October 2023


         o  It also needs BGP VPN intent-aware route between PEs and
            ASBR for V/24 prefix with VPN RD and color C2 awareness

         o  Paths traverse over intra-domain Flex Algo 128 in each AS
            and accounts for inter ASBR link delays and PE-CE link
            delays.

         o  CE1 learns (C2, V/24) BGP intent-aware best route using
            color through link CE1-PE12, FA128 to 122, link 122-212,
            FA128 to PE22 and link PE22-CE2 between PE-CE for V/24
            prefix and color C2 awareness.

6.1.2.1.1.  Exclusion/inclusion of link affinity

   *  Color C3 - Intent to minimize cost metric and avoid purple links

   *  In the reference topology of Figure 6 Each AS has Flex Algo 129
      and some links have purple affinity.  Flex Algo 129 definition is
      set to minimum cost metric and avoid purple links (within AS).
      ASBR cross links are colored purple by policy.  Bottom PE-CE links
      are colored purple as well by policy

   *  On CE1, flows requiring minimum cost path avoiding purple links to
      V/24 are steered over (C3, V/24) BGP intent-aware route using
      color

   CE1 learns (C3, V/24) route through link CE1-PE11, FA129 to 121, link
   121-211, FA129 to PE21 and link PE21-CE2.

6.1.2.2.  Virtual network function chains in local and core domains

   The below diagram represents a typical service function chaining
   deployment with NFV services deployed in the service layer.  The
   transport layer is not aware of the services in this model.

















Hegde, et al.             Expires 25 April 2024                [Page 27]

Internet-Draft      Intent-aware Routing using Color        October 2023


                                +-----+
        ........................|S-RR | .................
        :                       +-----+ ...........      :
        :                                           :    :
        :                                           :    :
        :  ___     ___           ___                :    :
        : /   \   /   \         /   \               :    :
        :| S1  | | S2  |       | S3  |              :    :
        : \   /   \   /         \   /               :    :
      +-:---------------+  +--------------+  +------:----:--+
      | :  |E11|  |E12| |  |    |E21|     |  |      :    :  |
      | :  +---+  +---+ |  |    +---+     |  |      :  +----| (V1/24,C1)
      | :               |  |              |  |      :  |PE31|--CE2
      | V               |  |              |  |      :  +----|
      |----+          +------+            +------+  :       |
 CE1--|PE11|          | 121  |            | 231  |  :       |
      |----+          +------+            +------+  :  +----| (V2/24/C2)
      |                 |  |              |  |      :..|PE32|--CE3
      |                 |  |              |  |         +----|
      |                 |  |              |  |              |
      |                 |  |              |  |              |
      |    Domain 1     |  |   Domain 2   |  |   Domain 3   |
      +-----------------+  +--------------+  +--------------+


        Figure 13: Virtual Network Functions Reference Topology

   *  Color intent

      -  C1 - Routing via NFV service chain comprising of [S1, S2]
         attached to E11 and E12

      -  C2 - Routing via NFV service [S3] attached to E21

   *  CE1, CE2, CE3 are sites of VPN1.  S1, S2 and S3 are service VNFs
      in VPN1

   *  Prefix V1/24 colored with C1 from CE2, and advertised as RD:V1/24
      with C1 by PE31 to PE11 via S-RR

   *  Prefix V2/24 colored with C2 from CE3, and advertised as RD:V2/24
      with C2 by PE32 to PE11 via SS-RR

   *  From PE11:

      -  [V1/24, C1] mapped packets are sent via S1, S2 and then routed
         to PE31, CE2




Hegde, et al.             Expires 25 April 2024                [Page 28]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  [V2/24, C2] mapped packets are sent via S3 and then routed to
         PE32, CE3

6.1.3.  Multicast Intent Requirements

   This section describes the intent requirements for the multicast
   traffic.  In principle all the intent requirements described in
   section Section 6.1.1 can apply to multicast traffic as well.  The
   intent requirements as currently seen from actual usecases have been
   listed here.

   *  Ability to create multicast distribution trees that minimize
      latency metric

   *  Ability to create multicast distribution trees that avoid nodes
      located in certain geographical region

   *  Ability to create multicast distribution trees that that provide
      bandwidth guarantees within as well as across domains

   *  Ability to create multicast distribution trees that use subset of
      the topology

6.2.  Traffic Steering Requirements

   Traffic arriving at an ingress PE for a colored service route gets
   steered into an intent-aware path to the egress PE.  Section 5
   illustrates the automated steering mechanism, driven through Color
   Extended Community in the service route.

   *  Flexible traffic steering is required, with support for different
      types:

      -  Per-Destination Steering: Incoming packets are steered based on
         the destination address of the packets

      -  Per-Flow Steering: Incoming packets are steered based on the
         destination address of the packets and additional fields in the
         packet header

         o  DSCP for IPv4/IPv6 packets and EXP for MPLS packets

         o  5-tuple IP flow (Source address, destination address, source
            port, destination port and protocol fields).

      -  The Per-Flow Steering enables different flows for the same
         destination to be steered into different paths – for example,
         one flow into an intent-aware path and another into a best-



Hegde, et al.             Expires 25 April 2024                [Page 29]

Internet-Draft      Intent-aware Routing using Color        October 2023


         effort path; or two different flows steered into paths of two
         different intents.  Section 8.6 of RFC 9256 describes the
         operation of per-flow steering in detail.

   *  When no path that fulfills the desired intent is available:

      -  An option of ordered fallback should be supported

         o  via one or more alternative intents; or via a best-effort
            path.

      -  An option of not using a fallback path for the service route
         should also be supported.

      -  Fallback scheme per service route should be supported

         o  Fallback schemes should be decoupled from primary.  For
            example, different service routes using same primary but
            different fallback schemes

      -  An indication that the route followed a less preferred path due
         to fallback may be given to a CE by modifying/adding suitable
         BGP attribute through policy.

   *  Above steering mechanisms should be supported for any service,
      including L2/L3 VPNs and Internet/global routing.

6.3.  Deployment Requirements

   The solution must support the representative deployment designs and
   associated deployment requirements described in the following sub
   sections.

6.3.1.  Multi-domain deployment designs

   This section describes four different ways that multi-domain networks
   could be organized.  This is a representation of most common
   deployments and not an exhaustive coverage.

6.3.1.1.  Multiple IGP domains within a single AS, inter-connected at
          border nodes










Hegde, et al.             Expires 25 April 2024                [Page 30]

Internet-Draft      Intent-aware Routing using Color        October 2023


                                    +-----+
     .............................. |S-RR | .........................
     :                              +-----+                         :
     :                                                              :
     :                                                              :
  +--:----iBGP---------+  +----------iBGP------+  +---------iBGP----:--+
  |  :                 |  |                    |  |                 :  |
  |  :                 |  |                    |  |                 :  |
  |  :               +------+                +------+               :  |
  |  :               | 121  |                | 231  |               :  |
  |  .               +------+                +------+               :  |
  |----+               |  |                    |  |               +----|
  |PE11|               |  |                    |  |               |PE31|
  |----+               |  |                    |  |               +----|
  |                  +------+                +------+                  |
  |                  | 122  |                | 232  |                  |
  |                  +------+                +------+                  |
  |                    |  |                    |  |                    |
  |  AS1 (Domain 1)    |  |    AS1(Domain 2)   |  |     AS1(Domain 3)  |
  +--------------------+  +--------------------+  +--------------------+



        Figure 14: Transport Multiple Domains Network Diagram

   The above diagram shows three different IGP domains, Domain1, Domain2
   and Domain3 inter-connected at the ABRs 121,122,231,232.

   This single-AS network uses I-BGP sessions, with ABRs acting as
   inline route reflectors to PEs.

   Note that the IGP design included here and in other models below is
   illustrative.  In practice, there may be multiple areas/levels or
   multiple IGP instances.

6.3.1.2.  Multiple IGP domains within a single AS, with iBGP between
          border nodes














Hegde, et al.             Expires 25 April 2024                [Page 31]

Internet-Draft      Intent-aware Routing using Color        October 2023


        +-----+                +-----+                  +-----+
    ....|S-RR1| .............. |S-RR2| ................ |S-RR3| ....
    :   +-----+                +-----+                  +-----+     :
    :                                                               :
    :                                                               :
 +--:--iBGP---------+ iBGP +--------iBGP------+ iBGP +--------iBGP--:--+
 |  :               |      |                  |      |              :  |
 |  :               |      |                  |      |              :  |
 |  :           +---|      |---+          +---|      |---+          :  |
 |  :           |121|------|211|          |231|------|321|          :  |
 |  :           +---|      |---+          +---|      |---+          :  |
 |----+             | \ /  |                  | \ /  |            +----|
 |PE11|             |  X   |                  |  X   |            |PE31|
 |----+             | / \  |                  | / \  |            +----|
 |              +---|      |---+          +---|      |---+             |
 |              |122|------|212|          |232|------|322|             |
 |              +---|      |---+          +---|      |---+             |
 |                  |      |                  |      |                 |
 |   AS1(Domain 1)  |      |   AS1(Domain 2)  |      |   AS1(Domain 3) |
 +------------------+      +------------------+      +-----------------+


   Figure 15: Transport Multiple Domains with iBGP Network Diagram

   The above diagram shows a single AS1 with three different IGP
   domains, Domain1, Domain2, and Domain3.
   121,122,211,212,231,232,321,322 are border nodes for the IGP domains
   and they participate in only one IGP domain.

   In this design, domain inter-connect is via iBGP peering links
   between Area border nodes.  ABRs act as inline route reflectors to
   PEs.

6.3.1.3.  Multiple ASes inter-connected with E-BGP between border nodes

















Hegde, et al.             Expires 25 April 2024                [Page 32]

Internet-Draft      Intent-aware Routing using Color        October 2023


        +-----+                +-----+                  +-----+
    ....|S-RR1| .............. |S-RR2| ................ |S-RR3| ....
    :   +-----+                +-----+                  +-----+     :
    :                                                               :
    :                                                               :
 +--:--iBGP---------+ eBGP +--------iBGP------+ eBGP +--------iBGP--:--+
 |  :               |      |                  |      |              :  |
 |  :               |      |                  |      |              :  |
 |  :           +---|      |---+          +---|      |---+          :  |
 |  :           |121|------|211|          |231|------|321|          :  |
 |  :           +---|      |---+          +---|      |---+          :  |
 |----+             |  \ / |                  |  \ / |            +----|
 |PE11|             |   X  |                  |   X  |            |PE31|
 |----+             |  / \ |                  |  / \ |            +----|
 |              +---|      |---+          +---|      |---+             |
 |              |122|------|212|          |232|------|322|             |
 |              +---|      |---+          +---|      |---+             |
 |                  |      |                  |      |                 |
 |   AS1(Domain 1)  |      |   AS2(Domain 2)  |      |   AS3(Domain 3) |
 +------------------+      +------------------+      +-----------------+


   Figure 16: Transport Multiple Domains with eBGP Network Diagram

   The above diagram shows three different ASes (AS1, AS2 and AS3.)
   121,122, 211, 212, 231,232, 321,322 are border nodes between the
   ASes.

   In this design, domain inter-connect is via eBGP peering links
   between AS border nodes.  The ASBR also runs I-BGP sessions with
   other ASBRs or RRs in the same AS.

6.3.1.4.  Multiple sites with same AS connected via different core AS


















Hegde, et al.             Expires 25 April 2024                [Page 33]

Internet-Draft      Intent-aware Routing using Color        October 2023


                                    +-----+
     .............................. |S-RR | .........................
     :                              +-----+                         :
     :                                                              :
     :                                                              :
  +--:----eBGP---------+  +-----iBGP-----------+  +---eBGP----------:--+
  |  :                 |  |                    |  |                 :  |
  |  :                 |  |                    |  |                 :  |
  |  :               +------+                +------+               :  |
  |  :               | 121  |                | 231  |               :  |
  |  .               +------+                +------+               :  |
  |----+               |  |                    |  |               +----|
  |PE11|               |  |                    |  |               |PE31|
  |----+               |  |                    |  |               +----|
  |                  +------+                +------+                  |
  |                  | 122  |                | 232  |                  |
  |                  +------+                +------+                  |
  |                    |  |                    |  |                    |
  |    AS1(Domain 1)   |  |    AS2(Domain 2)   |  |     AS1(Domain 3)  |
  +--------------------+  +--------------------+  +--------------------+


  Figure 17: Transport Multiple Domains with same AS Network Diagram

   121,122,231,232 belong to AS2 only.  AS1 and AS2 domains may run
   multi-instance IGP or different levels/areas.

   This topology uses I-BGP sessions to some clients and E-BGP sessions
   to other nodes.  When an RR is used between PEs in AS1 and ABRs in
   AS2, it will have iBGP sessions to clients in same AS and e-BGP
   sessions to nodes in other AS.

6.3.1.5.  AS Confederations

   BGP confederations [RFC 5065] allows the division of a public AS into
   multiple sub-ASes, usually with private identifiers.  The solution
   should support BGP based intent-aware paths within the sub-AS or
   across the sub-ASes of the confederation, in any of the network
   designs described in sections 5.4.1.1 to section 5.4.1.4.

6.3.1.6.  Transport Technologies

6.3.1.6.1.  Unicast transport

   The solution must support the following:

   *  End-to-end paths crossing transport domains that use different
      technologies and encapsulations, such as:



Hegde, et al.             Expires 25 April 2024                [Page 34]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  LDP-MPLS

      -  RSVP-TE-MPLS

      -  SR-MPLS

      -  SRv6

      -  SR-TE (MPLS and SRv6)

      -  IGP Flex-Algo (MPLS and SRv6)

      -  Native IPv4/IPv6 forwarding (networks without MPLS enabled

   *  Note:

      -  All MPLS/SR-MPLS deployments may be IPv4/IPv6 or dual-stack

      -  SR-TE includes color-only and other policies as defined in
         [RFC9256]

   *  Interworking between domains with different encapsulations (e.g.
      SR-MPLS and SRv6)

   *  Different transport encapsulations simultaneously within a domain,
      for co-existence and migration

6.3.1.6.2.  Multicast transport

   A routing solution for end-to-end intent-aware paths should support
   multicast as well as unicast.  An End-to-end multicast path crossing
   multiple transport domains may use different encapsulation
   mechanisms, such as:

   *  mLDP

   *  RSVP-TE P2MP

   *  SR-MPLS Tree SIDs

   *  SRv6 Tree SIDs

   *  Native IPv4/IPv6 forwarding (networks without MPLS enabled








Hegde, et al.             Expires 25 April 2024                [Page 35]

Internet-Draft      Intent-aware Routing using Color        October 2023


6.3.1.7.  Co-existence, compatibility and interworking with existing
          intent-aware routing solutions

   The BGP intent-aware routing solution MUST be compliant with the
   intent-aware routing framework described in Section 5.  Specifically,

   *  It MUST support service routes using Color Extended-Community to
      request intent as defined in [RFC9256]

   *  It MUST support automated steering of colored service routes on a
      BGP intent-aware path using color

   *  Intent-aware routes MAY resolve recursively via other intent-aware
      routes provided by any solution

6.3.1.8.  Co-existence and Interworking with BGP-LU

   BGP-LU [RFC8277] is widely deployed to provide inter-domain best-
   effort connectivity across different domains.  The BGP intent-aware
   routing solution should support:

   *  Establishment of best-effort paths by using a color to represent
      best-effort intent, to avoid the need to deploy both technologies

   *  Co-existence of inter-domain BGP-LU and BGP intent aware routing
      in a network

   *  Support interworking of BGP-LU and BGP intent-aware network
      domains.

6.3.1.9.  Domains with different intent granularity

   All domains in a network may not support the same number and granular
   definition of colors.  However, the maximum granularity of colors
   should be provided for end to end paths that are set up for steering
   of a colored service route, with mapping from a more granular color
   to a less granular color where needed.

6.3.1.10.  Domains with non-congruent Color-to-intent Mappings

   As illustrated in Section 4.1, network domains under different
   administrative control may assign different colors to represent the
   same intent.

   A color domain represents a collection of one or more network (IGP/
   BGP) domains with a single, consistent set of color-to-intent
   mappings.




Hegde, et al.             Expires 25 April 2024                [Page 36]

Internet-Draft      Intent-aware Routing using Color        October 2023


   Color for a given intent may need to be re-mapped across a color
   domain boundary.  The solution should support efficient color re-
   mapping for intent-aware routes that are propagated to a different
   color domain.

6.3.1.11.  Color-to-intent coordination

   It may be useful to have a few well-defined common intents with well-
   known color values assigned that can be used across multiple operator
   networks.  Such a scheme can provide a consistent service definition
   to customers that use paths for such intents from multiple operators.

   This scheme does not preclude operators from defining intents with
   similar characteristics and assigning other color values.

   It may additionally be useful to have a reserved range of color
   values for requirements that may arise in future.

   However, it should also be noted that color assignments have been
   used in customer deployments for a while now.  Coordination and care
   will be necessary for defining a range that does not conflict with
   current deployments.

6.3.1.12.  Co-existence with alternative solutions

   Section 5 describes co-existence and interworking of the BGP intent
   aware routing solution with other existing intent-aware solutions.

   Controller based approaches or other distributed TE solutions can
   also address the use-cases in this document.

   The intent-aware routing solution should coexist with such
   alternative solutions.

   *  It should allow traffic to use paths created by an alternative
      solution.

   *  It should allow part of the inter-domain path to be created by an
      alternative solution.

   *  The routing solution may be used to provide backup paths for a
      primary path created by an alternative solution, or vice versa.









Hegde, et al.             Expires 25 April 2024                [Page 37]

Internet-Draft      Intent-aware Routing using Color        October 2023


6.3.2.  Scalability Requirements

6.3.2.1.  Scale Requirements

   *  Support a massive scaled transport network

      -  Number of Remote PE's: >= 300k

      -  Number of Colors C: >= 5

   *  Support a scalable MPLS dataplane solution

   *  Constraints that need to be addressed:

      -  Typical inter-domain MPLS network designs (e.g.  Seamless-MPLS)
         build hop-by-hop stitched MPLS LSPs towards every PE in the
         network.  For the scale above, the number of forwarding entries
         required to represent each remote PE for each color will exceed
         the 1M MPLS label space limit.

      -  PE and transit nodes may be devices with low FIB capacity.

      -  Additionally, they may also have constraints on packet
         processing (e.g, label ops, number of labels pushed)

   *  To address these constraints:

      -  The solution must support hierarchy in the forwarding plane
         E.g. via a label stack or a list of segments, such that no
         single node needs to support a data-plane scaling in the order
         of (Remote PE * C)

      -  The solution should minimize state on border nodes in order to
         reduce label and FIB resource consumption, while taking into
         account packet processing constraints.

   *  Support ability to abstract the topology and network events from
      remote domains - for scale, stability and faster convergence.

      -  E.g. contain the control plane propagation of a failure event
         for an ABR within its attached upstream domain.

   *  Support an Emulated-PULL model for the BGP signaling

   PE nodes may be devices with limited CPU and memory.  The state on a
   PE should be restricted to transport endpoints that it needs for
   service steering.




Hegde, et al.             Expires 25 April 2024                [Page 38]

Internet-Draft      Intent-aware Routing using Color        October 2023


   BGP Signaling is natively a PUSH model.

   For comparison, the SR-PCE solution natively supports a PULL model:
   when PE1 installs a VPN route V/v via (C, PE2), PE1 requests its
   serving SR-PCE to compute the SR Policy to (C, PE2).  I.e.  PE1 does
   not learn unneeded SR policies.

   Emulated-PULL refers to the ability for a BGP node PE1 to "subscribe"
   to (C, PE2) route such that only paths for (C, PE2) are signaled to
   PE1.

   The requirements for an Emulated-PULL solution are as follows:

   *  The subscription and related filtering solution must apply to any
      BGP node.

   *  For transport routes, this means

      -  Ability for a node (e.g.  PE/ABR/ASBR) to signal interest for
         routes of specific colors.

      -  Ability for a node (e.g ABR/ASBR) to propagate the subscription
         message.

      -  PEs may choose to only learn routes that they need – e.g.
         remote VPN endpoints (PEs/VPN ASBRs) or transit nodes (ABRs/
         transport ASBRs).

      -  ABR/ASBRs also only learn and propagate routes for which nodes
         within the local domain have expressed interest.

      -  The requirements for VPN routes will be updated in the future
         version of the document.

   *  Automation of the subscription/filter route

      -  Similar to the SR-PCE solution, when an ingress PE1 installs
         VPN V/v via (C, PE2), PE1 originates its subscription/filter
         route for (C, PE2).

   *  Efficient propagation and processing of subscription/filter
      routes.

      -  Ability to summarize the endpoints and thus request a number of
         endpoints for a particular intent in a single subscription
         route.





Hegde, et al.             Expires 25 April 2024                [Page 39]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  The solution may be optional for networks that do not have the
      large scaling requirements.

6.3.2.2.  Scale Analysis

   This section will be updated in the future revision of the document.

6.3.3.  Network Availability Requirements

   *  A BGP intent-aware routing solution should provide high network
      availability for typical deployment topologies, with minimum loss
      of connectivity in different network failure scenarios.

   *  The network failure scenarios, applicable technologies and design
      options described in [I-D.ietf-mpls-seamless-mpls] should be used
      as a reference.

   *  In the Seamless-MPLS reference topology in section 5.4.1.1 :

      -  Failure of intra-domain links should limit loss of connectivity
         (LoC) to under 50ms.  E.g., PE11 to a P node (not shown), 121
         to a P node in Domain1 or Domain2)

      -  Failure of an intra-domain node (P node in any domain) should
         limit LoC to under 50ms

      -  Failure of an ABR node (e.g. 121, 231) should limit LoC to
         under 1sec, or under 50ms depending on the network deployment
         scenario.

      -  Failure of a remote PE node (e.g.  PE31) should limit LoC to
         under 1sec, or under 50ms depending on the network deployment
         scenario and specific service failover requirements

   *  In the Inter-AS Option C VPN reference topology in
      Section 5.4.1.3:

      -  Failure of intra-domain links should limit LoC to under 50ms.
         E.g., PE11 to a P node (not shown), 121 to a P node in Domain1
         or Domain2)

      -  Failure of an intra-domain node (P node in any domain) should
         limit LoC to under 50ms

      -  Failure of an ASBR node (e.g. 121, 211) should limit LoC to
         under 1sec, or under 50ms depending on the network deployment
         scenario.




Hegde, et al.             Expires 25 April 2024                [Page 40]

Internet-Draft      Intent-aware Routing using Color        October 2023


      -  Failure of a remote PE node (e.g.  PE31) should limit LoC to
         under 1sec, or under 50ms depending on the network deployment
         scenario and specific service failover requirements

      -  Failure of an external link (e.g. 121-211) should limit LoC to
         under 1sec, or under 50ms depending on the network deployment
         scenario.

   *  The solution should explore and describe additional techniques and
      design options that are applicable to further improve handling of
      the failure cases listed above.

6.3.4.  BGP Protocol Requirements

   This section summarizes the key protocol requirements that should be
   addressed by the intent-aware BGP routing solution.  While the
   context for several requirements has been discussed earlier in the
   document, this section emphasizes aspects pertinent to the protocol
   design.

   The solution should support the following:

   *  Signaling and distribution of different Intent-aware routes to
      reach a participating node, e.g. a PE.  Intent must be indicated
      by the notion of a Color as defined in [RFC9256]

      -  Signal different instances of a prefix, one route per color

      -  Signal intent (color) associated with each route

      -  At any BGP hop, allow propagating the best path selected for
         each route, or additional paths

      -  Generate routes sourced from IGP-FA, SR-TE Policies, RSVP-TE
         and BGP-LU from a domain

   *  Path selection for Intent-aware routes

      -  Accumulation of intent specific metric at each BGP hop and
         compare the accumulated metric across all received paths at
         intermediate hops and at an ingress PE.

      -  Ability to load balance among multiple received paths at
         intermediate BGP hops and at an ingress PE

      -  Backup path installation for fast convergence at intermediate
         BGP hops and at an ingress PE




Hegde, et al.             Expires 25 April 2024                [Page 41]

Internet-Draft      Intent-aware Routing using Color        October 2023


   *  Validation of received paths

      -  Resolvability of next-hop in control plane

      -  Availability of encapsulation in data plane

   *  Next-hop resolution for BGP Intent-aware route

      -  Flexibility to use different intra-domain and inter-domain
         mechanisms, both intent-aware and traditional

         o  IGP-FA, SR-TE, RSVP-TE, IGP, BGP-LU etc.

      -  Recursive resolution over other BGP Intent-Aware routes

      -  Recursive resolution via alternative color or best-effort paths
         when a particular intent is not available in a domain

   *  Flexible, efficient, extensible protocol definition

      -  As an example for context, currently deployed mechanisms such
         as BGP-LU (RFC 8277) were designed for MPLS, hence only signal
         per prefix label(s) in NLRI.  However, RFC9012 and RFC8669 have
         described extensions to BGP to signal multiple encapsulations,
         though in BGP attributes.  The target deployments for intent-
         aware routing need to support additional transport as described
         in section 6.3.1.6.1.  In addition, they also need to support a
         significantly higher targeted scale as described in scaling
         requirements.

      -  Hence, the protocol definition should

         o  Support efficient signaling of different transport
            encapsulations

         o  Support efficient signaling multiple encapsulations for co-
            existence and migration between encapsulations

         o  Accommodate efficiency of processing and future
            extensibility

   *  Separation of transport and VPN service semantics

      -  Allow for different route distribution planes or processing for
         service vs transport routes

   *  Signaling across domains with different color mappings for a given
      intent



Hegde, et al.             Expires 25 April 2024                [Page 42]

Internet-Draft      Intent-aware Routing using Color        October 2023


6.3.5.  OAM Requirements

   OAM in each domain should be function independently.  This allows for
   more flexible evolution of the network.

   Basic MPLS OAM mechanisms described in [RFC8029] should be supported
   for MPLS based solutions deployments.  Extensions defined in
   [RFC8287] should be supported.

   Mechanisms described in [RFC 9259] should be supported for SRv6 based
   deployments.

   End-to-end ping and traceroute procedures should be supported.

   The ability to validate the path inside each domain should be
   supported.

   Statistics for inter-domain intent-based transport paths should be
   supported on a per intent-aware path basis on the ingress PE nodes
   and as needed on egress and border nodes.

7.  Backward Compatibility

   This section will be updated in the future version of the document.

8.  Security Considerations

   This section will be updated in the future version of the document.

9.  IANA Considerations

   This section will be updated in the future version of the document.

10.  Acknowledgements

   The authors would especially like to thank Joel Halpern for his
   guidance on the collaboration work that has produced this document
   and feedback on many aspects of the problem statement.

   We would like to thank Daniel Voyer, Robert Raszuk, Kireeti Kompella,
   Ron Bonica, Krzysztof Szarkowicz, Julian Lucek, Ram Santhanakrishnan,
   Stephane Litkowski, Andrew Alston for discussions and inputs.

   We also express our appreciation to Hannes Gredler, Simon Spraggs,
   Jose Liste and Jiri Chaloupka for discussions that have helped
   provide input to the problem statement.





Hegde, et al.             Expires 25 April 2024                [Page 43]

Internet-Draft      Intent-aware Routing using Color        October 2023


   Many thanks to Colby Barth, John Scudder, Kamran Raza, Kris
   Michelson, Huaimo Chen for their review and valuable suggestions.

   Many thanks to Qassim Badat for valuable inputs on multicast
   requirements.

11.  Co-authors

   1.  Srihari Sangli

   Juniper Networks Inc.

   ssangli@juniper.net


   2.  Swadesh Agrawal

   Cisco Systems

   swaagraw@cisco.com


   3.  Clarence Filsfils

   Cisco Systems

   cfilsfils@cisco.com


   4.  Ketan Talaulikar

   Cisco Systems

   ketan.ietf@gmail.com


   5.  Keyur Patel

   Arrcus, Inc

   keyur@arrcus.com


   6.  Bruno Decraene

   Orange

   bruno.decraene@orange.com



Hegde, et al.             Expires 25 April 2024                [Page 44]

Internet-Draft      Intent-aware Routing using Color        October 2023


   7.  Xiaohu Xu

   China Mobile

   13910161692@qq.com


   8.  Arkadiy Gulko

   EdwardJones

   arkadiy.gulko@edwardjones.com


   9.  Mazen Khaddam

   Cox communications

   mazen.khaddam@cox.com


   10.  Luis M.  Contreras

   Telefonica

   luismiguel.contrerasmurillo@telefonica.com


   11.  Dirk Steinberg

   Lapishills Consulting Limited

   dirk@lapishills.com


   12.  Jim Guichard

   Futurewei

   james.n.guichard@futurewei.com


   13.  Wim Henderickx

   Nokia

   wim.henderickx@nokia.com




Hegde, et al.             Expires 25 April 2024                [Page 45]

Internet-Draft      Intent-aware Routing using Color        October 2023


   14.  Chris Bowers

   Independent Contributor

12.  Contributors

   1.Kaliraj Vairavakkalai

   Juniper Networks

   kaliraj@juniper.net


   2.  Jeffrey Zhang

   Juniper Networks

   zzhang@juniper.net

13.  References

13.1.  Normative References

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

13.2.  Informative References

   [I-D.dskc-bess-bgp-car]
              Rao, D., Agrawal, S., Filsfils, C., Steinberg, D., Jalil,
              L., Su, Y., Decraene, B., Guichard, J., Talaulikar, K.,
              Patel, K., Wang, H., and J. Uttaro, "BGP Color-Aware
              Routing (CAR)", Work in Progress, Internet-Draft, draft-
              dskc-bess-bgp-car-05, 6 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-dskc-bess-
              bgp-car-05>.

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




Hegde, et al.             Expires 25 April 2024                [Page 46]

Internet-Draft      Intent-aware Routing using Color        October 2023


   [I-D.filsfils-spring-sr-policy-considerations]
              Filsfils, C., Talaulikar, K., Król, P. G., Horneffer, M.,
              and P. Mattes, "SR Policy Implementation and Deployment
              Considerations", Work in Progress, Internet-Draft, draft-
              filsfils-spring-sr-policy-considerations-09, 24 April
              2022, <https://datatracker.ietf.org/doc/html/draft-
              filsfils-spring-sr-policy-considerations-09>.

   [I-D.hegde-rtgwg-egress-protection-sr-networks]
              Hegde, S., Lin, W., and S. Peng, "Egress Protection for
              Segment Routing (SR) networks", Work in Progress,
              Internet-Draft, draft-hegde-rtgwg-egress-protection-sr-
              networks-02, 2 March 2022,
              <https://datatracker.ietf.org/doc/html/draft-hegde-rtgwg-
              egress-protection-sr-networks-02>.

   [I-D.hegde-spring-node-protection-for-sr-te-paths]
              Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
              "Node Protection for SR-TE Paths", Work in Progress,
              Internet-Draft, draft-hegde-spring-node-protection-for-sr-
              te-paths-07, 30 July 2020,
              <https://datatracker.ietf.org/doc/html/draft-hegde-spring-
              node-protection-for-sr-te-paths-07>.

   [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://datatracker.ietf.org/doc/html/draft-hegde-spring-
              seamless-sr-architecture-00>.

   [I-D.ietf-idr-performance-routing]
              Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C.
              Jacquenet, "Performance-based BGP Routing Mechanism", Work
              in Progress, Internet-Draft, draft-ietf-idr-performance-
              routing-03, 22 December 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              performance-routing-03>.

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
              D. Jain, "Advertising Segment Routing Policies in BGP",
              Work in Progress, Internet-Draft, draft-ietf-idr-segment-
              routing-te-policy-25, 26 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              segment-routing-te-policy-25>.



Hegde, et al.             Expires 25 April 2024                [Page 47]

Internet-Draft      Intent-aware Routing using Color        October 2023


   [I-D.ietf-lsr-flex-algo-bw-con]
              Hegde, S., Britto, W., 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-07, 26 September
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lsr-flex-algo-bw-con-07>.

   [I-D.ietf-mpls-seamless-mpls]
              Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
              M., and D. Steinberg, "Seamless MPLS Architecture", Work
              in Progress, Internet-Draft, draft-ietf-mpls-seamless-
              mpls-07, 28 June 2014,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              seamless-mpls-07>.

   [I-D.ietf-pce-segment-routing-policy-cp]
              Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
              Bidgoli, "PCEP extension to support Segment Routing Policy
              Candidate Paths", Work in Progress, Internet-Draft, draft-
              ietf-pce-segment-routing-policy-cp-12, 24 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              segment-routing-policy-cp-12>.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
              Decraene, B., and D. Voyer, "Topology Independent Fast
              Reroute using Segment Routing", Work in Progress,
              Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
              11, 30 June 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rtgwg-segment-routing-ti-lfa-11>.

   [I-D.kaliraj-idr-bgp-classful-transport-planes]
              Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
              Mishra, G. S., Khaddam, M., Xu, X., Szarecki, R. J.,
              Gowda, D. J., Yadlapalli, C., and I. Means, "BGP Classful
              Transport Planes", Work in Progress, Internet-Draft,
              draft-kaliraj-idr-bgp-classful-transport-planes-17, 30
              June 2022, <https://datatracker.ietf.org/doc/html/draft-
              kaliraj-idr-bgp-classful-transport-planes-17>.

   [I-D.voyer-pim-sr-p2mp-policy]
              Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
              J. Zhang, "Segment Routing Point-to-Multipoint Policy",
              Work in Progress, Internet-Draft, draft-voyer-pim-sr-p2mp-
              policy-02, 10 July 2020,
              <https://datatracker.ietf.org/doc/html/draft-voyer-pim-sr-
              p2mp-policy-02>.



Hegde, et al.             Expires 25 April 2024                [Page 48]

Internet-Draft      Intent-aware Routing using Color        October 2023


   [I-D.zzhang-bess-bgp-multicast]
              Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I.,
              Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work
              in Progress, Internet-Draft, draft-zzhang-bess-bgp-
              multicast-03, 29 October 2019,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
              bgp-multicast-03>.

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

   [RFC3906]  Shen, N. and H. Smit, "Calculating Interior Gateway
              Protocol (IGP) Routes Over Traffic Engineering Tunnels",
              RFC 3906, DOI 10.17487/RFC3906, October 2004,
              <https://www.rfc-editor.org/info/rfc3906>.

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

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, DOI 10.17487/RFC4272, January 2006,
              <https://www.rfc-editor.org/info/rfc4272>.

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

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

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <https://www.rfc-editor.org/info/rfc6952>.

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






Hegde, et al.             Expires 25 April 2024                [Page 49]

Internet-Draft      Intent-aware Routing using Color        October 2023


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

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

   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
              DOI 10.17487/RFC9012, April 2021,
              <https://www.rfc-editor.org/info/rfc9012>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023,
              <https://www.rfc-editor.org/info/rfc9350>.

Authors' Addresses

   Shraddha Hegde (Editor)
   Juniper Networks Inc.
   Exora Business Park
   Bangalore 560103
   KA
   India
   Email: shraddha@juniper.net


   Dhananjaya Rao (Editor)
   Cisco Systems
   United States of America
   Email: dhrao@cisco.com






Hegde, et al.             Expires 25 April 2024                [Page 50]

Internet-Draft      Intent-aware Routing using Color        October 2023


   James Uttaro
   Independent Contributor
   Email: juttaro@ieee.org


   Alex Bogdanov
   BT
   Email: alex.bogdanov@bt.com


   Luay Jalil
   Verizon
   Email: luay.jalil@verizon.com






































Hegde, et al.             Expires 25 April 2024                [Page 51]