Skip to main content

1. Introduction

BGP Color-Aware Routing (BGP CAR) is a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. BGP CAR distributes different routes to a destination network endpoint (e.g., a Provider Edge (PE) router) for different intents or colors. A color is a non-zero 32-bit integer value associated with a network intent (such as low-cost, low-latency, avoid certain resources, 5G network slice, etc.) as defined in Section 2.1 of [RFC9256].

BGP CAR addresses the transport and VPN problem statement and requirements described in [INTENT-AWARE].

To this end, this document specifies two new BGP SAFIs, called BGP CAR SAFI (83) and VPN CAR SAFI (84), for carrying infrastructure routes to establish transport paths. Both CAR SAFI and VPN CAR SAFI are applicable to IPv4 Unicast and IPv6 Unicast AFIs (AFI 1 and AFI 2). Use of these SAFIs with other AFIs is outside the scope of this document.

BGP CAR SAFI can be enabled on transport devices in a provider network (underlay) to establish color-aware transport/infrastructure paths between provider networks. A multi-domain transport network may comprise multiple BGP Autonomous Systems (ASes) as well as multiple IGP domains within a single BGP AS. BGP CAR SAFI can also be enabled in VPN Routing and Forwarding (VRF) on PE routers towards peering Customer Edge (CE) routers, as well as on devices within customer networks. VPN CAR SAFI is used to distribute intent-aware routes received from different customers at PE routers, across the provider network, while maintaining separation of potentially overlapping customer address spaces. Thus, the BGP CAR solution enables intent-aware transport paths to be established in a multi-domain network spanning customer and provider network domains.

This document also defines two BGP CAR route types for this purpose.

BGP CAR Type-1 NLRI (E, C) supports originating and distributing multiple color-aware routes to the same destination IP prefix for different colors. This occurs in scenarios where a transport node (such as a PE) has a common IP address (such as a loopback address) for multiple intent advertisements. The operator intends to use this common IP address both as the BGP next hop for service routes and as the transport endpoint for data-plane paths. Multiple routes to this same address or prefix are needed to establish unique paths for each intent. An example is establishing multiple Label Switched Paths (LSPs) to an egress PE for MPLS or Segment Routing over MPLS (SR-MPLS), one for each intent.

BGP CAR Type-2 NLRI (IP prefix or E) supports distributing multiple color-aware routes to a transport node in scenarios where the operator designates unique network IP address blocks for a given intent and the transport node assigns a unique IP prefix or address for each intent. An example use case is per-intent locators for Segment Routing over IPv6 (SRv6).

These BGP CAR intent-aware paths are then used by ingress nodes (such as PEs) to steer traffic for service routes that need a specific intent. Steering may be for all or specific traffic to a destination.

BGP CAR follows the flat routing model used by BGP for IP routing (BGP-IP) [RFC4271] or BGP Labeled Unicast (BGP-LU) (SAFI 4 in [RFC8277]) and extends it to support intent-awareness, thus providing an operational experience consistent with these widely deployed transport routing technologies.

1.1. Terminology​

Intent (in routing):
Any behavior that influences routing or path selection, including any combination of the following behaviors:

a. Topological path selection (e.g., minimizing a metric or avoiding resources)
b. Network Function Virtualization (NFV) service insertion (e.g., service chain steering)
c. Per-hop behavior (e.g., 5G slicing)

This is a more specific concept than best-effort in terms of routing, as compared to intent as a declarative abstraction in [RFC9315].

Color:
A non-zero 32-bit integer value associated with an intent (e.g., low-cost, low-latency, or avoid certain resources), as defined in Section 2.1 of [RFC9256]. Color assignment is operator-managed.

Colored service route:
An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route (e.g., V/v) to indicate the intent it requests for traffic bound to V/v. The color is encoded as a BGP Color Extended Community [RFC9012], used per [RFC9256], or represented by the locator part of an SRv6 Service SID [RFC9252].

Color-aware path to (E2, C):
A path to forward packets towards E2 that satisfies the intent associated with color C. Multiple technologies can provide a color-aware path to (E2, C), such as SR Policy [RFC9256], IGP Flexible Algorithm [RFC9350], and BGP CAR (as specified in this document).

Color-aware route (E2, C):
A distributed or signaled route to build a color-aware path to E2 for color C.

Service route automated steering on color-aware path:
An ingress PE (or ASBR) E1 automatically steers traffic for a C-colored service route V/v from E2 onto a (E2, C) color-aware path. If multiple such paths exist, a preference scheme is used to select the best path (e.g., IGP Flexible Algorithm preferred over SR Policy, SR Policy preferred over BGP CAR).

Color domain:
A set of nodes sharing the same color-to-intent mapping, typically under a single administration. The set may be organized into one or more network domains (IGP areas/instances within a single BGP AS, or multiple BGP ASes). Color-to-intent mapping on nodes is set via configuration. Color remapping and filtering may occur at color domain boundaries. See [INTENT-AWARE].

Resolution of a BGP CAR route (E, C):
An inter-domain BGP CAR route (E, C) via N is resolved on an intra-domain color-aware path (N, C), where N is the next hop of the BGP CAR route.

Resolution versus steering:
Consistent with terminology used in SR Policy documents ([RFC9256] Section 8), in this document, (service route) steering is used to describe the mapping of traffic for a service route to a BGP CAR path. Conversely, the term resolution is reserved for the mapping of an inter-domain BGP CAR route to an intra-domain color-aware path.

Service steering:
Service route maps traffic to a BGP CAR path (or other color-aware path, e.g., SR Policy). If a color-aware path is not available, local policy may map to a color-unaware route/TE path (e.g., BGP-LU, RSVP-TE, IGP/LDP). The service steering concept is independent of the transport technology used. Section 3 describes specific service steering mechanisms for MPLS, SR-MPLS, and SRv6.

Intra-domain resolution:
BGP CAR route maps to an intra-domain color-aware path (e.g., SR Policy, IGP Flexible Algorithm, BGP CAR) or color-unaware route/TE path (e.g., RSVP-TE, IGP/LDP, BGP-LU).

Transport network:
A network comprising multiple collaborating domains managed by one or more operators, using routing technologies (such as IP, MPLS, and SR) to forward packets to provide connectivity and other services. In SR deployments, the transport network is within the trusted domain as defined in [RFC8402].

Transport layer:
Refers to the underlay network layer (e.g., MPLS LSPs between PEs) used by an overlay or service layer (e.g., MPLS VPN).

Transport RR:
A BGP Route Reflector (RR) used to distribute transport/underlay routes intra-domain or inter-domain.

Service RR:
A BGP Route Reflector (RR) used to distribute service/overlay routes intra-domain or inter-domain.

Abbreviations:

  • ABR: Area Border Router
  • AFI: Address Family Identifier
  • AIGP: Accumulated IGP Metric Attribute [RFC7311]
  • ASBR: Autonomous System Border Router
  • BGP-LU: BGP Labeled Unicast SAFI (SAFI value 4 per [RFC8277])
  • BGP-IP: BGP IPv4/IPv6 Unicast SAFI (SAFI value 1 per [RFC4760] and [RFC4271])
  • BR: Border Router (for IGP area (ABR) or BGP Autonomous System (ASBR))
  • Color-EC: BGP Color Extended Community [RFC9012]
  • E: Generic representation of a transport endpoint, e.g., PE, ABR, or ASBR
  • LCM-EC: BGP Local Color Mapping Extended Community
  • NLRI: Network Layer Reachability Information [RFC4271]
  • P node: Intra-domain transport router
  • RD: Route Distinguisher
  • RR: Route Reflector
  • T-RR: Transport Route Reflector
  • S-RR: Service Route Reflector
  • SAFI: Subsequent Address Family Identifier
  • TEA: Tunnel Encapsulation Attribute [RFC9012]
  • V/v, W/w: Generic representation of service routes (indicating prefix/mask length), irrespective of AFI/SAFI or actual NLRI encoding

1.2. Illustration​

The following is a brief illustration of notable features of the BGP CAR solution.

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

Figure 1: BGP CAR Solution Illustration

All nodes are part of an inter-domain network under a single authority with consistent color-to-intent mapping:

  • C1 maps to "low-latency"

    • Flex-Algo 1 maps to "low-latency", thus to C1

  • C2 maps to "low-latency and avoid resource R"

    • Flex-Algo 2 maps to "low-latency and avoid resource R", thus to C2

E1 receives two service routes from E2:

  • V/v with BGP Color-EC C1
  • W/w with BGP Color-EC C2

E1 has the following color-aware paths:

  • (E2, C1) provided by BGP CAR with per-domain support as follows:

    • Domain 1: via IGP FA1
    • Domain 2: via SR Policy bound to color C1
    • Domain 3: via IGP FA1

  • (E2, C2) provided by SR Policy

E1 automatically steers traffic for received service routes as follows:

  • V/v via (E2, C1) provided by BGP CAR
  • W/w via (E2, C2) provided by SR Policy

Example Properties:

  • Leverages BGP Color-EC

    • Service routes are colored using the widely used BGP Color Extended Community [RFC9012] to request intent

  • (E, C) Automated Steering

    • V/v and W/w are automatically steered to appropriate color-aware paths

  • Seamless Coexistence of BGP CAR and SR Policy

    • V/v steered to color-aware path provided by BGP CAR
    • W/w steered to color-aware path provided by SR Policy

  • Seamless Interworking of BGP CAR and SR Policy

    • V/v steered to BGP CAR path, which itself resolves within Domain 2 to an SR Policy bound to V/v's color

Additional Properties:

  • MPLS Data Plane: For 300k PEs and 5 colors, the BGP CAR solution ensures that no single node needs to support data-plane scale on the order of remote PEs * C (Section 5). This would otherwise exceed MPLS data-plane capabilities.

  • Control Plane: If a node does not participate in that color-aware path, it SHOULD NOT install the (E, C) path.

  • Inconsistent Color-Intent Mapping: The solution supports BGP CAR route signaling across different color domains (Section 2.8).

Key advantages of this model are:

  • Leverages BGP Color-EC [RFC9012] for service route coloring
  • Definition of automated service steering: C-colored service route V/v from E2 steers to color-aware path (E2, C)
  • Definition of BGP CAR path data model: (E, C)
    • Natural extension of BGP-IP/BGP-LU data model (E)
    • Consistent with SR Policy data model
  • Definition of recursive resolution for BGP CAR routes: BGP CAR (E2, C) route via N resolves on color-aware path (N, C), which itself may be provided by BGP CAR or via another color-aware routing solution (e.g., SR Policy, IGP Flexible Algorithm)
  • Explicit definition of multiple transport encapsulations (e.g., MPLS, SR, SRv6, IP)

1.3. Requirements Language​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Note: This document is based on RFC 9871. For the complete official specification, please refer to https://www.rfc-editor.org/rfc/rfc9871.html.

Last updated on