rfc9871xml2.original.xml   rfc9871.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="exp" docName="draft-ietf-idr-bgp-car-16"
ipr="trust200902"
submissionType="IETF">
<front>
<title abbrev="BGP Color-Aware Routing (CAR)">
BGP Color-Aware Routing (CAR)
</title>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
tf-idr-bgp-car-16" number="9871" consensus="true" updates="" obsoletes="" ipr="t
rust200902" submissionType="IETF" tocInclude="true" tocDepth="3" symRefs="true"
sortRefs="true" version="3" xml:lang="en">
<front>
<title abbrev="BGP Color-Aware Routing (CAR)">BGP Color-Aware Routing (CAR)<
/title>
<seriesInfo name="RFC" value="9871"/>
<author fullname="Dhananjaya Rao" initials="D" role="editor" surname="Rao"> <author fullname="Dhananjaya Rao" initials="D" role="editor" surname="Rao">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>dhrao@cisco.com</email> <email>dhrao@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Swadesh Agrawal" initials="S" role="editor" surname="Agraw al"> <author fullname="Swadesh Agrawal" initials="S" role="editor" surname="Agraw al">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>swaagraw@cisco.com</email> <email>swaagraw@cisco.com</email>
</address> </address>
</author> </author>
<date month="October" year="2025"/>
<area>RTG</area>
<workgroup>idr</workgroup>
<date/> <keyword>intent-aware routing</keyword>
<keyword>intent-based routing</keyword>
<area>Routing</area> <keyword>color-aware VPNs</keyword>
<keyword>color-aware BGP transport</keyword>
<workgroup>IDR WorkGroup</workgroup> <keyword>BGP extensible NLRI</keyword>
<abstract> <abstract>
<t> <t>
This document describes a BGP based routing solution to establish This document describes a BGP-based routing solution to establish
end-to-end intent-aware paths across a multi-domain transport network. The t ransport end-to-end intent-aware paths across a multi-domain transport network. The t ransport
network can span multiple service provider and customer network domains. network can span multiple service provider and customer network domains.
The BGP intent-aware paths can be used to steer traffic flows for service ro utes The BGP intent-aware paths can be used to steer traffic flows for service ro utes
that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR).
</t> </t>
<t> <t>
This document describes the routing framework and BGP extensions to enable This document describes the routing framework and BGP extensions to enable
intent-aware routing using the BGP CAR solution. The solution defines two new intent-aware routing using the BGP CAR solution. The solution defines two
BGP SAFIs new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It
(BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an ext also defines an extensible Network Layer Reachability Information (NLRI)
ensible NLRI model for both SAFIs that allows multiple NLRI types to be defined for
model for both SAFIs that allow multiple NLRI types to be defined for differe different use cases. Each type of NLRI contains key and TLV-based non-key
nt use cases. fields for efficient encoding of different per-prefix information. This
Each type of NLRI contains key and TLV based non-key fields for efficient enc specification defines two NLRI types: Color-Aware Route NLRI and IP Prefix
oding of different NLRI. It defines non-key TLV types for the MPLS label stack, SR-MPLS label
per-prefix information. This specification defines two NLRI types, Color-Awar index, and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This
e Route solution also defines a new Local Color Mapping (LCM) Extended Community.
NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, L </t>
abel Index
and SRv6 SIDs. This solution also defines a new Local Color Mapping (LCM) Ext
ended
Community.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO">
<name>Introduction</name>
<t> <t>
BGP Color-Aware Routing (CAR) is a BGP based routing solution to establish BGP Color-Aware Routing (CAR) is a BGP-based routing solution to establish
end-to-end intent-aware paths across a multi-domain service provider end-to-end intent-aware paths across a multi-domain service provider
transport network. BGP CAR distributes distinct routes to a destination ne twork transport network. BGP CAR distributes distinct routes to a destination ne twork
endpoint, such as a PE router, for different intents or colors. Color is a endpoint, such as a Provider Edge (PE) router, for different intents or co
non-zero 32-bit integer value associated with a network intent (low-cost, lors. Color is a
low-delay, non-zero 32-bit integer value associated with a network intent (such as lo
avoid some resources, 5G network slice, etc.) as defined in Section 2.1 of w cost, low delay,
<xref target="RFC9256"/>. avoid some resources, 5G network slice, etc.) as defined in
<xref target="RFC9256" sectionFormat="of" section="2.1"/>.
</t> </t>
<t> <t>
BGP CAR fulfills the transport and VPN problem statement and requirements described BGP CAR fulfills the transport and VPN problem statement and the requireme nts described
in <xref target="I-D.hr-spring-intentaware-routing-using-color"/>. in <xref target="I-D.hr-spring-intentaware-routing-using-color"/>.
</t> </t>
<t> <t>
For this purpose, this document specifies two new BGP SAFIs, called For this purpose, this document specifies two new BGP SAFIs, called
BGP CAR SAFI (83) and VPN CAR SAFI (84) that carry infrastructure routes t o BGP CAR SAFI (83) and VPN CAR SAFI (84), that carry infrastructure routes to
set up the transport paths. Both CAR SAFI and VPN CAR SAFI apply to IPv4 U nicast and set up the transport paths. Both CAR SAFI and VPN CAR SAFI apply to IPv4 U nicast and
IPv6 Unicast AFIs (AFI 1 and AFI 2). The use of these SAFIs with other AFI s are IPv6 Unicast AFIs (AFI 1 and AFI 2). The use of these SAFIs with other AFI s are
outside the scope of this document. outside the scope of this document.
</t> </t>
<t> <t>
BGP CAR SAFI can be enabled on transport devices in a provider network (un BGP CAR SAFI can be enabled on transport devices in a provider network
derlay) (underlay) to set up color-aware transport/infrastructure paths across
to set up color-aware transport/infrastructure paths across provider netwo provider networks. The multi-domain transport network may comprise of
rks. multiple BGP Autonomous Systems (ASes) as well as multiple IGP domains wit
The multi-domain transport network may comprise of multiple BGP ASes as we hin a single BGP
ll as AS. BGP CAR SAFI can also be enabled within a VPN Routing and Forwarding (
multiple IGP domains within a single BGP AS. BGP CAR SAFI can also be enab VRF) on a PE router towards
led within a peering Customer Edge (CE) router, and on devices within a customer
a VRF on a PE router towards a peering CE router, and on devices within a network. VPN CAR SAFI is used for the distribution of intent-aware
customer routes from different customers received on a PE router across the
network. VPN CAR SAFI is used for the distribution provider networks, maintaining the separation of the customer address
of intent-aware routes from different customers received on a PE router ac spaces that may overlap. The BGP CAR solution thus enables intent-aware
ross the transport paths to be set up across a multi-domain network that can span
provider networks, customer and provider network domains.
maintaining the separation of the customer address spaces that may overlap
. The BGP CAR
solution thus enables intent-aware transport paths to be set up across a m
ulti-domain
network that can span customer and provider network domains.
</t> </t>
<t> <t>
The document also defines two BGP CAR route types for this purpose. This document also defines two BGP CAR route types for this purpose.
</t> </t>
<t> <t>
The BGP CAR Type-1 NLRI (E, C) enables the generation and distribution of multiple The BGP CAR Type-1 NLRI (E, C) enables the generation and distribution of multiple
color-aware routes to the same destination IP prefix for different colors. color-aware routes to the same destination IP prefix for different colors.
This case arises from situations where a transport node such as a PE has a common This case arises from situations where a transport node such as a PE has a common
IP address (such as a loopback) to advertise for multiple intents. The ope rator intends IP address (such as a loopback) to advertise for multiple intents. The ope rator intends
to use the common IP address as both the BGP next hop for service routes a nd as the to use the common IP address as both the BGP next hop for service routes a nd as the
transport endpoint for the data plane path. Multiple routes are needed for this same transport endpoint for the data plane path. Multiple routes are needed for this same
address or prefix to set up a unique path for each intent. One example is setting up address or prefix to set up a unique path for each intent. One example is setting up
multiple MPLS/SR-MPLS LSPs to an egress PE, one per intent. multiple Label Switched Paths (LSPs) for MPLS or Segment Routing over MPLS (SR-MPLS) to an egress PE, one per intent.
</t> </t>
<t> <t>
The BGP CAR Type-2 NLRI (IP Prefix or E) enables the distribution of multi ple color-aware routes to a The BGP CAR Type-2 NLRI (IP Prefix or E) enables the distribution of multi ple color-aware routes to a
transport node for the case where the operator specifies a unique network transport node for the case where the operator specifies a unique network
IP address block for a given intent, and the transport node gets assigned a IP address block for a given intent, and the transport node gets assigned a
unique IP prefix or address for each intent. An example use-case is unique IP prefix or address for each intent. An example use case is Segmen
SRv6 per-intent locators. t Routing over IPv6 (SRv6)
per-intent locators.
</t> </t>
<t> <t>
These BGP CAR intent-aware paths are then used by an ingress node (such as a PE) to These BGP CAR intent-aware paths are then used by an ingress node (such as a PE) to
steer traffic flows for service routes that need the specific intents. Ste ering may be steer traffic flows for service routes that need the specific intents. Ste ering may be
towards a destination for all or specific traffic flows. towards a destination for all or specific traffic flows.
</t> </t>
<t>BGP CAR adheres to the flat routing model of BGP for IP routing (BGP-IP
) <xref
target="RFC4271"/> or BGP Labeled Unicast (BGP-LU) (SAFI 4 in <xref
target="RFC8277"/>), and extends it to support intent awareness, thereby
providing a consistent operational experience with those widely deployed
transport routing technologies.</t>
<section>
<name>Terminology</name>
<t> <dl spacing="normal" newline="true">
BGP CAR adheres to the flat routing model of BGP-IP/LU(Labeled Unicast) bu <dt>Intent (in routing):</dt>
t extends <dd>
it to support intent-awareness, thereby providing a consistent operational <t>Any behaviors to influence routing or path selection, including
experience any combination of the following behaviors:</t>
with those widely deployed transport routing technologies. <ol type="a" spacing="compact">
</t> <li>Topology path selection (e.g., minimize metric or avoid
resource)</li>
<li>Network Function Virtualization (NFV) service insertion (e.g.,
service chain steering)</li>
<li>Per-hop behavior (e.g., a 5G slice)</li>
</ol>
<t>This is a more specific concept with respect to routing
beyond best-effort, compared to intent as a declarative
abstraction in <xref target="RFC9315"/>.</t>
</dd>
<section title="Terminology"> <dt>Color:</dt>
<texttable> <dd>A non-zero 32-bit integer value associated with an intent
<ttcol width="20%"></ttcol> (e.g., low cost, low delay, or avoid some resources) as defined in
<ttcol width="48%"></ttcol> <xref target="RFC9256" sectionFormat="of" section="2.1"/>. Color assig
nment is managed by
the operator.</dd>
<c>Intent (in routing)</c> <dt>Colored service route:</dt>
<c>Any behaviors to influence routing or path selection, including any <dd>An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route
combination of the following (e.g., V/v) to indicate the intent that it requests for the traffic
behaviors: a) Topology path selection bound to V/v. The color is encoded as a BGP Color
(e.g. minimize metric or avoid resource), b) NFV service insertion (e. Extended Community <xref target="RFC9012"/>, used as per <xref target=
g. service "RFC9256"/>,
chain steering), c) per-hop behavior (e.g. a 5G slice). This is a more or represented by the locator part of SRv6 Service SID <xref
specific concept target="RFC9252"/>.</dd>
w.r.t. routing beyond best-effort, compared to intent as a declarative
abstraction in <xref target="RFC9315"/>.
</c>
<c></c> <dt>Color-aware path to (E2, C):</dt>
<c></c> <dd>A path to forward packets towards E2 that satisfies the intent
<c>Color</c> associated with color C. Several technologies may provide a
<c>A non-zero 32-bit integer value associated with an intent (e.g. low color-aware path to (E2, C), such as SR Policy <xref target="RFC9256"/
-cost >, IGP
, low-delay, or avoid some resources) as defined in Flexible Algorithm <xref target="RFC9350"/>, and BGP CAR (as specified
<xref target="RFC9256"/> Section 2.1. Color assignment is managed by t in this document).</dd>
he operator.</c>
<c></c> <dt>Color-aware route (E2, C):</dt>
<c></c> <dd>A distributed or signaled route that builds a color-aware path to
E2 for
color C.</dd>
<c>Colored Service Route</c> <dt>Service route automated steering on color-aware path:</dt>
<c>An egress PE (e.g. E2) colors its BGP service (e.g. VPN) route (e.g <dd>An ingress PE (or ASBR) E1 automatically steers traffic for a
. V/v) C-colored service route V/v from E2 onto an (E2, C) color-aware
to indicate the intent that it requests for the traffic bound to V/v. path. If several such paths exist, a preference scheme is used to
The color select the best path (for example, IGP Flexible Algorithm is preferred
is encoded as a BGP Color Extended-Community <xref target="RFC9012"/>, over SR
used as per [RFC9256], Policy, and SR Policy is preferred over BGP CAR).</dd>
or represented by the locator part of SRv6 Service SID <xref target="R
FC9252"/>.</c>
<c></c> <dt>Color domain:</dt>
<c></c> <dd>A set of nodes that share the same color-to-intent mapping, typica
lly under
single administration. This set can be organized into one or multiple
network domains
(IGP areas/instances within a single BGP AS, or multiple BGP ASes). Co
lor-to-intent
mapping on nodes is set by configuration. Color re-mapping and filteri
ng may happen
at color domain boundaries. Refer to
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>.</dd>
<c>Color-Aware Path to (E2, C)</c> <dt>Resolution of a BGP CAR route (E, C):</dt>
<c>A path to forward packets towards E2 which satisfies the intent ass <dd>An inter-domain BGP CAR route (E, C) via N is resolved on an
ociated with color C. intra-domain color-aware path (N, C) where N is the next hop of the
Several technologies may provide a Color-Aware Path to (E2, C): SR Pol BGP CAR route.</dd>
icy
<xref target="RFC9256"/>, IGP Flex-Algo
<xref target="RFC9350"/>, BGP CAR [specified in this document].</c>
<c></c> <dt>Resolution versus steering:</dt>
<c></c> <dd>
<t>Consistent with the terminology used in the SR Policy document
(<xref target="RFC9256" sectionFormat="of" section="8"/>), in
this document (service route) steering is used to describe the
mapping of the traffic for a service route onto a BGP CAR path.
In contrast, the term resolution is preserved for the mapping of
an inter-domain BGP CAR route on an intra-domain color-aware
path.</t>
<dl spacing="normal" newline="true">
<dt>Service steering:</dt>
<dd>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 routing/TE path
(e.g., BGP-LU, RSVP-TE, IGP/LDP). The service steering concept is
agnostic to the transport technology used. <xref
target="STEERING"/> describes the specific service steering
mechanisms leveraged for MPLS, SR-MPLS, and SRv6.</dd>
<c>Color-Aware Route (E2, C)</c> <dt>Intra-domain resolution:</dt>
<c>A distributed or signaled route that builds a color-aware path to E <dd>BGP CAR route maps to an intra-domain color-aware path (e.g., S
2 for R
color C. Policy, IGP Flexible Algorithm, BGP CAR) or a color-unaware routing
</c> /TE path
(e.g., RSVP-TE, IGP/LDP, BGP-LU).</dd>
</dl>
</dd>
<c></c> <dt>Transport network:</dt>
<c></c> <dd>A network that comprises of multiple cooperating domains managed
by one or more operators, and uses routing technologies such as IP,
MPLS, and SR to forward packets for connectivity and
other services. In an SR deployment, the transport network is
within a trusted domain as per <xref target="RFC8402"/>.</dd>
<c>Service Route Automated Steering on Color-Aware Path</c> <dt>Transport layer:</dt>
<c>An ingress PE (or ASBR) E1 automatically steers traffic for a C-col <dd>Refers to an underlay network layer (e.g., MPLS LSPs between
ored service route PEs) that gets used by an overlay or service layer (e.g., MPLS
V/v from E2 onto an (E2, C) color-aware path. If several such paths ex VPNs).</dd>
ist, a preference
scheme is used to select the best path (for example, IGP Flex-Algo pre
ferred over
SR Policy preferred over BGP CAR.</c>
<c></c> <dt>Transport RR:</dt>
<c></c> <dd>A BGP Route Reflector (RR) used to distribute transport/underlay r
outes within a domain or
across domains.</dd>
<c>Color Domain</c> <dt>Service RR:</dt>
<c>A set of nodes which share the same Color-to-Intent mapping, typica <dd>A BGP Route Reflector (RR) used to distribute service/overlay rout
lly under es
single administration. This set can be organized into one or multiple within a domain or across domains.</dd>
network domains </dl>
(IGP areas/instances within a single BGP AS, or multiple BGP ASes). Co
lor-to-intent
mapping on nodes is set by configuration. Color re-mapping and filteri
ng may happen
at color domain boundaries. Refer to
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>.</c>
<c></c> <t>Abbreviations:</t>
<c></c> <dl spacing="normal" newline="false">
<dt>ABR:</dt>
<dd>Area Border Router</dd>
<c>Resolution of a BGP CAR route (E, C)</c> <dt>AFI:</dt>
<c>An inter-domain BGP CAR route (E, C) via N is resolved on an <dd>Address Family Identifier</dd>
intra-domain color-aware path (N, C) where N is the next hop of the BG
P CAR
route.</c>
<c></c> <dt>AIGP:</dt>
<c></c> <dd>Accumulated IGP Metric Attribute <xref target="RFC7311"/></dd>
<c>Resolution vs Steering</c> <dt>ASBR:</dt>
<c>In this document, and consistent with the terminology used in the S <dd>Autonomous System Border Router</dd>
R Policy
document <xref target="RFC9256"/> Section 8, (Service route) steering
is used
to describe the mapping of the traffic for a service route onto a BGP
CAR path.
In contrast, the term resolution is preserved for the mapping of an in
ter-domain
BGP CAR route on an intra-domain color-aware path.</c>
<c></c> <dt>BGP-LU:</dt>
<c></c> <dd>BGP Labeled Unicast SAFI (SAFI value 4 as per <xref target="RFC8277
"/>)</dd>
<c></c> <dt>BGP-IP:</dt>
<c>Service Steering: Service route maps traffic to a BGP CAR path (or <dd>BGP IPv4/IPv6 Unicast SAFI (SAFI value 1 as per <xref target="RFC47
other Color-Aware 60"/> and <xref target="RFC4271"/>)</dd>
Path: e.g. SR Policy). If a Color-Aware Path is not available, local
policy may map to traditional routing/TE path (e.g. BGP LU, RSVP-TE, I
GP/LDP).
The service steering concept is agnostic to the transport technology u
sed.
<xref target="STEERING"/> describes the specific service steering mech
anisms leveraged
for MPLS, SR-MPLS and SRv6.
</c>
<c></c> <dt>BR:</dt><dd>Border Router (either for an IGP area (an ABR) or a BGP
<c></c> autonomous system (an ASBR))</dd>
<c></c> <dt>Color-EC:</dt>
<c>Intra-Domain Resolution: BGP CAR route maps to intra-domain color a <dd>BGP Color Extended Community <xref target="RFC9012"/></dd>
ware path
(e.g. SR Policy, IGP Flex-Algo, BGP CAR) or traditional routing/TE pat
h (e.g.
RSVP-TE, IGP/LDP, BGP-LU).</c>
<c></c> <dt>E:</dt>
<c></c> <dd>Generic representation of a transport endpoint such
<c>Transport Network</c> as a PE, ABR, or ASBR</dd>
<c>A network that comprises of multiple cooperating domains managed by
one or more
operators, and uses routing technologies such as IP, MPLS and Segment
Routing to
forward packets for connectivity and other services. In an SR deploym
ent, the
transport network is within a trust domain as per [RFC8402].</c>
<c></c>
<c></c>
<c>Transport Layer</c>
<c>Refers to an underlay network layer (e.g., MPLS LSPs between PEs) th
at gets used by
an overlay or service layer (e.g., MPLS VPNs).</c>
<c></c>
<c></c>
<c>Transport RR</c>
<c>A BGP Route Reflector used to distribute transport/underlay routes
within a domain or
across domains. </c>
<c></c>
<c></c>
<c>Service RR</c>
<c>A BGP Route Reflector used to distribute service/overlay routes wit
hin a domain or
across domains. </c>
</texttable> <dt>LCM-EC:</dt>
<dd>BGP Local Color Mapping Extended Community</dd>
<t>Abbreviations:</t> <dt>NLRI:</dt>
<t><list style="symbols"> <dd>Network Layer Reachability Information <xref target="RFC4271"/></dd
<t>AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers. >
</t>
<t>
AIGP: Accumulated IGP Metric Attribute <xref target="RFC7311"/>.
</t>
<t>
BGP-LU: BGP Labeled Unicast SAFI <xref target="RFC8277"/>.
</t>
<t>
BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs <xref target="RFC4271"/>,
<xref target="RFC4760"/>.
</t>
<t>BR: Border Router, either for an IGP Area (ABR) or a BGP Autonomous
System (ASBR).
</t>
<t>
Color-EC: BGP Color Extended-Community <xref target="RFC9012"/>.
</t>
<t>
E: Generic representation of a transport endpoint such as a PE, ABR or
ASBR.
</t>
<t>
LCM-EC: BGP Local Color Mapping Extended-Community.
</t>
<t>
NLRI: Network Layer Reachability Information <xref target="RFC4271"/>.
</t>
<t>P node: An intra-domain transport router.
</t>
<t>RR: BGP Route Reflector.
</t>
<t>
TEA: Tunnel Encapsulation Attribute <xref target="RFC9012"/>.
</t>
<t>
V/v, W/w: Generic representations of a service route (indicating prefi
x/masklength),
regardless of AFI/SAFI or actual NLRI encoding.
</t>
</list> <dt>P node:</dt>
</t> <dd>An intra-domain transport router</dd>
<dt>RD:</dt>
<dd>Route Distinguisher</dd>
<dt>RR:</dt>
<dd>Route Reflector</dd>
<dt>SAFI:</dt>
<dd>Subsequent Address Family Identifier</dd>
<dt>TEA:</dt>
<dd>Tunnel Encapsulation Attribute <xref target="RFC9012"/></dd>
<dt>V/v, W/w:</dt>
<dd>Generic representations of a service route (indicating
prefix/mask length), regardless of AFI/SAFI or actual NLRI
encoding</dd>
</dl>
</section> </section>
<section anchor="SECCARIllus" title="Illustration"> <section anchor="SECCARIllus">
<name>Illustration</name>
<t>Here is a brief illustration of the salient properties of the BGP CAR <t>Here is a brief illustration of the salient properties of the BGP CAR
solution.</t> solution.</t>
<figure anchor="Illustration" title="BGP CAR Solution Illustration"> <figure anchor="Illustration">
<name>BGP CAR Solution Illustration</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| | | | | | V/v with C1 | | | | | | V/v with C1
|----+ |------| |------| +----|/ |----+ |------| |------| +----|/
| E1 | | | | | | E2 |\ | E1 | | | | | | E2 |\
|----+ | | | | +----| W/w with C2 |----+ | | | | +----| W/w with C2
| |------| |------| | | |------| |------| |
| Domain 1 | | Domain 2 | | Domain 3 | | Domain 1 | | Domain 2 | | Domain 3 |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
]]></artwork>
]]></artwork>
</figure> </figure>
<t>All the nodes are part of an inter-domain network under a single auth ority <t>All the nodes are part of an inter-domain network under a single auth ority
and with a consistent color-to-intent mapping: and with a consistent color-to-intent mapping:
<list style="symbols">
<t>C1 is mapped to "low-delay"
<list>
<t>Flex-Algo FA1 is mapped to "low delay" and hence to C1</t>
</list>
</t>
<t>C2 is mapped to "low-delay and avoid resource R"
<list>
<t>Flex-Algo FA2 is mapped to "low delay and avoid resource R" and h
ence C2</t>
</list>
</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>C1 is mapped to "low delay"
</t>
<ul spacing="normal">
<li>
<t>Flex-Algo 1 is mapped to "low delay", and hence to C1</t>
</li>
</ul>
</li>
<li>
<t>C2 is mapped to "low delay and avoid resource R"</t>
<ul spacing="normal">
<li>
<t>Flex-Algo 2 is mapped to "low delay and avoid resource R", an
d hence to C2</t>
</li>
</ul>
</li>
</ul>
<t>E1 receives two service routes from E2: <t>E1 receives two service routes from E2:
<list style="symbols">
<t>V/v with BGP Color-EC C1</t>
<t>W/w with BGP Color-EC C2</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>V/v with BGP Color-EC C1</t>
</li>
<li>
<t>W/w with BGP Color-EC C2</t>
</li>
</ul>
<t>E1 has the following color-aware paths:</t>
<t>E1 has the following color-aware paths: <ul spacing="normal">
<list style="symbols"> <li>
<t>(E2, C1) provided by BGP CAR with the following per-domain support: <t>(E2, C1) provided by BGP CAR with the following per-domain suppor
<list> t:</t>
<t>Domain1: over IGP FA1</t> <ul spacing="normal">
<t>Domain2: over SR Policy bound to color C1</t> <li>
<t>Domain3: over IGP FA1</t> <t>Domain 1: over IGP FA1</t>
</list> </li>
</t> <li>
<t>(E2, C2) provided by SR Policy</t> <t>Domain 2: over SR Policy bound to color C1</t>
</list> </li>
</t> <li>
<t>Domain 3: over IGP FA1</t>
</li>
</ul>
</li>
<li>
<t>(E2, C2) provided by SR Policy</t>
</li>
</ul>
<t>E1 automatically steers traffic for the received service routes as fo <t>E1 automatically steers traffic for the received service routes as fo
llows: llows:</t>
<list style="symbols">
<t>V/v via (E2, C1) provided by BGP CAR</t>
<t>W/w via (E2, C2) provided by SR Policy</t>
</list>
</t>
<t>Illustrated Properties: <ul spacing="normal">
<list style="symbols"> <li>
<t>Leverage of the BGP Color-EC <t>V/v via (E2, C1) provided by BGP CAR</t>
<list> </li>
<t>The service routes are colored with widely used BGP Color <li>
Extended-Community <xref target="RFC9012"/> to request intent</t> <t>W/w via (E2, C2) provided by SR Policy</t>
</list> </li>
</t> </ul>
<t>(E, C) Automated Steering
<list> <t>Illustrated properties:</t>
<t>V/v and W/w are automatically steered on the appropriate color-aw
are <ul spacing="normal">
<li>
<t>Leverage of the BGP Color-EC
</t>
<ul spacing="normal">
<li>
<t>The service routes are colored with widely used BGP Color
Extended Community <xref target="RFC9012"/> to request
intent</t>
</li>
</ul>
</li>
<li>
<t>(E, C) automated steering</t>
<ul spacing="normal">
<li>
<t>V/v and W/w are automatically steered on the appropriate colo
r-aware
path</t> path</t>
</list> </li>
</t> </ul>
<t>Seamless co-existence of BGP CAR and SR Policy </li>
<list> <li>
<t>V/v is steered on BGP CAR color-aware path</t> <t>Seamless coexistence of BGP CAR and SR Policy
<t>W/w is steered on SR Policy color-aware path</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>Seamless interworking of BGP CAR and SR Policy <t>V/v is steered on a color-aware path provided by BGP CAR</t>
<list> </li>
<t>V/v is steered on a BGP CAR color-aware path that is itself resol <li>
ved <t>W/w is steered on a color-aware path provided by SR Policy</t
>
</li>
</ul>
</li>
<li>
<t>Seamless interworking of BGP CAR and SR Policy
</t>
<ul spacing="normal">
<li>
<t>V/v is steered on a BGP CAR path that is itself resolved
within domain 2 onto an SR Policy bound to the color of V/v</t> within domain 2 onto an SR Policy bound to the color of V/v</t>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
<t>Other properties: <t>Other properties:
<list style="symbols"> </t>
<t>MPLS data-plane: with 300k PE's and 5 colors, the BGP CAR solution <ul spacing="normal">
ensures <li>
that no single node needs to support a data-plane scaling in the order <t>MPLS data plane: with 300k PEs and 5 colors, the BGP CAR solution
of ensures
that no single node needs to support a data plane scaling in the order
of
Remote PE * C (<xref target="SCLNG"/>). This would otherwise exceed th e MPLS Remote PE * C (<xref target="SCLNG"/>). This would otherwise exceed th e MPLS
data-plane.</t> data plane.</t>
<t>Control-Plane: a node should not install a (E, C) path if it's not </li>
participating <li>
<t>Control plane: a node should not install a (E, C) path if it's no
t participating
in that color-aware path.</t> in that color-aware path.</t>
<t>Incongruent Color-Intent mapping: the solution supports the signali </li>
ng of <li>
a BGP CAR route across different color domains. <t>Incongruent color-intent mapping: the solution supports the signa
(<xref target="SDIFFCOLORS"/>)</t> ling of
</list> a BGP CAR route across different color domains
</t> (<xref target="SDIFFCOLORS"/>).</t>
</li>
</ul>
<t>The key benefits of this model are: <t>The key benefits of this model are:</t>
<list style="symbols"> <ul spacing="normal">
<t>leverage of the BGP Color-EC <xref target="RFC9012"/> to color <li>
<t>Leverage of the BGP Color-EC <xref target="RFC9012"/> to color
service routes</t> service routes</t>
<t>the definition of the automated service steering: a C-colored servi </li>
ce route V/v <li>
<t>The definition of the automated service steering: a C-colored ser
vice route V/v
from E2 is steered onto a color-aware path (E2, C)</t> from E2 is steered onto a color-aware path (E2, C)</t>
<t>the definition of the data model of a BGP CAR path: (E, C) </li>
<list> <li>
<t>natural extension of BGP IP/LU data model (E)</t> <t>The definition of the data model of a BGP CAR path: (E, C)
<t>consistent with SR Policy data model</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>the definition of the recursive resolution of a BGP CAR route: a BG <t>Natural extension of BGP-IP/BGP-LU data model (E)</t>
P CAR </li>
(E2, C) route via N is resolved onto the color-aware path (N, C) which <li>
may itself <t>Consistent with SR Policy data model</t>
</li>
</ul>
</li>
<li>
<t>The definition of the recursive resolution of a BGP CAR route: a
BGP CAR
(E2, C) route via N is resolved onto the color-aware path (N, C), whic
h may itself
be provided by BGP CAR or via another color-aware routing solution (e. g., be provided by BGP CAR or via another color-aware routing solution (e. g.,
SR Policy, IGP Flex-Algo).</t> SR Policy, IGP Flexible Algorithm)</t>
<t>Native support for multiple transport encapsulations (e.g., MPLS, S </li>
R, <li>
<t>Explicit definitions for multiple transport encapsulations (e.g.,
MPLS, SR,
SRv6, IP)</t> SRv6, IP)</t>
</list> </li>
</t> </ul>
</section> </section>
<section title="Requirements Language"> <section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>
"OPTIONAL" in this document are to be interpreted as described in BCP The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
when, they appear in all capitals, as shown here.</t> ",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="CARSAFI">
<section anchor="CARSAFI" title="BGP CAR SAFI"> <name>BGP CAR SAFI</name>
<section anchor="SECDATAMODEL" title="Data Model"> <section anchor="SECDATAMODEL">
<t>The BGP CAR data model is: <name>Data Model</name>
<list style="symbols"> <t>The BGP CAR data model is:</t>
<t>NLRI Key: Falls into two categories, to accommodate the use-cases d <dl spacing="normal" newline="false">
escribed <dt>NLRI key:</dt><dd><t>Falls into two categories to accommodate the
in the introduction: use cases described
<list style="symbols"> in the introduction:</t>
<t>Type-1: Key is IP Prefix and Color (E, C). Color in NLRI key dist <dl spacing="normal" newline="false">
inguishes <dt>Type-1:</dt><dd>Key is IP Prefix and Color (E, C). Color in
a color-aware route for a common IP prefix, one per intent. Color al NLRI key distinguishes a color-aware route for a common IP
so prefix, one per intent. Color also indicates the intent
indicates the intent associated with the route. associated with the route.</dd>
</t> <dt>Type-2:</dt><dd>Key is IP Prefix (E). The unique IP prefix
<t>Type-2: Key is IP Prefix (E). The unique IP prefix assigned for a assigned for an intent (i.e, IP Prefix == intent)
n distinguishes the color-aware route. Color is not needed in
intent (i.e, IP Prefix == Intent or Color) distinguishes the color-a NLRI key as a distinguisher.</dd>
ware route. </dl>
Color is not needed in NLRI key as a distinguisher. </dd>
</t> <dt>NLRI non-key encapsulation data:</dt><dd>Data such as MPLS label
</list> stack, SR-MPLS label index, and SRv6 SID list associated with NLRI. Co
</t> ntained
<t>NLRI non-key encapsulation data: Data such as MPLS label stack, Lab in TLVs as described in <xref target="NLRITLVs"/>.</dd>
el Index <dt>BGP next hop:</dt>
and SRv6 SID list associated with NLRI. Contained in TLVs as described <dd>Next hop address associated with a particular NLRI key <xref target
in ="RFC4760"/>.</dd>
<xref target="NLRITLVs"/></t> <dt>AIGP metric <xref target="RFC7311"/>:</dt><dd>Accumulates a metric
<t>BGP Next Hop.</t> value specific to color/intent
<t>AIGP Metric <xref target="RFC7311"/>: accumulates color/intent spec for a CAR route across multiple BGP hops.</dd>
ific metric value <dt>Local Color Mapping Extended Community (LCM-EC):</dt><dd><t>Option
for a CAR route across multiple BGP hops.</t> al non-zero 32-bit color
<t>Local-Color-Mapping Extended-Community (LCM-EC): Optional non-zero value used to represent the intent associated with a CAR route:</t>
32-bit Color <ul spacing="normal">
value used to represent the intent associated with a CAR route: <li>
<t>when the CAR route propagates between different color domains
<list style="symbols"> .</t>
<t>when the CAR route propagates between different color domains.</t </li>
> <li>
<t>when the CAR route has a unique IP prefix for an intent.</t> <t>when the CAR route has a unique IP prefix for an intent.</t>
</list> </li>
</t> </ul>
<t>BGP Color Extended-Community (Color-EC) <xref target="RFC9012"/>: O </dd>
ptional non-zero 32-bit Color value <dt>BGP Color Extended Community (Color-EC) <xref
used to represent the intent associated with the BGP CAR next hop. It target="RFC9012"/>:</dt><dd>Optional non-zero 32-bit color value
is used to represent the intent associated with the BGP CAR next
used as per <xref target="RFC9256"/> for automated route resolution, w hop. It is used as per <xref target="RFC9256"/> for automated route
hen resolution, when intent/color used for the next hop is different
intent/color used for the next hop is different than the CAR route's i than the CAR route's intent/color. </dd>
ntent/color. </t> </dl>
</list> <t>
</t>
<t>
The sections below describe the data model in detail. The sections tha t The sections below describe the data model in detail. The sections tha t
describe the protocol processing for CAR SAFI generally apply consiste ntly describe the protocol processing for CAR SAFI generally apply consiste ntly
to both route types (for instance, any operation based on color). The to both route types (for instance, any operation based on color). The
examples use (E, C) for simplicity. examples use (E, C) for simplicity.
</t> </t>
</section> </section>
<section>
<name>Extensible Encoding</name>
<t>Extensible encoding is provided by:</t>
<section title="Extensible Encoding"> <dl spacing="normal" newline="false">
<t>Extensible encoding is provided by: <dt>NLRI Type field:</dt><dd><t>This provides extensibility to add new
<list style="symbols"> NLRI formats for new route types.</t>
<t>NLRI Type field: provides extensibility to add new NLRI formats for <t>NLRI (route) types other than Type-1 (E, C) and Type-2 (E) are
new route-types. outside the scope of this document.</t></dd>
<list style="empty"> <dt>Key Length field:</dt><dd>This specifies the key length. It allows
<t>NLRI (Route) Types other than Type-1 (E, C) and Type-2 (E) are outs new NLRI types to be handled
ide the scope of this document. </t>
</list>
</t>
<t>Key length field: specifies the key length. It allows new NLRI type
s to be handled
opaquely, which permits transitivity of new route types through BGP sp eakers such as opaquely, which permits transitivity of new route types through BGP sp eakers such as
Route Reflectors. Route Reflectors (RRs).</dd>
</t> <dt>TLV-based encoding of non-key part of NLRI:</dt><dd>This allows
the inclusion of additional non-key fields for a prefix to support
<t>TLV-based encoding of non-key part of NLRI: This allows different types of transport simultaneously with efficient BGP
the inclusion of additional non-key fields for a prefix to support di update packing (<xref target="ColorFamily"/>).</dd>
fferent types <dt>AIGP attribute:</dt><dd>This provides extensibility via TLVs, enab
of transport simultaneously with efficient BGP update packing (<xref ling definition of
target="ColorFamily"/>). additional metric semantics for a color as needed for an intent.</dd>
</t> </dl>
<t>AIGP Attribute provides extensibility via TLVs, enabling definition
of
additional metric semantics for a color as needed for an intent.</t>
</list>
</t>
</section> </section>
<section title="BGP CAR Route Origination"> <section>
<name>BGP CAR Route Origination</name>
<t>A BGP CAR route may be originated locally (e.g., loopback) or through <t>A BGP CAR route may be originated locally (e.g., loopback) or through
redistribution of an (E, C) color-aware path provided by another routing redistribution of an (E, C) color-aware path provided by another routing
solution: e.g., SR Policy, IGP Flex-Algo, RSVP-TE, BGP-LU <xref target=" RFC8277"/>. solution (e.g., SR Policy, IGP Flexible Algorithm, RSVP-TE, BGP-LU <xref target="RFC8277"/>).
</t> </t>
</section> </section>
<section anchor="ROUTEVALIDN">
<section anchor="ROUTEVALIDN" title="BGP CAR Route Validation"> <name>BGP CAR Route Validation</name>
<t>A BGP CAR path (E, C) via next hop N with encapsulation T is valid if color-aware <t>A BGP CAR path (E, C) via next hop N with encapsulation T is valid if color-aware
path (N, C) exists with encapsulation T available in data-plane.</t> path (N, C) exists with encapsulation T available in data plane.</t>
<t>A local policy may customize the validation process: <t>A local policy may customize the validation process:
<list style="symbols"> </t>
<t>The color constraint in the first check may be relaxed. If N is <ul spacing="normal">
<li>
<t>The color constraint in the first check may be relaxed. If N is
reachable via alternate color(s) or in the default routing table, the route reachable via alternate color(s) or in the default routing table, the route
may be considered valid.</t> may be considered valid.</t>
<t>The data-plane availability constraint of T may be relaxed to use a </li>
n <li>
<t>The data plane availability constraint of T may be relaxed to use
an
alternate encapsulation.</t> alternate encapsulation.</t>
<t>A performance-measurement verification may be added to ensure that </li>
the <li>
intent associated with C is met (e.g. delay &lt; bound).</t> <t>A performance-measurement verification may be added to ensure tha
</list> t the
</t> intent associated with C is met (e.g., delay &lt; bound).</t>
<t>A path that is not valid MUST NOT be considered for BGP best path sel </li>
ection. </ul>
<t>A path that is not valid <bcp14>MUST NOT</bcp14> be considered for BG
P best path selection.
</t> </t>
</section> </section>
<section anchor="ROUTERES">
<section anchor="ROUTERES" title="BGP CAR Route Resolution"> <name>BGP CAR Route Resolution</name>
<t>A BGP color-aware route (E2, C1) with next hop N is automatically <t>A BGP color-aware route (E2, C1) with next hop N is automatically
resolved over a color-aware route (N, C1) by default. The color-aware ro resolved over a color-aware route (N, C1) by default. The color-aware
ute route (N, C1) is provided by color-aware mechanisms such as IGP
(N, C1) is provided by color aware mechanisms such as IGP Flex-Algo <xre Flexible Algorithm <xref target="RFC9350"/>, SR Policy (<xref target="RF
f target="RFC9350"/>, C9256"
SR policy <xref target="RFC9256"/> Section 2.2, or recursively by BGP CA sectionFormat="of" section="2.2"/>), or recursively by BGP CAR.
R. When multiple producers of (N, C1) are available, the default
When multiple producers of (N, C1) are available, preference is: IGP Flexible Algorithm, SR Policy, BGP CAR.
the default preference is: IGP Flex-Algo, SR Policy, BGP CAR.
</t> </t>
<t>Local policy <bcp14>SHOULD</bcp14> provide additional control:</t>
<ul spacing="normal">
<li>
<t>A BGP color-aware route (E2, C1) with next hop N may be
resolved over a color-aware route (N, C2) (i.e., the local policy
maps the resolution of C1 over a different color C2). Examples where
such
a resolution can occur are:</t>
<ul spacing="normal">
<li>
<t>In a domain where resource R is known to not be present, the
inter-domain intent C1="low delay and avoid R" may be resolved o
ver
an intra-domain path of intent C2="low delay".</t>
</li>
<t>Local policy SHOULD provide additional control: <li>
<list style="symbols"> <t>In a domain where if no (N, C1) path is available, resolution
<t>A BGP color-aware route (E2, C1) with next hop N may be resolved ov may fallback
er a to a C2 path if the user has permitted it.</t>
color-aware route (N, C2): i.e., the local policy maps the resolution </li>
of C1 </ul>
over a different color C2. </li>
<list style="symbols"> <li>
<t>For example, in a domain where resource R is known to not be <t>
present, the inter-domain intent C1="low delay and avoid R"
may be resolved over an intra-domain path of intent C2="l
ow delay".</t>
<t>Another example is: if no (N, C1) path is available an
d the
user has allowed resolution to fallback to a C2 path.</t>
</list>
</t>
<t>
Route resolution may be driven by an egress node. In an SRv6 domain, a n egress node Route resolution may be driven by an egress node. In an SRv6 domain, a n egress node
selects and advertises an SRv6 SID from its locator for intent C1, wit h a BGP CAR selects and advertises an SRv6 SID from its locator for intent C1, wit h a BGP CAR
route. In such a case, the ingress node resolves the received SRv6 SID over an route. In such a case, the ingress node resolves the received SRv6 SID over an
IPv6 route for the intent-aware locator of the egress node for C1 or a IPv6 route for the intent-aware locator of the egress node for C1 or a
summary route that covers the locator. This summary route may be provi ded by SRv6 summary route that covers the locator. This summary route may be provi ded by SRv6
Flex Algo or BGP CAR IP Prefix route itself (e.g., <xref target="SECSR Flexible Algorithm or BGP CAR IP Prefix route itself (e.g., <xref targ
v6LOCencap"/>). et="SECSRv6LOCencap"/>).
</t> </t>
<t>Local policy may map the CAR route to traditional mechanisms that a </li>
re unaware of <li>
color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP LU/IP <t>Local policy may map the CAR route to mechanisms that are unaware
(e.g., of
color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP-LU/BG
P-IP (e.g.,
<xref target="COREDOMAINTE"/>) for brownfield scenarios.</t> <xref target="COREDOMAINTE"/>) for brownfield scenarios.</t>
</list> </li>
</t> </ul>
<t>Route resolution via a different color C2 can be automated by
<t>Route resolution via a different color C2 can be automated by attachi attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging automated
ng steering as described in Section <xref target="RFC9256"
BGP Color-EC C2 to CAR route (E2, C1), leveraging Automated sectionFormat="bare" section="8.4"/> of "Segment Routing Policy
steering as described in Section 8.4 of Segment Routing Policy Architect Architecture" <xref target="RFC9256"/> for BGP CAR routes. This
ure mechanism is illustrated in <xref target="APPENDIXNM"/>. This
<xref target="RFC9256"/> for BGP CAR routes. This mechanism is illustrat mechanism <bcp14>SHOULD</bcp14> be supported.</t>
ed
in <xref target="APPENDIXNM"/>. This mechanism SHOULD be supported.</t>
<t>For CAR route resolution, Color-EC color if present takes precedence
over
the route's intent color (LCM-EC if present (<xref target="SECLCMEC"/>),
or else NLRI color).</t>
<t>Local policy takes precedence over the color based automated resoluti <t>For CAR route resolution, if Color-EC color is present with the route
on specified above.</t> , it takes
precedence over the route's intent color. The route’s intent color is th
e LCM-EC color
if present (see <xref target="SECLCMEC"/>), or else it is the NLRI color
.</t>
<t>Local policy takes precedence over the color-based automated resoluti on specified above.</t>
<t>The color-aware route (N, C1) may be provided by BGP CAR itself in a <t>The color-aware route (N, C1) may be provided by BGP CAR itself in a
hierarchical transport routing design. In such cases, based on the hierarchical transport routing design. In such cases, based on the
procedures described above, recursive resolution may occur over the same procedures described above, recursive resolution may occur over the same
or different CAR route type. or different CAR route type.
<xref target="SECNRSSID"/> describes a scenario where CAR (E, C) route <xref target="SECNRSSID"/> describes a scenario where CAR (E, C) route
resolves over CAR IP Prefix route. resolves over CAR IP Prefix route.
</t> </t>
<t>CAR IP Prefix route is allowed to be without color for best-effort. I n this <t>CAR IP Prefix route is allowed to be without color for best-effort. I n this
case, resolution is based on BGP next hop N, or when present, a best-eff ort case, resolution is based on BGP next hop N, or when present, a best-eff ort
SRv6 SID advertised by node N.</t> SRv6 SID advertised by node N.</t>
<t>A BGP CAR route may recursively resolve over a BGP route that
<t>A BGP CAR route may recursively resolve over a BGP route that carries carries a TEA and follows <xref target="RFC9012" sectionFormat="of"
TEA and section="6"/> for validation. In this case, the procedures of <xref
follows Section 6 of [RFC9012] for validation. In this case, procedures target="RFC9012" sectionFormat="of" section="8"/> apply to BGP CAR
of section 8 of [RFC9012] routes, using color precedence as specified above for resolution.</t>
apply to BGP CAR routes, using color precedence as specified above for r <t>The procedures of <xref target="RFC9012" sectionFormat="comma"
esolution.</t> section="6"/>, also apply to BGP CAR routes (AFI/SAFI = 1/83 or
2/83). For instance, a BGP CAR BR may advertise a BGP CAR route to an
<t>The procedures of [RFC9012] Section 6 also apply to BGP CAR routes (A ingress BR or PE with a specific BGP next hop per color, with a TEA or
FI/SAFI = 1/83 or 2/83). For instance, Tunnel Encapsulation EC, as per <xref target="RFC9012" sectionFormat="of
a BGP CAR BR may advertise a BGP CAR route to an ingress BR or PE with a " section="6"/>.</t>
specific BGP next hop per color,
with a TEA or Tunnel Encapsulation EC, as per Section 6 of [RFC9012].</t
>
<t> BGP CAR resolution in one network domain is independent of resolutio n in <t> BGP CAR resolution in one network domain is independent of resolutio n in
another domain.</t> another domain.</t>
</section> </section>
<section anchor="AIGPMETRIC">
<section anchor="AIGPMETRIC" title="AIGP Metric Computation"> <name>AIGP Metric Computation</name>
<t>The Accumulated IGP (AIGP) Attribute <xref target="RFC7311"/> is upda <t>The Accumulated IGP (AIGP) Metric Attribute <xref target="RFC7311"/>
ted as is updated as
the BGP CAR route propagates across the network.</t> the BGP CAR route propagates across the network.</t>
<t>The value that is set (or appropriately incremented) in the AIGP TLV
<t>The value set (or appropriately incremented) in the AIGP TLV correspo corresponds
nds
to the metric associated with the underlying intent of the color. For ex ample, to the metric associated with the underlying intent of the color. For ex ample,
when the color is associated with a low-latency path, the metric value i s set when the color is associated with a low latency path, the metric value i s set
based on the delay metric.</t> based on the delay metric.</t>
<t>Information regarding the metric type used by the underlying intra-do main <t>Information regarding the metric type used by the underlying intra-do main
mechanism can also be used to set the metric value.</t> mechanism can also be used to set the metric value.</t>
<t>If BGP CAR routes traverse across a discontinuity in the transport pa th for <t>If BGP CAR routes traverse across a discontinuity in the transport pa th for
a given intent, a penalty is added in accumulated IGP metric (value set a given intent, a penalty is added in the AIGP metric (value set by user
by user policy). This could occur, for instance, when color C1 path is not avail
policy). For instance, when color C1 path is not available, and route r able, and route resolves via
esolves via color C2 path (see <xref target="SHDFAUSECASE"/> for an example).</t>
color C2 path (See <xref target="SHDFAUSECASE"/> for an example).</t>
<t>AIGP metric computation is recursive.</t> <t>AIGP metric computation is recursive.</t>
<t>To avoid continuous IGP metric changes causing end-to-end BGP CAR rou
<t>To avoid continuous IGP metric changes causing end to end BGP CAR rou te churn, an
te churn, an implementation should provide thresholds to trigger AIGP updates.</t>
implementation should provide thresholds to trigger AIGP update.</t>
<t>Additional AIGP extensions may be defined to signal state for specifi c <t>Additional AIGP extensions may be defined to signal state for specifi c
use-cases: Maximum SID-Depth along the BGP CAR route advertisement, Mini mum MTU along the BGP use cases such as Maximum SID Depth (MSD) along the BGP CAR route advert isement and minimum MTU along the BGP
CAR route advertisement. This is out of scope for this document.</t> CAR route advertisement. This is out of scope for this document.</t>
</section> </section>
<section anchor="SECPA">
<section anchor="SECPA" title="Native MultiPath Capability"> <name>Inherent Multipath Capability</name>
<t>The (E, C) route definition inherently provides availability of redun dant paths at <t>The (E, C) route definition inherently provides availability of redun dant paths at
every BGP hop identical to BGP-LU or BGP IP. For instance, BGP CAR route s originated every BGP hop identical to BGP-LU or BGP-IP. For instance, BGP CAR route s originated
by two or more egress ABRs in a domain are advertised as multiple paths to ingress by two or more egress ABRs in a domain are advertised as multiple paths to ingress
ABRs in the domain, where they become equal-cost or primary-backup paths . ABRs in the domain, where they become equal-cost or primary-backup paths .
A failure of an egress ABR is detected and handled by ingress ABRs local ly within A failure of an egress ABR is detected and handled by ingress ABRs local ly within
the domain for faster convergence, without any necessity to propagate th e event the domain for faster convergence, without any necessity to propagate th e event
to upstream nodes for traffic restoration.</t> to upstream nodes for traffic restoration.</t>
<t>BGP ADD-PATH <xref target="RFC7911"/> SHOULD be enabled for BGP CAR t <t>BGP ADD-PATH <xref target="RFC7911"/> <bcp14>SHOULD</bcp14> be enable
o signal multiple d for BGP CAR to signal multiple
next hops through a transport RR.</t> next hops through a TRR.</t>
</section> </section>
<section anchor="SDIFFCOLORS" title="BGP CAR Signaling through different C <section anchor="SDIFFCOLORS">
olor Domains"> <name>BGP CAR Signaling Through Different Color Domains</name>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
[Color Domain 1 A]-----[B Color Domain 2 E2] [Color Domain 1 A]-----[B Color Domain 2 E2]
[C1=low-delay ] [C2=low-delay ] [C1=low delay ] [C2=low delay ]
]]></artwork> ]]></artwork>
</figure>
<t>Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two b
order
routers of respectively domain 2 and domain 1. Let us assume that these
two
domains do not share the same color-to-intent mapping (i.e., they belong
to different
color domains). Low-delay in domain 2 is color C2, while it is C1 in
domain 1 (C1 &lt;> C2).</t>
<t>It is not expected to be a typical scenario to have an underlay trans <t>Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two B
port path (e.g., an MPLS LSP) extend across Rs of Domain 2 and Domain 1, respectively. Let us assume that these two
different color domains. However, the BGP CAR solution seamlessly suppor domains do not share the same color-to-intent mapping (i.e., they belong
ts this rare scenario while to different
maintaining the separation and independence of the administrative author color domains). Low delay in Domain 2 is color C2, while it is C1 in
ity in different color domains.</t> Domain 1 (C1 &lt;&gt; C2).</t>
<t>It is not expected to be a typical scenario to have an underlay
<t>The solution works as described below: transport path (e.g., an MPLS LSP) extend across different color
<list style="symbols"> domains. However, the BGP CAR solution seamlessly supports this rare
<t>Within domain 2, the BGP CAR route is (E2, C2) via E2.</t> scenario while maintaining the separation and independence of the
administrative authority in different color domains.</t>
<t>The solution works as described below:</t>
<ul spacing="normal">
<li>
<t>Within Domain 2, the BGP CAR route is (E2, C2) via E2.</t>
</li>
<li>
<t>B signals to A the BGP CAR route as (E2, C2) via B with <t>B signals to A the BGP CAR route as (E2, C2) via B with
Local-Color-Mapping-Extended-Community (LCM-EC) of color C2.</t> Local Color Mapping Extended Community (LCM-EC) of color C2.</t>
</li>
<li>
<t>A is aware of the intent-to-color mapping <t>A is aware of the intent-to-color mapping
within domain 2 ("low-delay" in domain 2 is C2), as per typical coor within Domain 2 ("low delay" in Domain 2 is C2), as per typical coor
dination that exists between operators of peering domains.</t> dination that exists between operators of peering domains.</t>
<t>A maps C2 in LCM-EC to C1 and signals within domain 1 the receive </li>
d <li>
BGP CAR route as (E2, C2) via A with LCM-EC(C1).</t> <t>A maps C2 in LCM-EC to C1 and signals within Domain 1 the receive
<t>The nodes within the receiving domain 1 use the local color encod d
ed BGP CAR route as (E2, C2) via A with LCM-EC (C1).</t>
</li>
<li>
<t>The nodes within the receiving Domain 1 use the local color encod
ed
in the LCM-EC for next-hop resolution and service steering.</t> in the LCM-EC for next-hop resolution and service steering.</t>
</list> </li>
</t> </ul>
<t> <t>
The following procedures apply at a color domain boundary for BGP CAR ro utes, The following procedures apply at a color domain boundary for BGP CAR ro utes,
performed by route policy at the sending and receiving peer: performed by route policy at the sending and receiving peer:
<list style="symbols"> </t>
<t>Use local policy to control which routes are advertised to or accepte <ul spacing="normal">
d from a <li>
<t>Use local policy to control which routes are advertised to or acc
epted from a
peer in a different color domain.</t> peer in a different color domain.</t>
<t>Attach LCM-EC if not present with the route. If LCM-EC is present, th </li>
en update <li>
<t>Attach LCM-EC if not present with the route. If LCM-EC is present
, then update
the value to re-map the color as needed. the value to re-map the color as needed.
<list> </t>
<t>This function may be done by the advertising BGP speaker or the recei <ul spacing="normal">
ving BGP <li>
<t>This function may be done by the advertising BGP speaker or t
he receiving BGP
speaker as determined by the operator peering agreement, and indicated b y local policy speaker as determined by the operator peering agreement, and indicated b y local policy
on the BGP peers.</t> on the BGP peers.</t>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
<t>These procedures apply to both CAR route types, in addition to all pr ocedures specified in earlier sections. LCM-EC is described in <xref target="SEC LCMEC"/>.</t> <t>These procedures apply to both CAR route types, in addition to all pr ocedures specified in earlier sections. LCM-EC is described in <xref target="SEC LCMEC"/>.</t>
<t>Salient properties: <t>Salient properties:
<list style="symbols">
<t>The NLRI never changes, even though the color-to-intent mapping cha
nges</t>
<t>E is globally unique, which makes E-C in that order unique</t>
<t>In typical expected cases, the color of the NLRI is used for
resolution and steering</t>
<t>In the rare case of color incongruence, the local color encoded in
LCM-EC takes precedence</t>
</list>
</t> </t>
<ul spacing="normal">
<t>Operational consideratons are in <xref target="MANAGEOPER"/>. Further <li>
illustrations are provided in <xref target="ColorMapping"/>.</t> <t>The NLRI never changes, even though the color-to-intent mapping c
hanges.</t>
</li>
<li>
<t>E is globally unique, which makes E-C in that order unique.</t>
</li>
<li>
<t>In typical expected cases, the color of the NLRI is used for
resolution and steering.</t>
</li>
<li>
<t>In the rare case of color incongruence, the local color encoded i
n
LCM-EC takes precedence.</t>
</li>
</ul>
<t>Operational considerations are in <xref target="MANAGEOPER"/>. Furthe
r illustrations are provided in <xref target="ColorMapping"/>.</t>
</section> </section>
<section anchor="ColorFamily">
<section anchor="ColorFamily" title="Format and Encoding"> <name>Format and Encoding</name>
<t>BGP CAR leverages BGP multi-protocol extensions <xref <t>BGP CAR leverages BGP multiprotocol extensions <xref target="RFC4760"
target="RFC4760"/> and uses the MP_REACH_NLRI and MP_UNREACH_NLRI /> and uses the MP_REACH_NLRI and MP_UNREACH_NLRI
attributes for route updates within SAFI value 83 along with attributes for route updates within SAFI value 83 along with
AFI 1 for IPv4 prefixes and AFI 2 for IPv6 prefixes.</t> AFI 1 for IPv4 prefixes and AFI 2 for IPv6 prefixes.</t>
<t>BGP speakers <bcp14>MUST</bcp14> use the BGP Capabilities Advertiseme
<t>BGP speakers MUST use BGP Capabilities Advertisement to ensure nt to ensure
support for processing of BGP CAR updates. This is done as support for processing of BGP CAR updates. This is done as
specified in <xref target="RFC4760"/>, by using capability code 1 specified in <xref target="RFC4760"/>, by using capability code 1
(multi-protocol BGP), with AFI 1 and 2 (as required) and SAFI 83.</t> (multiprotocol BGP), with AFI 1 and 2 (as required) and SAFI 83.</t>
<t> <t>
The Next Hop network address field in the MP_REACH_NLRI may either be The Next Hop network address field in the MP_REACH_NLRI may either be
an IPv4 address or an IPv6 address, independent of AFI. If the an IPv4 address or an IPv6 address, independent of AFI. If the
next hop length is 4, then the next hop is an IPv4 address. The next hop next hop length is 4, then the next hop is an IPv4 address. The next hop
length may be 16 or 32 for an IPv6 next hop address, set as per section length may be 16 or 32 for an IPv6 next hop address, set as per
3 <xref target="RFC2545" sectionFormat="of" section="3"/>. Processing of t
of [RFC2545]. Processing of the Next Hop field is governed by he Next Hop field is governed by
standard BGP procedures as described in section 3 of [RFC4760]. standard BGP procedures as described in <xref target="RFC4760" sectionFo
rmat="of" section="3"/>.
</t> </t>
<t>The sub-sections below specify the generic encoding of the BGP CAR NL
<t>The sub-sections below specify the generic encoding of the BGP CAR NL RI and non-key TLV fields,
RI and non-key TLV fields
followed by the encoding for specific NLRI types introduced in this followed by the encoding for specific NLRI types introduced in this
document.</t> document.</t>
<section anchor="NLRI">
<section anchor="NLRI" title="BGP CAR SAFI NLRI Format"> <name>BGP CAR SAFI NLRI Format</name>
<t>The generic format for the BGP CAR SAFI NLRI is shown <t>The generic format for the BGP CAR SAFI NLRI is shown
below:</t> below:</t>
<artwork align="left"><![CDATA[
<t><figure align="center"> 0 1 2 3
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type | // | NLRI Length | Key Length | NLRI Type | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
| Type-specific Key Fields // | Type-Specific Key Fields //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Non-Key TLV Fields (if applicable) // | Type-Specific Non-Key TLV Fields (if applicable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
where: ]]></artwork> <t>where:</t>
</figure> <dl spacing="normal" newline="false">
<list style="symbols"> <dt>NLRI Length:</dt><dd>1-octet field that indicates the length in
<t>NLRI Length: 1 octet field that indicates the length in octets octets
of the NLRI excluding the NLRI Length field itself.</t> of the NLRI excluding the NLRI Length field itself.</dd>
<dt>Key Length:</dt><dd>1-octet field that indicates the length in o
<t>Key Length: 1 octet field that indicates the length in octets ctets
of the NLRI type-specific key fields. Key length MUST be at least of the NLRI Type-Specific Key Fields. Key Length <bcp14>MUST</bcp14>
2 less than the NLRI length.</t> be at least
2 less than the NLRI Length.</dd>
<t>NLRI Type: 1 octet field that indicates the type of the BGP <dt>NLRI Type:</dt><dd>1-octet field that indicates the type of the
CAR NLRI.</t> BGP
CAR NLRI.</dd>
<t>Type-Specific Key Fields: The exact definition of these fields <dt>Type-Specific Key Fields:</dt><dd>The exact definition of these
depends on the NLRI type. They have length indicated by the Key Leng fields
th.</t> depends on the NLRI Type. They have length indicated by the Key Leng
th.</dd>
<t>Type-Specific Non-Key TLV Fields: The fields are optional and can <dt>Type-Specific Non-Key TLV Fields:</dt><dd>The fields are
carry optional and can carry one or more non-key TLVs (of different
one or more non-key TLVs (of different types) depending on the NLRI types) depending on the NLRI Type. The NLRI definition allows for
type. encoding of specific non-key information associated with the route
The NLRI definition allows for encoding of specific as part of the NLRI for efficient packing of BGP updates.</dd>
non-key information associated with the route as part of the NLRI fo </dl>
r <t>The non-key TLVs portion of the NLRI <bcp14>MUST</bcp14> be omitted
efficient packing of BGP updates. while carrying it
</t>
</list>
</t>
<t>The non-key TLVs portion of the NLRI MUST be omitted while carrying
it
within the MP_UNREACH_NLRI when withdrawing the route advertisement.</ t> within the MP_UNREACH_NLRI when withdrawing the route advertisement.</ t>
<t>Error handling for CAR SAFI NLRI and non-key TLVs is described in <t>Error handling for CAR SAFI NLRI and non-key TLVs is described in
<xref target="Fault"/>.</t> <xref target="Fault"/>.</t>
<t>The benefits of CAR NLRI design are:</t>
<t>Benefits of CAR NLRI design:</t> <ul spacing="normal">
<li>The indication of the key length enables BGP speakers to
<t>The indication of the key length enables BGP Speakers to determine determine the key portion of the NLRI and use it along with the
the key portion of the NLRI and use it along with the NLRI Type field NLRI Type field in an opaque manner for the handling of unknown or
in an opaque manner for handling of unknown or unsupported NLRI types. unsupported NLRI types. This can help deployed Route Reflectors
This can help deployed Route Reflectors (RR) to propagate NLRI types i (RR) to propagate NLRI types introduced in the future in a
ntroduced transparent manner.</li>
in the future in a transparent manner.</t> <li>The key length also helps error handling be more resilient and
minimally disruptive. The use of key length in error handling is
<t>The key length also helps error handling be more resilient and mini described in <xref target="Fault"/>.</li>
mally <li><t>The ability of a route (NLRI) to carry more than one non-key
disruptive. The use of key length in error handling is described in TLV (of different types) provides significant benefits such as
<xref target="Fault"/>.</t> signaling multiple encapsulations simultaneously for the same
route, each with a different value (label/SID, etc.). This enables
<t>The ability of a route (NLRI) to carry more than one non-key TLV (o simpler and efficient migrations with low overhead:</t>
f <ul spacing="normal">
different types) provides significant benefits such as signaling multi <li>
ple <t>avoids the need for duplicate routes to signal different encap
encapsulations simultaneously for the same route, each with a differen sulations</t>
t value </li>
(label/SID etc). This enables simpler, efficient migrations with low <li>
overhead : <t>avoids the need for separate control planes for distribution</
<list style="symbols"> t>
<t>avoids need for duplicate routes to signal different encapsulat </li>
ions</t> <li>
<t>avoids need for separate control planes for distribution</t> <t>preserves update packing (e.g., <xref target="UPDATEPACKING"/>
<t>preserves update packing (e.g. <xref target="UPDATEPACKING"/>)< )</t>
/t> </li>
</list> </ul>
</t> </li>
</ul>
</section> </section>
<section anchor="NLRITLVs">
<section anchor="NLRITLVs" title="Type-Specific Non-Key TLV Format"> <name>Type-Specific Non-Key TLV Format</name>
<t>The generic format for Non-Key TLVs is shown below:</t> <t>The generic format for Non-Key TLVs is shown below:</t>
<t><figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[ 0 1 0 1 2 3
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value (variable) // | Type | Length | Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
where:]]></artwork>
</figure>
<list style="symbols">
<t>Type: 1 octet that contains the type code and flags. It is enco
ded
as shown below:
<figure align="center"> <t>where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd><t>1 octet that contains the type code and
flags. It is encoded as shown below:</t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |R|T| Type code |
|R|T| Type code | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ ]]></artwork>
where:]]></artwork> <t>where:</t>
</figure> <dl spacing="normal" newline="false">
<list style="symbols"> <dt>R:</dt><dd>Bit is reserved and <bcp14>MUST</bcp14> be set
<t>R: Bit is reserved and MUST be set to 0 and ignored on receive to 0 and ignored on receive.</dd>
.</t> <dt>T:</dt><dd><t>Transitive bit, applicable to speakers that
<t>T: Transitive bit, applicable to speakers that change the change the BGP CAR next hop.</t>
BGP CAR next hop. <ul spacing="normal">
<list> <li><t>The T bit is set to indicate TLV is transitive. An
<t>T bit set to indicate TLV is transitive. An unrecognized unrecognized transitive TLV <bcp14>MUST</bcp14> be
transitive TLV MUST be propagated by a speaker that propagated by a speaker that changes the next hop.</t>
changes the next hop.</t> </li>
<t>T bit unset to indicate TLV is non-transitive. An <li><t>The T bit is unset to indicate TLV is non-transitive.
unrecognized non-transitive TLV MUST NOT be propagated by An
a speaker that changes next hop.</t> unrecognized non-transitive TLV <bcp14>MUST NOT</bcp14> be
</list> propagated by a speaker that changes the next hop.</t>
A speaker that does not change next hop SHOULD propagate all re </li>
ceived </ul>
TLVs.</t> <t>A speaker that does not change the next hop
<t>Type code: Remaining 6 bits contain the type of the TLV.</t> <bcp14>SHOULD</bcp14> propagate all received TLVs.</t>
</list> </dd>
</t> </dl>
</dd>
<t>Length: 1 octet field that contains the length of the value <dt>Type code:</dt><dd>Remaining 6 bits contain the type of the TLV.
portion of the non-key TLV in terms of octets.</t> </dd>
<dt>Length:</dt><dd>1-octet field that contains the length of the
<t>Value: variable length field as indicated by the length value portion of the Non-Key TLV in terms of octets.</dd>
field and to be interpreted as per the type field.</t> <dt>Value:</dt><dd>Variable-length field as indicated by the
</list> Length field and to be interpreted as per the Type field.</dd>
</t> </dl>
<t> The following sub-sections specify non-key TLVs. Each NLRI type MU <t> The following sub-sections specify non-key TLVs. Each NLRI Type <b
ST cp14>MUST</bcp14>
list the TLVs that can be associated with it.</t> list the TLVs that can be associated with it.</t>
<section anchor="CARMPLS">
<section anchor="CARMPLS" title="Label TLV"> <name>Label TLV</name>
<t>The Label TLV is used for advertisement of CAR routes <t>The Label TLV is used for the advertisement of CAR routes
along with their MPLS labels and has the following format as per along with their MPLS labels. It has the following format as per
<xref target="NLRITLVs"/>:</t> <xref target="NLRITLVs"/>:</t>
<artwork align="left"><![CDATA[
<t><figure align="center"> 0 1 2 3
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | |R|T| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Followed by one (or more) Labels encoded as below: It is followed by one (or more) labels encoded as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S| | Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
where: ]]></artwork>
</figure>
<list style="symbols">
<t>Type : Type code is 1. T bit MUST be unset.</t>
<t>Length: In octets. Length is variable, MUST be a multiple of 3.
</t>
<t>Label Information: multiples of 3 octet fields to convey the
MPLS label(s) associated with the advertised CAR route.
It is used for encoding a single label or a stack of labels for
usage as described in <xref target="RFC8277"/>. Number of labels
is derived from length field. 3-bit Rsrv and 1-bit S field SHOULD
be set
to zero on transmission and MUST be ignored on reception.
</t>
</list>
</t>
<t>where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>Type code is 1. The T bit <bcp14>MUST</bcp14> be
unset.</dd>
<dt>Length:</dt><dd>Length is in octets, variable, and
<bcp14>MUST</bcp14> be a multiple of 3.</dd>
<dt>Label Information:</dt><dd>Multiples of 3-octet fields to
convey the MPLS label(s) associated with the advertised CAR
route. It is used for encoding a single label or a stack of
labels for usage as described in <xref
target="RFC8277"/>. The number of labels is derived from the Lengt
h
field. The 3-bit Rsrv field and the 1-bit S field <bcp14>SHOULD</b
cp14> be set
to zero on transmission and <bcp14>MUST</bcp14> be ignored on
reception.</dd>
</dl>
<t>If a BGP transport CAR speaker sets itself as the next hop while <t>If a BGP transport CAR speaker sets itself as the next hop while
propagating a CAR route, it allocates a local label for propagating a CAR route, it allocates a local label for
the type specific key, and updates the value in this the type-specific key, and updates the value in this
TLV. It also MUST program a label cross-connect that would result in TLV. It also <bcp14>MUST</bcp14> program a label cross-connect that
would result in
the label swap operation for the incoming label that it advertises the label swap operation for the incoming label that it advertises
with the label received from its best-path router(s).</t> with the label received from its best-path router(s).</t>
</section> </section>
<section anchor="CARMPLSSID">
<section anchor="CARMPLSSID" title="Label Index TLV"> <name>Label-Index TLV</name>
<t>The Label Index TLV is used for advertisement of Segment Routing <t>The Label-Index TLV is used for the advertisement of Segment
MPLS (SR-MPLS) Segment Identifier (SID) <xref target="RFC8402"/> Routing over MPLS (SR-MPLS) Segment Identifier (SID) <xref
information associated with the labeled CAR routes and target="RFC8402"/> information associated with the labeled CAR
has the following format as per <xref target="NLRITLVs"/>:</t> routes. It has the following format as per <xref
target="NLRITLVs"/>:</t>
<t><figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[ 0 1 0 1 2 3
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | Reserved | Flags ~ |R|T| Type | Length | Reserved | Flags ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Label Index ~ ~ | Label Index ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
where: ]]></artwork>
</figure>
<list style="symbols">
<t>Type : Type code is 2. T bit MUST be set.</t>
<t>Length: In octets. Length is 7.</t>
<t>Reserved: 1 octet field that MUST be set to 0 and ignored on
receipt.</t>
<t>Flags: 2 octet field that's defined as per the Flags field of t
he
Label Index TLV of the BGP Prefix-SID Attribute (<xref
target="RFC8669"/> section 3.1).</t>
<t>Label Index: 4 octet field that's defined as per the Label Inde <t>where:</t>
x field <dl spacing="normal" newline="false">
of the Label Index TLV of the BGP Prefix-SID Attribute (<xref <dt>Type:</dt><dd>Type code is 2. The T bit <bcp14>MUST</bcp14> be
target="RFC8669"/> section 3.1).</t> set.</dd>
</list> <dt>Length:</dt><dd>Length is in octets and is 7.</dd>
</t> <dt>Reserved:</dt><dd>1-octet field that <bcp14>MUST</bcp14> be
set to 0 and ignored on receipt.</dd>
<t>This TLV provides the equivalent functionality as Label Index TLV <dt>Flags:</dt><dd>2-octet field that's defined as per the Flags
field of the Label-Index TLV of the BGP Prefix-SID attribute
(<xref target="RFC8669" sectionFormat="of" section="3.1"/>).</dd>
<dt>Label Index:</dt><dd>4-octet field that's defined as per the
Label Index field of the Label-Index TLV of the BGP Prefix-SID
attribute (<xref target="RFC8669" sectionFormat="of" section="3.1"
/>).</dd>
</dl>
<t>This TLV provides the equivalent functionality as the Label-Index
TLV
of <xref target="RFC8669"/> for Transport CAR route in SR-MPLS of <xref target="RFC8669"/> for Transport CAR route in SR-MPLS
deployments. deployments.
When a speaker allocates a local label for a received CAR route as p er When a speaker allocates a local label for a received CAR route as p er
<xref target="CARMPLS"/>, it SHOULD use the received Label Index as <xref target="CARMPLS"/>, it <bcp14>SHOULD</bcp14> use the received
a hint Label Index as a hint
using procedures as specified in [RFC8669] Section 4. using procedures as specified in <xref target="RFC8669" sectionForma
t="comma" section="4"/>.
</t> </t>
<t>The Label-Index TLV provides much better packing efficiency by ca
<t>The Label Index TLV provides much better packing efficiency by ca rrying the
rrying Label Index in NLRI instead of in the BGP Prefix-SID attribute
Label Index in NLRI instead of in the BGP Prefix-SID Attribute
(<xref target="UPDATEPACKING"/>). </t> (<xref target="UPDATEPACKING"/>). </t>
<t>The Label-Index TLV <bcp14>MUST NOT</bcp14> be carried in the Pre
<t>Label Index TLV MUST NOT be carried in the Prefix-SID attribute f fix-SID attribute for
or BGP CAR routes. If a speaker receives a CAR route with the Label-Ind
BGP CAR routes. If a speaker receives a CAR route with Label Index T ex TLV in
LV in the Prefix-SID attribute, it <bcp14>SHOULD</bcp14> ignore it. The BG
the Prefix-SID attribute, it SHOULD ignore it. The BGP Prefix-SID At P Prefix-SID attribute
tribute <bcp14>SHOULD NOT</bcp14> be sent with the labeled CAR routes if the
SHOULD NOT be sent with the labeled CAR routes if the attribute is attribute is
being used only to convey the Label Index TLV.</t> being used only to convey the Label-Index TLV.</t>
</section> </section>
<section anchor="CRSRv6">
<section anchor="CRSRv6" title="SRv6 SID TLV"> <name>SRv6 SID TLV</name>
<t>BGP Transport CAR can be also used to setup end-to-end color-awar <t>BGP Transport CAR can be also used to set up end-to-end
e color-aware connectivity using Segment Routing over IPv6 (SRv6)
connectivity using Segment Routing over IPv6 (SRv6) <xref <xref target="RFC8402"/>. <xref target="RFC8986"/> specifies the
target="RFC8402"/>. <xref SRv6 Endpoint behaviors (e.g., End Penultimate Segment Pop (PSP)), w
target="RFC8986"/> specifies the hich can be leveraged for
SRv6 Endpoint behaviors (e.g. End PSP) which can be leveraged for BGP CAR with SRv6. The SRv6 SID TLV is used for the advertisement of
BGP CAR with SRv6. The SRv6 SID TLV is used for advertisement of CAR routes along with their SRv6 SIDs. It has the following format
CAR routes along with their SRv6 SIDs and has the as per <xref target="NLRITLVs"/>:</t>
following format as per <xref target="NLRITLVs"/>:</t> <artwork align="left"><![CDATA[
0 1 2 3
<t><figure align="center">
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T| Type | Length | SRv6 SID Info (variable) // |R|T| Type | Length | SRv6 SID Info (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
where: ]]></artwork> <t>where:</t>
</figure> <dl spacing="normal" newline="false">
<list style="symbols"> <dt>Type:</dt><dd>Type code is 3. The T bit <bcp14>MUST</bcp14> be
<t>Type : Type code is 3. T bit MUST be unset.</t> unset.</dd>
<dt>Length:</dt><dd>Length is in octets, variable, and
<t>Length: In octets. Length is variable, MUST be either less than <bcp14>MUST</bcp14> be either less than or equal to 16, or be a
or equal to 16, multiple of 16.</dd>
or be a multiple of 16.</t> <dt>SRv6 SID Information:</dt><dd><t>Field of size as indicated by
the
<t>SRv6 SID Information: field of size as indicated by the
length that either carries the SRv6 SID(s) for the advertised length that either carries the SRv6 SID(s) for the advertised
CAR route as one of the following: CAR route as one of the following:</t>
<list style="symbols"> <ul spacing="normal">
<t>A single 128-bit SRv6 SID or an ordered list of 128-bit SRv6 <li><t>A single 128-bit SRv6 SID or an ordered list of
SIDs.</t> 128-bit SRv6 SIDs.</t></li>
<li><t>A transposed portion (refer to <xref
<t>A transposed portion (refer <xref target="RFC9252"/>) of the SRv6 SID that <bcp14>MUST</bcp14>
target="RFC9252"/>) of the SRv6 SID that be of size in multiples of one octet and less than 16.</t>
MUST be of size in multiples of one octet and less than </li>
16.</t> </ul>
</list> </dd>
</t> </dl>
</list>
</t>
<t> <t>
BGP CAR SRv6 SID TLV definitions provide the following benefits: BGP CAR SRv6 SID TLV definitions provide the following benefits:
<list style="symbols">
<t>Native encoding of SIDs avoids robustness issue caused by overl
oading
of MPLS label fields.</t>
<t>Simple encoding to signal Unique SIDs (non-transposition),
maintaining BGP update prefix packing.</t>
<t>Highly efficient transposition scheme (12-14 bytes saved per NL
RI),
also maintaining BGP update prefix packing.</t>
</list>
</t> </t>
<ul spacing="normal">
<t>The BGP CAR route update for SRv6 encapsulation MUST <li>The explicit encoding of SIDs avoids robustness issues caused
by the
overloading of MPLS label fields.</li>
<li>The encoding to include the entire 128 bits for unique SIDs (n
on-transposition)
maintains BGP update prefix packing.</li>
<li>The highly efficient transposition scheme (12-14 bytes saved p
er
NLRI) also maintains BGP update prefix packing.</li>
</ul>
<t>The BGP CAR route update for SRv6 encapsulation <bcp14>MUST</bcp1
4>
include the BGP Prefix-SID attribute along with the SRv6 L3 Service TLV include the BGP Prefix-SID attribute along with the SRv6 L3 Service TLV
carrying the SRv6 SID information as specified in <xref target="RFC9 252"/>. carrying the SRv6 SID information as specified in <xref target="RFC9 252"/>.
When using the transposition scheme of encoding for packing efficien cy When using the transposition scheme of encoding for packing efficien cy
of BGP updates <xref target="RFC9252"/>, transposed part of SID is c of BGP updates <xref target="RFC9252"/>, the transposed part of the
arried SID is carried
in SRv6 SID TLV and not limited by MPLS label field size. in the SRv6 SID TLV and is not limited by MPLS label field size.
</t> </t>
<t>If a BGP transport CAR speaker sets itself as the next hop while <t>If a BGP transport CAR speaker sets itself as the next hop while
propagating a CAR route and allocates an SRv6 SID that maps to the r eceived propagating a CAR route and allocates an SRv6 SID that maps to the r eceived
SRv6 SID, it updates the value in this TLV.</t> SRv6 SID, it updates the value in this TLV.</t>
<t>Received MPLS information can map to SRv6 and vice versa.</t>
<t>Received MPLS information can map to SRv6 and vice versa. <aside>
<t>
<xref target="I-D.ietf-spring-srv6-mpls-interworking"/> describes M PLS <xref target="I-D.ietf-spring-srv6-mpls-interworking"/> describes M PLS
and SRv6 interworking procedures and extension to BGP CAR routes.</t and SRv6 interworking procedures and their applicability to BGP CAR
> routes.</t>
</aside>
</section> </section>
</section> </section>
<section anchor="NLRITYPE1">
<section anchor="NLRITYPE1" title="Color-Aware Route (E, C) NLRI Type"> <name>Color-Aware Route (E, C) NLRI Type</name>
<t>The Color-Aware Route NLRI Type is used for advertisement of <t>The Color-Aware Route NLRI Type is used for the advertisement of
BGP CAR color-aware routes (E, C) and has the following format:</t> BGP CAR color-aware routes (E, C). It has the following format:</t>
<artwork align="left"><![CDATA[
<t><figure align="center"> 0 1 2 3
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (4 octets) | | Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>It is followed by optional Non-Key TLVs encoded as per <xref target
]]></artwork> ="NLRITLVs"/>.</t>
</figure> <t>Where:</t>
<dl spacing="normal" newline="false">
<t>Followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t <dt>NLRI Length:</dt><dd>Variable.</dd>
> <dt>Key Length:</dt><dd>Variable. It indicates the total length comp
<t>where:</t> rised of
<list style="symbols">
<t>NLRI Length: variable</t>
<t>Key Length: variable. It indicates the total length comprised of
the Prefix Length field, IP Prefix field, and the Color field, as the Prefix Length field, IP Prefix field, and the Color field, as
described below. For IPv4 (AFI=1), the minimum length is 5 and described below. For IPv4 (AFI=1), the minimum length is 5 and the
maximum length is 9. For IPv6 (AFI=2), the minimum length is 5 maximum length is 9. For IPv6 (AFI=2), the minimum length is 5
and maximum length is 21.</t> and the maximum length is 21.</dd>
<dt>NLRI Type:</dt><dd>1.</dd>
<t>NLRI Type: 1</t> <dt>Type-Specific Key Fields:</dt><dd><t>These are as seen below:</t
<t>Type-Specific Key Fields: as below >
<list style="symbols"> <dl spacing="normal" newline="false">
<dt>Prefix Length:</dt><dd>1-octet field that carries the
<t>Prefix Length: 1 octet field that carries the length of length of prefix in bits. Length <bcp14>MUST</bcp14> be less
prefix in bits. Length MUST be less than or equal to 32 for than or equal to 32 for IPv4 (AFI=1) and less than or equal to
IPv4 (AFI=1) and less than or equal to 128 for IPv6 128 for IPv6 (AFI=2).</dd>
(AFI=2).</t> <dt>IP Prefix:</dt><dd><t>IPv4 or IPv6 prefix (based on the
AFI). A variable-size field that contains the most significant
<t>IP Prefix: IPv4 or IPv6 prefix (based on the AFI). A octets of the prefix. The format of this field for an IPv4
variable size field that contains the most significant octets prefix is:</t>
of the prefix. The format of this field for an IPv4 prefix is: <ul spacing="normal">
<list style="empty"> <li>0 octet for prefix length 0</li>
<t>0 octet for prefix length 0,</t> <li>1 octet for prefix length 1 to 8</li>
<t>1 octet for prefix length 1 to 8,</t> <li>2 octets for prefix length 9 to 16</li>
<t>2 octets for prefix length 9 to 16,</t> <li>3 octets for prefix length 17 up to 24</li>
<t>3 octets for prefix length 17 up to 24,</t> <li>4 octets for prefix length 25 up to 32</li>
<t>4 octets for prefix length 25 up to 32.</t> </ul>
</list> <t>The format for this field for an IPv6 address follows the
</t> same pattern for prefix lengths of 1-128 (octets 1-16).</t>
<t>The format for this field for an IPv6 address follows the same <t>The last octet has enough trailing bits to make the end of
pattern the field fall on an octet boundary. Note that the value of
for prefix lengths of 1-128 (octets 1-16).</t> the trailing bits <bcp14>MUST</bcp14> be set to zero. The size
<t>The last octet has enough trailing bits to make the end of the field <bcp14>MUST</bcp14> be less than or equal to 4
of the field fall on an octet boundary. Note that the value of for IPv4 (AFI=1) and less than or equal to 16 for IPv6
the trailing bits MUST be set to zero. The size of the field MUS (AFI=2).</t>
T be less than </dd>
or equal to 4 for IPv4 (AFI=1) and less than or equal to 16 for <dt>Color:</dt><dd>4 octets that contain non-zero color value
IPv6 (AFI=2).</t> associated with the prefix.</dd>
</dl>
<t>Color: 4 octets that contains non-zero color value associated w </dd>
ith the prefix. </t> <dt>Type-Specific Non-Key TLVs:</dt><dd>The Label TLV, Label-Index T
</list> LV,
</t> and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
with the color-aware route NLRI type.</dd>
<t>Type-Specific Non-Key TLVs: Label TLV, Label Index TLV and </dl>
SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated with the
Color-aware route NLRI type.</t>
</list>
</t>
<t>The prefix is unique across the administrative domains where BGP <t>The prefix is unique across the administrative domains where BGP
transport CAR is deployed. It is possible that the same prefix is transport CAR is deployed. It is possible that the same prefix is
originated by multiple BGP CAR speakers in the case of originated by multiple BGP CAR speakers in the case of
anycast addressing or multi-homing.</t> anycast addressing or multihoming.</t>
<t>The Color is introduced to enable multiple route advertisements <t>The Color is introduced to enable multiple route advertisements
for the same prefix. The color is associated with an intent for the same prefix. The color is associated with an intent
(e.g. low-latency) in originator color-domain.</t> (e.g., low latency) in originator color domain.</t>
</section> </section>
<section anchor="NLRITYPE2">
<section anchor="NLRITYPE2" title="IP Prefix (E) NLRI Type"> <name>IP Prefix (E) NLRI Type</name>
<t>The IP Prefix Route NLRI Type is used for advertisement of <t>The IP Prefix Route NLRI Type is used for the advertisement of
BGP CAR IP Prefix routes (E) and has the following format:</t> BGP CAR IP Prefix routes (E). It has the following format:</t>
<t><figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[ 0 1 0 1 2 3
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>It is followed by optional Non-Key TLVs encoded as per <xref target
="NLRITLVs"/>.</t>
<t>Followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t <t>Where:</t>
> <dl spacing="normal" newline="false">
<t>where:</t> <dt>NLRI Length:</dt><dd>Variable.</dd>
<list style="symbols"> <dt>Key Length:</dt><dd>Variable. It indicates the total length comp
<t>NLRI Length: variable</t> rised of
<t>Key Length: variable. It indicates the total length comprised of
the Prefix Length field and IP Prefix field as described below. the Prefix Length field and IP Prefix field as described below.
For IPv4 (AFI=1), the minimum length is 1 and For IPv4 (AFI=1), the minimum length is 1 and the
maximum length is 5. For IPv6 (AFI=2), the minimum length is 1 maximum length is 5. For IPv6 (AFI=2), the minimum length is 1
and maximum length is 17.</t> and the maximum length is 17.</dd>
<dt>NLRI Type:</dt><dd>2.</dd>
<t>NLRI Type: 2.</t> <dt>Type-Specific Key Fields:</dt><dd><t>These are as seen below:</t
<t>Type-Specific Key Fields: as below >
<list style="symbols"> <dl spacing="normal" newline="false">
<dt>Prefix Length:</dt><dd>1-octet field that carries the
<t>Prefix Length: 1 octet field that carries the length of length of prefix in bits. Length <bcp14>MUST</bcp14> be less
prefix in bits. Length MUST be less than or equal to 32 for than or equal to 32 for IPv4 (AFI=1) and less than or equal to
IPv4 (AFI=1) and less than or equal to 128 for IPv6 128 for IPv6 (AFI=2).</dd>
(AFI=2).</t> <dt>IP Prefix:</dt><dd><t>IPv4 or IPv6 prefix (based on the
AFI). A variable-size field that contains the most significant
<t>IP Prefix: IPv4 or IPv6 prefix (based on the AFI). A octets of the prefix. The format of this field for an IPv4
variable size field that contains the most significant octets prefix is:</t>
of the prefix. The format of this field for an IPv4 prefix is: <ul spacing="normal">
<list style="empty"> <li>0 octet for prefix length 0</li>
<t>0 octet for prefix length 0,</t> <li>1 octet for prefix length 1 to 8</li>
<t>1 octet for prefix length 1 to 8,</t> <li>2 octets for prefix length 9 to 16</li>
<t>2 octets for prefix length 9 to 16,</t> <li>3 octets for prefix length 17 up to 24</li>
<t>3 octets for prefix length 17 up to 24,</t> <li>4 octets for prefix length 25 up to 32</li>
<t>4 octets for prefix length 25 up to 32.</t> </ul>
</list> <t>The format for this field for an IPv6 address follows the
</t> same pattern for prefix lengths of 1-128 (octets 1-16).</t>
<t>The format for this field for an IPv6 address follows the same <t>The last octet has enough trailing bits to make the end of
pattern the field fall on an octet boundary. Note that the value of the
for prefix lengths of 1-128 (octets 1-16).</t> trailing bits <bcp14>MUST</bcp14> be set to zero. The size of
<t>The last octet has enough trailing bits to make the end the field <bcp14>MUST</bcp14> be less than or equal to 4 for
of the field fall on an octet boundary. Note that the IPv4 (AFI=1) and less than or equal to 16 for IPv6 (AFI=2).</t>
value of </dd>
the trailing bits MUST be set to zero. The size of the </dl>
field MUST be </dd>
less than or equal to 4 for IPv4 (AFI=1) and less than <dt>Type-Specific Non-Key TLVs:</dt><dd>The Label TLV, Label-Index
or equal to 16 TLV, and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be
for IPv6 (AFI=2).</t> associated with the IP Prefix NLRI Type.</dd>
</list> </dl>
</t>
<t>Type-Specific Non-Key TLVs: Label TLV, Label Index TLV and SRv6 S
ID TLV (<xref target="NLRITLVs"/>)
may be associated with the IP Prefix NLRI type.</t>
</list>
</t>
</section> </section>
<section anchor="SECLCMEC">
<section anchor="SECLCMEC" title="Local-Color-Mapping (LCM) Extended-Com <name>Local Color Mapping (LCM) Extended Community</name>
munity"> <t>This document defines a new BGP Extended Community called "LCM".
<t>This document defines a new BGP Extended-Community called "LCM". The LCM is a Transitive Opaque Extended Community with the following e
The LCM is a Transitive Opaque Extended-Community with the following e ncoding:</t>
ncoding:</t> <artwork align="left"><![CDATA[
0 1 2 3
<t><figure align="center">
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x3 | Sub-Type=0x1b | Reserved | | Type=0x3 | Sub-Type=0x1b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color | | Color |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
where: ]]></artwork> <t>where:</t>
</figure> <dl spacing="normal" newline="false">
<list style="symbols"> <dt>Type:</dt><dd>0x3.</dd>
<dt>Sub-Type:</dt><dd>0x1b.</dd>
<t>Type: 0x3.</t> <dt>Reserved:</dt><dd>2-octet reserved field that
<bcp14>MUST</bcp14> be set to zero on transmission and ignored on
<t>Sub-Type: 0x1b.</t> reception.</dd>
<dt>Color:</dt><dd>4-octet field that carries the non-zero 32-bit co
<t>Reserved: 2 octet of reserved field that MUST be set to zero on lor value.</dd>
transmission and ignored on reception.</t> </dl>
<t>
<t>Color: 4-octet field that carries the non-zero 32-bit color value
.</t>
</list>
When a CAR route crosses the originator's color domain boundary, LCM-E C When a CAR route crosses the originator's color domain boundary, LCM-E C
is added or updated, as specified in <xref target="SDIFFCOLORS"/>. LCM -EC is added or updated, as specified in <xref target="SDIFFCOLORS"/>. LCM -EC
conveys the local color mapping for the intent conveys the local color mapping for the intent
(e.g. low latency) in other (transit or destination) color domains. (e.g., low latency) in other (transit or destination) color domains.
</t> </t>
<t>For CAR IP Prefix routes, LCM-EC may also be added in the originato r color domain to <t>For CAR IP Prefix routes, LCM-EC may also be added in the originato r color domain to
indicate the color associated with the IP prefix.</t> indicate the color associated with the IP prefix.</t>
<t>An implementation <bcp14>SHOULD NOT</bcp14> send more than one inst
<t>An implementation SHOULD NOT send more than one instance of the LCM ance of the LCM-EC.
-EC. However, if more than one instance is received, an implementation <
However, if more than one instance is received, an implementation M bcp14>MUST</bcp14>
UST
disregard all instances other than the one with the numerically hig hest disregard all instances other than the one with the numerically hig hest
value.</t> value.</t>
<t>If a node receives multiple BGP CAR routes (paths) for a given dest
<t>If a node receives multiple BGP CAR routes (paths) for a given d ination endpoint and color that have
estination endpoint and color that have
different LCM values, it is a misconfiguration in color re-mappin g for one of the routes.</t> different LCM values, it is a misconfiguration in color re-mappin g for one of the routes.</t>
<t>In this case, the LCM from the selected BGP best path SHOULD be chosen to be installed into the routing <t>In this case, the LCM from the selected BGP best path <bcp14>SHOULD </bcp14> be chosen to be installed into the routing
table.</t> table.</t>
<t>A warning message SHOULD also be logged for further operator in <t>A warning message <bcp14>SHOULD</bcp14> also be logged for further
tervention.</t> operator intervention.</t>
<t>If present, LCM-EC contains the intent of a BGP CAR route.
<t>If present, LCM-EC contains the intent of a BGP CAR route.
LCM-EC Color is used instead of the Color in CAR route NLRI for pro cedures LCM-EC Color is used instead of the Color in CAR route NLRI for pro cedures
described in earlier sections such as route validation (<xref targe t="ROUTEVALIDN"/>), described in earlier sections such as route validation (<xref targe t="ROUTEVALIDN"/>),
route resolution (<xref target="ROUTERES"/>), route resolution (<xref target="ROUTERES"/>),
AIGP calculation (<xref target="AIGPMETRIC"/>) and steering (<xref target="STEERING"/>).</t> AIGP calculation (<xref target="AIGPMETRIC"/>) and steering (<xref target="STEERING"/>).</t>
<t>The LCM-EC <bcp14>MAY</bcp14> be used for filtering of BGP CAR rout
<t>The LCM-EC MAY be used for filtering of BGP CAR routes and/or for es and/or for
applying routing policies on the intent, when present.</t> applying routing policies on the intent, when present.</t>
</section> </section>
</section> </section>
<section anchor="LCMBGPECUSAGE">
<section anchor="LCMBGPECUSAGE" <name>LCM-EC and BGP Color-EC Usage</name>
title="LCM-EC and BGP Color-EC usage">
<t>There are 2 distinct requirements to be supported as stated in <t>There are 2 distinct requirements to be supported as stated in
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>: <xref target="I-D.hr-spring-intentaware-routing-using-color"/>:
<list style="numbers">
<t>Domains with different intent granularity (section 6.3.1.9)</t>
<t>Network domains under different administration, i.e., color domains
(section 6.3.1.10)</t>
</list>
</t> </t>
<ol spacing="normal" type="1"><li>
<t>Domains with different intent granularity (<xref
target="I-D.hr-spring-intentaware-routing-using-color"
sectionFormat="of" section="6.3.1.9"/>)</t>
</li>
<li>
<t>Network domains under different administration (i.e., color
domains; see <xref
target="I-D.hr-spring-intentaware-routing-using-color"
sectionFormat="of" section="6.3.1.10"/>)</t>
</li>
</ol>
<t>Requirement 1 is the case where within the same administrative or <t>Requirement 1 is the case where within the same administrative or
color domain, BGP CAR routes for N end-to-end intents may need to traver se color domain, BGP CAR routes for N end-to-end intents may need to traver se
across an intermediate transit domain where only M intents are available , N >= M. across an intermediate transit domain where only M intents are available , N &gt;= M.
For example, consider a multi-domain network is designed as Access-Core- Access. For example, consider a multi-domain network is designed as Access-Core- Access.
The core may have the most granular N intents, whereas the access only h as fewer M The core may have the most granular N intents, whereas the access only h as fewer M
intents. So, the BGP next-hop resolution for a CAR route in the access d omain must be intents. Therefore, the BGP next-hop resolution for a CAR route in the a ccess domain must be
via a color-aware path for one of these M intents. As the procedures in <xref target="ROUTERES"/> describe, via a color-aware path for one of these M intents. As the procedures in <xref target="ROUTERES"/> describe,
and the example in <xref target="APPENDIXNM"/> illustrates, and the example in <xref target="APPENDIXNM"/> illustrates,
BGP Color-EC is used to automate the CAR route resolution in this case.< /t> BGP Color-EC is used to automate the CAR route resolution in this case.< /t>
<t>For requirement 2, where CAR routes traverse across different color d omains, <t>For requirement 2, where CAR routes traverse across different color d omains,
LCM-EC is used to carry the local color mapping for the NLRI color in ot her color LCM-EC is used to carry the local color mapping for the NLRI color in ot her color
domains. The related procedures are described in <xref target="SDIFFCOLO RS"/>, and domains. The related procedures are described in <xref target="SDIFFCOLO RS"/>, and
an example is given in <xref target="APPENDIXMCD"/>.</t> an example is given in <xref target="APPENDIXMCD"/>.</t>
<t>Both LCM-EC and BGP Color-EC may be present at the same time with a B GP CAR route. <t>Both LCM-EC and BGP Color-EC may be present at the same time with a B GP CAR route.
For example, a BGP CAR route (E, C1) from color domain D1, with LCM-EC C 2 in color For example, a BGP CAR route (E, C1) from color domain D1, with LCM-EC C 2 in color
domain D2, may also carry Color-EC C3 and next hop N in a transit networ k domain domain D2, may also carry Color-EC C3 and next hop N in a transit networ k domain
within D2 where C2 is being resolved via an available intra-domain inten within D2 where C2 is being resolved via an available intra-domain inten
t C3 (See t C3 (see
the detailed example in the combination of <xref target="APPENDIXNM"/> a the detailed example in the combination of Appendices <xref target="APPE
nd NDIXNM" format="counter"/> and
<xref target="APPENDIXMCD"/>). <xref target="APPENDIXMCD" format="counter"/>).
</t> </t>
<t>In this case, as described in <xref target="ROUTERES"/>, the default
<t>In this case, as described in <xref target="ROUTERES"/>, default orde order of
r of processing for resolution in the presence of LCM-EC is local policy, the
processing for resolution in presence of LCM-EC is local policy, then BG n BGP Color-EC
P Color-EC
color, and finally LCM-EC color.</t> color, and finally LCM-EC color.</t>
</section> </section>
<section anchor="Fault">
<name>Error Handling</name>
<section anchor="Fault" title="Error Handling"> <t>The error handling actions as described in <xref target="RFC7606"/> a
<t>The error handling actions as described in <xref re applicable for the handling of BGP update messages
target="RFC7606"/> are applicable for handling of BGP update messages
for BGP CAR SAFI. In general, as indicated in <xref target="RFC7606"/>, for BGP CAR SAFI. In general, as indicated in <xref target="RFC7606"/>,
the goal is to minimize the disruption of a session reset or the goal is to minimize the disruption of a session reset or
'AFI/SAFI disable' to the extent possible.</t> 'AFI/SAFI disable' to the extent possible.</t>
<t>When the error determined allows for the router to skip the malformed <t>When the error determined allows for the router to skip the malformed
NLRI(s) and continue processing of the rest of the update message, then NLRI(s) and continue processing of the rest of the update message, then
it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. it <bcp14>MUST</bcp14> handle such malformed NLRIs as 'treat-as-withdraw '.
In other cases, where the error in the NLRI encoding results in the inab ility to In other cases, where the error in the NLRI encoding results in the inab ility to
process the BGP update message, then the router SHOULD handle such malfo rmed process the BGP update message, then the router <bcp14>SHOULD</bcp14> ha ndle such malformed
NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides BGP CAR are bein g NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides BGP CAR are bein g
advertised over the same session. Alternately, the router MUST perform advertised over the same session. Alternately, the router <bcp14>MUST</b cp14> perform
'session reset' when the session is only being used for BGP CAR SAFI.</t > 'session reset' when the session is only being used for BGP CAR SAFI.</t >
<t>The CAR NLRI definition encodes NLRI length and key length explicitly . <t>The CAR NLRI definition encodes NLRI length and key length explicitly .
The NLRI length MUST be relied upon to enable the beginning of the next The NLRI length <bcp14>MUST</bcp14> be relied upon to enable the beginni
NLRI field to be located. Key length MUST be relied upon to extract the ng of the next
NLRI field to be located. Key length <bcp14>MUST</bcp14> be relied upon
to extract the
key and perform 'treat-as-withdraw' for malformed information.</t> key and perform 'treat-as-withdraw' for malformed information.</t>
<t>A sender <bcp14>MUST</bcp14> ensure that the NLRI and key lengths are
<t>A sender MUST ensure that the NLRI and key lengths are number of actu the number of actual
al bytes encoded in the NLRI and key fields, respectively, regardless of
bytes encoded in NLRI and key fields respectively, regardless of
content being encoded.</t> content being encoded.</t>
<t>Given the NLRI length and Key length <bcp14>MUST</bcp14> be valid, fa
ilures in the following
checks result in 'AFI/SAFI disable' or 'session reset':</t>
<ul spacing="normal">
<li>
<t>The minimum NLRI Length <bcp14>MUST</bcp14> be at least 2, as Key
Length and NLRI Type are required fields.</t>
</li>
<li>
<t>The Key Length <bcp14>MUST</bcp14> be at least 2 less than NLRI L
ength.</t>
</li>
</ul>
<t>Given NLRI length and Key length MUST be valid, failures in following <t>NLRI type-specific error handling:
checks result in 'AFI/SAFI disable' or 'session reset': </t>
<list style="symbols"> <ul spacing="normal">
<t>Minimum NLRI length (must be atleast 2, as key length and NLRI type <li>
are required fields).</t> <t>By default, a speaker <bcp14>SHOULD</bcp14> discard an
<t>Key Length MUST be at least two less than NLRI Length.</t> unrecognized or unsupported NLRI type and move to the next
</list> NLRI.</t>
</t> </li>
<li>
<t>NLRI Type specific error handling: <t>Key length and key errors of a known NLRI type
<list style="symbols"> <bcp14>SHOULD</bcp14> result in the discard of NLRI similar to an
<t>By default, a speaker SHOULD discard unrecognized or unsupported NLRI unrecognized NLRI type. (This <bcp14>MUST</bcp14> be logged for
type trouble shooting.)</t>
and move to next NLRI.</t> </li>
<t>Key length and key errors of known NLRI type SHOULD result in discard </ul>
of <t>Transparent propagation of unrecognized NLRI type:</t>
NLRI similar to unrecognized NLRI type. (This MUST be logged for <ul spacing="normal">
trouble shooting).</t> <li>
</list> <t>Key length allows unrecognized route types to transit through the
</t> RR
<t>Transparent propagation of unrecognized NLRI type:
<list style="symbols">
<t>Key length allows unrecognized route types to transit through RR
transparently without a software upgrade. The RR receiving unrecognized r oute transparently without a software upgrade. The RR receiving unrecognized r oute
types does not need to interpret the key portion of an NLRI and handles the NLRI types does not need to interpret the key portion of an NLRI and handles the NLRI
as an opaque value of a specific length. An implementation SHOULD provid as an opaque value of a specific length. An implementation <bcp14>SHOULD
e configuration </bcp14> provide configuration
that controls the RR unrecognized route type propagation behavior and po that controls the RR unrecognized route type propagation behavior, possi
ssibly at bly at
the granularity of route type values allowed. This configuration option gives the the granularity of route type values allowed. This configuration option gives the
operator the ability to allow specific route types to be transparently p assed through operator the ability to allow specific route types to be transparently p assed through
RRs based on client speaker support.</t> RRs based on client speaker support.</t>
</li>
<t>In such a case RR may reflect NLRIs with NLRI type specific key length <li>
and <t>In such a case, the RRs may reflect NLRIs with NLRI type-specific
field errors. Clients of such RR that consume the route for installation key length and
will perform the key error handling of known NLRI type or discard field errors. Clients of such an RR that consume the route for installati
on
will perform the key error handling of known NLRI type or discard the
unrecognized type. This prevents propagation of routes with NLRI errors a ny unrecognized type. This prevents propagation of routes with NLRI errors a ny
further in network.</t> further in network.</t>
</list> </li>
</t> </ul>
<t>Type-specific Non-Key TLV handling:</t>
<t>Type-Specific Non-Key TLV handling: <ul spacing="normal">
<list style="symbols"> <li>
<t>Either the length of a TLV would cause the NLRI length to be exce
<t>Either the length of a TLV would cause the NLRI length to be exceeded eded when
when
parsing the TLV, or fewer than 2 bytes remain when beginning to parse the TLV. parsing the TLV, or fewer than 2 bytes remain when beginning to parse the TLV.
In either of these cases, an error condition exists and the 'treat-as-wit In either of these cases, an error condition exists, and the 'treat-as-wi
hdraw' thdraw'
approach MUST be used.</t> approach <bcp14>MUST</bcp14> be used.</t>
</li>
<t>Type specific length constraints should be verified. The TLV MUST be <li>
<t>Type-specific length constraints should be verified. The TLV <bcp
14>MUST</bcp14> be
discarded if there is an error. When discarded, an error may be logged fo r further discarded if there is an error. When discarded, an error may be logged fo r further
analysis.</t> analysis.</t>
</li>
<t>If multiple instances of same type are encountered, all but the first <li>
instance MUST be discarded. When discarded, an error may be logged for fu <t>If multiple instances of same type are encountered, all but the f
rther analysis.</t> irst
instance <bcp14>MUST</bcp14> be discarded. When discarded, an error may b
<t>If a speaker that performs encapsulation to the BGP next hop does not e logged for further analysis.</t>
receive at least one recognized forwarding information TLV with T bit unset (su </li>
ch as label or SRv6 SID), such NLRI is considered invalid and not eligible for b <li>
est path selection. Treat-as-withdraw may be used, though it is recommended to k <t>If a speaker that performs encapsulation to the BGP next hop
eep the NLRI for debugging purposes.</t> does not receive at least one recognized forwarding information
TLV with the T bit unset (such as label or SRv6 SID), such NLRI is
</list> considered invalid and not eligible for best path
</t> selection. 'Treat-as-withdraw' may be used, though it is recommended
to keep the NLRI for debugging purposes.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="STEERING">
<section anchor="STEERING" title="Service Route Automated Steering on Color- <name>Service Route Automated Steering on Color-Aware Paths</name>
Aware Path">
<t>An ingress PE (or ASBR) E1 automatically steers a C-colored service rou te <t>An ingress PE (or ASBR) E1 automatically steers a C-colored service rou te
V/v from E2 onto an (E2, C) color-aware path, as illustrated in V/v from E2 onto an (E2, C) color-aware path, as illustrated in
(<xref target="SECCARIllus"/>). If several such paths exist, a preference <xref target="SECCARIllus"/>. If several such paths exist, a preference sc
scheme is used heme is used
to select the best path. The default preference scheme is IGP Flex-Algo fi to select the best path. The default preference scheme is IGP Flexible Alg
rst, then orithm first, then
SR Policy, followed by BGP CAR. A configuration option may be used to adju st the SR Policy, followed by BGP CAR. A configuration option may be used to adju st the
default preference scheme.</t> default preference scheme.</t>
<t>An egress PE may express its intent that traffic should be steered a ce rtain way through the transport layer <t>An egress PE may express its intent that traffic should be steered a ce rtain way through the transport layer
by including the BGP Color-EC [RFC9012] with the relevant service routes. An ingress PE by including the BGP Color-EC <xref target="RFC9012"/> with the relevant s ervice routes. An ingress PE
steers service traffic over a CAR (E, C) route using the service route's n ext steers service traffic over a CAR (E, C) route using the service route's n ext
hop and BGP Color-EC. hop and BGP Color-EC.
</t> </t>
<t>This is consistent with the automated service route steering on SR
<t>This is consistent with the automated service route steering on Policy (a routing solution providing color-aware paths) defined in <xref
SR Policy (a routing solution providing color-aware path) defined in target="RFC9256"/>. All the steering variations described in <xref
<xref target="RFC9256"/>. All the steering variations described in <xref t target="RFC9256"/> are applicable to BGP CAR paths:
arget="RFC9256"/> on-demand steering, per-destination steering, per-flow steering, and
are applicable to BGP CAR color-aware path: on-demand steering, per-destin color-only steering. For brevity, please refer to <xref target="RFC9256"
ation, sectionFormat="of" section="8"/>.</t>
per-flow, color-only steering. For brevity, please refer to <xref target="
RFC9256"/> Section 8.</t>
<t><xref target="SSTEERINGAPNDX"/> provides illustrations of service route <t><xref target="SSTEERINGAPNDX"/> provides illustrations of service route
automated steering over BGP CAR (E, C) routes.</t> automated steering over BGP CAR (E, C) routes.</t>
<t>An egress PE may express its intent that traffic should be steered a ce rtain way through the transport layer <t>An egress PE may express its intent that traffic should be steered a ce rtain way through the transport layer
by allocating the SRv6 Service SID from a routed intent-aware by allocating the SRv6 Service SID from a routed intent-aware
locator prefix (Section 3.3 of <xref target="RFC8986"/>). Steering at an i ngress locator prefix (<xref target="RFC8986" sectionFormat="of" section="3.3"/>) . Steering at an ingress
PE is via resolution of the Service SID over a CAR Type-2 IP Prefix route. PE is via resolution of the Service SID over a CAR Type-2 IP Prefix route.
Service Steering over BGP CAR SRv6 transport is described in Service steering over BGP CAR SRv6 transport is described in
<xref target="SECCARSRV6"/>.</t> <xref target="SECCARSRV6"/>.</t>
<t>Service steering via BGP CAR routes is applicable to any BGP SAFI, incl uding SAFIs for <t>Service steering via BGP CAR routes is applicable to any BGP SAFI, incl uding SAFIs for
IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), PW, EVPN (SAFI 70), FlowSpec, IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), pseudowire (PW), EVPN (SAFI 70), Flo wSpec,
and BGP-LU (SAFI 4).</t> and BGP-LU (SAFI 4).</t>
</section> </section>
<section anchor="FILTERING">
<section anchor="FILTERING" title="Filtering"> <name>Filtering</name>
<t>PE and BRs may support filtering of CAR routes. For instance, the filte <t>PEs and BRs may support filtering of CAR routes. For instance, the filt
ring ering
may only accept routes of locally configured colors.</t> may only accept routes of locally configured colors.</t>
<t>Techniques such as RT Constrain <xref target="RFC4684"/> may also be ap
<t>Techniques such as RT-Constrain <xref target="RFC4684"/> may also be ap plied to the CAR SAFI, where
plied to the CAR SAFI, where Route Target (RT) Extended Communities <xref target="RFC4360"/> can be use
Route Target (RT) Extended-Communities <xref target="RFC4360"/> can be use d to constrain distribution and
d to constrain distribution and automate filtering of CAR routes. RT assignment may be via user policy; fo
automate filtering of CAR routes. RT assignment may be via user policy, fo r example, an RT
r example an RT
value can be assigned to all routes of a specific color.</t> value can be assigned to all routes of a specific color.</t>
<t>A PE may support on-demand installation of a CAR route based on the pre
<t>A PE may support on-demand installation of a CAR route based on the pre sence of a service route whose next hop
sence of a service route whose next-hop
resolves via the CAR route.</t> resolves via the CAR route.</t>
<t>Similarly, a PE may dynamically subscribe to receive individual CAR
<t>Similarly, a PE may dynamically subscribe to receive individual CAR rou routes from upstream routers or Route Reflectors (RRs) to limit the routes
tes from upstream routers or that it needs to learn. On-demand subscription and automated filtering
route-reflectors to limit the routes that it needs to learn. On-demand sub procedures for individual CAR routes are outside the scope of this
scription and automated filtering procedures for individual CAR routes are outsi document.
de the </t>
scope of this document.
</t>
</section> </section>
<section anchor="SCLNG">
<section anchor="SCLNG" title="Scaling"> <name>Scaling</name>
<t>This section analyses the key scale requirement of <t>This section analyzes the key scale requirement of
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>, specifical ly: <xref target="I-D.hr-spring-intentaware-routing-using-color"/>, specifical ly:
<list style="symbols">
<t>No intermediate node data-plane should need to scale to (Colors * PEs
).</t>
<t>No node should learn and install a BGP CAR route to (E, C) if it does
not install a Colored service route to E.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>No intermediate node data plane should need to scale to (Colors * P
Es).</t>
</li>
<li>
<t>No node should learn and install a BGP CAR route to (E, C) if it do
es
not install a colored service route to E.</t>
</li>
</ul>
<t>While the requirements and design principles generally apply to any tra nsport, <t>While the requirements and design principles generally apply to any tra nsport,
the logical analysis based on the network design in this section focuses o n the logical analysis based on the network design in this section focuses o n
MPLS / SR-MPLS transport since the scaling constraints are specifically re levant to MPLS/SR-MPLS transport since the scaling constraints are specifically rele vant to
these technologies. BGP CAR SAFI is used here, but the considerations can apply to these technologies. BGP CAR SAFI is used here, but the considerations can apply to
[RFC8277] or [RFC8669] used with MPLS/SR-MPLS. <xref target="RFC8277"/> or <xref target="RFC8669"/> used with MPLS/SR-MPL S.
</t> </t>
<t>Two key principles used to address the scaling requirements are a <t>Two key principles used to address the scaling requirements are a
hierarchical network and routing design, and on-demand route hierarchical network and routing design, and on-demand route
subscription and filtering.</t> subscription and filtering.</t>
<t><xref target="SUSRT"/> in <xref target="USTOP"/> provides an ultra-scal e <t><xref target="SUSRT"/> in <xref target="USTOP"/> provides an ultra-scal e
reference topology. <xref target="USTOP"/> describes this topology. reference topology. <xref target="USTOP"/> describes this topology.
<xref target="SSDM"/> presents three design models to deploy BGP CAR in th e <xref target="SSDM"/> presents three design models to deploy BGP CAR in th e
reference topology, including hierarchical options. <xref target="SSA"/> a nalyses reference topology, including hierarchical options. <xref target="SSA"/> a nalyzes
the logical scaling properties of each model.</t> the logical scaling properties of each model.</t>
<t>Filtering techniques described in the previous section allow a PE to
<t>Filtering techniques described in the previous section allow a PE to li limit the CAR routes that it needs to learn or install. Scaling benefits
mit the CAR routes that it needs to of on-demand BGP subscription and filtering will be described in a
learn or install. Scaling benefits of on-demand BGP subscription and filte separate document.</t>
ring will be described in a separate document.</t> <section anchor="USTOP">
<name>Ultra-Scale Reference Topology</name>
<section anchor="USTOP" title="Ultra-Scale Reference Topology"> <figure anchor="SUSRT">
<figure anchor="SUSRT" title="Ultra-Scale Reference Topology"> <name>Ultra-Scale Reference Topology</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ +-----+ vpn label:30030 +-----+ +-----+ +-----+ vpn label:30030 +-----+
....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
: +-----+ +-----+ Color C1 +-----+ : : +-----+ +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+:------------+--------------+--------------+--------------+--------:-+ +:------------+--------------+--------------+--------------+--------:-+
|: | | | | : | |: | | | | : |
|: | | | | : | |: | | | | : |
|: +---+ +---+ +---+ +---+ : | |: +---+ +---+ +---+ +---+ : |
|: |121| |231| |341| |451| : | |: |121| |231| |341| |451| : |
|: +---+ +---+ +---+ +---+ : | |: +---+ +---+ +---+ +---+ : |
|---+ | | | | +---| |---+ | | | | +---|
| E1| | | | | | E2| | E1| | | | | | E2|
|---+ | | | | +---| |---+ | | | | +---|
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| |122| |232| |342| |452| | | |122| |232| |342| |452| |
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access | | Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+ +-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE iPE iBRM iBRC eBRC eBRM ePE
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The following description applies to the reference topology above: <t>The following description applies to the reference topology above:
<list style="symbols"> </t>
<t>Independent IS-IS/OSPF SR instance in each domain.</t> <ul spacing="normal">
<t>Each domain has Flex Algo 128. Prefix SID for a node is SRGB 168000 <li>
plus <t>Independent IS-IS/OSPF SR instance in each domain.</t>
</li>
<li>
<t>Each domain has Flex-Algo 128. Prefix-SID for a node is Segment R
outing Global Block (SRGB) 168000 plus
node number.</t> node number.</t>
<t>A BGP CAR route (E2, C1) is advertised by egress BRM node 451. The </li>
route is <li>
sourced locally from redistribution from IGP-FA 128.</t> <t>A BGP CAR route (E2, C1) is advertised by egress BRM node 451. Th
<t>Not shown for simplicity, node 452 will also advertise (E2, C1).</t e route is
> sourced locally from redistribution from IGP Flex-Algo 128.</t>
<t>When a transport RR is used within the domain or across domains, </li>
ADD-PATH is enabled to advertise paths from both egress BRs to it's <li>
<t>Not shown for simplicity, node 452 will also advertise (E2, C1).<
/t>
</li>
<li>
<t>When a TRR is used within the domain or across domains,
ADD-PATH is enabled to advertise paths from both egress BRs to its
clients.</t> clients.</t>
<t>Egress PE E2 advertises a VPN route RD:V/v with BGP Color extended </li>
community C1 that propagates via service RRs to ingress PE E1.</t> <li>
<t>E1 steers V/v prefix via color-aware path (E2, C1) and VPN label 30 <t>Egress PE E2 advertises a VPN route RD:V/v with BGP Color-EC C1 t
030.</t> hat propagates via service RRs to ingress PE E1.</t>
</list> </li>
</t> <li>
<t>E1 steers V/v prefix via color-aware path (E2, C1) and VPN label
30030.</t>
</li>
</ul>
</section> </section>
<section anchor="SSDM">
<section anchor="SSDM" title="Deployment Model"> <name>Deployment Model</name>
<section title="Flat"> <section>
<figure anchor="SFLAT" <name>Flat</name>
title="Flat Transport Network Design"> <figure anchor="SFLAT">
<name>Flat Transport Network Design</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ +-----+ vpn label:30030 +-----+ +-----+ +-----+ vpn label:30030 +-----+
....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <...... ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
: +-----+ +-----+ Color C1 +-----+ : : +-----+ +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+:------------+--------------+--------------+--------------+--------:-+ +:------------+--------------+--------------+--------------+--------:-+
|: | | | | : | |: | | | | : |
skipping to change at line 1524 skipping to change at line 1569
| |122| |232| |342| |452| | | |122| |232| |342| |452| |
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access | | Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+ +-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE iPE iBRM iBRC eBRC eBRM ePE
168121 168231 168341 168451 168121 168231 168341 168451
168002 168002 168002 168002 168002 168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>Node 451 advertises BGP CAR route (E2, C1) to 341, from which it <t>Node 451 advertises BGP CAR route (E2, C1) to 341, from which
goes it goes to 231, then to 121, and finally to E1.</t>
to 231 then to 121 and finally to E1.</t> </li>
<t>Each BGP hop allocates local label and programs swap entry in for <li>
warding <t>Each BGP hop allocates local label and programs swap entry in f
orwarding
for (E2, C1).</t> for (E2, C1).</t>
<t>E1 receives BGP CAR route (E2, C1) via 121 with label 168002. </li>
<list> <li>
<t>Let's assume E1 selects that path.</t> <t>E1 receives BGP CAR route (E2, C1) via 121 with label 168002.
</list> </t>
</t> <ul spacing="normal">
<t>E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path (1 <li>
21, C1). <t>Let's assume E1 selects that path.</t>
<list> </li>
<t>Color-aware path (121, C1) is FA128 path to 121 (label 168121). </ul>
</t> </li>
</list> <li>
</t> <t>E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path
<t>E1's imposition color-aware label-stack for V/v is thus (121, C1).
<list> </t>
<t>30030 &lt;=> V/v</t> <ul spacing="normal">
<t>168002 &lt;=> (E2, C1)</t> <li>
<t>168121 &lt;=> (121, C1)</t> <t>Color-aware path (121, C1) is Flex-Algo 128 path to 121
</list> (label 168121).</t>
</t> </li>
<t>Each BGP hop performs swap operation on 168002 bound to color-awa </ul>
re path </li>
<li>
<t>E1's imposition color-aware label stack for V/v is thus:</t>
<ul spacing="normal">
<li>
<t>30030 &lt;=&gt; V/v</t>
</li>
<li>
<t>168002 &lt;=&gt; (E2, C1)</t>
</li>
<li>
<t>168121 &lt;=&gt; (121, C1)</t>
</li>
</ul>
</li>
<li>
<t>Each BGP hop performs swap operation on 168002 bound to color-a
ware path
(E2, C1).</t> (E2, C1).</t>
</list> </li>
</t> </ul>
</section> </section>
<section>
<section title="Hierarchical Design with Next-Hop-Self at Ingress Domain <name>Hierarchical Design with Next-Hop-Self at Ingress Domain BR</nam
BR"> e>
<figure anchor="BGPCARSCALEHEIRNH" <figure anchor="BGPCARSCALEHEIRNH">
title="Hierarchical BGP transport CAR, Next-Hop-Self (NHS) at iBR"> <name>Hierarchical BGP Transport CAR, Next-Hop-Self (NHS) at iBR</na
me>
<artwork><![CDATA[ <artwork><![CDATA[
(E2,C1) (E2,C1)
+-----+ via 451 +-----+ +-----+ via 451 +-----+
|T-RR1| <-------------- |T-RR2| |T-RR1| <-------------- |T-RR2|
/ +-----+ L=168002 +-----+\ / +-----+ L=168002 +-----+\
/ \ / \
+-------------+---/----------+--------------+-----------\--+----------+ +-------------+---/----------+--------------+-----------\--+----------+
| | / | | \ | | | | / | | \ | |
| (E2,C1) | / (451,C1) | (451,C1) | \| | | (E2,C1) | / (451,C1) | (451,C1) | \| |
| via 121 +---+ via 231 +---+ via 341 +---+ +---+ | | via 121 +---+ via 231 +---+ via 341 +---+ +---+ |
| L=168002 |121| <======= |231| <========|341| <======= |451| | | L=168002 |121| <======= |231| <========|341| <======= |451| |
skipping to change at line 1586 skipping to change at line 1650
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| Access | Metro | Core | Metro | Access | | Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+ +-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE iPE iBRM iBRC eBRC eBRM ePE
168231 168341 168231 168341
168121 168451 168451 168451 168121 168451 168451 168451
168002 168002 168002 168002 168002 168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>Node 451 advertises BGP CAR route (451, C1) to 341, from which it <t>Node 451 advertises BGP CAR route (451, C1) to 341, from which
goes to it goes to
231 and finally to 121.</t> 231, and finally to 121.</t>
<t>Each BGP hop allocates local label and programs swap entry in for </li>
warding <li>
<t>Each BGP hop allocates local label and programs swap entry in f
orwarding
for (451, C1).</t> for (451, C1).</t>
<t>121 resolves received BGP CAR route (451, C1) via 231 (label 1684 </li>
51) on <li>
<t>121 resolves received BGP CAR route (451, C1) via 231 (label 16
8451) on
color-aware path (231, C1). color-aware path (231, C1).
<list> </t>
<t>Color-aware path (231, C1) is FA128 path to 231 (label 168231). <ul spacing="normal">
</t> <li>
</list> <t>Color-aware path (231, C1) is Flex-Algo 128 path to 231 (la
</t> bel 168231).</t>
<t>451 advertises BGP CAR route (E2, C1) via 451 to transport RR T-R </li>
R2, which </ul>
reflects it to transport RR T-RR1, which reflects it to 121.</t> </li>
<t>121 receives BGP CAR route (E2, C1) via 451 with label 168002. <li>
<list> <t>451 advertises BGP CAR route (E2, C1) via 451 to TRR T-RR2, whi
<t>Let's assume 121 selects that path.</t> ch
</list> reflects it to TRR T-RR1, which reflects it to 121.</t>
</t> </li>
<t>121 resolves BGP CAR route (E2, C1) via 451 on color-aware path ( <li>
451, C1). <t>121 receives BGP CAR route (E2, C1) via 451 with label 168002.
<list> </t>
<t>Color-aware path (451, C1) is BGP CAR path to 451 (label 168451 <ul spacing="normal">
).</t> <li>
</list> <t>Let's assume 121 selects that path.</t>
</t> </li>
<t>121 imposition of color-aware label stack for (E2, C1) is thus </ul>
<list> </li>
<t>168002 &lt;=> (E2, C1)</t> <li>
<t>168451 &lt;=> (451, C1)</t> <t>121 resolves BGP CAR route (E2, C1) via 451 on color-aware path
<t>168231 &lt;=> (231, C1)</t> (451, C1).
</list> </t>
</t> <ul spacing="normal">
<t>121 advertises (E2, C1) to E1 with next hop self (121) and label <li>
168002</t> <t>Color-aware path (451, C1) is BGP CAR path to 451 (label 16
<t>E1 constructs same imposition color-aware label-stack for V/v via 8451).</t>
(E2, C1) </li>
</ul>
</li>
<li>
<t>121 imposition of color-aware label stack for (E2, C1) is thus:
</t>
<ul spacing="normal">
<li>
<t>168002 &lt;=&gt; (E2, C1)</t>
</li>
<li>
<t>168451 &lt;=&gt; (451, C1)</t>
</li>
<li>
<t>168231 &lt;=&gt; (231, C1)</t>
</li>
</ul>
</li>
<li>
<t>121 advertises (E2, C1) to E1 with next-hop-self (121) and labe
l 168002.</t>
</li>
<li>
<t>E1 constructs same imposition color-aware label stack for V/v v
ia (E2, C1)
as in the flat model: as in the flat model:
<list> </t>
<t>30030 &lt;=> V/v</t> <ul spacing="normal">
<t>168002 &lt;=> (E2, C1)</t> <li>
<t>168121 &lt;=> (121, C1)</t> <t>30030 &lt;=&gt; V/v</t>
</list> </li>
</t> <li>
<t>121 performs swap operation on 168002 with hierarchical color-awa <t>168002 &lt;=&gt; (E2, C1)</t>
re label </li>
<li>
<t>168121 &lt;=&gt; (121, C1)</t>
</li>
</ul>
</li>
<li>
<t>121 performs swap operation on 168002 with hierarchical color-a
ware label
stack for (E2, C1) via 451 from step 7.</t> stack for (E2, C1) via 451 from step 7.</t>
<t>Nodes 231 and 341 perform swap operation on 168451 bound to color </li>
-aware <li>
<t>Nodes 231 and 341 perform swap operation on 168451 bound to col
or-aware
path (451, C1).</t> path (451, C1).</t>
<t>451 performs swap operation on 168002 bound to color-aware path ( </li>
E2, C1).</t> <li>
</list> <t>451 performs swap operation on 168002 bound to color-aware path
</t> (E2, C1).</t>
</li>
</ul>
<t>Note: E1 does not need the BGP CAR route (451, C1) in this design.< /t> <t>Note: E1 does not need the BGP CAR route (451, C1) in this design.< /t>
</section> </section>
<section anchor="SBGPCARSCALEHEIRNHU">
<section anchor="SBGPCARSCALEHEIRNHU" <name>Hierarchical Design with Next-Hop-Unchanged at Ingress Domain BR
title="Hierarchical Design with Next-Hop-Unchanged at Ingress Domain BR" </name>
> <figure anchor="BGPCARSCALEHEIRNHU">
<figure anchor="BGPCARSCALEHEIRNHU" <name>Hierarchical BGP Transport CAR, Next-Hop-Unchanged (NHU) at iB
title="Hierarchical BGP transport CAR, Next-Hop-Unchanged (NHU) at iBR R</name>
">
<artwork><![CDATA[ <artwork><![CDATA[
(E2,C1) (E2,C1)
+-----+ via 451 +-----+ +-----+ via 451 +-----+
|T-RR1| <-------------- |T-RR2| |T-RR1| <-------------- |T-RR2|
/ +-----+ L=168002 +-----+\ / +-----+ L=168002 +-----+\
/ \ / \
+-------------+---/----------+--------------+-----------\--+----------+ +-------------+---/----------+--------------+-----------\--+----------+
| | / | | \ | | | | / | | \ | |
| (E2,C1) | / (451,C1) | (451,C1) | \| | | (E2,C1) | / (451,C1) | (451,C1) | \| |
| via 451 +---+ via 231 +---+ via 341 +---+ +---+ | | via 451 +---+ via 231 +---+ via 341 +---+ +---+ |
skipping to change at line 1670 skipping to change at line 1772
| | | | | | | | | | | |
| Access | Metro | Core | Metro | Access | | Access | Metro | Core | Metro | Access |
| domain 1 | domain 2 | domain 3 | domain 4 | domain 5 | | domain 1 | domain 2 | domain 3 | domain 4 | domain 5 |
+-------------+--------------+--------------+--------------+----------+ +-------------+--------------+--------------+--------------+----------+
iPE iBRM iBRC eBRC eBRM ePE iPE iBRM iBRC eBRC eBRM ePE
168121 168231 168341 168121 168231 168341
168451 168451 168451 168451 168451 168451 168451 168451
168002 168002 168002 168002 168002 168002 168002 168002 168002 168002
30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030 30030
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<list style="symbols"> <ul spacing="normal">
<t>Nodes 341, 231 and 121 receive and resolve BGP CAR route (451, C1 <li>
) the <t>Nodes 341, 231, and 121 receive and resolve BGP CAR route (451,
C1) the
same as in the previous model.</t> same as in the previous model.</t>
<t>Node 121 allocates local label and programs swap entry in forward </li>
ing for <li>
<t>Node 121 allocates local label and programs swap entry in forwa
rding for
(451, C1).</t> (451, C1).</t>
<t>451 advertises BGP CAR route (E2, C1) to transport RR T-RR2, whic </li>
h <li>
reflects it to transport RR T-RR1, which reflects it to 121.</t> <t>451 advertises BGP CAR route (E2, C1) to TRR T-RR2, which
<t>Node 121 advertises (E2, C1) to E1 with next hop as 451; i.e., reflects it to TRR T-RR1, which reflects it to 121.</t>
next-hop-unchanged.</t> </li>
<t>121 also advertises (451, C1) to E1 with next hop self (121) and <li>
label <t>Node 121 advertises (E2, C1) to E1 with next hop as 451
(i.e., next-hop-unchanged).</t>
</li>
<li>
<t>121 also advertises (451, C1) to E1 with next-hop-self (121) an
d label
168451.</t> 168451.</t>
<t>E1 resolves BGP CAR route (451, C1) via 121 on color-aware path ( </li>
121, C1). <li>
<list> <t>E1 resolves BGP CAR route (451, C1) via 121 on color-aware path
<t>Color-aware path (121, C1) is FA128 path to 121 (label 168121). (121, C1).
</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>E1 receives BGP CAR route (E2, C1) via 451 with label 168002. <t>Color-aware path (121, C1) is Flex-Algo 128 path to 121 (la
<list> bel 168121).</t>
<t>Let's assume E1 selects that path.</t> </li>
</list> </ul>
</t> </li>
<t>E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path (4 <li>
51, C1). <t>E1 receives BGP CAR route (E2, C1) via 451 with label 168002.
<list> </t>
<t>Color-aware path (451, C1) is BGP CAR path to 451 (label 168451 <ul spacing="normal">
).</t> <li>
</list> <t>Let's assume E1 selects that path.</t>
</t> </li>
<t>E1's imposition color-aware label-stack for V/v is thus </ul>
<list> </li>
<t>30030 &lt;=> V/v</t> <li>
<t>168002 &lt;=> (E2, C1)</t> <t>E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path
<t>168451 &lt;=> (451, C1)</t> (451, C1).
<t>168121 &lt;=> (121, C1)</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>Nodes 121, 231 and 341 perform swap operation on 168451 bound to <t>Color-aware path (451, C1) is BGP CAR path to 451 (label 16
(451, C1).</t> 8451).</t>
<t>451 performs swap operation on 168002 bound to color-aware path ( </li>
E2, C1).</t> </ul>
</list> </li>
</t> <li>
<t>E1's imposition color-aware label stack for V/v is thus:</t>
<ul spacing="normal">
<li>
<t>30030 &lt;=&gt; V/v</t>
</li>
<li>
<t>168002 &lt;=&gt; (E2, C1)</t>
</li>
<li>
<t>168451 &lt;=&gt; (451, C1)</t>
</li>
<li>
<t>168121 &lt;=&gt; (121, C1)</t>
</li>
</ul>
</li>
<li>
<t>Nodes 121, 231, and 341 perform swap operation on 168451 bound
to (451, C1).</t>
</li>
<li>
<t>451 performs swap operation on 168002 bound to color-aware path
(E2, C1).</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="SSA">
<section anchor="SSA" title="Scale Analysis"> <name>Scale Analysis</name>
<t>The following two tables summarize the logically analyzed scaling of the <t>The following two tables summarize the logically analyzed scaling of the
control-plane and data-plane for these three models:</t> control plane and data plane for the previous three models:</t>
<table>
<figure> <thead>
<artwork><![CDATA[ <tr>
| E1 | 121 | 231 <th></th>
FLAT | (E2,C) via (121,C) | (E2,C) via (231,C) | (E2,C) via (341,C) <th>E1</th>
H.NHS| (E2,C) via (121,C) | (E2,C) via (451,C) | <th>121</th>
| | (451,C) via (231,C) | (451,C) via (341,C) <th>231</th>
H.NHU| (E2,C) via (451,C) | | </tr>
| (451,C) via (121,C) | (451,C) via (231,C) | (451,C) via (341,C) </thead>
]]></artwork> <tbody>
</figure> <tr>
<th>FLAT</th>
<figure> <td>(E2,C) via (121,C)</td>
<artwork><![CDATA[ <td>(E2,C) via (231,C)</td>
| E1 | 121 | 231 <td>(E2,C) via (341,C)</td>
FLAT | V -> 30030 | 168002 -> 168002 | 168002 -> 168002 </tr>
| 168002 | 168231 | 168341 <tr>
| 168121 | | <th>H.NHS</th>
H.NHS| V -> 30030 | 168002 -> 168002 | 168451 -> 168451 <td>(E2,C) via (121,C)</td>
| 168002 | 168451 | 168341 <td>(E2,C) via (451,C)<br/>(451,C) via (231,C)</td>
| 168121 | 168231 | <td>(451,C) via (341,C)</td>
H.NHU| V -> 30030 | 168451 -> 168451 | 168451 -> 168451 </tr>
| 168002 | 168231 | 168341 <tr>
| 168451 | | <th>H.NHU</th>
| 168121 | | <td>(E2,C) via (451,C)<br/>(451,C) via (121,C)</td>
]]></artwork> <td>(451,C) via (231,C)</td>
</figure> <td>(451,C) via (341,C)</td>
</tr>
</tbody>
</table>
<t> <table>
<list style="symbols"> <thead>
<t>The flat model is the simplest design, with a single BGP transport <tr>
level. <th></th>
It results in the minimum label/SID stack at each BGP hop. However, it <th>E1</th>
significantly increases the scale impact on the core BRs (e.g. 341), w <th>121</th>
hose <th>231</th>
FIB capacity and even MPLS label space may be exceeded. </tr>
<list> </thead>
<t>341's data-plane scales with (E2, C) where there may be 300k E's <tbody>
and 5 C's <tr>
hence 1.5M entries > 1M MPLS data-plane.</t> <th>FLAT</th>
</list> <td align="right">V -> 30030<br/>168002<br/>168121</td>
</t> <td align="right">168002 -> 168002<br/>168231</td>
<t>The hierarchical models avoid the need for core BRs to learn routes <td align="right">168002 -> 168002<br/>168341</td>
and </tr>
<tr>
<th>H.NHS</th>
<td align="right">V -> 30030<br/>168002<br/>168121</td>
<td align="right">168002 -> 168002<br/>168451<br/>168231</td>
<td align="right">168451 -> 168451<br/>168341</td>
</tr>
<tr>
<th>H.NHU</th>
<td align="right">V -> 30030<br/>168002<br/>168451<br/>168121</td>
<td align="right">168451&nbsp;->&nbsp;168451<br/>168231</td>
<td align="right">168451&nbsp;->&nbsp;168451<br/>168341</td>
</tr>
</tbody>
</table>
<ul spacing="normal">
<li>
<t>The flat model is the simplest design, with a single BGP
transport level. It results in the minimum label/SID stack at
each BGP hop. However, it significantly increases the scale impact
on the core BRs (e.g., 341), whose FIB capacity and even MPLS
label space may be exceeded.
</t>
<ul spacing="normal">
<li>
<t>341's data plane scales with (E2, C) where there may be
300k Es and 5 Cs, hence 1.5M entries &gt; 1M MPLS
data plane.</t>
</li>
</ul>
</li>
<li>
<t>The hierarchical models avoid the need for core BRs to learn rout
es and
install label forwarding entries for (E, C) routes. install label forwarding entries for (E, C) routes.
<list> </t>
<t>Whether next hop is set to self or left unchanged at 121, 341's d <ul spacing="normal">
ata-plane <li>
scales with (451, C) where there may be thousands of 451's and 5 C's <t>Whether next hop is set to self or left unchanged at 121, 341
. Therefore, 's data plane
this scaling is well under the 1 million MPLS labels data-plane limi scales with (451, C) where there may be thousands of 451s and 5 Cs.
t.</t> Therefore,
<t>They also aid faster convergence by allowing the PE routes to this scaling is well under the 1 million MPLS labels data plane limi
be distributed via out-of-band RRs that can be scaled t.</t>
independent of the transport BRs.</t> </li>
</list> <li>
</t> <t>They also aid faster convergence by allowing the PE routes
<t>The next-hop-self option at ingress BRM (e.g. 121) hides the hierar to be distributed via out-of-band RRs that can be scaled
chical independent of the transport BRs.</t>
</li>
</ul>
</li>
<li>
<t>The next-hop-self option at ingress BRM (e.g., 121) hides the hie
rarchical
design from the ingress PE, keeping its outgoing label programming as simple as design from the ingress PE, keeping its outgoing label programming as simple as
the flat model. However, the ingress BRM requires an additional BGP tr ansport the flat model. However, the ingress BRM requires an additional BGP tr ansport
level recursion, which coupled with load-balancing adds data-plane com plexity. level recursion, which coupled with load-balancing adds data plane com plexity.
It needs to support a swap and push operation. It also needs to instal l label It needs to support a swap and push operation. It also needs to instal l label
forwarding entries for the egress PEs that are of interest to its loca l ingress forwarding entries for the egress PEs that are of interest to its loca l ingress
PEs.</t> PEs.</t>
<t>With the next-hop-unchanged option at ingress BRM (e.g. 121), only </li>
an ingress <li>
<t>With the next-hop-unchanged option at ingress BRM (e.g., 121), on
ly an ingress
PE needs to learn and install output label entries for egress (E, C) r outes. PE needs to learn and install output label entries for egress (E, C) r outes.
The ingress BRM only installs label forwarding entries for the egress ABR The ingress BRM only installs label forwarding entries for the egress ABR
(e.g. 451). However, the ingress PE needs an additional BGP transport level (e.g., 451). However, the ingress PE needs an additional BGP transport level
recursion and pushes a BGP VPN label and two BGP transport labels. It may also recursion and pushes a BGP VPN label and two BGP transport labels. It may also
need to handle load-balancing for the egress ABRs. This is the most co mplex need to handle load-balancing for the egress ABRs. This is the most co mplex
data-plane option for the ingress PE.</t> data plane option for the ingress PE.</t>
</list> </li>
</t> </ul>
</section> </section>
<section anchor="SECANYCASTSID">
<section anchor="SECANYCASTSID" title="Anycast SID"> <name>Anycast SID</name>
<t>This section describes how Anycast SID complements and improves the <t>This section describes how Anycast SID complements and improves the
scaling designs above.</t> scaling designs above.</t>
<section anchor="ASIDTRANS">
<section anchor="ASIDTRANS" title="Anycast SID for Transit Inter-domain <name>Anycast SID for Transit Inter-Domain Nodes</name>
Nodes"> <ul spacing="normal">
<t> <li>
<list style="symbols"> <t>Redundant BRs (e.g., two egress BRMs, 451 and 452) advertise BG
<t>Redundant BRs (e.g. two egress BRMs, 451 and 452) advertise BGP C P CAR
AR
routes for a local PE (e.g., E2) with the same SID (based on label i ndex). routes for a local PE (e.g., E2) with the same SID (based on label i ndex).
Such egress BRMs may be assigned a common Anycast SID, so that the B GP Such egress BRMs may be assigned a common Anycast SID, so that the B GP
next hops for these routes will also resolve via a color-aware path to next hops for these routes will also resolve via a color-aware path to
the Anycast SID.</t> the Anycast SID.</t>
<t>The use of Anycast SID naturally provides fast local convergence </li>
upon <li>
<t>The use of Anycast SID naturally provides fast local convergenc
e upon
failure of an egress BRM node. In addition, it decreases the recursi ve failure of an egress BRM node. In addition, it decreases the recursi ve
resolution and load-balancing complexity at an ingress BRM or PE in the resolution and load-balancing complexity at an ingress BRM or PE in the
hierarchical designs above.</t> hierarchical designs above.</t>
</list> </li>
</t> </ul>
</section> </section>
<section title="Anycast SID for Transport Color Endpoints (e.g., PEs)"> <section>
<name>Anycast SID for Transport Color Endpoints</name>
<t>The common Anycast SID technique may also be used for a redundant p air <t>The common Anycast SID technique may also be used for a redundant p air
of PEs that share an identical set of service (VPN) attachments. of PEs that share an identical set of service (VPN) attachments.
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> <t>
For example, assume a node E2' paired with E2 above For example, assume a node E2' is paired with E2 above
(e.g., <xref target="BGPCARSCALEHEIRNHU"/>). Both (e.g., <xref target="BGPCARSCALEHEIRNHU"/>). Both
PEs should be configured with the same static label/SID for the serv ices PEs should be configured with the same static label/SID for the serv ices
(e.g., per-VRF VPN label/SID), and will advertise associated service (e.g., per-VRF VPN label/SID), and will advertise associated service
routes with the Anycast IP as BGP next hop. </t> routes with the Anycast IP as BGP next hop. </t>
<t>This design provides a convergence and recursive resolution benef </li>
it on <li>
an ingress PE or ABR similar to the egress ABR case in the previous <t>This design provides a convergence and recursive resolution ben
section efit on
(<xref target="ASIDTRANS"/>). However, its applicability is limited an ingress PE or ABR similar to the egress ABR case in
<xref target="ASIDTRANS"/>. However, its applicability is limited
to cases where the above constraints can be met.</t> to cases where the above constraints can be met.</t>
</list> </li>
</t> </ul>
</section> </section>
</section> </section>
</section> </section>
<section>
<section title="Routing Convergence"> <name>Routing Convergence</name>
<t>BGP CAR leverages existing well-known design techniques to provide fast <t>BGP CAR leverages existing well-known design techniques to provide fast
convergence.</t> convergence.</t>
<t><xref target="SECPA"/> describes how BGP CAR provides localized <t><xref target="SECPA"/> describes how BGP CAR provides localized
convergence within a domain for BR failures, including originating BRs, wi thout convergence within a domain for BR failures, including originating BRs, wi thout
propagating failure churn into other domains.</t> propagating failure churn into other domains.</t>
<t>Anycast SID techniques described in <xref target="SECANYCASTSID"/> <t>Anycast SID techniques described in <xref target="SECANYCASTSID"/>
can provide further convergence optimizations for BR and PE failures deplo yed in can provide further convergence optimizations for BR and PE failures deplo yed in
redundant designs. redundant designs.
</t> </t>
</section> </section>
<section anchor="SECCARSRV6">
<section anchor="SECCARSRV6" title="CAR SRv6"> <name>CAR SRv6</name>
<section title="Overview"> <section>
<t>Steering services over SRv6 based intent-aware multi-domain transport <name>Overview</name>
paths <t>Steering services over SRv6-based intent-aware multi-domain
may be categorized into two distinct cases that are described in Section transport paths may be categorized into two distinct cases that are
5 of described in <xref target="RFC9252" sectionFormat="of"
<xref target="RFC9252"/>. Both cases are supported by BGP CAR, as descri section="5"/>. Both cases are supported by BGP CAR, as described
bed below.</t> below.</t>
<section anchor="SECRTDSSID">
<section anchor="SECRTDSSID" title="Routed Service SID"> <name>Routed Service SID</name>
<t>The SRv6 Service SID that is advertised with a service route is <t>The SRv6 Service SID that is advertised with a service route is
allocated by an egress PE from a routed intent-aware locator prefix allocated by an egress PE from a routed intent-aware locator prefix
(Section 3.3 of <xref target="RFC8986"/>). Service steering at an ingr ess PE is (<xref target="RFC8986" sectionFormat="of" section="3.3"/>). Service s teering at an ingress PE is
via resolution of the Service SID signaled with the service route as d escribed in via resolution of the Service SID signaled with the service route as d escribed in
(<xref target="RFC9252"/>).</t> <xref target="RFC9252"/>.</t>
<t>The intent-aware transport path to the SRv6 locator of the egress P E is provided <t>The intent-aware transport path to the SRv6 locator of the egress P E is provided
by underlay IP routing. Underlay IP routing can include IGP Flex-Algo by underlay IP routing. Underlay IP routing can include IGP Flexible A
<xref target="RFC9350"/> lgorithm <xref target="RFC9350"/>
within a domain, and BGP CAR [this document] across multiple IGP domai within a domain, and BGP CAR (as defined in this document) across mult
ns or BGP ASes.</t> iple IGP domains or BGP ASes.</t>
<t> An SRv6 locator prefix is assigned for a given intent or color. Th e SRv6 locator <t> An SRv6 locator prefix is assigned for a given intent or color. Th e SRv6 locator
may be shared with an IGP Flex-Algo, or may be assigned specific to BG P CAR for may be shared with an IGP Flexible Algorithm, or it may be assigned sp ecific to BGP CAR for
a given intent.</t> a given intent.</t>
<t>Distribution of SRv6 locators in BGP CAR SAFI: <t>Distribution of SRv6 locators in BGP CAR SAFI:
<list style="symbols"> </t>
<t>In a multi-domain network, the SRv6 locator prefix is distributed u <ul spacing="normal">
sing BGP CAR SAFI <li>
<t>In a multi-domain network, the SRv6 locator prefix is distribut
ed using BGP CAR SAFI
to ingress PEs and ASBRs in a remote domain. The SRv6 locator prefix m ay be advertised to ingress PEs and ASBRs in a remote domain. The SRv6 locator prefix m ay be advertised
in the BGP CAR SAFI from an egress PE, or redistributed into BGP CAR f rom an IGP-FlexAlgo in the BGP CAR SAFI from an egress PE, or redistributed into BGP CAR f rom an IGP Flex-Algo
at a BR. The locator prefix may also be summarized on a border node al ong the path and at a BR. The locator prefix may also be summarized on a border node al ong the path and
a summary route distributed to ingress PEs.</t> a summary route distributed to ingress PEs.</t>
</li>
<t> An IP Prefix CAR route (Type-2) is defined to distribute SRv6 loca <li>
tor prefixes <t> An IP Prefix CAR route (Type-2) is defined to distribute SRv6
and described in <xref target="NLRITYPE2"/> and <xref target="CARIPPRE locator prefixes
FIX"/>.</t> and described in Sections <xref target="NLRITYPE2" format="counter"/>
and <xref target="CARIPPREFIX" format="counter"/>.</t>
<t>A BGP CAR advertised SRv6 locator prefix may also be used for resol </li>
ution <li>
of the SRv6 service SID advertised for best-effort connectivity.</t> <t>A BGP CAR advertised SRv6 locator prefix may also be used for r
</list> esolution
</t> of the SRv6 Service SID advertised for best-effort connectivity.</t>
</li>
<t><xref target="SECLOCHBYH"/> and <xref target="SECSRv6LOCencap"/> </ul>
illustrates the control and forwarding behaviors for routed SRv6 <t>Appendices <xref target="SECLOCHBYH" format="counter"/> and <xref t
Service SID.</t> arget="SECSRv6LOCencap" format="counter"/>
illustrate the control, and forwarding behaviors for routed SRv6
Service SIDs.</t>
<t><xref target="SRv6DEPLT"/> describes the deployment options.</t> <t><xref target="SRv6DEPLT"/> describes the deployment options.</t>
<t><xref target="SRv6CAROPER"/> describes operational considerations <t><xref target="SRv6CAROPER"/> describes operational considerations
of using BGP CAR SAFI vs BGP IPv6 SAFI for inter-domain route distribu tion of using BGP CAR SAFI versus BGP IPv6 SAFI for inter-domain route dist ribution
of SRv6 locators.</t> of SRv6 locators.</t>
</section> </section>
<section anchor="SECNRSSID">
<section anchor="SECNRSSID" title="Non-routed Service SID"> <name>Non-Routed Service SID</name>
<t>The SRv6 Service SID allocated by an egress PE is not routed. The s ervice <t>The SRv6 Service SID allocated by an egress PE is not routed. The s ervice
route carrying the non-routed SRv6 Service SID is advertised by the eg ress PE route carrying the non-routed SRv6 Service SID is advertised by the eg ress PE
with a Color-EC C (<xref target="RFC9252"/> section 5). with a Color-EC C (<xref target="RFC9252" sectionFormat="comma" sectio n="5"/>).
An ingress PE in a remote domain steers traffic for the received servi ce route with An ingress PE in a remote domain steers traffic for the received servi ce route with
Color-EC C and this SRv6 Service SID as described below.</t> Color-EC C and this SRv6 Service SID as described below.</t>
<t>BGP CAR distribution of (E, C) underlay route: <t>BGP CAR distribution of (E, C) underlay route:
<list style="symbols"> </t>
<t>The intent-aware path to the egress PE within the egress domain is <ul spacing="normal">
<li>
<t>The intent-aware path to the egress PE within the egress domain
is
provided by an SR-TE or similar policy (E, C) <xref target="RFC9256"/> . provided by an SR-TE or similar policy (E, C) <xref target="RFC9256"/> .
This (E, C) policy is distributed into the multi-domain network from e gress BRs This (E, C) policy is distributed into the multi-domain network from e gress BRs
using a BGP CAR (E, C) route towards ingress PEs in other domains. using a BGP CAR (E, C) route towards ingress PEs in other domains.
This signaling is the same as for SR-MPLS as described in earlier sect ions.</t> This signaling is the same as for SR-MPLS as described in earlier sect ions.</t>
</li>
<t>The (E, C) BGP CAR Type-1 route is advertised from a BR with an <li>
<t>The (E, C) BGP CAR Type-1 route is advertised from a BR with an
SRv6 transport SID allocated from an SRv6 locator assigned for the int ent C. SRv6 transport SID allocated from an SRv6 locator assigned for the int ent C.
An SR-PCE or local configuration may ensure multiple BRs in the egress An SR-PCE or local configuration may ensure multiple BRs in the egress
domain that originate the (E, C) route advertise the same SRv6 transpo rt SID. domain that originate the (E, C) route advertise the same SRv6 transpo rt SID.
</t> </t>
</list> </li>
</t> </ul>
<t>BGP CAR distribution of SRv6 locator underlay route: <t>BGP CAR distribution of SRv6 locator underlay route:
<list style="symbols"> </t>
<t> <ul spacing="normal">
BGP CAR MAY also provide the underlay intent-aware inter-domain route <li>
to resolve <t>
BGP CAR <bcp14>MAY</bcp14> also provide the underlay intent-aware inte
r-domain route to resolve
the intent-aware SRv6 transport SID advertised with the (E, C) BGP CAR route as the intent-aware SRv6 transport SID advertised with the (E, C) BGP CAR route as
follows: follows:
<list> </t>
<t>An egress domain BR has a SRv6 locator prefix that covers the SRv6 t <ul spacing="normal">
ransport SID <li>
<t>An egress domain BR has an SRv6 locator prefix that covers
the SRv6 transport SID
allocated by the egress BR for the (E, C) BGP CAR route.</t> allocated by the egress BR for the (E, C) BGP CAR route.</t>
<t>The egress domain BR advertises an IP Prefix Type-2 CAR route for t </li>
he SRv6 <li>
<t>The egress domain BR advertises an IP Prefix Type-2 CAR rou
te for the SRv6
locator prefix, and the route is distributed across BGP hops in the un derlay locator prefix, and the route is distributed across BGP hops in the un derlay
towards ingress PEs. This distribution is the same as the previous towards ingress PEs. This distribution is the same as the previous cas
<xref target="SECRTDSSID"/> case. The route may also be summarized in e in
another <xref target="SECRTDSSID"/>. The route may also be summarized in anoth
CAR type-2 route prefix.</t> er
</list> CAR Type-2 route prefix.</t>
</t> </li>
</list> </ul>
</t> </li>
</ul>
<t>Service traffic steering and SRv6 transport SID resolution at ingre ss PE: <t>Service traffic steering and SRv6 transport SID resolution at ingre ss PE:
<list style="symbols"> </t>
<t>An ingress PE in a remote domain resolves the received service rout <ul spacing="normal">
e with Color C <li>
via the (E, C) BGP CAR route above, as described in <xref target="STEE <t>An ingress PE in a remote domain resolves the received
RING"/>.</t> service route with color C via the (E, C) BGP CAR route above,
<t>Additionally, the ingress PE resolves the SRv6 transport SID receiv as described in <xref target="STEERING"/>.</t>
ed in the </li>
BGP CAR (E, C) route via the BGP CAR IP Prefix route, similar to the <li>
SRv6 Routed Service SID resolution in <xref target="SECRTDSSID"/>. <t>Additionally, the ingress PE resolves the SRv6 transport SID
<list> received in the BGP CAR (E, C) route via the BGP CAR IP Prefix
<t>Multiple (E, C) routes may resolve via a single IP Prefix CAR route route, similar to the SRv6 Routed Service SID resolution in
. <xref target="SECRTDSSID"/>.
<list> </t>
<t>Resolution of (E, C) routes over IP Prefix CAR routes is the typica <ul spacing="normal">
l <li>
<t>Multiple (E, C) routes may resolve via a single IP Prefix C
AR route.
</t>
<ul spacing="normal">
<li>
<t>Resolution of (E, C) routes over IP Prefix CAR routes i
s the typical
resolution order as the IP Prefix route provides resolution order as the IP Prefix route provides
intent-aware reachability to the BRs that advertise the (E, C) specifi c intent-aware reachability to the BRs that advertise the (E, C) specifi c
routes for each egress PE. However, there can be use-cases where a IP Prefix routes for each egress PE. However, there can be use cases where an IP Prefix
CAR route may resolve via a (E, C) route.</t> CAR route may resolve via a (E, C) route.</t>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
</li>
<t>The ingress PE via the recursive resolution above builds the packet <li>
<t>The ingress PE via the recursive resolution above builds the pa
cket
encapsulation that contains the SRv6 Service SID and the received (E, C) encapsulation that contains the SRv6 Service SID and the received (E, C)
route's SRv6 transport SID in the SID-list. route's SRv6 transport SID in the SID list.
</t> </t>
</li>
</list> </ul>
</t>
<t><xref target="SECSRv6EC"/> contains an example that illustrates the control <t><xref target="SECSRv6EC"/> contains an example that illustrates the control
plane distribution, recursive resolution and forwarding behaviors desc ribed plane distribution, recursive resolution and forwarding behaviors desc ribed
above. above.
</t> </t>
<t>Note: An SR Policy may also be defined for multi-domain end to end
<t>Note: An SR-policy may also be defined for multi-domain end to end
<xref target="RFC9256"/>, independent of BGP CAR. In that case, both <xref target="RFC9256"/>, independent of BGP CAR. In that case, both
BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route
(<xref target="SECCARIllus"/>).</t> (<xref target="SECCARIllus"/>).</t>
</section> </section>
</section> </section>
<section anchor="SRv6DEPLT" <section anchor="SRv6DEPLT">
title="Deployment Options For CAR SRv6 Locator Reachability Distribution a <name>Deployment Options for CAR SRv6 Locator Reachability Distribution
nd Forwarding"> and Forwarding</name>
<t>Since an SRv6 locator (or summary) is an IPv6 prefix, it will be inst alled <t>Since an SRv6 locator (or summary) is an IPv6 prefix, it will be inst alled
into the IPv6 forwarding table on a BGP router (e.g., ABR or ASBR), for packet into the IPv6 forwarding table on a BGP router (e.g., ABR or ASBR) for p acket
forwarding. With the use of IPv6 locator prefixes, there is no need to a llocate and forwarding. With the use of IPv6 locator prefixes, there is no need to a llocate and
install per-PE SIDs on each BGP hop to forward packets.</t> install per-PE SIDs on each BGP hop to forward packets.</t>
<t> A few options to forward packets for BGP SRv6 prefixes described in <t> A few options to forward packets for BGP SRv6 prefixes described in
(<xref target="I-D.ietf-spring-srv6-mpls-interworking"/> <xref target="I-D.ietf-spring-srv6-mpls-interworking"/>
also apply to BGP CAR. These options are described in also apply to BGP CAR. These options are described in
<xref target="SRv6HBH"/> and <xref target="SRv6ENC"/>. </t> Sections <xref target="SRv6HBH" format="counter"/> and <xref target="SRv
<section anchor="SRv6HBH" title="Hop by Hop IPv6 Forwarding for BGP SRv6 6ENC" format="counter"/>. </t>
Prefixes"> <section anchor="SRv6HBH">
<t>This option employs hop by hop IPv6 lookup and forwarding on both <name>Hop-by-Hop IPv6 Forwarding for BGP SRv6 Prefixes</name>
BRs and P nodes <t>This option employs hop-by-hop IPv6 lookup and forwarding on both B
Rs and P nodes
in a domain along the path of propagation of BGP CAR routes. This op tion's in a domain along the path of propagation of BGP CAR routes. This op tion's
procedures include the following: procedures include the following:
<list style="symbols"> </t>
<t>In addition to BRs, P nodes within a domain also learn BGP CAR IP <ul spacing="normal">
Prefix routes (for SRv6) <li>
<t>In addition to BRs, P nodes within a domain also learn BGP CAR
IP Prefix routes (for SRv6)
and install them into the forwarding table. </t> and install them into the forwarding table. </t>
</li>
<t>BGP routing is enabled on all internal nodes (iBGP) using full-mes <li>
h or an RR.</t> <t>BGP routing is enabled on all internal nodes (iBGP) using full-
mesh or an RR.</t>
<t>BRs distribute external BGP SRv6 routes to internal peers includin </li>
g P routers, <li>
<t>BRs distribute external BGP SRv6 routes to internal peers inclu
ding P routers,
with the following conditions: with the following conditions:
<list style="symbols"> </t>
<t>The external BGP Next-hop is advertised unchanged to the internal <ul spacing="normal">
peers;</t> <li>
<t>Internal nodes use recursive resolution via IGP at each hop to fo <t>the external BGP next hop is advertised unchanged to the in
rward ternal peers;</t>
IPv6 packets towards the external BGP next-hop; and </t> </li>
<t>Resolution is per intent/color (e.g., via IGP IPv6 FlexAlgo).</t> <li>
</list> <t>internal nodes use recursive resolution via IGP at each
</t> hop to forward IPv6 packets towards the external BGP
</list> next hop; and </t>
</li>
<li>
<t>resolution is per intent/color (e.g., via IGP IPv6 Flex-Alg
o).</t>
</li>
</ul>
</li>
</ul>
<t>This design is illustrated with an example in <xref target="SECLOCH
BYH"/>.</t>
<t>The benefits of this scheme are:
</t> </t>
<ul spacing="normal">
<t>This design is illustrated with an example in <xref target="SECLO <li>
CHBYH"/>.</t> <t>A simpler design, as no tunnel encapsulation is required betwee
n BRs in a domain.</t>
<t>The benefits of this scheme are: </li>
<list style="symbols"> <li>
<t>Simpler design, no tunnel encapsulation is required between BRs
in a domain.</t>
<t>No per-PE SID allocation and installation on any BGP hop.</t> <t>No per-PE SID allocation and installation on any BGP hop.</t>
</li>
<t>This design is similar to the well-known Internet / BGP hop-by- <li>
hop IP routing model and <t>This design is similar to the well-known Internet / BGP
can support large scale route distribution.</t> hop-by-hop IP routing model and can support large-scale route
<t>In addition, since SRv6 locator prefixes can be summarized, this distribution.</t>
minimizes the number of routes and hence </li>
the scale requirements on P routers.</t> <li>
</list> <t>In addition, since SRv6 locator prefixes can be summarized,
</t> this minimizes the number of routes, and hence the scale
requirements on P routers.</t>
</li>
</ul>
</section> </section>
<section anchor="SRv6ENC" title="Encapsulation between BRs for BGP SRv6 <section anchor="SRv6ENC">
Prefixes"> <name>Encapsulation Between BRs for BGP SRv6 Prefixes</name>
<t>In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes <t>In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes ar
are only done on e only done on
BGP BRs. This option includes the following procedures: BGP BRs. This option includes the following procedures:</t>
<ul spacing="normal">
<list style="symbols"> <li>
<t> These nodes use SRv6 (or other) encapsulation to reach the BGP S <t>These nodes use SRv6 (or other) encapsulations to reach the BGP
Rv6 next hop. SRv6 next hop.
<list> </t>
<t> SRv6 outer encapsulation may be H.Encaps.Red.</t> <ul spacing="normal">
<t> Encapsulation is not needed for directly connected next h <li>
ops, such as with eBGP single-hop sessions.</t> <t>SRv6 outer encapsulation may be H.Encaps.Red.</t>
</list> </li>
</t> <li>
<t>BGP route distribution is enabled between BRs via RRs, or directl <t>Encapsulation is not needed for directly connected next hop
y if single-hop BGP.</t> s, such as with eBGP single-hop sessions.</t>
<t>An egress BR sets itself as BGP next hop, selects and advertises </li>
an appropriate </ul>
</li>
<li>
<t>BGP route distribution is enabled between BRs via RRs, or direc
tly if single-hop BGP.</t>
</li>
<li>
<t>An egress BR sets itself as BGP next hop, and selects and adver
tises an appropriate
encapsulation towards itself. encapsulation towards itself.
<list> </t>
<t>If SRv6 encapsulation, then SRv6 SID advertised from egress BR is <ul spacing="normal">
from an SRv6 <li>
<t>If SRv6 encapsulation, then the SRv6 SID advertised from eg
ress BR is from an SRv6
locator for the specific intent within the domain. locator for the specific intent within the domain.
Multiple BGP SRv6 prefixes may share a common SID, avoiding Multiple BGP SRv6 prefixes may share a common SID, avoiding
per-PE SID allocation and installation on any BGP hop.</t> per-PE SID allocation and installation on any BGP hop.</t>
<t>If MPLS/SR-MPLS transport, the route will carry label/prefix-SID </li>
allocated <li>
by the next hop, may be shared.</t> <t>If MPLS/SR-MPLS transport, the route will carry the label/P
</list> refix-SID allocated
</t> by the next hop. The label/SID may be shared among multiple routes.<
/t>
<t>An ingress BR encapsulates SRv6 egress PE destined packets with </li>
encapsulation to BGP next hop, ie. the egress BR. </t> </ul>
</list> </li>
</t> <li>
<t>An ingress BR encapsulates SRv6 egress PE destined packets with
<t>Benefits of this scheme are: encapsulation to BGP next hop (i.e., the egress BR).</t>
<list style="symbols"> </li>
<t>P nodes do not need to learn or install BGP SRv6 prefixes in this </ul>
(BGP-free core) design.</t> <t>The benefits of this scheme are:
<t>No per-PE SID allocation and installation on any BGP hop.</t>
</list>
</t> </t>
<t>This design is illustrated in <xref target="SECSRv6LOCencap"/>.</ <ul spacing="normal">
t> <li>
<t>P nodes do not need to learn or install BGP SRv6 prefixes in th
is (BGP-free core) design.</t>
</li>
<li>
<t>No per-PE SID allocation and installation on any BGP hop.</t>
</li>
</ul>
<t>This design is illustrated in <xref target="SECSRv6LOCencap"/>.</t>
</section> </section>
</section> </section>
<section anchor="SRv6CAROPER" <section anchor="SRv6CAROPER">
title="Operational Benefits of using CAR SAFI for SRv6 Locator Prefix Dist <name>Operational Benefits of Using CAR SAFI for SRv6 Locator Prefix Dis
ribution"> tribution</name>
<t>When reachability to an SRv6 SID is provided by distribution of a locat <t>When reachability to an SRv6 SID is provided by distribution of a loc
or prefix ator prefix
via underlay routing, BGP IPv6 SAFI (AFI/SAFI=2/1) may also be used for via underlay routing, BGP IPv6 SAFI (AFI/SAFI=2/1) may also be used for
inter-domain distribution of these IPv6 prefixes as described in inter-domain distribution of these IPv6 prefixes as described in
<xref target="I-D.ietf-spring-srv6-mpls-interworking"/> (Section 7.1.2) or <xref target="I-D.ietf-spring-srv6-mpls-interworking" sectionFormat="of" s
<xref target="I-D.ietf-idr-cpr"/>.</t> ection="7.1.2"/> or
<t>Using the BGP CAR SAFI provides the following operational benefits: <xref target="RFC9723"/>.</t>
<list style="symbols"> <t>Using the BGP CAR SAFI provides the following operational benefits:
<t>CAR SAFI is a separate BGP SAFI used for underlay transport intent-aw </t>
are routing. <ul spacing="normal">
<li>
<t>CAR SAFI is a separate BGP SAFI used for underlay transport inten
t-aware routing.
It avoids overloading of BGP IPv6 SAFI, which also carries Internet (ser vice) It avoids overloading of BGP IPv6 SAFI, which also carries Internet (ser vice)
prefixes. Using CAR SAFI provides: prefixes. Using CAR SAFI provides:
<list style="symbols"> </t>
<t>Automatic separation of SRv6 locator (transport) routes from Intern <ul spacing="normal">
et <li>
<t>Automatic separation of SRv6 locator (transport) routes from
Internet
(service) routes, (service) routes,
<list> </t>
<t>Preventing inadvertent leaking of routes.</t> <ul spacing="normal">
<t>Avoiding need to configure specific route filters for locator rout <li>
es.</t> <t>preventing inadvertent leaking of routes, and</t>
</list> </li>
</t> <li>
<t>Priority handling of infrastructure routes over service (Internet) <t>avoiding the need to configure specific route filters for
routes.</t> locator routes.</t>
</list> </li>
</t> </ul>
<t>CAR SAFI also supports inter-domain distribution of (E, C) routes </li>
sourced from SR-Policy, in addition to SRv6 locator IPv6 prefixes.</t> <li>
<t>CAR SAFI may also be used for best-effort routes in addition to intent- <t>Priority handling of infrastructure routes over service (Inte
aware rnet) routes.</t>
routes as described in the next section.</t> </li>
</list> </ul>
</t> </li>
<li>
<t>Note: If infrastructure routes such as SRv6 locator routes are carried <t>CAR SAFI also supports inter-domain distribution of (E, C) routes
in sourced from SR Policy, in addition to SRv6 locator IPv6 prefixes.</t>
both BGP-IP [RFC4271] / BGP-LU [RFC8277, RFC4798], and BGP CAR, <xref targ </li>
et="CARIPPREFIX"/> describes <li>
the path selection preference between them.</t> <t>CAR SAFI may also be used for best-effort routes in addition to
intent-aware routes as described in the next section.</t>
</li>
</ul>
<t>Note: If infrastructure routes such as SRv6 locator routes are
carried in both BGP-IP <xref target="RFC4271"/> / BGP-LU <xref
target="RFC8277"/> <xref target="RFC4798"/>, and BGP CAR, <xref
target="CARIPPREFIX"/> describes the path selection preference between
them.</t>
</section> </section>
</section> </section>
<section anchor="CARIPPREFIX">
<section anchor="CARIPPREFIX" title="CAR IP Prefix Route"> <name>CAR IP Prefix Route</name>
<t> <t>An IP Prefix CAR route is a route type (Type-2) that carries a
An IP Prefix CAR route is a route type (Type-2) that carries a routable IP prefi routable IP prefix whose processing follows the semantics of <xref target=
x whose processing follows [RFC4271] and [RFC2545] semantics. IP Prefix CAR rout "RFC4271"/> and
es are installed in the default routing and forwarding table and provide longest <xref target="RFC2545"/>. IP Prefix CAR routes are installed
-prefix-match forwarding. This is unlike Type-1 (E, C) routes, where it is the s in the default routing and forwarding table and provide
ignaled forwarding data such as labels/SIDs that are installed in the forwarding longest-prefix-match forwarding. This is unlike Type-1 (E, C) routes,
table to create end to end paths.</t> where it is the signaled forwarding data such as labels/SIDs that are
installed in the forwarding table to create end-to-end paths.</t>
<t> <t>IP Prefix CAR routes may be originated into BGP CAR SAFI either from
IP Prefix CAR routes may be originated into BGP CAR SAFI either from an egress P an egress PE or from a BR in a domain. Type-2 routes carry
E or from a BR in a domain. Type-2 routes carry infrastructure routes for both I infrastructure routes for both IPv4 and IPv6.</t>
Pv4 and IPv6.
</t>
<t>As described in <xref target="SECDATAMODEL"/>, it is used for cases <t>As described in <xref target="SECDATAMODEL"/>, it is used for cases
where a unique routable IP prefix is assigned for a given intent or color. where a unique routable IP prefix is assigned for a given intent or
It may also be used for routes providing best-effort connectivity.</t> color. It may also be used for routes providing best-effort
connectivity.</t>
<t>A few applicable example use-cases: <t>A few applicable example use cases:</t>
<list style="symbols"> <ul spacing="normal">
<t>SRv6 locator prefix with color for specific intents.</t> <li>
<t>SRv6 locator prefix without color for best-effort.</t> <t>SRv6 locator prefix with color for specific intents.</t>
<t>Best effort transport reachability to a PE/BR without color.</t> </li>
</list> <li>
</t> <t>SRv6 locator prefix without color for best-effort.</t>
</li>
<li>
<t>Best-effort transport reachability to a PE/BR without color.</t>
</li>
</ul>
<t> <t>
For specific intents, color may be signaled with the IP Prefix CAR route for pur For specific intents, color may be signaled with the IP Prefix CAR
poses such as intent-aware SRv6 SID or BGP next-hop selection at each transit BR route for purposes such as intent-aware SRv6 SID or BGP next hop
, color based routing policies and filtering, and intent-aware next-hop resoluti selection at each transit BR, color-based routing policies and
on (<xref target="ROUTERES"/>). These purposes are the same as with (E, C) route filtering, and intent-aware next-hop resolution (<xref
s. For such purposes, color associated with the CAR IP Prefix route is signaled target="ROUTERES"/>). These purposes are the same as with (E, C)
using LCM-EC. routes. For such purposes, color associated with the CAR IP Prefix
route is signaled using LCM-EC.
</t> </t>
<t> <t>
Reminder: LCM-EC conveys end-to-end intent/color associated with route/NLRI. Whe Reminder: LCM-EC conveys end-to-end intent/color associated with
n traversing network domain(s) where a different intent/color is used for next-h route/NLRI. When traversing network domain(s) where a different
op resolution, BGP Color-EC may additionally be used as in intent/color is used for next-hop resolution, BGP Color-EC may
<xref target="LCMBGPECUSAGE"/>.</t> additionally be used as in <xref target="LCMBGPECUSAGE"/>.</t>
<t> <t>
A special case of intent is best-effort which may be represented by a color and A special case of intent is best-effort, which may be represented by a
follow above procedures. But to be compatible with traditional operational usage color and follow the above procedures. However, to be compatible with
, CAR IP Prefix route is allowed to be without color for best-effort. In this ca existing operational usage, the CAR IP Prefix route is allowed to be
se, the routes will not carry an LCM-EC. Resolution is described in <xref target without color for best-effort. In this case, the routes will not carry
="ROUTERES"/>.</t> an LCM-EC. Resolution is described in <xref target="ROUTERES"/>.</t>
<t> <t>
As described in <xref target="SRv6CAROPER"/>, infrastructure prefixes are intend As described in <xref target="SRv6CAROPER"/>, infrastructure prefixes
ed to be carried in CAR SAFI instead of SAFIs that also carry service routes suc are intended to be carried in CAR SAFI instead of SAFIs that also
h as BGP-IP (SAFI 1, [RFC4271]) and BGP-LU (SAFI 4, <xref target="RFC4798"/>). H carry service routes such as BGP-IP (SAFI 1, <xref target="RFC4271"/>)
owever, if such infrastructure routes are also distributed in these SAFIs, a rou and BGP-LU (SAFI 4, <xref target="RFC4798"/>). However, if such
ter may receive both BGP CAR SAFI paths and IP/LU SAFI paths. By default, CAR SA infrastructure routes are also distributed in these SAFIs, a router
FI transport path is preferred over BGP IP or BGP-LU SAFI path. may receive both BGP CAR SAFI paths and IP/LU SAFI paths. By default, the
CAR SAFI transport path is preferred over the BGP-IP or BGP-LU SAFI path.
</t> </t>
<t>A BGP transport CAR speaker that supports packet forwarding lookup base
<t>A BGP transport CAR speaker that supports packet forwarding lookup base d on the
d on
IPv6 prefix route (such as a BR) will set itself as next hop while adverti sing the IPv6 prefix route (such as a BR) will set itself as next hop while adverti sing the
route to peers. It will also install the IPv6 route into forwarding with t he route to peers. It will also install the IPv6 route into forwarding with t he
received next hop and/or encapsulation. If such a transit router does not support received next hop and/or encapsulation. If such a transit router does not support
this route type, it will not install this route and will not set itself as this route type, it will not install this route and will not set itself as
next hop, next hop;
hence will not propagate the route any further. hence, it will not propagate the route any further.
</t> </t>
</section> </section>
<section>
<name>VPN CAR</name>
<t>This section illustrates the extension of BGP CAR to address the VPN
intent-aware routing requirement stated in <xref
target="I-D.hr-spring-intentaware-routing-using-color"
sectionFormat="of" section="6.1.2"/>. The examples use MPLS, but other
transport types can also be used (e.g., SRv6).</t>
<section title="VPN CAR"> <artwork><![CDATA[
<t>This section illustrates the extension of BGP CAR to address the VPN in CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V
tent-aware routing ]]></artwork>
requirement stated in Section 6.1.2 of
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>. The exampl
es use
MPLS, but other transport types can also be used (e.g., SRv6). </t>
<figure> <ul spacing="normal">
<artwork><![CDATA[ <li>
<t>BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions.</t>
</li>
<li>
<t>BGP VPN CAR SAFI is enabled between PE1 and PE2.</t>
</li>
<li>
<t>Provider publishes to customer that intent "low delay" is mapped to
color CP ("Provider Color") on its
inbound peering links.</t>
</li>
<li>
<t>Within its infrastructure, provider maps intent "low delay" to colo
r CPT ("Provider Transport Color").</t>
</li>
<li>
<t>On CE1 and CE2, intent "low delay" is mapped to CC ("Customer Color
").</t>
</li>
</ul>
<t>(V, CC) is a color-aware route originated by CE2.</t>
<ol>
<li>
<t>CE2 sends to PE2:</t>
<t indent="3">[(V, CC), label L1] via CE2 with LCM-EC (CP) as per peering ag
reement.</t></li>
CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V <li>
<t>PE2 installs in VRF A:</t>
<t indent="3">[(V, CC), L1] via CE2, which resolves on (CE2, CP) or connecte
d Outgoing Interface (OIF).</t></li>
]]></artwork> <li>PE2 allocates VPN label L2 and programs swap entry for (V, CC).</li>
</figure>
<t>
<list style="symbols">
<t>BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions</t>
<t>BGP VPN CAR SAFI is enabled between PE1 and PE2</t>
<t>Provider publishes to customer that intent 'low-delay' is mapped to c
olor CP on its
inbound peering links</t>
<t>Within its infrastructure, Provider maps intent 'low-delay' to color
CPT</t>
<t>On CE1 and CE2, intent 'low-delay' is mapped to CC</t>
</list>
</t>
<t>(V, CC) is a Color-Aware route originated by CE2</t> <li>
<figure> <t>PE2 sends to PE1:</t>
<artwork><![CDATA[ <t indent="3">[(RD, V, CC), L2] via PE2, LCM-EC (CP) with regular Color-EC (
1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with LCM-EC (CP) CPT).</t>
as per peering agreement </li>
2. PE2 installs in VRF A: [(V, CC), L1] via CE2
which resolves on (CE2, CP) <li>
or connected OIF <t>PE1 installs in VRF A:</t>
3 PE2 allocates VPN Label L2 and programs swap entry for (V, CC) <t indent="3">[(V, CC), L2] via (PE2, CPT) steered on (PE2, CPT).</t>
4. PE2 sends to PE1 : [(RD, V, CC), L2] via PE2, LCM-EC(CP) </li>
with regular Color-EC (CPT)
5. PE1 installs in VRF A: [(V, CC), L2] via (PE2, CPT) <li>PE1 allocates label L3 and programs swap entry for (V, CC).</li>
steered on (PE2, CPT)
6. PE1 allocates Label L3 and programs swap entry for (V, CC) <li>
7. PE1 sends to CE1 : [(V, CC), L3] via PE1 <t>PE1 sends to CE1:</t>
after removing LCM-EC through route-policy <t indent="3">[(V, CC), L3] via PE1 after removing LCM-EC through route poli
8. CE1 installs : [(V, CC), L3] via PE1 cy.</t>
which resolves on (PE1, CC) </li>
or connected OIF
9. Label L3 is installed as the imposition label for (V, CC) <li>
]]></artwork> <t>CE1 installs:</t>
</figure> <t indent="3">[(V, CC), L3] via PE1, which resolves on (PE1, CC) or connecte
<t>VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows d OIF.</t>
</li>
<li>Label L3 is installed as the imposition label for (V, CC).</li>
</ol>
<t>VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows t
he
same VPN semantics as defined in <xref target="RFC4364"/> and also support s the same VPN semantics as defined in <xref target="RFC4364"/> and also support s the
distribution of routes with the CAR NLRI and associated non-key TLVs defin ed in distribution of routes with the CAR NLRI and associated non-key TLVs defin ed in
<xref target="ColorFamily"/> of this document. </t> <xref target="ColorFamily"/> of this document. </t>
<t>Procedures defined in <xref target="RFC4364"/> and <xref target="RFC465 9"/> apply to <t>Procedures defined in <xref target="RFC4364"/> and <xref target="RFC465 9"/> apply to
VPN CAR SAFI. VPN CAR SAFI.
Further, all CAR SAFI procedures described in <xref target="CARSAFI"/> abo ve apply to Further, all CAR SAFI procedures described in <xref target="CARSAFI"/> abo ve apply to
CAR SAFI enabled within a VRF. Since CE and PE are typically in different administrative CAR SAFI enabled within a VRF. Since CE and PE are typically in different administrative
domains, LCM-EC is attached to CAR routes.</t> domains, LCM-EC is attached to CAR routes.</t>
<t>VPN CAR SAFI routes follow color-based steering techniques as described
<t>VPN CAR SAFI routes follow color based steering techniques as described in
in <xref target="STEERING"/> and illustrated in the example above.</t>
<xref target="STEERING"/> and illustrated in example above.</t>
<t>VPN CAR SAFI routes may also be advertised with a specific BGP next hop per color, <t>VPN CAR SAFI routes may also be advertised with a specific BGP next hop per color,
with a TEA or Tunnel Encapsulation EC and follow the procedures of [RFC901 with a TEA or Tunnel Encapsulation EC, and follow the procedures of <xref
2] target="RFC9012" sectionFormat="of" section="6"/>.</t>
Section 6.</t>
<t>CAR routes distributed in VPN CAR SAFI are infrastructure routes advert ised by <t>CAR routes distributed in VPN CAR SAFI are infrastructure routes advert ised by
CEs in different customer VRFs on a PE. Example use-cases are intent-aware CEs in different customer VRFs on a PE. Example use cases are intent-aware
L3VPN CsC (<xref target="RFC4364"/> Section 9) and SRv6 over a provider L3VPN Carriers' Carriers (<xref target="RFC4364" sectionFormat="of" sectio
network . The VPN RD distinguishes CAR routes of different customers bein n="9"/>) and SRv6 over a provider
g network. The VPN RD distinguishes CAR routes of different customers being
advertised by the PE.</t> advertised by the PE.</t>
<section anchor="VPNColorFamily">
<section anchor="VPNColorFamily" title="Format and Encoding"> <name>Format and Encoding</name>
<t>BGP VPN CAR SAFI leverages BGP multi-protocol extensions [RFC4760] and <t>BGP VPN CAR SAFI leverages BGP multiprotocol extensions <xref
uses the MP_REACH_NLRI and MP_UNREACH_NLRI attributes for route target="RFC4760"/> and uses the MP_REACH_NLRI and MP_UNREACH_NLRI
updates within SAFI value 84 along with AFI 1 for IPv4 VPN CAR prefixes attributes for route updates within SAFI value 84 along with AFI 1 for
and AFI 2 for IPv6 VPN CAR prefixes.</t> IPv4 VPN CAR prefixes and AFI 2 for IPv6 VPN CAR prefixes.</t>
<t>BGP speakers <bcp14>MUST</bcp14> use the BGP Capabilities Advertiseme
<t>BGP speakers MUST use BGP Capabilities Advertisement to ensure nt
support for processing of BGP VPN CAR updates. This is done as specified to ensure support for processing of BGP VPN CAR updates. This is done
in [RFC4760], by using capability code 1 (multi-protocol BGP), with as specified in <xref target="RFC4760"/>, by using capability code 1
AFI 1 and 2 (as required) and SAFI 84.</t> (multiprotocol BGP), with AFI 1 and 2 (as required) and SAFI 84.</t>
<t>The Next Hop network address field in the MP_REACH_NLRI may contain
<t>The Next Hop network address field in the MP_REACH_NLRI may contain either either a VPN-IPv4 or a VPN-IPv6 address with 8-octet RD set to zero,
a VPN-IPv4 independent of AFI. If the next hop length is 12, then the next hop is
or a VPN-IPv6 address with 8-octet RD set to zero, independent of AFI. If a VPN-IPv4 address with an RD of 0 constructed as per <xref
the next hop length is 12, then the next hop is a VPN-IPv4 address wit target="RFC4364"/>. If the next hop length is 24 or 48, then the next
h an RD of 0 hop is a VPN-IPv6 address constructed as per <xref target="RFC4659"
constructed as per [RFC4364]. If the next hop length is 24 or 48, then the ne sectionFormat="of" section="3.2.1.1"/>.</t>
xt hop <section anchor="VPNCARNLRITYPE1">
is a VPN-IPv6 address constructed as per section 3.2.1.1 of [RFC4659].</t> <name>VPN CAR (E, C) NLRI Type</name>
<t>VPN CAR Type-1 (E, C) NLRI with RD has the format shown below:</t>
<section anchor="VPNCARNLRITYPE1" title="VPN CAR (E, C) NLRI Type"> <artwork align="left"><![CDATA[
<t>VPN CAR Type-1 (E, C) NLRI with RD has the format shown below</t> 0 1 2 3
<figure align="center">
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2245 skipping to change at line 2527
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (4 octets) | | Color (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>It is followed by optional Non-Key TLVs encoded as per <xref target
="NLRITLVs"/>.</t>
<t>Followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t <t>where:</t>
> <t>all fields are encoded as per <xref target="NLRITYPE1"/> with the f
<t>where:</t> ollowing changes:</t>
<t>All fields are encoded as per <xref target="NLRITYPE1"/> with the <dl spacing="normal" newline="false">
following changes:</t> <dt>Key Length:</dt><dd>This length indicates the total length compr
<list style="symbols"> ised of the
<t>Key Length: This length indicates the total length comprised of t RD, Prefix Length field, IP Prefix field, and the Color field.</dd>
he <dt>Route Distinguisher:</dt><dd>An 8-octet field encoded
RD, Prefix Length field, IP Prefix field, and the Color field.</t> according to <xref target="RFC4364"/>.</dd>
<dt>Type-Specific Non-Key TLVs:</dt><dd>The Label TLV, Label-Index T
<t>Route Distinguisher: An 8-octet field encoded according to <xref LV,
target="RFC4364"/>. and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
</t> with the VPN CAR (E, C) NLRI Type.</dd>
<t>Type-Specific Non-Key TLVs: Label TLV, Label Index TLV and SRv6 S </dl>
ID TLV (<xref target="NLRITLVs"/>) </section>
may be associated with the VPN CAR (E, C) NLRI type.</t> <section anchor="VPNCARNLRITYPE2">
</list> <name>VPN CAR IP Prefix NLRI Type</name>
</section> <artwork align="left"><![CDATA[
<section anchor="VPNCARNLRITYPE2" 0 1 2 3
title="VPN CAR IP Prefix NLRI Type">
<figure align="center">
<artwork align="left"><![CDATA[ 0 1
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2276 skipping to change at line 2555
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Length | Key Length | NLRI Type |Prefix Length | | NLRI Length | Key Length | NLRI Type |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix (variable) // | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>It is followed by optional Non-Key TLVs encoded as per <xref target
="NLRITLVs"/>.</t>
<t>Followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t <t>where:</t>
> <t>all fields are encoded as per <xref target="NLRITYPE2"/> with the f
<t>where:</t> ollowing changes:</t>
<t>All fields are encoded as per <xref target="NLRITYPE2"/> with the <dl spacing="normal" newline="false">
following changes:</t> <dt>Key Length:</dt><dd>This length indicates the total length compr
<list style="symbols"> ised of the
<t>Key Length: This length indicates the total length comprised of t RD, Prefix Length field, and IP Prefix field.</dd>
he <dt>Route Distinguisher:</dt><dd>An 8-octet field encoded according
RD, Prefix Length field and IP Prefix field.</t> to <xref target="RFC4364"/>.</dd>
<t>Route Distinguisher: 8 octet field encoded according to <xref tar <dt>Type-Specific Non-Key TLVs:</dt><dd>The Label TLV, Label-Index T
get="RFC4364"/>. LV,
</t> and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
<t>Type-Specific Non-Key TLVs: Label TLV, Label Index TLV and SRv6 S with the VPN CAR IP Prefix NLRI Type.</dd>
ID TLV (<xref target="NLRITLVs"/>) </dl>
may be associated with the VPN CAR IP Prefix NLRI type.</t> <t>The error handling specified in <xref target="Fault"/> also applies
</list> to VPN CAR SAFI.</t>
<t>Error handling specified in <xref target="Fault"/> also applies to VPN </section>
CAR SAFI.</t>
</section>
</section> </section>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="BGP CAR SAFIs"> <section>
<t>IANA has assigned SAFI value 83 (BGP CAR) and SAFI value <name>BGP CAR SAFIs</name>
84 (BGP VPN CAR) from the "SAFI Values" sub-registry under the "Subsequent <t>IANA has assigned SAFI value 83 (BGP CAR) and SAFI value
Address Family Identifiers (SAFI) Parameters" registry with this document 84 (BGP VPN CAR) from the "SAFI Values" registry in the "Subsequent
as a Address Family Identifiers (SAFI) Parameters" registry group with this doc
ument as a
reference.</t> reference.</t>
</section> </section>
<section anchor="NLRITYPESREG">
<section anchor="NLRITYPESREG" <name>"BGP CAR NLRI Types" Registry</name>
title="BGP CAR NLRI Types Registry"> <t>IANA has created a "BGP CAR NLRI Types"
<t>IANA is requested to create a "BGP CAR NLRI Types"
registry in the "Border Gateway Protocol (BGP) Parameters" registry in the "Border Gateway Protocol (BGP) Parameters"
registry group with this document as a reference. The registry is for registry group with this document as a reference. The registry is for
assignment of the one octet sized code-points for BGP CAR NLRI types assignment of the 1-octet code points for BGP CAR NLRI types
and populated with the values shown below:</t> and is populated with the values shown below:</t>
<figure align="center">
<artwork align="center"><![CDATA[ Type NLRI Type
Reference
0 Reserved [This document]
1 Color-Aware Route NLRI [This document]
2 IP Prefix NLRI [This document]
3-255 Unassigned
]]></artwork>
</figure>
<t>Allocations within the registry are to be made under the <table>
"Specification Required" policy as specified in <xref <thead>
target="RFC8126"/>) and in <xref target="DE-Guidance"/>.</t> <tr><th>Type</th><th>NLRI Type</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0</td><td>Reserved</td><td>RFC 9871</td></tr>
<tr><td>1</td><td>Color-Aware Route NLRI</td><td>RFC 9871</td></tr>
<tr><td>2</td><td>IP Prefix NLRI</td><td>RFC 9871</td></tr>
<tr><td>3-255</td><td colspan="2">Unassigned</td></tr>
</tbody>
</table>
<t>Allocations within the registry are to be made with the
"Specification Required" policy as specified in <xref target="RFC8126"/>
and in <xref target="DE-Guidance"/>.</t>
</section> </section>
<section anchor="TLVTYPESREG">
<section anchor="TLVTYPESREG" <name>"BGP CAR NLRI TLV" Registry</name>
title="BGP CAR NLRI TLV Registry"> <t>IANA has created a "BGP CAR NLRI TLV Types"
<t>IANA is requested to create a "BGP CAR NLRI TLV Types"
registry in the "Border Gateway Protocol (BGP) Parameters" registry in the "Border Gateway Protocol (BGP) Parameters"
registry group with this document as a reference. The registry is for registry group with this document as a reference. The registry is for
assignment of the 6-bits sized code-points for BGP CAR NLRI non-key assignment of the 6-bit code points for BGP CAR NLRI non-key
TLV types and populated with the values shown below:</t> TLV types and is populated with the values shown below:</t>
<figure align="center">
<artwork align="center"><![CDATA[ Type NLRI TLV Type
Reference
0 Reserved [This document]
1 Label TLV [This document]
2 Label Index TLV [This document]
3 SRv6 SID TLV [This document]
4-64 Unassigned
]]></artwork>
</figure>
<t>Allocations within the registry are to be made under the
"Specification Required" policy as specified in <xref
target="RFC8126"/>) and in <xref target="DE-Guidance"/>.</t>
<t>For a new TLV to be used with existing NLRI Types, documentation of t <table>
he NLRI Types <thead>
<tr><th>Type</th><th>NLRI TLV Type</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0</td><td>Reserved</td><td>RFC 9871</td></tr>
<tr><td>1</td><td>Label TLV</td><td>RFC 9871</td></tr>
<tr><td>2</td><td>Label-Index TLV</td><td>RFC 9871</td></tr>
<tr><td>3</td><td>SRv6 SID TLV</td><td>RFC 9871</td></tr>
<tr><td>4-64</td><td colspan="2">Unassigned</td></tr>
</tbody>
</table>
<t>Allocations within the registry are to be made with the
"Specification Required" policy as specified in <xref target="RFC8126"/>
and in <xref target="DE-Guidance"/>.</t>
<t>For a new TLV to be used with existing NLRI types, documentation of t
he NLRI types
must be updated.</t> must be updated.</t>
</section> </section>
<section anchor="DE-Guidance">
<section anchor="DE-Guidance" title="Guidance for Designated Experts"> <name>Guidance for Designated Experts</name>
<t>In all cases of review by the Designated Expert (DE) described <t>In all cases of review by the Designated Expert (DE) described
here, the DE is expected to ascertain the existence of suitable here, the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in <xref documentation (a specification) as described in <xref
target="RFC8126"/> for BGP CAR NLRI Types Registry and BGP CAR NLRI TLV target="RFC8126"/> for the "BGP CAR NLRI Types" registry and the "BGP CA
Registry. R NLRI
TLV" registry.
</t> </t>
<t> <t>The DE is also expected to check the clarity of purpose and use of
The DE is also expected to check the clarity of the requested code points. Additionally, the DE must verify that any
purpose and use of the requested code points. Additionally, the DE request for one of these code points has been made available for
must verify that any request for one of these code points has been review and comment within the IETF: the DE will post the request to
made available for review and comment within the IETF: the DE will the IDR Working Group mailing list (or a successor mailing list
post the request to the IDR Working Group mailing list (or a successor designated by the IESG). The DE must ensure that any request for a
mailing list designated by the IESG). The DE must ensure that any reques code point does not conflict with work that is active or already
t for a published within the IETF.</t>
code point does not conflict with work that is active or already publish <t>The DE is expected to confirm that the specification satisfies the
ed within requirements for the "Specification Required" policy (<xref
the IETF.</t> target="RFC8126" sectionFormat="of" section="4.6"/>). In particular,
as a reminder, the specification is required to be "permanent and
<t>The DE is expected to confirm that the specification satisfies the re readily available". The DE may assume that any document in the
quirements Internet-Draft or RFC repository satisfies the requirement for
for Specification Required (RFC 8126 Section 4.6). In particular, as a r permanence and availability. In other cases, and in particular for any
eminder, document not hosted by another standards development organization, the
the specification is required to be "permanent and readily available". T burden of proof of permanence falls on the applicant.
he DE may
assume that any document in the Internet Draft or RFC repository satisfi
es the
requirement for permanence and availability. In other cases, and in part
icular for
any document not hosted by another standards development organization, t
he burden of
proof of permanence falls on the applicant.
</t> </t>
<section>
<section title="Additional evaluation criteria for the BGP CAR NLRI Type <name>Additional Evaluation Criteria for the "BGP CAR NLRI Types" Regi
s Registry"> stry</name>
<list style="symbols"> <ul spacing="normal">
<t>Check the interoperability between new NLRI type and current NLRI t <li>
ypes <t>Check the interoperability between the new NLRI type and
specified in this document for BGP CAR SAFIs (BGP CAR SAFI and VPN CAR current NLRI types specified in this document for BGP CAR SAFIs
SAFI), (BGP CAR SAFI and VPN CAR SAFI), and any updates to this
and any updates to this document.</t> document.</t>
<t>Check if specification indicates which non-key TLVs are applicable </li>
for <li>
the new NLRI Type.</t> <t>Check if the specification indicates which non-key TLVs are
</list> applicable for the new NLRI type.</t>
</li>
</ul>
</section> </section>
<section>
<section title="Additional evaluation criteria for the BGP CAR NLRI TLV <name>Additional Evaluation Criteria for the "BGP CAR NLRI TLV" Regist
Registry"> ry</name>
<list style="symbols"> <ul spacing="normal">
<t>Check the applicability of new TLV for the BGP CAR NLRI Types defin <li>
ed.</t> <t>Check the applicability of the new TLV for the BGP CAR NLRI typ
<t>Check the T bit setting for the new TLV</t> es defined.</t>
</list> </li>
<li>
<t>Check the T bit setting for the new TLV.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="PROTOIDREG">
<section anchor="PROTOIDREG" title="BGP Extended-Community Registry"> <name>"Border Gateway Protocol (BGP) Extended Communities" Registry</nam
e>
<t>IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)" <t>IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)"
in the "Transitive Opaque Extended Community Sub-Types" registry located in the in the "Transitive Opaque Extended Community Sub-Types" registry in the
"Border Gateway Protocol (BGP) Extended Communities" registry group.</t> "Border Gateway Protocol (BGP) Extended Communities" registry group.</t>
</section> </section>
</section> </section>
<section anchor="MANAGEOPER">
<section anchor="MANAGEOPER" title="Manageability and Operational Considerat <name>Manageability and Operational Considerations</name>
ions"> <t>Color assignments in a multi-domain network operating under a common
<t>Color assignments in a multi-domain network operating under a common or or cooperating administrative control (i.e., a color domain) should be
cooperating administrative control (i.e., a color domain) should be man managed similar to transport layer IP addresses, and ensure a unique and
aged non-conflicting color allocation across the different network domains in
similar to transport layer IP addresses, and ensure a unique and that color domain. This is a logical best practice in a single color or
non-conflicting color allocation across the different network domains i administrative domain, which is the most typical deployment
n scenario.</t>
that color domain. This is a logical best practice in a single color or <t>When color-aware routes propagate across a color domain boundary,
administrative domain, which is the most typical deployment scenario.< there is typically no need for color assignments to be identical in both
/t> color domains, since the IP prefix is unique in the inter-domain
transport network. This unique IP prefix provides a unique and
<t>When color-aware routes propagate across a color domain boundary, th non-conflicting scope for the color in an (E, C) route. Coordination
ere between the operators of the color domains is needed only to enable the
is typically no need for color assignments to be identical in both colo color to be re-mapped into a local color (carried in the LCM-EC)
r domains, assigned for the same intent in the receiving color domain.</t>
since the IP prefix is unique in the inter-domain transport network. T <t>However, if networks under different administrative control establish
his unique a shared transport service between them, where the same transport
IP prefix provides a unique and non-conflicting scope for the color in service IP address is coordinated and shared among two (or more) color
an (E, C) domain networks, then the color assignments associated with that shared
route. Co-ordination between the operators of the color domains is nee IP address should also be coordinated to avoid any conflicts in either
ded only network (<xref target="SHAREDIP"/>).</t>
to enable the color to be re-mapped into a local color (carried in the <t>It should be noted that the color assignments coordination is only
LCM-EC) necessary for routes specific to the shared service IP. Colors used for
assigned for the same intent in the receiving color domain.</t> intra-domain or for inter-domain intents associated with unique IP
addresses do not need any coordination.
<t>However, if networks under different administrative control establis </t>
h a <t>Extended communities (LCM-EC/Color-EC) carried in BGP CAR and service
shared transport service between them, where the same transport routes <bcp14>MUST NOT</bcp14> be filtered, otherwise the desired intent
service IP address is co-ordinated and shared among two (or more) col will not be achieved.
or </t>
domains networks, then the color assignments associated with that sha
red IP
address should also be co-ordinated to avoid any conflicts in either
network (<xref target="SHAREDIP"/>).</t>
<t>It should be noted that the color assignments coordination are only
necessary
for routes specific to the shared service IP. Colors used for intra-do
main or for
inter-domain intents associated with unique IP addresses do not need
any coordination.
</t>
<t>Extended communities (LCM-EC/Color-EC) carried in BGP CAR and Servi
ce routes
MUST NOT be filtered, otherwise the desired intent will not be achiev
ed.
</t>
</section> </section>
<section anchor="SecurityConsiderations">
<section anchor="SecurityConsiderations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document does not change the underlying security considerations
<t>This document does not change the underlying security considerations and and issues inherent in the existing BGP protocol, such as those
issues inherent in the described in <xref target="RFC4271"/> and <xref target="RFC4272"/>.</t>
existing BGP protocol, such as those described in <xref target="RFC4271"/> a <t>This document defines a new BGP SAFI and related extensions to carry
nd <xref target="RFC4272"/>.</t> color-aware routes and their associated attributes. The separate SAFI is
expected to be explicitly configured by an operator. It is also expected
<t>This document defines a new BGP SAFI and related extensions to carry colo that the necessary BGP route policy filtering is configured on this new
r SAFI to filter routing information distributed by the routers
aware routes and their associated attributes. The separate SAFI is expected participating in this network, at appropriate points within and at the
to be boundaries of this network.</t>
explicitly configured by an operator. It is also expected that the necessary <t>Also, given that this SAFI and these mechanisms can only be enabled
BGP route policy filtering through configuration of routers within an operator's network, standard
is configured on this new SAFI to filter routing information distributed by security measures should be taken to restrict access to the management
the routers participating in interface(s) of routers that implement these mechanisms.
this network, at appropriate points within and at the boundaries of this net </t>
work.</t> <t>Additionally, BGP sessions <bcp14>SHOULD</bcp14> be protected using the
TCP Authentication Option <xref target="RFC5925"/> and the Generalized
<t>Also, given that this SAFI and these mechanisms can only be enabled throu TTL Security Mechanism <xref target="RFC5082"/>. BGP origin validation
gh <xref target="RFC6811"/> and BGPsec <xref target="RFC8205"/> could also
configuration of routers within an operator's network, standard security mea be used with this SAFI.</t>
sures should <t>Since CAR SAFI is a separate BGP SAFI that carries transport or
be taken to restrict access to the management interface(s) of routers that infrastructure routes for routers in the operator network, it provides
implement these mechanisms. automatic separation of infrastructure routes and the service routes
</t> that are carried in existing BGP SAFIs such as BGP IPv4/IPv6 (SAFI=1),
and BGP-LU (SAFI=4) (e.g., 6PE <xref target="RFC4798"/>). Using CAR
<t>Additionally, BGP sessions SHOULD be protected using TCP Authentication O SAFI thus provides better security (such as protection against route
ption leaking) than would be obtained by distributing the infrastructure
<xref target="RFC5925"/> and the Generalized TTL Security Mechanism routes in existing SAFIs that also carry service routes.</t>
<xref target="RFC5082"/>. BGP Origin Validation <xref target="RFC6811"/> and <t>BGP CAR distributes label binding similar to <xref target="RFC8277"/>;
BGPsec <xref target="RFC8205"/> could also be used with this SAFI.</t> hence, its security considerations apply.</t>
<t>In SR deployments, BGP CAR distributes infrastructure prefixes along
<t>Since CAR SAFI is a separate BGP SAFI that carries transport or infrastru with their SID information for both SR-MPLS and SRv6. These deployments
cture are within an SR domain <xref target="RFC8402"/> and the security
routes for routers in the operator network, it provides automatic separation considerations of <xref target="RFC8402"/> apply. Additionally, security
of considerations related to SRv6 deployments that are discussed in <xref
infrastructure routes and the service routes that are carried in existing BG section="9.3" sectionFormat="of" target="RFC9252"/> also apply.</t>
P SAFIs <t>As <xref target="RFC4272"/> discusses, BGP is vulnerable to
such as BGP IPv4/IPv6 (SAFI=1), and BGP-LU (SAFI=4) (e.g., 6PE [RFC4798]). traffic-diversion attacks. This SAFI route adds a new means by which an
Using CAR SAFI thus provides better security (such as protection against rou attacker could cause the traffic to be diverted from its normal
te leaking) path. Potential consequences include "hijacking" of traffic (insertion
than would be obtained by distributing the infrastructure routes in existing of an undesired node in the path, which allows for inspection or
SAFIs that modification of traffic, or avoidance of security controls) or denial of
also carry service routes.</t> service (directing traffic to a node that doesn't desire to receive it).
</t>
<t>BGP CAR distributes label binding similar to <xref target="RFC8277"/> and <t>The restriction of the applicability of this SAFI to its intended well-
hence its security considerations apply. </t> defined scope
<t>
In SR deployments, BGP CAR distributes infrastructure prefixes along with th
eir SID
information for both SR-MPLS and SRv6. These deployments are within an SR Do
main [RFC8402]
and the security considerations of [RFC8402] apply. Additionally, security c
onsiderations
related to SRv6 deployments that are discussed in section 9.3 of [RFC9252] a
lso apply.</t>
<t>As <xref target="RFC4272"/> discusses, BGP is vulnerable to traffic-diver
sion
attacks. This SAFI routes adds a new means by which an attacker could cause
the
traffic to be diverted from its normal path. Potential consequences include
"hijacking" of traffic (insertion of an undesired node in the path, which al
lows for
inspection or modification of traffic, or avoidance of security controls) or
denial of service (directing traffic to a node that doesn't desire to receiv
e it).
</t>
<t>The restriction of the applicability of this SAFI to its intended well-de
fined scope
and the use of techniques described above limit the likelihood of traffic di versions.</t> and the use of techniques described above limit the likelihood of traffic di versions.</t>
</section> </section>
<section anchor="Contributors" title="Contributors">
<section anchor="COAUTH" title="Co-authors">
<t>
The following people gave substantial contributions to the content of this docum
ent and should be considered as coauthors:</t>
<figure>
<artwork><![CDATA[Clarence Filsfils
Cisco Systems
Belgium
Email: cfilsfil@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Luay Jalil
Verizon
USA
Email: luay.jalil@verizon.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Yuanchao Su
Alibaba, Inc
Email: yitai.syc@alibaba-inc.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Jim Uttaro
Individual
USA
Email: juttaro@ieee.org
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Jim Guichard
Futurewei
USA
Email: james.n.guichard@futurewei.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Keyur Patel
Arrcus, Inc
USA
Email: keyur@arrcus.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Haibo Wang
Huawei Technologies
China
Email: rainsword.wang@huawei.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
]]></artwork>
</figure>
</section>
<section anchor="CONTR" title="Additional Contributors">
<figure>
<artwork><![CDATA[Dirk Steinberg
Lapishills Consulting Limited
Germany
Email: dirk@lapishills.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Israel Means
AT&T
USA
Email: im8327@att.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Reza Rokui
Ciena
USA
Email: rrokui@ciena.com
]]></artwork>
</figure>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors would like to acknowledge the invaluable contributions of many
collaborators towards the BGP CAR
solution and this document in providing input about use-cases, participati
ng in brainstorming and mailing list
discussions and in reviews of the solution and draft revisions. In additio
n to the contributors listed in
<xref target="Contributors"/>, the authors would like to thank Robert Rasz
uk, Bin Wen, Chaitanya Yadlapalli,
Satoru Matsushima, Moses Nagarajah, Gyan Mishra, Jorge Rabadan, Daniel Voy
er, Stephane Litkowski, Hannes Gredler,
Jose Liste, Jakub Horn, Brent Foster, Dave Smith, Jiri Chaloupka, Miya Koh
no, Kamran Raza, Zafar Ali, Xing Jiang,
Oleksander Nestorov, Peter Psenak, Kaliraj Vairavakkalai, Natrajan Venkata
raman, Srihari Sangli, Ran Chen and
Jingrong Xie. </t>
<t>The authors also appreciate the detailed reviews and astute suggestions
provided by Sue Hares (as document
shepherd), Jeff Haas, Yingzhen Qu and John Scudder that have greatly impro
ved the document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 <displayreference target="I-D.hr-spring-intentaware-routing-using-color" to="INT
9.xml"/> ENT-AWARE"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817 <displayreference target="I-D.ietf-spring-srv6-mpls-interworking" to="SRv6-INTER
4.xml"/> WORK"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.827
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.436
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.476
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.866
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.731
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.840
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.468
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.760
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.925
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.898
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.935
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.901
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.925
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.254
5.xml"/>
</references> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
277.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
360.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
669.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
311.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
545.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <!-- [I-D.hr-spring-intentaware-routing-using-color]
draft-hr-spring-intentaware-routing-using-color-04
IESG State: I-D Exists as of 04/18/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hr -spring-intentaware-routing-using-color.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hr -spring-intentaware-routing-using-color.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
tf-spring-srv6-mpls-interworking.xml"/> <!-- [I-D.ietf-spring-srv6-mpls-interworking]
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie draft-ietf-spring-srv6-mpls-interworking-00
tf-idr-cpr.xml"/> IESG State: I-D Exists as of 04/18/25
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.436 -->
4.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.465 ietf-spring-srv6-mpls-interworking.xml"/>
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.427 <!-- [I-D.ietf-idr-cpr] is now RFC 9723. -->
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.427 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
1.xml"/> 723.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.791 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
1.xml"/> 364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.546 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
2.xml"/> 659.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.931 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
5.xml"/> 272.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.820 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
5.xml"/> 271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.592 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
5.xml"/> 911.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.681 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
1.xml"/> 462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.508 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
2.xml"/> 315.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.479 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
8.xml"/> 205.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
811.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
798.xml"/>
</references>
</references> </references>
<section anchor="SSTEERINGAPNDX" title="Illustrations of Service Steering"> <section anchor="SSTEERINGAPNDX">
<t>The following sub-sections illustrate example scenarios of Colored <name>Illustrations of Service Steering</name>
Service Route Steering over E2E BGP CAR paths, resolving over different <t>The following sub-sections illustrate example scenarios of colored
service route steering over end-to-end (E2E) BGP CAR paths, resolving over
different
intra-domain mechanisms.</t> intra-domain mechanisms.</t>
<t>The examples in this section use MPLS/SR for the transport data plane. Scenarios <t>The examples in this section use MPLS/SR for the transport data plane. Scenarios
related to SRv6 encapsulation are in a section below. related to SRv6 encapsulation are in a section below.
</t> </t>
<section anchor="SFAUSECASE">
<section anchor="SFAUSECASE" <name>E2E BGP Transport CAR Intent Realized Using IGP Flexible Algorithm
title="E2E BGP transport CAR intent realized using IGP Flex-Algo"> </name>
<figure anchor="FAUSECASE" title="BGP FA Aware transport CAR path"> <figure anchor="FAUSECASE">
<name>BGP Flexible Algorithm Aware Transport CAR Path</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:--+ +-:-----------------------+----------------------+------------------:--+
| : | | : | | : | | : |
skipping to change at line 2691 skipping to change at line 2867
| : |-------------------|121|<-----------------|231|<-------------| : | | : |-------------------|121|<-----------------|231|<-------------| : |
| : V LI=8002 +---+ LI=8002 +---+ | : | | : V LI=8002 +---+ LI=8002 +---+ | : |
|----+ | | +-----| |----+ | | +-----|
| E1 | | | | E2 | | E1 | | | | E2 |
|----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----| |----+(E2,C1) via 122 | (E2,C1) via 232 | (E2,C1)via E2+-----|
| ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | | | ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3 | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| LI=8002 +---+ LI=8002 +---+ LI=8002 | | LI=8002 +---+ LI=8002 +---+ LI=8002 |
| | | | | | | |
| IS-IS SR | IS-IS SR | IS-IS SR | | IS-IS SR | IS-IS SR | IS-IS SR |
| FA 128 | FA 128 | FA 128 | | FA128 | FA128 | FA128 |
+-------------------------+----------------------+---------------------+ +-------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
|168121| |168231| |168121| |168231|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|168002| |168002| |168002| |168002| |168002| |168002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Use case: Provide end to end intent for service flows. <t>Use case: Provide end-to-end intent for service flows.</t>
<list style="symbols"> <ul spacing="normal">
<t>The following description applies to the reference topology above: <li>
<list style="symbols"> <t>The following description applies to the reference topology above
<t>IGP FA 128 is running in each domain, and mapped to Color C1.</t> :</t>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC <ul spacing="normal">
C1 <li>
<t>IGP Flex-Algo 128 is running in each domain, and mapped to co
lor C1.</t>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color
-EC C1
to steer traffic to BGP transport CAR (E2, C1). to steer traffic to BGP transport CAR (E2, C1).
VPN route propagates via service RRs to ingress PE E1.</t> VPN route propagates via service RRs to ingress PE E1.</t>
<t>BGP CAR route (E2, C1) with next hop, label index and label as </li>
shown above are advertised through border routers in each domain. <li>
When a <t>BGP CAR route (E2, C1) with next hop, label index, and
RR is used in the domain, ADD-PATH is enabled to advertise multiple label as shown above are advertised through BRs in
available each domain. When an RR is used in the domain, ADD-PATH is
paths.</t> enabled to advertise multiple available paths.</t>
<t>On each BGP hop, the (E2, C1) route's next hop is resolved over I </li>
GP FA 128 <li>
of the domain. The AIGP attribute influences BGP CAR route best path <t>On each BGP hop, the (E2, C1) route's next hop is resolved ov
decision as er IGP Flex-Algo 128
of the domain. The AIGP attribute influences the BGP CAR route best
path decision as
per <xref target="RFC7311"/>. The BGP CAR label swap entry is instal led that goes per <xref target="RFC7311"/>. The BGP CAR label swap entry is instal led that goes
over FA 128 LSP to next hop providing intent in each IGP domain. The over Flex-Algo 128 LSP to next hop providing intent in each IGP doma
AIGP in. The AIGP
metric should be updated to reflect FA 128 metric to next hop.</t> metric should be updated to reflect Flex-Algo 128 metric to next hop
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored .</t>
</li>
<li>
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored
VPN route RD:V/v into (E2, C1).</t> VPN route RD:V/v into (E2, C1).</t>
</list> </li>
</t> </ul>
<t>Important: </li>
<list style="symbols"> <li>
<t>IGP FA 128 top label provides intent within each domain.</t> <t>Important:
<t>BGP CAR label (e.g. 168002) carries end to end intent. Thus </t>
it stitches intent over intra-domain FA 128.</t> <ul spacing="normal">
</list> <li>
</t> <t>IGP Flex-Algo 128 top label provides intent within each domai
</list> n.</t>
</t> </li>
<li>
<t>BGP CAR label (e.g., 168002) carries end-to-end
intent. Thus, it stitches intent over intra-domain Flex-Algo 128
.</t>
</li>
</ul>
</li>
</ul>
</section> </section>
<section>
<section title="E2E BGP transport CAR intent realized using SR Policy"> <name>E2E BGP Transport CAR Intent Realized Using SR Policy</name>
<figure anchor="SRPUSECASE" title="BGP SR policy Aware transport CAR pat <figure anchor="SRPUSECASE">
h"> <name>BGP SR Policy Aware Transport CAR Path</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:1/8 via E2 RD:1/8 via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <...... ...... |S-RR1| <..................................|S-RR2| <......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:-+ +-:-----------------------+----------------------+------------------:-+
| : | | : | | : | | : |
| : | | : | | : | | : |
| : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : | | : <-(E2,C1) via 121 | <-(E2,C1) via 231 | <-(E2,C1)via E2 : |
| : +---+ +---+ : | | : +---+ +---+ : |
| : ------------------>|121|----------------->|231|--------------| : | | : ------------------>|121|----------------->|231|--------------| : |
| : | SR policy(C1,121) +---+ SR policy(C1,231)+---+ SR policy v : | | : | SR Policy(C1,121) +---+ SR Policy(C1,231)+---+ SR Policy v : |
|----+ | | (C1,E2) +---| |----+ | | (C1,E2) +---|
| E1 | | | |E2 | | E1 | | | |E2 |
|----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---| |----+ <-(E2,C1) via 122 | (E2,C1) via 232 | <-(E2,C1)via E2+---|
| | +---+ +---+ ^ | | | +---+ +---+ ^ |
| ------------------>|122|----------------->|232|---------------| | | ------------------>|122|----------------->|232|---------------| |
| SR policy(C1,122) +---+ SR policy(C1,232)+---+ SR policy(C1,E2) | | SR Policy(C1,122) +---+ SR Policy(C1,232)+---+ SR Policy(C1,E2) |
| | | | | | | |
| | | | | | | |
| IS-IS SR | IS-IS SR | IS-IS SR | | IS-IS SR | IS-IS SR | IS-IS SR |
+-------------------------+----------------------+--------------------+ +-------------------------+----------------------+--------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
| S1 | | S2 | | S1 | | S2 |
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|160121| |160231| | S3 | |160121| |160231| | S3 |
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|168002| |168002| |168002| |168002| |168002| |168002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
]]></artwork>
]]></artwork>
</figure> </figure>
<t>Use case: Provide end to end intent for service flows. <t>Use case: Provide end-to-end intent for service flows.</t>
<list style="symbols"> <ul spacing="normal">
<t>The following description applies to the reference topology above: <li>
<list style="symbols"> <t>The following description applies to the reference topology above
<t>An SR Policy provides intra-domain intent. The following are the :
example SID lists
that are realized from SR policies in each domain and correspond to
the label stack
shown in <xref target="SRPUSECASE"/>
<list>
<t>SR policy (C1,121) segments &lt;S1, 121&gt;,</t>
<t>SR policy (C1,231) segments &lt;S2, 231&gt;, and</t>
<t>SR policy (C1,E2) segments &lt;S3, E2&gt;.</t>
</list>
</t> </t>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC <ul spacing="normal">
C1 <li>
<t>An SR Policy provides intra-domain intent. The following are
the example SID lists
that are realized from SR policies in each domain and correspond to
the label stack
shown in <xref target="SRPUSECASE"/>:
</t>
<ul spacing="normal">
<li>
<t>SR Policy (C1, 121) segments &lt;S1, 121&gt;,</t>
</li>
<li>
<t>SR Policy (C1, 231) segments &lt;S2, 231&gt;, and</t>
</li>
<li>
<t>SR Policy (C1, E2) segments &lt;S3, E2&gt;.</t>
</li>
</ul>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color
-EC C1
to steer traffic to BGP transport CAR (E2, C1). to steer traffic to BGP transport CAR (E2, C1).
VPN route propagates via service RRs to ingress PE E1.</t> VPN route propagates via service RRs to ingress PE E1.</t>
<t>BGP CAR route (E2, C1) with next hop, label index and label as </li>
shown above are advertised through border routers in each domain. <li>
When a <t>BGP CAR route (E2, C1) with next hop, label index, and label
RR is used in the domain, ADD-PATH is enabled to advertise multiple as shown above are advertised through BRs in each
available domain. When an RR is used in the domain, ADD-PATH is enabled
paths.</t> to advertise multiple available paths.</t>
<t>On each BGP hop, the CAR route (E2, C1) next hop is resolved over </li>
an <li>
SR policy (C1, next hop). BGP CAR label swap entry is installed that <t>On each BGP hop, the CAR route (E2, C1) next hop is resolved
goes over an
over SR policy segment list.</t> SR Policy (C1, next hop). The BGP CAR label swap entry is installed
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored that goes
over SR Policy segment list.</t>
</li>
<li>
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored
VPN route RD:V/v into (E2, C1). VPN route RD:V/v into (E2, C1).
</t>
</li>
</ul>
</li>
<li>
<t>Important:
</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>Important: <t>SR Policy provides intent within each domain.</t>
<list style="symbols"> </li>
<t>SR policy provides intent within each domain.</t> <li>
<t>BGP CAR label (e.g. 168002) carries end to end intent. Thus <t>BGP CAR label (e.g., 168002) carries end-to-end
it stitches intent over intra-domain SR policies.</t> intent. Thus, it stitches intent over intra-domain SR
</list> policies.</t>
</t> </li>
</list> </ul>
</t> </li>
</ul>
</section> </section>
<section anchor="SHDFAUSECASE">
<section anchor="SHDFAUSECASE" <name>BGP Transport CAR Intent Realized in a Section of the Network</nam
title="BGP transport CAR intent realized in a section of the network"> e>
<section title="Provide intent for service flows only in core domain <section>
running IS-IS Flex-Algo"> <name>Provide Intent for Service Flows Only in Core Domain Running IS-
<figure anchor="HDFAUSECASE" title="BGP Hybrid Flex-Algo Aware transpo IS Flexible Algorithm</name>
rt CAR path"> <figure anchor="HDFAUSECASE">
<artwork><![CDATA[ <name>BGP Hybrid Flexible Algorithm Aware Transport CAR Path</name>
<artwork><![CDATA[
RD:1/8 via E2 RD:1/8 via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:--+ +-:-----------------------+----------------------+------------------:--+
| : | | : | | : | | : |
| : | | : | | : | | : |
skipping to change at line 2868 skipping to change at line 3082
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
|160121| |168231| |160121| |168231|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|168002| |168002| |160002| |168002| |168002| |160002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>The following description applies to the reference topology above <t>The following description applies to the reference topology abo
: ve:
<list style="symbols"> </t>
<t>IGP FA 128 is only enabled in Core (e.g. WAN network), mapped t <ul spacing="normal">
o C1. <li>
Access network domain only has Base Algo 0.</t> <t>IGP Flex-Algo 128 is only enabled in core (e.g., WAN networ
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-E k),
C C1 mapped to C1. Access network domain only has Base Algo
0.</t>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Col
or-EC C1
to steer traffic via BGP transport CAR (E2, C1). to steer traffic via BGP transport CAR (E2, C1).
VPN route propagates via service RRs to ingress PE E1.</t> VPN route propagates via service RRs to ingress PE E1.</t>
<t>BGP CAR route (E2, C1) with next hop, label index and label as </li>
shown above are advertised through border routers in each domain. <li>
When a RR is used in the domain, ADD-PATH is enabled to advertise <t>BGP CAR route (E2, C1) with next hop, label index, and labe
multiple l as
shown above are advertised through BRs in each domain.
When an RR is used in the domain, ADD-PATH is enabled to advertise
multiple
available paths.</t> available paths.</t>
<t>Local policy on 231 and 232 maps intent C1 to resolve CAR route </li>
next hop over IGP Base Algo 0 in right access domain. <li>
BGP CAR label swap entry is installed that goes over Base Algo 0 L <t>Local policy on 231 and 232 maps intent C1 to resolve CAR
SP route next hop over IGP Base Algo 0 in right access
to next hop. Updates AIGP metric to reflect Base Algo 0 metric to domain. The BGP CAR label swap entry is installed that goes
next hop over Base Algo 0 LSP to next hop. AIGP metric is updated to
with an additional penalty (+1000).</t> reflect Base Algo 0 metric to next hop with an additional
<t>On 121 and 122, CAR route (E2, C1) next hop learnt from Core do penalty (+1000).</t>
main is </li>
resolved over IGP FA 128. BGP CAR label swap entry is installed th <li>
at goes <t>On 121 and 122, CAR route (E2, C1) next hop learnt from
over FA 128 LSP to next hop providing intent in Core IGP domain.</ Core domain is resolved over IGP Flex-Algo 128. The BGP CAR la
t> bel
<t>Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to swap entry is installed that goes over Flex-Algo 128 LSP to ne
resolve CAR route next hop over IGP Base Algo 0. It steers colored xt
VPN route RD:V/v via (E2, C1)</t> hop providing intent in Core IGP domain.</t>
</list> </li>
</t> <li>
<t>Ingress PE E1 learns CAR route (E2, C1). It maps intent
<t>Important: C1 to resolve CAR route next hop over IGP Base Algo 0. It
<list style="symbols"> steers colored VPN route RD:V/v via (E2, C1).</t>
<t>IGP Flex-Algo 128 top label provides intent in Core domain.</t> </li>
<t>BGP CAR label (e.g. 168002) carries intent from PEs which is </ul>
realized in core domain.</t> </li>
</list> <li>
</t> <t>Important:
</list> </t>
</t> <ul spacing="normal">
<li>
<t>IGP Flex-Algo 128 top label provides intent in Core domain.
</t>
</li>
<li>
<t>BGP CAR label (e.g., 168002) carries intent from PEs, which
is
realized in Core domain.</t>
</li>
</ul>
</li>
</ul>
</section> </section>
<section anchor="COREDOMAINTE" <section anchor="COREDOMAINTE">
title="Provide intent for service flows only in core domain over TE <name>Provide Intent for Service Flows Only in Core Domain over TE Tun
tunnel mesh"> nel Mesh</name>
<figure anchor="HRSVPDFAUSECASE" title="BGP CAR over TE tunnel mesh in <figure anchor="HRSVPDFAUSECASE">
core network"> <name>BGP CAR over TE Tunnel Mesh in Core Network</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:1/8 via E2 RD:1/8 via E2
+-----+ vpn label: 30030 +-----+ +-----+ vpn label: 30030 +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C1 +-----+ : : +-----+ Color C1 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+-----------------:-+ +-:-----------------------+----------------------+-----------------:-+
| : | | : | | : | | : |
| : | | : | | : | | : |
skipping to change at line 2949 skipping to change at line 3183
---------direction of traffic--------> ---------direction of traffic-------->
+------+ +------+ +------+ +------+
|240121| |241231| |240121| |241231|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|242003| |242002| |240002| |242003| |242002| |240002|
+------+ +------+ +------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|30030 | |30030 | |30030 | |30030 | |30030 | |30030 |
+------+ +------+ +------+ +------+ +------+ +------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>The following description applies to the reference topology above <t>The following description applies to the reference topology abo
: ve:
<list style="symbols"> </t>
<t>RSVP-TE MPLS tunnel mesh is configured only in core (e.g. WAN <ul spacing="normal">
network). <li>
Access only has IS-IS/LDP. (Figure does not show all TE tunnels).< <t>RSVP-TE MPLS tunnel mesh is configured only in core
/t> (e.g., WAN network). Access only has IS-IS/LDP. (The figure
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-E does not show all TE tunnels.)</t>
C C1 </li>
to steer traffic via BGP transport CAR (E2, C1). VPN route propaga <li>
tes <t>Egress PE E2 advertises a VPN route RD:V/v colored with
via service RRs to ingress PE E1.</t> Color-EC C1 to steer traffic via BGP transport CAR (E2,
<t>BGP CAR route (E2, C1) with next hops and labels as C1). VPN route propagates via service RRs to ingress PE
shown above is advertised through border routers in each E1.</t>
domain. When a RR is used in the domain, ADD-PATH is enabled </li>
<li>
<t>BGP CAR route (E2, C1) with next hops and labels as
shown above is advertised through BRs in each
domain. When an RR is used in the domain, ADD-PATH is enabled
to advertise multiple available paths.</t> to advertise multiple available paths.</t>
<t>Local policy on 231 and 232 maps intent C1 to resolve CAR route </li>
next hop over best-effort LDP LSP in access domain 1. BGP CAR <li>
<t>Local policy on 231 and 232 maps intent C1 to resolve CAR r
oute
next hop over best-effort LDP LSP in access domain 1. The BGP
CAR
label swap entry is installed that goes over LDP LSP to label swap entry is installed that goes over LDP LSP to
next hop. AIGP metric is updated to reflect best-effort metric to next hop next hop. AIGP metric is updated to reflect best-effort metric to next hop
with an additional penalty (+1000).</t> with an additional penalty (+1000).</t>
<t>Local policy on 121 and 122 maps intent C1 to resolve CAR route </li>
next hop in Core domain over RSVP-TE tunnels. BGP CAR label swa <li>
p entry is <t>Local policy on 121 and 122 maps intent C1 to resolve CAR r
oute
next hop in Core domain over RSVP-TE tunnels. The BGP CAR label
swap entry is
installed that goes over a TE tunnel to next hop providing inte nt in Core installed that goes over a TE tunnel to next hop providing inte nt in Core
domain. AIGP metric is updated to reflect TE tunnel metric.</t> domain. AIGP metric is updated to reflect TE tunnel metric.</t>
<t>Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to </li>
resolve CAR route's next hop over best-effort LDP LSP in Access <li>
domain 0. It <t>Ingress PE E1 learns CAR route (E2, C1). It maps intent C1
to
resolve CAR route's next hop over best-effort LDP LSP in access
domain 0. It
steers colored VPN route RD:V/v via (E2, C1).</t> steers colored VPN route RD:V/v via (E2, C1).</t>
</list> </li>
</t> </ul>
</li>
<t>Important: <li>
<list style="symbols"> <t>Important:</t>
<t>RSVP-TE tunnel LSP provides intent in Core domain.</t> <ul spacing="normal">
<t>Dynamic BGP CAR label carries intent from PEs which is <li>
realized in core domain by resolution via RSVP-TE tunnel.</t> <t>RSVP-TE tunnel LSP provides intent in Core domain.</t>
</list> </li>
</t> <li>
</list> <t>Dynamic BGP CAR label carries intent from PEs, which is
</t> realized in Core domain by resolution via RSVP-TE tunnel.</t>
</li>
</ul>
</li>
</ul>
</section> </section>
</section> </section>
<section>
<name>Transit Network Domains That Do Not Support CAR</name>
<ul spacing="normal">
<li>
<t>In a brownfield deployment, color-aware paths between two PEs
may need to go through a transit domain that does not support CAR.
Examples of such a brownfield network include an MPLS LDP network
with IGP best-effort, or a multi-domain network based on BGP-LU. An
MPLS
LDP network with best-effort IGP can adopt the above scheme in
<xref target="SHDFAUSECASE"/>. Below is the example scenario for
BGP-LU.</t>
</li>
<li>
<t>Reference topology:</t>
<section title="Transit network domains that do not support CAR"> <figure anchor="TRANSITNOCAR">
<t> <name>BGP CAR Not Supported in Transit Domain</name>
<list style="symbols">
<t>In a brownfield deployment, color-aware paths between two PEs may n
eed
to go through a transit domain that does not support CAR.
Examples of such a brownfield network include an MPLS LDP network w
ith
IGP best-effort, or a BGP-LU based multi-domain network. MPLS LDP
network
with best-effort IGP can adopt the above scheme in Section A.3. Be
low is
the example scenario for BGP LU.</t>
<t>Reference topology:
<figure anchor="TRANSITNOCAR" title="BGP CAR not supported in tra
nsit domain">
<artwork><![CDATA[ <artwork><![CDATA[
E1 --- BR1 --- BR2 ......... BR3 ---- BR4 --- E2 E1 --- BR1 --- BR2 ......... BR3 ---- BR4 --- E2
Ci <----LU----> Ci Ci <----LU----> Ci
]]></artwork> ]]></artwork>
</figure> </figure>
<list style="symbols"> <ul spacing="normal">
<t>Network between BR2 and BR3 comprises of multiple BGP-LU hops <li>
<t>Network between BR2 and BR3 comprises of multiple BGP-LU hops
(over IGP-LDP domains).</t> (over IGP-LDP domains).</t>
<t>E1, BR1, BR4 and E2 are enabled for BGP CAR, with Ci colors.</t> </li>
<t>BR1 and BR2 are directly connected; BR3 and BR4 are directly conn <li>
ected.</t> <t>E1, BR1, BR4, and E2 are enabled for BGP CAR, with Ci colors.
</list> </t>
</t> </li>
<t>BR1 and BR4 form an over-the-top peering (via RRs as needed) to <li>
exchange <t>BR1 and BR2 are directly connected; BR3 and BR4 are directly
connected.</t>
</li>
</ul>
</li>
<li>
<t>BR1 and BR4 form an over-the-top peering (via RRs as needed) to e
xchange
BGP CAR routes.</t> BGP CAR routes.</t>
<t>BR1 and BR4 also form direct BGP-LU sessions to BR2 and BR3 respect </li>
ively, <li>
<t>BR1 and BR4 also form direct BGP-LU sessions to BR2 and BR3, resp
ectively,
to establish labeled paths between each other through the BGP-LU netwo rk. to establish labeled paths between each other through the BGP-LU netwo rk.
The sessions may be eBGP or iBGP.</t> The sessions may be eBGP or iBGP.</t>
<t>BR1 recursively resolves the BGP CAR next hop for CAR routes learnt </li>
from <li>
<t>BR1 recursively resolves the BGP CAR next hop for CAR routes lear
nt from
BR4 via the BGP-LU path to BR4.</t> BR4 via the BGP-LU path to BR4.</t>
<t>BR1 signals the transport discontinuity to E1 via the AIGP TLV, so </li>
that <li>
<t>BR1 signals the transport discontinuity to E1 via the AIGP TLV, s
o that
E1 can prefer other paths if available.</t> E1 can prefer other paths if available.</t>
<t>BR4 does the same in the reverse direction.</t> </li>
<t>Thus, the color-awareness of the routes and hence the paths in the <li>
data plane are maintained between E1 and E2, even if the intent is <t>BR4 does the same in the reverse direction.</t>
not available within the BGP-LU island.</t> </li>
<t>A similar design can be used for going over network islands of othe <li>
r <t>Thus, the color awareness of the routes, and hence the paths
in the data plane, are maintained between E1 and E2, even if the
intent is not available within the BGP-LU island.</t>
</li>
<li>
<t>A similar design can be used for going over network islands of ot
her
types.</t> types.</t>
</list> </li>
</t> </ul>
</section> </section>
<section title="Resource Avoidance using BGP CAR and IGP Flex-Algo"> <section>
<name>Resource Avoidance Using BGP CAR and IGP Flexible Algorithm</name>
<t>This example illustrates a case of resource avoidance within a domain for a <t>This example illustrates a case of resource avoidance within a domain for a
multi-domain color-aware path. multi-domain color-aware path.</t>
</t>
<figure anchor="HRAVOIDUSECASE" title="BGP CAR resolution over IGP FLex-
Algo for
resource avoidance in a domain">
<artwork><![CDATA[
<figure anchor="HRAVOIDUSECASE">
<name>BGP CAR Resolution over IGP Flexible Algorithm for Resource Avoi
dance in a Domain</name>
<artwork><![CDATA[
+-------------+ +-------------+ +-------------+ +-------------+
| | | | V/v with C1 | | | | V/v with C1
|----+ |------| +----|/ |----+ |------| +----|/
| E1 | | | | E2 |\ | E1 | | | | E2 |\
|----+ | | +----| W/w with C2 |----+ | | +----| W/w with C2
| |------| IGP FA128 | | |------| IGP FA128 |
| IGP FA128 | | IGP FA129 | | IGP FA128 | | IGP FA129 |
| Domain 1 | | Domain 2 | | Domain 1 | | Domain 2 |
+-------------+ +-------------+ +-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<list style="symbols"> <ul spacing="normal">
<li>
<t>C1 and C2 represent the following two unique intents in the multi -domain network: <t>C1 and C2 represent the following two unique intents in the multi -domain network:
<list style="symbols">
<t>C1 is mapped to "minimize IGP metric", and</t>
<t>C2 is mapped to "minimize IGP metric and avoid resource R".</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>C1 is mapped to "minimize IGP metric", and</t>
</li>
<li>
<t>C2 is mapped to "minimize IGP metric and avoid resource R".</
t>
</li>
</ul>
</li>
<li>
<t>Resource R represents link(s) or node(s) to be avoided.</t> <t>Resource R represents link(s) or node(s) to be avoided.</t>
<t>Flex-Algo FA128 in Domain 2 is mapped to "minimize IGP metric" an </li>
d hence <li>
<t>Flex-Algo 128 in Domain 2 is mapped to "minimize IGP metric", and
hence
to C1.</t> to C1.</t>
<t>Flex-Algo FA129 in Domain 2 is mapped to "minimize IGP metric and </li>
avoid <li>
resource R" and hence to C2.</t> <t>Flex-Algo 129 in Domain 2 is mapped to "minimize IGP metric
<t>Flex-Algo FA128 in Domain 1 is mapped to "minimize IGP metric" i. and avoid resource R", and hence to C2.</t>
e., </li>
<list style="symbols"> <li>
<t>There is no resource R to be avoided in Domain 1, hence both C1 <t>Flex-Algo 128 in Domain 1 is mapped to "minimize IGP metric"
and C2 (i.e., there is no resource R to be avoided in Domain 1, hence
are mapped to FA128.</t> both C1 and C2 are mapped to Flex-Algo 128).</t>
</list> </li>
</t> <li>
<t>E1 receives the following two service routes from E2: <t>E1 receives the following two service routes from E2:</t>
<list style="symbols"> <ul spacing="normal">
<t>V/v with BGP Color-EC C1, and</t> <li>
<t>W/w with BGP Color-EC C2.</t> <t>V/v with BGP Color-EC C1, and</t>
</list> </li>
</t> <li>
<t>W/w with BGP Color-EC C2.</t>
</li>
</ul>
</li>
<li>
<t>E1 has the following color-aware paths: <t>E1 has the following color-aware paths:
<list style="symbols"> </t>
<t>(E2, C1) provided by BGP CAR with the following per-domain <ul spacing="normal">
<li>
<t>(E2, C1) provided by BGP CAR with the following per-domain
resolution: resolution:
<list style="symbols"> </t>
<t>Domain1: over IGP FA128, and</t> <ul spacing="normal">
<t>Domain2: over IGP FA128.</t> <li>
</list> <t>Domain 1: over IGP Flex-Algo 128, and</t>
</t> </li>
<t>(E2, C2) provided by BGP CAR with the following per-domain <li>
<t>Domain 2: over IGP Flex-Algo 128.</t>
</li>
</ul>
</li>
<li>
<t>(E2, C2) provided by BGP CAR with the following per-domain
resolution: resolution:
<list style="symbols"> </t>
<t>Domain1: over IGP FA128, and</t> <ul spacing="normal">
<t>Domain2: over IGP FA129 (avoiding resource R).</t> <li>
</list> <t>Domain 1: over IGP Flex-Algo 128, and</t>
</t> </li>
</list> <li>
</t> <t>Domain 2: over IGP Flex-Algo 129 (avoiding resource R).</
t>
</li>
</ul>
</li>
</ul>
</li>
<li>
<t>E1 automatically steers the received service routes as follows: <t>E1 automatically steers the received service routes as follows:
<list style="symbols">
<t>V/v via (E2, C1) provided by BGP CAR.</t>
<t>W/w via (E2, C2) provided by BGP CAR.</t>
</list>
</t> </t>
</list> <ul spacing="normal">
</t> <li>
<t>Observations: <t>V/v via (E2, C1) provided by BGP CAR.</t>
<list style="symbols"> </li>
<t>C1 and C2 are realized over a common intra-domain intent (FA128) <li>
in one <t>W/w via (E2, C2) provided by BGP CAR.</t>
</li>
</ul>
</li>
</ul>
<t>Observations:</t>
<ul spacing="normal">
<li>
<t>C1 and C2 are realized over a common intra-domain intent (Flex-Al
go 128) in one
domain and distinct intents in another domain as required.</t> domain and distinct intents in another domain as required.</t>
<t>32-bit Color space provides flexibility in defining a large numbe </li>
r of <li>
intents in a multi-domain network. They may be efficiently realiz <t>32-bit Color space provides flexibility in defining a large
ed by number of intents in a multi-domain network. They may be
mapping to a smaller number of intra-domain intents in different dom efficiently realized by mapping to a smaller number of
ains.</t> intra-domain intents in different domains.</t>
</list> </li>
</t> </ul>
</section> </section>
<section title="Per-Flow Steering over CAR routes">
<section>
<name>Per-Flow Steering over CAR Routes</name>
<t>This section provides an example of ingress PE per-flow steering as d efined <t>This section provides an example of ingress PE per-flow steering as d efined
in section 8.6 of <xref target="RFC9256"/> in <xref target="RFC9256" sectionFormat="of" section="8.6"/>
onto BGP CAR routes. onto BGP CAR routes.
</t> </t>
<t>The following description applies to the reference topology in <xref target="FAUSECASE"/>: <t>The following description applies to the reference topology in <xref target="FAUSECASE"/>:
<list style="symbols"> </t>
<t>Ingress PE E1 learns best-effort BGP LU route E2.</t> <ul spacing="normal">
<t>Ingress PE E1 learns CAR route (E2, C1), C1 is mapped to "low delay <li>
".</t> <t>Ingress PE E1 learns best-effort BGP-LU route E2.</t>
<t>Ingress PE E1 learns CAR route (E2, C2), C2 is mapped to </li>
<li>
<t>Ingress PE E1 learns CAR route (E2, C1), C1 is mapped to "low del
ay".</t>
</li>
<li>
<t>Ingress PE E1 learns CAR route (E2, C2), C2 is mapped to
"low delay and avoid resource R".</t> "low delay and avoid resource R".</t>
<t>Ingress PE E1 is configured to instantiate an array of paths to E2 </li>
where <li>
entry 0 is the BGP LU path to next hop, color C1 is the first entry an <t>Ingress PE E1 is configured to instantiate an array of paths to E
d 2 where
entry 0 is the BGP-LU path to next hop, color C1 is the first entry, a
nd
color C2 is the second entry. The index into the array is called a color C2 is the second entry. The index into the array is called a
Forwarding Class (FC). The index can have values 0 to 7, especially w hen Forwarding Class (FC). The index can have values 0 to 7, especially w hen
derived from the MPLS TC bits <xref target="RFC5462"/>.</t> derived from the MPLS TC bits <xref target="RFC5462"/>.</t>
<t>E1 is configured to match flows in its ingress interfaces (upon any </li>
field <li>
<t>E1 is configured to match flows in its ingress interfaces (upon a
ny field
such as Ethernet destination/source/VLAN/TOS or IP destination/source/ DSCP such as Ethernet destination/source/VLAN/TOS or IP destination/source/ DSCP
or transport ports etc.) and color them with an internal per-packet FC or transport ports, etc.) and color them with an internal per-packet F
variable C variable
(0, 1 or 2 in this example).</t> (0, 1, or 2 in this example).</t>
<t>This array is presented as composite candidate path of SR policy (E </li>
2, C100) <li>
<t>This array is presented as a composite candidate path of SR Polic
y (E2, C100)
and acts as a container for grouping constituent paths of different and acts as a container for grouping constituent paths of different
colors/best-effort. This representation provides automated steering fo r colors/best-effort. This representation provides automated steering fo r
services colored with Color-EC C100 via paths of different services colored with Color-EC C100 via paths of different
colors. Note that Color-EC C100 is used as indirection to the colors. Note that Color-EC C100 is used as indirection to the
composite policy configured on ingress PE.</t> composite policy configured on ingress PE.</t>
<t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100 </li>
to steer traffic via composite SR policy (E2, C100); i.e., FC array of <li>
paths.</t> <t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100
</list> to steer traffic via composite SR Policy (E2, C100) (i.e., FC array of
</t> paths).</t>
</li>
</ul>
<t>E1 receives three packets K, K1, and K2 on its incoming interface. Th ese three <t>E1 receives three packets K, K1, and K2 on its incoming interface. Th ese three
packets matches on VPN route which recurses on E2. E1 colors these 3 pac packets match on the VPN route that recurses on E2. E1 colors these 3 pa
kets ckets with forwarding class 0, 1, and 2, respectively.</t>
respectively with forwarding-class 0, 1, and 2.</t> <t>As a result:
<t>As a result
<list style="symbols">
<t>E1 forwards K along the best-effort path to E2 (i.e., for MPLS data
plane,
it pushes the best-effort label of E2).</t>
<t>E1 forwards K1 along the (E2, C1) BGP CAR route.</t>
<t>E1 forwards K2 along the (E2, C2) BGP CAR route.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>E1 forwards K along the best-effort path to E2 (i.e., for the MPL
S data plane,
it pushes the best-effort label of E2).</t>
</li>
<li>
<t>E1 forwards K1 along the (E2, C1) BGP CAR route.</t>
</li>
<li>
<t>E1 forwards K2 along the (E2, C2) BGP CAR route.</t>
</li>
</ul>
</section> </section>
<section anchor="SHAREDIP" title="Advertising BGP CAR routes for shared IP <section anchor="SHAREDIP">
addresses"> <name>Advertising BGP CAR Routes for Shared IP Addresses</name>
<figure anchor="HSHIPUSECASE" title="BGP CAR advertisements for shared I <figure anchor="HSHIPUSECASE">
P <name>BGP CAR Advertisements for Shared IP Addresses</name>
addresses">
<artwork><![CDATA[ <artwork><![CDATA[
+-------------+ +--------------+ +-------------+ +--------------+
| | | +----| | | | +----|
| |------| | E2 |(IP1) | |------| | E2 |(IP1)
|----+ | | +----| |----+ | | +----|
| E1 | | | Domain 2 | | E1 | | | Domain 2 |
|----+ | +--------------+ |----+ | +--------------+
| | +--------------+ | | +--------------+
| | | +----| | | | +----|
| Domain 1 |------| | E3 |(IP1) | Domain 1 |------| | E3 |(IP1)
+-------------+ | +----| +-------------+ | +----|
| Domain 3 | | Domain 3 |
+--------------+ +--------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This example describes a case where a route for the same transport IP
address <t>This example describes a case where a route for the same transport
is originated from multiple nodes in different network domains. IP address is originated from multiple nodes in different network
</t> domains.</t>
<t>One use of this scenario is an Anycast transport service, where packe <t>One use of this scenario is an anycast transport service, where packe
t t
encapsulation (e.g., LSP) may terminate on any one among a set of nodes. All the encapsulation (e.g., LSP) may terminate on any one among a set of nodes. All the
nodes are capable of forwarding the inner payload, typically via an IP l ookup in nodes are capable of forwarding the inner payload, typically via an IP l ookup in
the global table for Internet routes. the global table for Internet routes.</t>
</t> <t>A couple of variations of the use case are described in the example b
<t>A couple of variations of the use-case are described in the example b elow.</t>
elow.
</t>
<t>One node is shown in each domain, but there will be multiple nodes in practice <t>One node is shown in each domain, but there will be multiple nodes in practice
for redundancy. for redundancy.</t>
</t>
<t>Example-1: Anycast with forwarding to nearest <t>Example 1: Anycast with forwarding to nearest egress:</t>
<list style="symbols"> <ul spacing="normal">
<t>Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise <li>
<t>Both E2 (in egress domain 2) and E3 (in egress domain 3) advertis
e
Anycast (shared) IP (IP1, C1) with same label L1.</t> Anycast (shared) IP (IP1, C1) with same label L1.</t>
<t>An ingress PE E1 receives by default the best path(s) for (IP1, C1) </li>
<li>
<t>An ingress PE E1 receives by default the best path(s) for (IP1, C
1)
propagated through BGP hops across the network.</t> propagated through BGP hops across the network.</t>
<t>The paths to (IP1, C1) from E2 and E3 may merge at a common node </li>
<li>
<t>The paths to (IP1, C1) from E2 and E3 may merge at a common node
along the path to E1, forming equal cost multipaths or active-backup p aths along the path to E1, forming equal cost multipaths or active-backup p aths
at that node.</t> at that node.</t>
<t>Service route V/v is advertised from egress domains D2 and D3 with </li>
color <li>
<t>Service route V/v is advertised from egress domains D2 and D3 wit
h color
C1 and next hop IP1.</t> C1 and next hop IP1.</t>
<t>Traffic for V/v steered at E1 via (IP1, C1) is forwarded </li>
to either E2 or E3 (or both) as determined by routing along the net <li>
work (nodes <t>Traffic for V/v steered at E1 via (IP1, C1) is forwarded to
in the path). either E2 or E3 (or both) as determined by routing along the
</t> network (nodes in the path).
</list> </t>
</t> </li>
<t>Example-2: Anycast with egress domain visibility at ingress PE </ul>
<list style="symbols">
<t>E2 advertises (IP1, C1) and E3 advertises (IP1, C2) CAR routes for <t>Example 2: Anycast with egress domain visibility at ingress PE:</t>
the <ul spacing="normal">
<li>
<t>E2 advertises (IP1, C1) and E3 advertises (IP1, C2) CAR routes fo
r the
Anycast IP IP1. C1 and C2 are colors assigned to distinguish the egres s Anycast IP IP1. C1 and C2 are colors assigned to distinguish the egres s
domains originating the routes to IP1.</t> domains originating the routes to IP1.</t>
<t>An ingress PE E1 receives the best path(s) propagated through BGP h </li>
ops <li>
<t>An ingress PE E1 receives the best path(s) propagated through BGP
hops
across the network for both (IP1, C1) and (IP1, C2).</t> across the network for both (IP1, C1) and (IP1, C2).</t>
<t>The CAR routes (IP1, C1) and (IP1, C2) do not get merged at any </li>
<li>
<t>The CAR routes (IP1, C1) and (IP1, C2) do not get merged at any
intermediate node, providing E1 control over path selection and load-b alancing intermediate node, providing E1 control over path selection and load-b alancing
of traffic across these two routes. Each route may itself provide mult ipathing of traffic across these two routes. Each route may itself provide mult ipathing
or Anycast to a set of egress nodes.</t> or anycast to a set of egress nodes.</t>
<t>Service route V/v advertised from egress domains D2 and D3 with col </li>
ors <li>
C1 and C2 respectively, but with same next hop IP1.</t> <t>Service route V/v advertised from egress domains D2 and D3 with c
<t>E1 will resolve and steer V/v path from D2 via (IP1, C1) and path f olors
rom C1 and C2, respectively, but with same next hop IP1.</t>
</li>
<li>
<t>E1 will resolve and steer V/v path from D2 via (IP1, C1) and path
from
D3 via (IP2, C2). E1 will load-balance traffic to V/v across the two p aths D3 via (IP2, C2). E1 will load-balance traffic to V/v across the two p aths
as determined by a local load-balancing policy.</t> as determined by a local load-balancing policy.</t>
<t>Traffic for colored service routes steered at E1 is forwarded to ei </li>
ther E2 <li>
<t>Traffic for colored service routes steered at E1 is forwarded to
either E2
or E3 (or load-balanced across both) as determined by E1.</t> or E3 (or load-balanced across both) as determined by E1.</t>
</list> </li>
</t> </ul>
<t>In above example, D2 and D3 belonged to the same color or administrat <t>In above example, D2 and D3 belonged to the same color or
ive administrative domain. If D2 and D3 belong to different color domains,
domain. If D2 and D3 belong to different color domains, the domains will the domains will coordinate the assignment of colors with shared IP
coordinate the assignment of colors with shared IP IP1 so that IP1 so that they do not cause conflicts. For instance, in Example
they do not cause conflicts. 1:</t>
For instance, in Example-1: <ul spacing="normal">
<list style="symbols"> <li>
<t>D2 and D3 may both use C1 for the same intent when they orig <t>D2 and D3 may both use C1 for the same intent when they originate
inate CAR route for IP1. CAR route for IP1.
<list style="symbols"> </t>
<t>In this case, neither D2 nor D3 will reuse C1 for some <ul spacing="normal">
other <li>
intent.</t> <t>In this case, neither D2 nor D3 will reuse C1 for some
</list> other intent.</t>
</t> </li>
<t>Alternatively, D2 may use C2 and D3 may use C3 for originati </ul>
ng a CAR route </li>
for IP1 for the same intent. <li>
<list style="symbols"> <t>Alternatively, D2 may use C2 and D3 may use C3 for originating
<t>In this case, D2 will not use C3 for originating CAR r a CAR route for IP1 for the same intent.</t>
oute for IP1 for <ul spacing="normal">
some other intent. Similarly, D3 will not use C2 for orig <li>
inating CAR route <t>In this case, D2 will not use C3 for originating CAR route
for IP1 for some other intent.</t> for IP1 for some other intent. Similarly, D3 will not use C2
</list> for originating CAR route for IP1 for some other intent.</t>
</t> </li>
</list> </ul>
</t> </li>
</ul>
</section> </section>
</section> </section>
<section anchor="ColorMapping" title="Color Mapping Illustrations"> <section anchor="ColorMapping">
<name>Color Mapping Illustrations</name>
<t> <t>
There are a variety of deployment scenarios that arise when different There are a variety of deployment scenarios that arise when different
color mappings are used in an inter-domain environment. This section attem color mappings are used in an inter-domain environment. This section
pts to attempts to enumerate them and provide clarity into the usage of the
enumerate them and provide clarity into the usage of the color related color-related protocol constructs.
protocol constructs.
</t> </t>
<section>
<section title="Single color domain containing network domains with N:N <name>Single Color Domain Containing Network Domains with N:N Color
color distribution"> Distribution</name>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> <t>All network domains (ingress, egress, and all transit domains)
All network domains (ingress, egress and all transit domains) are enab are enabled for the same N colors.</t>
led for <ul spacing="normal">
the same N colors. <li>
<list> <t>A color may of course be realized by different
<t> technologies in different domains as described above.</t>
A color may of course be realized by different technologies in differe </li>
nt </ul>
domains as described above. </li>
</t> <li>
</list> <t>The N intents are both signaled end-to-end via BGP CAR routes,
</t> as well as realized in the data plane.</t>
<t> </li>
The N intents are both signaled end-to-end via BGP CAR routes; as well <li>
as <t>
realized in the data plane.
</t>
<t>
<xref target="SFAUSECASE"/> is an example of this case. <xref target="SFAUSECASE"/> is an example of this case.
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
<section anchor="APPENDIXNM" <section anchor="APPENDIXNM">
title="Single color domain containing network domains with N:M color distr <name>Single Color Domain Containing Network Domains with N:M Color Dist
ibution"> ribution</name>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> <t>
Certain network domains may not be enabled for some of the Certain network domains may not be enabled for some of the
colors used for end-to-end intents, but may still be required to provi de colors used for end-to-end intents, but may still be required to provi de
transit for routes of those colors. transit for routes of those colors.
</t> </t>
<t> </li>
<li>
<t>
When a (E, C1) route traverses a domain where color C1 is not When a (E, C1) route traverses a domain where color C1 is not
available, the operator may decide to use a different intent of color available, the operator may decide to use a different intent of color
C2 that is available in that domain to resolve the next hop and establ ish C2 that is available in that domain to resolve the next hop and establ ish
a path through the domain. a path through the domain.
<list style="symbols">
<t>
The next hop resolution may occur via paths of any intra-domain
protocol or even via paths provided by BGP CAR.
</t> </t>
<t> <ul spacing="normal">
The next hop resolution color C2 may be defined as a local policy at <li>
<t>
The next-hop resolution may occur via paths of any intra-domain
protocol or even via paths provided by BGP CAR.
</t>
</li>
<li>
<t>
The next-hop resolution color C2 may be defined as a local policy at
ingress or transit nodes of the domain. ingress or transit nodes of the domain.
</t> </t>
<t> </li>
<li>
<t>
It may also be automatically signaled from egress border nodes by It may also be automatically signaled from egress border nodes by
attaching a Color-EC with value C2 to the BGP CAR routes. attaching a Color-EC with value C2 to the BGP CAR routes.
</t> </t>
</list> </li>
</t> </ul>
</li>
<t> <li>
<t>
Hence, routes of N end-to-end colors may be resolved over paths from a smaller Hence, routes of N end-to-end colors may be resolved over paths from a smaller
set of M colors in a transit domain, while preserving the original set of M colors in a transit domain, while preserving the original
color-awareness end-to-end. color awareness end-to-end.
</t> </t>
<t> </li>
Any ingress PE that installs a service (VPN) route with a color C1, <li>
<t>
Any ingress PE that installs a service (VPN) route with a color C1
must have C1 enabled locally to install IP routes to (E, C1) and must have C1 enabled locally to install IP routes to (E, C1) and
resolve the service route's next hop. resolve the service route's next hop.
</t> </t>
<t> </li>
<li>
<t>
A degenerate variation of this scenario is where a transit domain does A degenerate variation of this scenario is where a transit domain does
not support any color. <xref target="SHDFAUSECASE"/> describes an exam ple not support any color. <xref target="SHDFAUSECASE"/> describes an exam ple
of this case. of this case.
</t> </t>
</list> </li>
</t> </ul>
<t>Illustration for N end-to-end intents over fewer M intra-domain inten
<t>Illustration for N end to end intents over fewer M intra-domain inten ts:</t>
ts: <figure anchor="NMUSECASE">
<figure anchor="NMUSECASE" title="N:M illustration"> <name>N:M Illustration</name>
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 Color-EC: 100 RD:V/v via E2 Color-EC: 100
RD:W/w via E2 Color-EC: 200 RD:W/w via E2 Color-EC: 200
+-----+ RD:X/x via E2 Color-EC: 300 +-----+ +-----+ RD:X/x via E2 Color-EC: 300 +-----+
...... |S-RR1| <..................................|S-RR2| <........ ...... |S-RR1| <..................................|S-RR2| <........
: +-----+ RD:Y/y via E2 Color-EC: 400 +-----+ : : +-----+ RD:Y/y via E2 Color-EC: 400 +-----+ :
: : : :
: : : :
: : : :
+-:---------------------+---------------------+----------------------:-+ +-:---------------------+---------------------+----------------------:-+
skipping to change at line 3373 skipping to change at line 3748
| +===+ +===+ | | +===+ +===+ |
| C1=FA132 | C10=FA128 | C1=FA132 | | C1=FA132 | C10=FA128 | C1=FA132 |
| C2=FA133 | C20=FA129 | C2=FA133 | | C2=FA133 | C20=FA129 | C2=FA133 |
| | C30=FA130 | | | | C30=FA130 | |
| | C40=FA131 | | | | C40=FA131 | |
| | | | | | | |
| IS-IS SR | IS-IS SR | IS-IS SR | | IS-IS SR | IS-IS SR | IS-IS SR |
| ACCESS | CORE | ACCESS | | ACCESS | CORE | ACCESS |
+-----------------------+---------------------+------------------------+ +-----------------------+---------------------+------------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
]]></artwork> ]]></artwork>
</figure> </figure>
<ul spacing="normal">
<list style="symbols"> <li>
<t>The following description applies to the reference topology above: <t>The following description applies to the reference topology above
<list style="symbols"> :
<t>Core domain provides 4 intra-domain intents as described below:
<list style="symbols">
<t>FA128 mapped to C10,</t>
<t>FA129 mapped to C20,</t>
<t>FA130 mapped to C30, and</t>
<t>FA131 mapped to C40.</t>
</list>
</t>
<t>Access domain provides following 2 intra-domain intents:
<list style="symbols">
<t>FA132 mapped to C1, and</t>
<t>FA133 mapped to C2</t>
</list>
</t>
<t>Operator defines following 4 BGP CAR end to end intents as below:
<list style="symbols">
<t>CAR color C100 that resolves on C1 in access and C10 in core do
main,</t>
<t>CAR color C200 that resolves on C1 in access and C20 in core do
main,</t>
<t>CAR color C300 that resolves on C2 in access and C30 in core do
main, and
</t>
<t>CAR color C400 that resolves on C2 in access and C40 in core do
main.</t>
</list>
</t> </t>
<t>E2 may originate BGP CAR routes with multiple BGP Color-ECs as sh <ul spacing="normal">
own above. <li>
At each hop, CAR route's next hop is resolved over the available int <t>Core domain provides 4 intra-domain intents as described belo
ra-domain w:
color. For example (E2, C100) with BGP color ECs C1, C10 resolves ov </t>
er C1 at <ul spacing="normal">
ABR 231, C10 at ABR 121, and C1 at E1. </t> <li>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with BGP Color <t>FA128 mapped to C10,</t>
-EC C100 to </li>
steer traffic through FA 132 in access and FA 128 in core. It also a <li>
dvertises <t>FA129 mapped to C20,</t>
</li>
<li>
<t>FA130 mapped to C30, and</t>
</li>
<li>
<t>FA131 mapped to C40.</t>
</li>
</ul>
</li>
<li>
<t>Access domain provides the following 2 intra-domain intents:
</t>
<ul spacing="normal">
<li>
<t>FA132 mapped to C1, and</t>
</li>
<li>
<t>FA133 mapped to C2.</t>
</li>
</ul>
</li>
<li>
<t>Operator defines the following 4 BGP CAR end-to-end intents a
s below:
</t>
<ul spacing="normal">
<li>
<t>CAR color C100 that resolves on C1 in access and C10 in C
ore domain,</t>
</li>
<li>
<t>CAR color C200 that resolves on C1 in access and C20 in C
ore domain,</t>
</li>
<li>
<t>CAR color C300 that resolves on C2 in access and C30 in C
ore domain, and
</t>
</li>
<li>
<t>CAR color C400 that resolves on C2 in access and C40 in C
ore domain.</t>
</li>
</ul>
</li>
<li>
<t>E2 may originate BGP CAR routes with multiple BGP Color-ECs
as shown above. At each hop, CAR route's next hop is resolved
over the available intra-domain color. For example (E2, C100)
with BGP Color-ECs C1, C10 resolves over C1 at ABR 231, C10 at
ABR 121, and C1 at E1. </t>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v colored with BGP C
olor-EC C100 to
steer traffic through Flex-Algo 132 in access and Flex-Algo 128 in c
ore. It also advertises
another VPN route RD:W/w colored with BGP Color-EC C200 to steer tra ffic through another VPN route RD:W/w colored with BGP Color-EC C200 to steer tra ffic through
FA 132 in access and FA 129 in core.</t> Flex-Algo 132 in access and Flex-Algo 129 in core.</t>
</list> </li>
</t> </ul>
<t>Important: </li>
<list style="symbols"> <li>
<t> End-to-end (BGP CAR) colors can be decoupled from intra-domain t <t>Important:
ransport colors. </t> </t>
<t>Each end-to-end BGP CAR color is a combination of various intra-d <ul spacing="normal">
omain colors or intents.</t> <li>
<t>Combination can be expressed by local policy at ABRs or by attach <t> End-to-end (BGP CAR) colors can be decoupled from intra-doma
ing in transport colors. </t>
</li>
<li>
<t>Each end-to-end BGP CAR color is a combination of various int
ra-domain colors or intents.</t>
</li>
<li>
<t>Combination can be expressed by local policy at ABRs or by at
taching
multiple BGP Color-ECs at origination point of BGP CAR route.</t> multiple BGP Color-ECs at origination point of BGP CAR route.</t>
<t>Service traffic is steered into suitable CAR color to use the mos </li>
t granular intent <li>
<t>Service traffic is steered into suitable CAR color to use the
most granular intent
in a domain multiple hops away from ingress PE.</t> in a domain multiple hops away from ingress PE.</t>
<t>Consistent reuse of standard color based resolution mechanism at b </li>
oth service and <li>
<t>Consistent reuse of standard color-based resolution mechanism
at both service and
transport layers.</t> transport layers.</t>
</list> </li>
</t> </ul>
</list> </li>
</t> </ul>
</section> </section>
<section anchor="APPENDIXMCD">
<section anchor="APPENDIXMCD" title="Multiple color domains"> <name>Multiple Color Domains</name>
<t> <t>When the routes are distributed between domains with different
When the routes are distributed between domains with different
color-to-intent mapping schemes, both N:N and N:M cases are possible. color-to-intent mapping schemes, both N:N and N:M cases are possible.
Although an N:M mapping is more likely to occur. Although an N:M mapping is more likely to occur. </t>
</t> <t>Reference topology:</t>
<t>Reference topology:
<figure anchor="MCD" title="Multiple color domains"> <figure anchor="MCD">
<artwork><![CDATA[ <name>Multiple Color Domains</name>
<artwork><![CDATA[
D1 ----- D2 ----- D3 D1 ----- D2 ----- D3
C1 C2 C3 C1 C2 C3
]]></artwork> ]]></artwork>
</figure> </figure>
<list style="symbols"> <ul spacing="normal">
<li>
<t>C1 in D1 maps to C2 in D2 and to C3 in D3.</t> <t>C1 in D1 maps to C2 in D2 and to C3 in D3.</t>
</li>
<li>
<t>BGP CAR is enabled in all three color domains.</t> <t>BGP CAR is enabled in all three color domains.</t>
</list> </li>
</t> </ul>
<t> <t>
The reference topology above is used to elaborate on the design The reference topology above is used to elaborate on the design
described in <xref target="SDIFFCOLORS"/> described in <xref target="SDIFFCOLORS"/>
</t> </t>
<t> <t>
When the route originates in color domain D1 and gets advertised When the route originates in color domain D1 and gets advertised
to a different color domain D2, following procedures apply: to a different color domain D2, the following procedures apply:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The NLRI of the BGP CAR route is preserved end to end, i.e., route is <li>
(E, C1). <t>The NLRI of the BGP CAR route is preserved end to end (i.e.,
</t> route is (E, C1)).</t>
<t> </li>
A BR of D1 attaches LCM-EC with value C1 when advertising to a BR in D2. <li>
</t> <t>A BR of D1 attaches LCM-EC with value C1 when advertising to a
<t> BR in D2.</t>
A BR in D2 receiving (E, C1) maps C1 in received LCM-EC to local </li>
color, say C2. <li>
<list style="symbols"> <t>A BR in D2 receiving (E, C1) maps C1 in received LCM-EC to
<t>A BR in D2 may receive (E, C1) from multiple D1 BRs which provide local color, say C2.</t>
<ul spacing="normal">
<li>
<t>A BR in D2 may receive (E, C1) from multiple D1 BRs, which pr
ovide
equal cost or primary/backup paths.</t> equal cost or primary/backup paths.</t>
</list> </li>
</t> </ul>
<t> </li>
<li>
<t>
Within D2, this LCM-EC value of C2 is used instead of the Color in Within D2, this LCM-EC value of C2 is used instead of the Color in
CAR route NLRI (E, C1). This applies to all procedures described in the CAR route NLRI (E, C1). This applies to all procedures described in the
earlier section for a single color domain, such as next-hop resolution and earlier section for a single color domain, such as next-hop resolution and
service steering. service steering.
</t> </t>
<t> </li>
<li>
<t>
A colored service route V/v originated in color domain D1 with next hop E A colored service route V/v originated in color domain D1 with next hop E
and Color-EC C1 will also have its color extended-community value re-mapped and Color-EC C1 will also have its Color-EC value re-mapped
to C2, typically at a service RR. to C2, typically at a service RR.
</t> </t>
<t> </li>
<li>
<t>
On an ingress PE in D2, V/v will resolve via C2. On an ingress PE in D2, V/v will resolve via C2.
</t> </t>
<t> </li>
<li>
<t>
When a BR in D2 advertises the route to a BR in D3, the same process When a BR in D2 advertises the route to a BR in D3, the same process
repeats. repeats.
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
</section> </section>
<section anchor="SRv6ILLUS">
<section anchor="SRv6ILLUS" title="CAR SRv6 Illustrations"> <name>CAR SRv6 Illustrations</name>
<section anchor="SECLOCHBYH" <section anchor="SECLOCHBYH">
title="BGP CAR SRv6 locator reachability hop by hop distribution"> <name>BGP CAR SRv6 Locator Reachability Hop-by-Hop Distribution</name>
<figure anchor="SRv6LOCHopByHOP"> <figure anchor="SRv6LOCHopByHOP">
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ SRv6SID=B:C11:2:DT4:: +-----+ +-----+ SRv6SID=B:C11:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <..... ...... |S-RR1| <..................................|S-RR2| <.....
: +-----+ +-----+ : : +-----+ +-----+ :
: : : :
: : : :
: AS2 AS1 : : AS2 AS1 :
+-:------------------------------------+ +--------------:--+ +-:------------------------------------+ +--------------:--+
| : | | : | | : | | : |
| : B:C11::/32 via IP1 | | : | | : B:C11::/32 via IP1 | | : |
| : +-----+ LCM=C1, AIGP=10 | | : | | : +-----+ LCM=C1, AIGP=10 | | : |
| : | TRR |<.............. | | : | | : | TRR |<.............. | | : |
| : +-----+<.......... : | | : | | : +-----+<.......... : | | : |
| : : B:C11::/32 : : | | : | | : : B:C11::/32 : : | | : |
| : : via IP2 : : | | : | | : : via IP2 : : | | : |
| : : LCM=C1,AIGP=10: : | | : | | : : LCM=C1,AIGP=10: : | | : |
| : ......... : : : | B:C11::/32 | : | | : ......... : : : | B:C11::/32 | : |
| : : : : : | via 231 | +-----| | : : : : : | via 231 | +-----|
| : : : : : | LCM=C1 | | E2 | | : : : : : | LCM=C1 | | E2 |
: : +---+ : +---+ : : | AIGP=10 | +-----| : : +---+ : +---+ : : | AIGP=10 | +-----|
| : : |P11|<.:..>|P13| : +----+ +---+ : | | : : |P11|<.:..>|P13| : +----+ +---+ : |
| : : +---+ : +---+ : | 121|-----IP1|231| : | | : : +---+ : +---+ : | 121|-----IP1|231| : |
| V V : : +----+ eBGP +---+ : | | V V : : +----+ eBGP +---+ : |
|----+ : : | | +-----| |----+ : : | | +-----|
| E1 | +---+ : +---+ : | | | En | | E1 | +---+ : +---+ : | | | En |
|----+ |P12|<.:..>|P14| : | | +-----| |----+ |P12|<.:..>|P14| : | | +-----|
| +---+ +---+ : +----+ eBGP +---+ | | +---+ +---+ : +----+ eBGP +---+ |
| IPv6 FIB: ...| 122|-----IP2|232| | | IPv6 FIB: ...| 122|-----IP2|232| |
| B:C11::/32 via IP1 +----+ +---+ | | B:C11::/32 via IP1 +----+ +---+ |
| via IP2 | B:C11::/32 | | | via IP2 | B:C11::/32 | |
| | via 232 | | | | via 232 | |
| | LCM=C1 | | | | LCM=C1 | |
| | AIGP=10 | | | | AIGP=10 | |
| IS-ISv6 | | IS-ISv6 | | IS-ISv6 | | IS-ISv6 |
| FA 128 (B:C12::/32) | |FA128(B:C11::/32)| | FA128 (B:C12::/32) | |FA128(B:C11::/32)|
| FA 0 (B:02::/32) | |FA0 (B:01::/32) | | FA0 (B:02::/32) | |FA0 (B:01::/32) |
+--------------------------------------+ +-----------------+ +--------------------------------------+ +-----------------+
iPE ASBR ASBR ePE iPE ASBR ASBR ePE
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The topology above is an example to illustrate the BGP CAR SRv6 l <t>The topology above is an example to illustrate the BGP CAR SRv6
ocator locator prefix route-based design (<xref target="SECRTDSSID"/>) with
prefix route based design (Routed Service SID: <xref target="SECRTDS hop-by-hop IPv6 routing within and between domains.
SID"/>), with hop by hop IPv6 routing </t>
within and between domains. <ul spacing="normal">
<list style="symbols"> <li>
<t>Multi-AS network with eBGP CAR session between ASBRs.</t> <t>Multi-AS network with eBGP CAR session between ASBRs.</t>
<t>Transport RR (TRR) peers with P, BR and PE clients within an AS </li>
to propagate <li>
CAR prefixes. AddPath is enabled to propagate multiple paths.</t> <t>Transport RR (TRR) peers with P, BR, and PE clients within an AS
<t>IS-IS (IGP) Flex-Algo 128 for SRv6 is running in each AS (AS ma to propagate
y consist CAR prefixes. ADD-PATH is enabled to propagate multiple paths.</t>
</li>
<li>
<t>IS-IS (IGP) Flex-Algo 128 for SRv6 is running in each AS (AS may
consist
of multiple IGP domains), where the following steps apply: of multiple IGP domains), where the following steps apply:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in AS1 for t he given <t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in AS1 for t he given
intent. Node locators in the egress domain are sub-allocated fro m the intent. Node locators in the egress domain are sub-allocated fro m the
block for the given intent.</t> block for the given intent.</t>
</li>
<li>
<t>Similarly, Prefix B:C12::/32 summarizes Flex-Algo 128 block i n AS2.</t> <t>Similarly, Prefix B:C12::/32 summarizes Flex-Algo 128 block i n AS2.</t>
</li>
<li>
<t>Per Flex-Algo external subnets for eBGP next hops IP1 and IP2 are <t>Per Flex-Algo external subnets for eBGP next hops IP1 and IP2 are
distributed in IS-IS within AS2.</t> distributed in IS-IS within AS2.</t>
</list> </li>
</t> </ul>
<t>BGP CAR prefix route B:C11::/32 with LCM C1 is originated by AS </li>
1 <li>
<t>BGP CAR prefix route B:C11::/32 with LCM C1 is originated by AS1
BRs 231 and 232 on eBGP sessions to AS2 BRs 121 and 122.</t> BRs 231 and 232 on eBGP sessions to AS2 BRs 121 and 122.</t>
<t>ASBR 121 and 122 propagate the route in AS2 to all the P, ABRs </li>
and PEs <li>
through transport RR.</t> <t>ASBR 121 and 122 propagate the route in AS2 to all the P, ABRs, a
<t>Every router in AS2 resolves BGP CAR prefix B:C11::/32 next hop nd PEs
s through TRR.</t>
</li>
<li>
<t>Every router in AS2 resolves BGP CAR prefix B:C11::/32 next hops
IP1 and IP2 in IS-ISv6 Flex-Algo 128 and programs B:C11::/32 prefi x in global IP1 and IP2 in IS-ISv6 Flex-Algo 128 and programs B:C11::/32 prefi x in global
IPv6 forwarding table.</t> IPv6 forwarding table.</t>
<t>AIGP attribute influences BGP CAR route best path decision.</t> </li>
<t>Egress PE E2 advertises a VPN route RD:V/v with SRv6 service <li>
<t>AIGP attribute influences BGP CAR route best path decision.</t>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v with SRv6 Service
SID B:C11:2:DT4::. Service SID is allocated by E2 from its locator of SID B:C11:2:DT4::. Service SID is allocated by E2 from its locator of
color C1 intent.</t> color C1 intent.</t>
<t>Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN rout </li>
e RD:V/v <li>
<t>Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN route
RD:V/v
with SRv6 SID B:C11:2:DT4::.</t> with SRv6 SID B:C11:2:DT4::.</t>
<t>Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4: </li>
: is <li>
natively steered hop by hop along IPv6 routed path to B:C11::/32 p <t>Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4::
rovided is
inherently steered hop by hop along IPv6 routed path to B:C11::/32
provided
by BGP CAR in AS2.</t> by BGP CAR in AS2.</t>
<t>Encapsulated service traffic is natively steered along IPv6 rou </li>
ted path <li>
<t>Encapsulated service traffic is inherently steered along IPv6 rou
ted path
to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in AS1.</t> to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in AS1.</t>
<t> Design applies to multiple ASNs. BGP next hop is rewritten acr </li>
oss a eBGP hop.</t> <li>
</list> <t>Design applies to multiple ASNs. BGP next hop is rewritten across
</t> an eBGP hop.</t>
<t>Important: </li>
<list style="symbols"> </ul>
<t>No tunneling/encapsulation on Ingress PE and BRs for BGP CAR pr <t>Important:
ovided </t>
<ul spacing="normal">
<li>
<t>No tunneling/encapsulation on ingress PE and BRs for BGP CAR prov
ided
transport.</t> transport.</t>
<t>Uses longest prefix match of SRv6 service SID to BGP CAR IP pre </li>
fix. <li>
No mapping to labels/SIDs, instead use of simple IP based forwardi <t>Uses longest prefix match of SRv6 Service SID to BGP CAR IP prefi
ng.</t> x.
</list> No mapping to labels/SIDs, instead use of simple IP-based forwardi
</t> ng.</t>
<t>Packet forwarding</t> </li>
<figure> </ul>
<t>Packet forwarding:</t>
<artwork><![CDATA[ <artwork><![CDATA[
@E1: IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => forward based on @E1: IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => Forward based
B:C11::/32 on B:C11::/32
@P*: IPv6 table: B:C11::/32 => forward to interface, NH @P*: IPv6 table: B:C11::/32 => Forward to interface, NH
@121: IPv6 Table: B:C11::/32 => forward to interface, NH @121: IPv6 Table: B:C11::/32 => Forward to interface, NH
@231: IPv6 table: B:C11:2::/48 :: => forward via IS-ISv6 FA path to E2 @231: IPv6 table: B:C11:2::/48 :: => Forward via IS-ISv6 Flex-Algo
@231: IPv6 Table B:C11:2::/48 => forward via IS-ISv6 FA path to E2 path to E2
@E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the @231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo
inner DA in the VRF path to E2
]]></artwork> @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
</figure> the inner DA in the VRF
]]></artwork>
</section> </section>
<section anchor="SECSRv6LOCencap" <section anchor="SECSRv6LOCencap">
title="BGP CAR SRv6 locator reachability distribution with encapsulation <name>BGP CAR SRv6 Locator Reachability Distribution with Encapsulation<
"> /name>
<figure anchor="SRv6LOCencap"> <figure anchor="SRv6LOCencap">
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ SRv6SID=B:C11:2:DT4:: +-----+ +-----+ SRv6SID=B:C11:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ +-----+ : : +-----+ +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:--+ +-:-----------------------+----------------------+------------------:--+
| : | | : | | : | | : |
skipping to change at line 3634 skipping to change at line 4102
| | | | | En | | | | | | En |
| | | | +-----| | | | | +-----|
| | +---+ +---+ | | | | +---+ +---+ | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| +---+ +---+ | | +---+ +---+ |
| B:C11::/32 via 122 | B:C11::/32 via 232 | | | B:C11::/32 via 122 | B:C11::/32 via 232 | |
| SID=B:C13:122:END:: | SID=B:C12:232:END:: | | | SID=B:C13:122:END:: | SID=B:C12:232:END:: | |
| LCM=C1 AIGP=120 | LCM=C1 AIGP=20 | | | LCM=C1 AIGP=120 | LCM=C1 AIGP=20 | |
| | | | | | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 | | IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA 128 (B:C13::/32) | FA 128 (B:C12::/32) | FA128 (B:C11::/32) | | FA128 (B:C13::/32) | FA128 (B:C12::/32) | FA128 (B:C11::/32) |
| FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA1 0 (B:01::/32) | | FA0 (B:03::/32) | FA0 (B:02::/32) | FA0 (B:01::/32) |
+-------------------------+----------------------+---------------------+ +-------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The topology above is an example to illustrate the BGP CAR SRv6 loc <t>The topology above is an example to illustrate the BGP CAR SRv6 locat
ator or
prefix route based design (Routed Service SID: <xref target="SECRTDSSI prefix route-based design (<xref target="SECRTDSSID"/>) with intra-dom
D"/>), with intra-domain encapsulation. ain encapsulation.
The example shown is iBGP, but also applies to eBGP (multi-AS). The example shown is iBGP, but also applies to eBGP (multi-AS).
<list style="symbols"> </t>
<t>IGP Flex-Algo 128 is running in each domain, where <ul spacing="normal">
<list style="symbols"> <li>
<t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress doma <t>IGP Flex-Algo 128 is running in each domain, where:
in for the </t>
<ul spacing="normal">
<li>
<t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress do
main for the
given intent. Node locators in the egress domain are sub-allocated from given intent. Node locators in the egress domain are sub-allocated from
the block.</t> the block.</t>
<t>Prefix B:C12::/32 summarizes FA128 block in transit domain.</t> </li>
<t>Prefix B:C13::/32 summarizes FA128 block in ingress domain.</t> <li>
</list> <t>Prefix B:C12::/32 summarizes Flex-Algo 128 block in transit d
</t> omain.</t>
</li>
<li>
<t>Prefix B:C13::/32 summarizes Flex-Algo 128 block in ingress d
omain.</t>
</li>
</ul>
</li>
<li>
<t>BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with L CM C1. <t>BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with L CM C1.
Along the propagation path, border routers set next-hop-self and app ropriately Along the propagation path, BRs set next-hop-self and appropriately
update the intra-domain encapsulation information for the C1 intent. update the intra-domain encapsulation information for the C1 intent.
For example, 231 and 121 signal SRv6 SID of END behavior For example, 231 and 121 signal SRv6 SID of End behavior
<xref target="RFC8986"/> allocated from their respective <xref target="RFC8986"/> allocated from their respective
locators for the C1 intent. (Note: IGP Flex-Algo is shown for intra- locators for the C1 intent. (Note: IGP Fleixible Algorithm is shown
domain path, for intra-domain path,
but SR-Policy may also provide the path as shown in but SR Policy may also provide the path as shown in
<xref target="SECSRv6EC"/>).</t> <xref target="SECSRv6EC"/>.)</t>
</li>
<li>
<t>AIGP attribute influences BGP CAR route best path decision.</t> <t>AIGP attribute influences BGP CAR route best path decision.</t>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v with SRv6 <t>Egress PE E2 advertises a VPN route RD:V/v with SRv6
service SID B:C11:2:DT4::. Service SID is allocated by E2 from its Service SID B:C11:2:DT4::. Service SID is allocated by E2 from its
locator of color C1 intent.</t> locator of color C1 intent.</t>
</li>
<li>
<t>Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v wi th <t>Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v wi th
SRv6 SID B:C11:2:DT4::.</t> SRv6 SID B:C11:2:DT4::.</t>
</li>
<li>
<t>Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is steer ed <t>Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is steer ed
along IPv6 routed path provided by BGP CAR IP prefix route to locato r along IPv6 routed path provided by BGP CAR IP Prefix route to locato r
B:C11::/32.</t> B:C11::/32.</t>
</list> </li>
</t> </ul>
<t>Important <t>Important:
<list style="symbols"> </t>
<t>Uses longest prefix match of SRv6 service SID to BGP CAR prefix. <ul spacing="normal">
No mapping labels/SIDs, instead simple IP based forwarding.</t> <li>
<t>Uses longest prefix match of SRv6 Service SID to BGP CAR prefix.
There is no mapping labels/SIDs; there is simple IP-based forwarding
instead.</t>
</li>
<li>
<t>Originating domain PE locators of the given intent can be summari zed on <t>Originating domain PE locators of the given intent can be summari zed on
transit BGP hops eliminating per PE state on border routers.</t> transit BGP hops eliminating per PE state on BRs.</t>
</list> </li>
</t> </ul>
<t> Packet forwarding</t> <t>Packet forwarding:</t>
<figure>
<artwork><![CDATA[ <artwork><![CDATA[
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::> @E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4:: @121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::> @121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::>
@231: My SID table: B:C12:231:END:: => Remove IPv6 header; Inner DA B:C11:2:DT4: @231: My SID table: B:C12:231:END:: => Remove IPv6 header;
: Inner DA B:C11:2:DT4::
@231: IPv6 Table B:C11:2::/48 => forward via IS-ISv6 FA path to E2 @231: IPv6 Table B:C11:2::/48 => Forward via IS-ISv6 Flex-Algo
@E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the path to E2
inner DA in the VRF @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
]]></artwork> the inner DA in the VRF
</figure> ]]></artwork>
</section> </section>
<section anchor="SECSRv6EC" <section anchor="SECSRv6EC">
title="BGP CAR (E, C) route distribution for steering non-routed service <name>BGP CAR (E, C) Route Distribution for Steering Non-Routed Service
SID"> SID</name>
<figure anchor="SRv6EC"> <figure anchor="SRv6EC">
<artwork><![CDATA[ <artwork><![CDATA[
RD:V/v via E2 RD:V/v via E2
+-----+ SRv6SID: B:01:2:DT4:: +-----+ +-----+ SRv6SID: B:01:2:DT4:: +-----+
...... |S-RR1| <..................................|S-RR2| <....... ...... |S-RR1| <..................................|S-RR2| <.......
: +-----+ Color C2 +-----+ : : +-----+ Color C2 +-----+ :
: : : :
: +-----+ (E2,C2) via 231 : : +-----+ (E2,C2) via 231 :
: -----------------| TRR |-------------------| : : -----------------| TRR |-------------------| :
:| +-----+ SID=B:C21:2:B6:: | : :| +-----+ SID=B:C21:2:B6:: | :
+-:|---------------------+---------------------|+------------------:--+ +-:|---------------------+---------------------|+------------------:--+
| :| | || : | | :| | || : |
| :| | || : | | :| | || : |
| :| B:C21::/32 via 121 | B:C21::/32 via 231 ||SR policy(E2,C2) : | | :| B:C21::/32 via 121 | B:C21::/32 via 231 ||SR Policy(E2,C2) : |
| :| LCM=C2,AIGP=110 | LCM=C2 AIGP=10 ||BSID=B:C21:2:B6:: : | | :| LCM=C2,AIGP=110 | LCM=C2 AIGP=10 ||BSID=B:C21:2:B6:: : |
| :| +---+ +---+ : | | :| +---+ +---+ : |
| :|-------------------|121|<-----------------|231|<-------------| : | | :|-------------------|121|<-----------------|231|<-------------| : |
| :V SR policy(121,C2) +---+SR policy(231,C2) +---+ | : | | :V SR Policy(121,C2) +---+SR Policy(231,C2) +---+ | : |
|----+ | | +-----| |----+ | | +-----|
| E1 | | | | E2 | | E1 | | | | E2 |
|----+ | | +-----| |----+ | | +-----|
| ^ SR policy(122,C2) +---+SR policy(232,C2) +---+ | | | ^ SR Policy(122,C2) +---+SR Policy(232,C2) +---+ | |
| |---------------- |122|<-----------------|232|<-------------| | | |---------------- |122|<-----------------|232|<-------------| |
| B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR policy(E2,C2) | | B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR Policy(E2,C2) |
| LCM=C2,AIGP=120 | LCM=C2 AIGP=20 | BSID=B:C21:2:B6:: | | LCM=C2,AIGP=120 | LCM=C2 AIGP=20 | BSID=B:C21:2:B6:: |
| | | | | | | |
| IS-ISv6 | IS-ISv6 | IS-ISv6 | | IS-ISv6 | IS-ISv6 | IS-ISv6 |
| FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA 0(B:01::/32) | | FA0 (B:03::/32) | FA0 (B:02::/32) | FA0(B:01::/32) |
+------------------------+----------------------+---------------------+ +------------------------+----------------------+---------------------+
iPE iABR eABR ePE iPE iABR eABR ePE
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The topology above is an example to illustrate the BGP CAR (E, C) r <t>The topology above is an example to illustrate the BGP CAR (E, C)
oute route-based design (<xref target="SECNRSSID"/>). The example is iBGP,
based design (<xref target="SECNRSSID"/>). The example is iBGP, but de but the design also applies to eBGP (multi-AS).
sign </t>
also applies to eBGP (multi-AS). <ul spacing="normal">
<list style="symbols"> <li>
<t>SR policy (E2, C2) provides given intent in egress domain. <t>SR Policy (E2, C2) provides given intent in egress domain.
<list style="symbols">
<t>SR policy (E2, C2) with segments &lt;B:01:z:END::, B:01:2:END:
:&gt;
where z is the node id in egress domain.</t>
</list>
</t> </t>
<t>Egress ABRs 231 and 232 redistribute SR policy into BGP CAR Type- <ul spacing="normal">
1 NLRI <li>
<t>SR Policy (E2, C2) with segments &lt;B:01:z:END::, B:01:2:EN
D::&gt;,
where z is the node id in egress domain.</t>
</li>
</ul>
</li>
<li>
<t>Egress ABRs 231 and 232 redistribute SR Policy into BGP CAR Type-
1 NLRI
(E2, C2) to other domains, with SRv6 SID of End.B6 behavior. This ro ute is (E2, C2) to other domains, with SRv6 SID of End.B6 behavior. This ro ute is
propagated to ingress PEs through transport RR (TRR) or inline with propagated to ingress PEs through TRR or inline with next-hop-unchan
next hop ged.</t>
unchanged.</t> </li>
<li>
<t>The ABRs also advertise BGP CAR prefix route (B:C21::/32) summari zing locator <t>The ABRs also advertise BGP CAR prefix route (B:C21::/32) summari zing locator
part of SRv6 SIDs for SR policies of given intent to different PEs i n part of SRv6 SIDs for SR policies of given intent to different PEs i n
egress domain. BGP CAR prefix route propagates through border router s. egress domain. BGP CAR prefix route propagates through BRs.
At each BGP hop, BGP CAR prefix next-hop resolution triggers intra-d omain At each BGP hop, BGP CAR prefix next-hop resolution triggers intra-d omain
transit SR policy (C2, CAR next hop). For example: transit SR Policy (C2, CAR next hop). For example:
<list style="symbols">
<t>SR policy (231, C2) with segments &lt;B:02:y:END::, B:02:231:EN
D::&gt;, and
</t>
<t>SR policy (121, C2) with segments &lt;B:03:x:END::, B:03:121:EN
D::&gt;,</t>
<t>where x and y are node ids within the respective domains.</t>
</list>
</t> </t>
<ul spacing="normal">
<li>
<t>SR Policy (231, C2) with segments &lt;B:02:y:END::, B:02:231:
END::&gt;, and
</t>
</li>
<li>
<t>SR Policy (121, C2) with segments &lt;B:03:x:END::, B:03:121:
END::&gt;,</t>
</li>
<li>
<t>where x and y are node ids within the respective domains.</t>
</li>
</ul>
</li>
<li>
<t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2.</t> <t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2.</t>
</li>
<li>
<t>Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2 ) that <t>Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2 ) that
results in H.Encaps.red of SRv6 transport SID B:C21:2:B6:: and SRv6 service SID results in H.Encaps.red of SRv6 transport SID B:C21:2:B6:: and SRv6 Service SID
as last segment in IPv6 header.</t> as last segment in IPv6 header.</t>
</li>
<li>
<t>IPv6 destination B:C21:2:B6:: match on CAR prefix B:C21::/32 that <t>IPv6 destination B:C21:2:B6:: match on CAR prefix B:C21::/32 that
steers the packet into intra-domain (intent-aware) SR Policy on ingr ess PE E1 steers the packet into intra-domain (intent-aware) SR Policy on ingr ess PE E1
and ABR 121.</t> and ABR 121.</t>
</li>
<li>
<t>IPv6 packet destination B:C21:2:B6:: lookup in mySID table on ABR <t>IPv6 packet destination B:C21:2:B6:: lookup in mySID table on ABR
231 or 232 results in END.B6 behavior (i.e., push of policy segments to E2).</t> 231 or 232 results in END.B6 behavior (i.e., push of policy segments to E2).</t>
</list> </li>
</t> </ul>
<t>Important <t>Important:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>Ingress PE steers services via (E, C) CAR route as per <t>Ingress PE steers services via (E, C) CAR route as per
<xref target="RFC9256"/>.</t> <xref target="RFC9256"/>.</t>
<t>In data plane (E, C) resolution results in IPv6 header destinatio </li>
n being <li>
<t>In data plane (E, C), resolution results in IPv6 header destinati
on being
SRv6 SID of END.B6 behavior whose locator is of given intent on SRv6 SID of END.B6 behavior whose locator is of given intent on
originating ABRs.</t> originating ABRs.</t>
<t>CAR IP prefix route along the transit path provides simple LPM IP </li>
v6 forwarding <li>
<t>CAR IP Prefix route along the transit path provides simple Longes
t Prefix Match (LPM) IPv6 forwarding
along the transit BGP hops.</t> along the transit BGP hops.</t>
</li>
<li>
<t>CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies on <t>CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies on
originating ABR of a given intent to different PEs in egress domain. originating ABR of a given intent to different PEs in egress domain.
This eliminates per PE state on transit routers.</t> This eliminates per PE state on transit routers.</t>
</list> </li>
</t> </ul>
<t>Packet forwarding</t> <t>Packet forwarding:</t>
<figure> <artwork><![CDATA[
<artwork><![CDATA[
@E1: IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::> @E1: IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::>
H.Encaps.red <SR policy (C2,121) sid list> H.Encaps.red <SR Policy (C2,121) sid list>
@121: My SID table: B:03:121:END:: => Remove outer IPv6 header; Inner DA B:C21:2 @121: My SID table: B:03:121:END:: => Remove outer IPv6 header;
:B6:: Inner DA B:C21:2:B6::
@121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid @121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid
list> list>
@231: My SID table: B:02:231:END:: => Remove outer IPv6 header; Inner DA B:C21:2 @231: My SID table: B:02:231:END:: => Remove outer IPv6 header;
:B6:: Inner DA B:C21:2:B6::
@231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid @231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid
list> list>
@E2: IPv6 Table B:0:2:DT4:: =>pop the outer header and lookup the @E2: IPv6 Table B:0:2:DT4:: => Pop the outer header and look up the
inner DA in the VRF inner DA in the VRF
]]></artwork> ]]></artwork>
</figure>
</section> </section>
</section> </section>
<section anchor="UPDATEPACKING" title="CAR SAFI NLRI update packing efficien <section anchor="UPDATEPACKING">
cy <name>CAR SAFI NLRI Update Packing Efficiency Calculation</name>
calculation">
<t> <t>
CAR SAFI NLRI encoding is optimized for update packing. It allows CAR SAFI NLRI encoding is optimized for update packing. It allows
per route information (for example label, label index and SRv6 SID encapsu per-route information (for example, label, label index, and SRv6 SID encap
lation data) to be sulation data) to be
carried in non-key TLV part of NLRI. This allows multiple NLRIs to be pack carried in the non-key TLV part of NLRI. This allows multiple NLRIs to be
ed in packed in a
single update message when other attributes (including LCM-EC when present single update message when other attributes (including LCM-EC, when presen
) are shared. t) are shared.
The table below shows a theoretical analysis calculated from observed BGP update message The table below shows a theoretical analysis calculated from observed BGP update message
size in operational networks. It compares total BGP data on the wire for C size in operational networks. It compares total BGP data on the wire for C
AR SAFI and AR SAFI against encoding as specified in [RFC8277] in the following cases: an MP
<xref target="RFC8277"/> style encoding in MPLS label (CASE A), LS label (CASE A), an SR extension with MPLS
SR extension with MPLS (per-prefix label index in Prefix-SID attribute) (per-prefix label index in Prefix-SID attribute; see [RFC8669]) (CASE B), and
<xref target="RFC8669"/> (CASE B) and SRv6 SID (CASE C) cases. an SRv6 SID (CASE C).
Scenarios considered are ideal packing (maximum number of routes The packing scenarios considered are as follows:</t>
packed to update message limit of 4k bytes), practical deployment <ul>
case with average packing (5 routes share set of BGP path attributes and h <li>the ideal case (where the maximum number of routes are packed to the
ence update message
packed in single update message) and worst-case of no packing limit of 4k bytes),</li>
(each route in separate update message). <li>the practical case of average packing (where 5 routes share a set
</t> of BGP path attributes, and hence are packed in a single update
message), and</li>
<li>the worst case of no packing (where each route is in a separate updat
e message).</li>
</ul>
<t> <table anchor="UPFIGURE">
<figure anchor="UPFIGURE" title="Summary of ideal, practical and no-packin <name>Summary of the Ideal, Practical, and Worst Cases of Packing BGP Data</na
g BGP data in each case"> me>
<artwork><![CDATA[ <thead>
Encoding | BGP CAR |RFC-8277 style | Result <tr>
| NLRI |NLRI | <th>Encoding</th>
CASE A: Label | | | <th>BGP CAR NLRI</th>
(Ideal) | 27.5 MB | 26 MB | <th>NLRI as per <xref target="RFC8277"/></th>
+--------------+----------------+ No degradation from <th>Result</th>
(Practical) | 86 MB | 84 MB | RFC8277 like encoding </tr>
+--------------+----------------+ </thead>
(No packing) | 325 MB | 324 MB | <tbody>
CASE B: Label | | 339 MB | CAR SAFI encoding more <tr>
& Label-index | | Packing not | efficient by 88% in <th colspan="4">CASE A: Label</th>
(Ideal) | 42 MB | possible | best case and 71% in </tr>
+--------------+----------------+ average case over <tr>
(Practical) | 99 MB | 339 MB | RFC8277 style encoding <td>(Ideal)</td>
| | Packing not | (which precludes <td>27.5&nbsp;MB</td>
| | possible | packing) <td>26 MB</td>
+--------------+----------------+ <td rowspan="3">No degradation compared to encoding as specified in <xref
(No packing) | 339 MB | 339 MB | target="RFC8277"/>.</td>
| | | </tr>
CASE C: SRv6 SID| | | Results are similar to <tr>
(Ideal) | 49 MB | 378 MB | SR MPLS case. <td>(Practical)</td>
| | | Transposition provides <td>86&nbsp;MB</td>
+--------------+----------------+ further 20% reduction <td>84 MB</td>
(Practical) | 115 MB | 378 MB | in BGP data. </tr>
+--------------+----------------+ <tr>
(No packing) | 378 MB | 378 MB | <td>(Worst; no packing)</td>
<td>325&nbsp;MB</td>
<td>324 MB</td>
</tr>
]]></artwork> <tr>
</figure> <th colspan="4">CASE B: Label &amp; Label-Index</th>
</t> </tr>
<tr>
<td>(Ideal)</td>
<td>42&nbsp;MB</td>
<td>339 MB Packing not possible</td>
<td rowspan="3">CAR SAFI encoding is more efficient by 88% in the best cas
e and
71% in the average case over the encoding as specified in <xref target="RF
C8277"/> (which precludes
packing).</td>
</tr>
<tr>
<td>(Practical)</td>
<td>99&nbsp;MB</td>
<td>339 MB Packing not possible</td>
</tr>
<tr>
<td>(Worst; no packing)</td>
<td>339&nbsp;MB</td>
<td>339 MB</td>
</tr>
<t>Analysis considers 1.5 million routes (5 colors across 300k endpoints) <tr>
</t> <th colspan="4">CASE C: SRv6 SID</th>
</tr>
<tr>
<td>(Ideal)</td>
<td>49&nbsp;MB</td>
<td>378 MB Packing not possible</td>
<td rowspan="3">Results are similar to the SR-MPLS case. Transposition pro
vides a further 20% reduction in BGP data.</td>
</tr>
<tr>
<td>(Practical)</td>
<td>115&nbsp;MB</td>
<td>378 MB Packing not possible</td>
</tr>
<tr>
<td>(Worst; no packing)</td>
<td>378&nbsp;MB</td>
<td>378 MB</td>
</tr>
</tbody>
</table>
<t>CASE A: BGP data exchanged for non SR MPLS case <t>This analysis considers 1.5 million routes (5 colors across 300k endpoi
<figure> nts).</t>
<artwork><![CDATA[ <t>CASE A: BGP data exchanged for MPLS (non-SR):</t>
<artwork><![CDATA[
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals label in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 223 (4k-200/17) Number of NLRIs in 4k update size = 223 (4k-200/17)
number of update messages of 4k size = 1.5 million/223 = 6726 Number of update messages of 4k size = 1.5 million/223 = 6726
Total BGP data on wire = 6726 * 4k = ~27.5MB Total BGP data on wire = 6726 * 4k = ~27.5 MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
size of update message = (17 * 5) + 200 = 285 Size of update message = (17 * 5) + 200 = 285
Total BGP data on wire = 285 * 300k = ~86MB Total BGP data on wire = 285 * 300k = ~86 MB
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message = 17 + 200 = 217 Size of update message = 17 + 200 = 217
Total BGP data on wire = 217 * 1.5 million = ~325MB Total BGP data on wire = 217 * 1.5 million = ~325 MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 237 (4k-200/16) Number of NLRIs in 4k update size = 237 (4k-200/16)
number of update messages of 4k size = 1.5 million/237 = ~6330 Number of update messages of 4k size = 1.5 million/237 = ~6330
Total BGP data on wire = 6330 * 4k = ~25.9MB Total BGP data on wire = 6330 * 4k = ~25.9 MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
size of update message = (16 * 5) + 200 = 280 Size of update message = (16 * 5) + 200 = 280
Total BGP data on wire = 280 * 300k = ~84MB Total BGP data on wire = 280 * 300k = ~84 MB
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message = 16 + 200 = 216 Size of update message = 16 + 200 = 216
Total BGP data on wire = 216 * 1.5 million = ~324MB Total BGP data on wire = 216 * 1.5 million = ~324 MB
]]></artwork> ]]></artwork>
</figure>
</t>
<t>CASE B: BGP data exchanged for SR label index <t>CASE B: BGP data exchanged for SR-MPLS label index:</t>
<figure> <artwork><![CDATA[
<artwork><![CDATA[
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals label index in non-key TLV part of NLRI
Each NLRI size for AFI 1 Each NLRI size for AFI 1
= 12(key) + 5(label) + 9(Index) = 26 bytes = 12(key) + 5(label) + 9(Index) = 26 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 146 (4k-200/26) Number of NLRIs in 4k update size = 146 (4k-200/26)
number of update messages of 4k size = 1.5 million/146 = 6726 Number of update messages of 4k size = 1.5 million/146 = 6726
Total BGP data on wire = 10274 * 4k = ~42MB Total BGP data on wire = 10274 * 4k = ~42 MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message)
size of update message = (26 * 5) + 200 = 330 Size of update message = (26 * 5) + 200 = 330
Total BGP data on wire = 330 * 300k = ~99MB Total BGP data on wire = 330 * 300k = ~99 MB
No-packing case (1 route per update message) No-packing case (1 route per update message)
size of update message = 26 + 200 = 226 Size of update message = 26 + 200 = 226
Total BGP data on wire = 226 * 1.5 million = ~339MB Total BGP data on wire = 226 * 1.5 million = ~339 MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 using encoding specified in RFC 8277 with label in NLRI
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing Ideal packing:
Not supported as label index is encoded in Prefix-SID Not supported as label index is encoded in Prefix-SID
Attribute attribute
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
Not supported as label index is encoded in Prefix-SID Not supported as label index is encoded in Prefix-SID
Attribute attribute
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message = 16 + 210 = 226 Size of update message = 16 + 210 = 226
Total BGP data on wire = 216 * 1.5 million = ~339MB Total BGP data on wire = 216 * 1.5 million = ~339 MB
]]></artwork> ]]></artwork>
</figure>
</t>
<t>CASE C: BGP data exchanged with 128 bit single SRv6 SID <t>CASE C: BGP data exchanged with 128 bit single SRv6 SID:</t>
<figure> <artwork><![CDATA[
<artwork><![CDATA[
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 18(Srv6 SID) = 30 bytes Each NLRI size for AFI 1 = 12(key) + 18(SRv6 SID) = 30 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 126 (4k-200/30) Number of NLRIs in 4k update size = 126 (4k-200/30)
number of update messages of 4k size = 1.5 million/126 = ~12k Number of update messages of 4k size = 1.5 million/126 = ~12k
Total BGP data on wire = 12k * 4k = ~49MB Total BGP data on wire = 12k * 4k = ~49 MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
size of update message Size of update message
= (30 * 5) + 236 (including Prefix SID) = 386 = (30 * 5) + 236 (including Prefix-SID) = 386
Total BGP data on wire = 386 * 300k = ~115MB Total BGP data on wire = 386 * 300k = ~115 MB
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message = 12 + 236 (SID in Prefix SID) = 252 Size of update message = 12 + 236 (SID in Prefix-SID) = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378 MB
SAFI 128 8277 style encoding with label in NLRI (No transposition) SAFI 128 using encoding specified in RFC 8277 with label in NLRI
(No transposition)
Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
Ideal packing Ideal packing:
Not supported as label index is encoded in Prefix-SID Not supported as SRv6 SID is encoded in Prefix-SID
Attribute attribute
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
Not supported as label index is encoded in Prefix-SID Not supported as SRv6 SID is encoded in Prefix-SID
Attribute attribute
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message = 16 + 236 = 252 Size of update message = 16 + 236 = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378 MB
]]></artwork> ]]></artwork>
</figure>
</t>
<t>BGP data exchanged with SRv6 SID 4 bytes transposition into SRv6 SID TL <t>BGP data exchanged with transposition of 4 bytes from SRv6 SID into SRv
V 6 SID TLV:</t>
<figure> <artwork><![CDATA[
<artwork><![CDATA[
Consider 200 bytes of shared attributes Consider 200 bytes of shared attributes
CAR SAFI signal Label in non-key TLV part of NLRI CAR SAFI signals SRv6 SID in non-key TLV part of NLRI
Each NLRI size for AFI 1 = 12(key) + 6(Srv6 SID) = 18 bytes Each NLRI size for AFI 1 = 12(key) + 6(SRv6 SID) = 18 bytes
Ideal packing: Ideal packing:
number of NLRIs in 4k update size = 211 (4k-200/18) Number of NLRIs in 4k update size = 211 (4k-200/18)
number of update messages of 4k size = 1.5 million/211 = ~7110 Number of update messages of 4k size = 1.5 million/211 = ~7110
Total BGP data on wire = 7110 * 4k = ~29MB Total BGP data on wire = 7110 * 4k = ~29 MB
Practical packing (5 routes in update message) Practical packing (5 routes in update message):
size of update message Size of update message
= (18 * 5) + 236 (including Prefix SID) = 326 = (18 * 5) + 236 (including Prefix-SID) = 326
Total BGP data on wire = 326 * 300k = ~98MB Total BGP data on wire = 326 * 300k = ~98 MB
No-packing case (1 route per update message) No-packing case (1 route per update message):
size of update message Size of update message
= 12 + 236 (SID in Prefix-SID Attribute) = 252 = 12 + 236 (SID in Prefix-SID attribute) = 252
Total BGP data on wire = 252 * 1.5 million = ~378MB Total BGP data on wire = 252 * 1.5 million = ~378 MB
]]></artwork> ]]></artwork>
</figure> </section>
</t>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>
The authors would like to acknowledge the invaluable contributions of
many collaborators towards the BGP CAR solution and this document in
providing input about use cases, participating in brainstorming and
mailing list discussions and in reviews of the solution and draft
revisions. In addition to the contributors listed in the Contributors
section, the authors would like to thank <contact fullname="Robert
Raszuk"/>, <contact fullname="Bin Wen"/>, <contact fullname="Chaitanya
Yadlapalli"/>, <contact fullname="Satoru Matsushima"/>, <contact
fullname="Moses Nagarajah"/>, <contact fullname="Gyan Mishra"/>,
<contact fullname="Jorge Rabadan"/>, <contact fullname="Daniel Voyer"/>,
<contact fullname="Stephane Litkowski"/>, <contact fullname="Hannes
Gredler"/>, <contact fullname="Jose Liste"/>, <contact fullname="Jakub
Horn"/>, <contact fullname="Brent Foster"/>, <contact fullname="Dave
Smith"/>, <contact fullname="Jiri Chaloupka"/>, <contact fullname="Miya
Kohno"/>, <contact fullname="Kamran Raza"/>, <contact fullname="Zafar
Ali"/>, <contact fullname="Xing Jiang"/>, <contact fullname="Oleksander
Nestorov"/>, <contact fullname="Peter Psenak"/>, <contact
fullname="Kaliraj Vairavakkalai"/>, <contact fullname="Natrajan
Venkataraman"/>, <contact fullname="Srihari Sangli"/>, <contact
fullname="Ran Chen"/>, and <contact fullname="Jingrong Xie"/>. </t>
<t>The authors also appreciate the detailed reviews and astute
suggestions provided by <contact fullname="Sue Hares"/> (as document
shepherd), <contact fullname="Jeff Haas"/>, <contact fullname="Yingzhen
Qu"/>, and <contact fullname="John Scudder"/> that have greatly improved
the document.</t>
</section>
<section anchor="Contributors" numbered="false">
<name>Contributors</name>
<t>The following people gave substantial contributions to the content
of this document and should be considered as coauthors:</t>
<contact fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</contact>
<contact fullname="Bruno Decraene">
<organization>Orange</organization>
<address>
<postal>
<country>France</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</contact>
<contact fullname="Luay Jalil">
<organization>Verizon</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>luay.jalil@verizon.com</email>
</address>
</contact>
<contact fullname="Yuanchao Su">
<organization>Alibaba, Inc</organization>
<address>
<email>yitai.syc@alibaba-inc.com</email>
</address>
</contact>
<contact fullname="Jim Uttaro">
<organization>Individual</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>juttaro@ieee.org</email>
</address>
</contact>
<contact fullname="Jim Guichard">
<organization>Futurewei</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>james.n.guichard@futurewei.com</email>
</address>
</contact>
<contact fullname="Ketan Talaulikar">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>India</country>
</postal>
<email>ketant.ietf@gmail.com</email>
</address>
</contact>
<contact fullname="Keyur Patel">
<organization>Arrcus, Inc</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>keyur@arrcus.com</email>
</address>
</contact>
<contact fullname="Haibo Wang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>rainsword.wang@huawei.com</email>
</address>
</contact>
<contact fullname="Jie Dong">
<organization>Huawei Technologies</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>jie.dong@huawei.com</email>
</address>
</contact>
<t>Additional contributors:</t>
<contact fullname="Dirk Steinberg">
<organization>Lapishills Consulting Limited</organization>
<address>
<postal>
<country>Germany</country>
</postal>
<email>dirk@lapishills.com</email>
</address>
</contact>
<contact fullname="Israel Means">
<organization>AT&amp;T</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>im8327@att.com</email>
</address>
</contact>
<contact fullname="Reza Rokui">
<organization>Ciena</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>rrokui@ciena.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
<!-- [rfced] Terminology: Please review the following questions we have regardin
g
the terminology used in this document.
a) We note different capitalization of the terms below. Please review and let
us know each term should appear for consistency.
Label vs. label
DR# Label TLV when refering the the TLV.
DR# label when refering the the label value
DR# fixed inline
Color value vs. color value
DR# fixed inline
NLRI Type vs. NLRI type
DR# fixed inline
NLRI Length vs. NLRI length
DR# fixed inline
Key Length vs. Key length vs. key length
DR# fixed inline with Key length
c) How should "prefix" be capitalized in the different instances below?
BGP CAR IP Prefix routes vs. BGP CAR IP prefix route
CAR IP prefix route vs. CAR IP Prefix route
IP Prefix vs. IP prefix
DR# Fixed a couple of them inline. "IP Prefix" is used when referring to the CAR
route type, and "IP prefix" for the general reference to an IP prefix.
-->
 End of changes. 561 change blocks. 
3335 lines changed or deleted 3892 lines changed or added

This html diff was produced by rfcdiff 1.48.