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="September" year="2025"/>
<area>RTG</area>
<workgroup>idr</workgroup>
<date/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>Routing</area>
<workgroup>IDR WorkGroup</workgroup> <keyword>example</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 -- Label Index an
per-prefix information. This specification defines two NLRI types, Color-Awar d
e Route and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This
NLRI and IP Prefix NLRI. It defines non-key TLV types for MPLS label stack, L solution also defines a new Local Color Mapping (LCM) Extended Community.
abel Index </t>
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> <t>
BGP CAR adheres to the flat routing model of BGP-IP/LU(Labeled Unicast) bu t extends BGP CAR adheres to the flat routing model of BGP-IP/LU(Labeled Unicast) bu t extends
it to support intent-awareness, thereby providing a consistent operational experience it to support intent awareness, thereby providing a consistent operational experience
with those widely deployed transport routing technologies. with those widely deployed transport routing technologies.
</t> </t>
<section>
<name>Terminology</name>
<section title="Terminology"> <!-- [rfced] Section 1.1. Terminology: We have made the following changes in
<texttable> this section; please review and let us know if any adjustments are needed.
<ttcol width="20%"></ttcol>
<ttcol width="48%"></ttcol>
<c>Intent (in routing)</c> a) We have updated the text below to clarify the order of preference:
<c>Any behaviors to influence routing or path selection, including any
combination of the following
behaviors: a) Topology path selection
(e.g. minimize metric or avoid resource), b) NFV service insertion (e.
g. service
chain steering), c) per-hop behavior (e.g. a 5G slice). This is a more
specific concept
w.r.t. routing beyond best-effort, compared to intent as a declarative
abstraction in <xref target="RFC9315"/>.
</c>
<c></c> Original:
<c></c> If several such paths exist, a preference scheme is used to select the best
<c>Color</c> path (for example, IGP Flex-Algo preferred over SR Policy preferred over BGP C
<c>A non-zero 32-bit integer value associated with an intent (e.g. low AR.
-cost
, low-delay, or avoid some resources) as defined in
<xref target="RFC9256"/> Section 2.1. Color assignment is managed by t
he operator.</c>
<c></c> Current:
<c></c> If several such paths exist, a preference scheme is used to select the best
path (for example, IGP Flex-Algo is preferred over SR Policy, and SR Policy
is preferred over BGP CAR).
<c>Colored Service Route</c> b) We have updated "trust domain" to "trusted domain" in the text below
<c>An egress PE (e.g. E2) colors its BGP service (e.g. VPN) route (e.g for consistency with RFC 8402.
. V/v)
to indicate the intent that it requests for the traffic bound to V/v.
The color
is encoded as a BGP Color Extended-Community <xref target="RFC9012"/>,
used as per [RFC9256],
or represented by the locator part of SRv6 Service SID <xref target="R
FC9252"/>.</c>
<c></c> Original:
<c></c> In an SR deployment, the transport network is within a trust domain as per
[RFC8402].
<c>Color-Aware Path to (E2, C)</c> Current:
<c>A path to forward packets towards E2 which satisfies the intent ass In an SR deployment, the transport network is within a trusted domain as per
ociated with color C. [RFC8402].
Several technologies may provide a Color-Aware Path to (E2, C): SR Pol -->
icy
<xref target="RFC9256"/>, IGP Flex-Algo
<xref target="RFC9350"/>, BGP CAR [specified in this document].</c>
<c></c> <!-- [rfced] Section 1.1. (Abbreviations): We have the following
<c></c> questions regarding the abbreviations list in this section.
<c>Color-Aware Route (E2, C)</c> a) We were unable to find the term "BGP-LU" or "BGP Labeled Unicast SAFI"
<c>A distributed or signaled route that builds a color-aware path to E mentioned in RFC 8277. Is it the correct reference for this term?
2 for
color C.
</c>
<c></c> In addition, we also note the following different uses of this term throughout
<c></c> this document. Please review and let us know how to update for consistency.
<c>Service Route Automated Steering on Color-Aware Path</c> BGP IP/LU
<c>An ingress PE (or ASBR) E1 automatically steers traffic for a C-col BGP LU
ored service route BGP-IP/LU(Labeled Unicast)
V/v from E2 onto an (E2, C) color-aware path. If several such paths ex BGP LU/IP
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> Original:
<c></c> * BGP-LU: BGP Labeled Unicast SAFI [RFC8277].
<c>Color Domain</c> b) We were unable to find the term "BGP-IP" or "BGP IPv4/IPv6 Unicast AFI/SAFIs"
<c>A set of nodes which share the same Color-to-Intent mapping, typica in RFCs 4271 and 4760. How may we update?
lly under
Original:
* BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271], [RFC4760].
c) FYI - We have already made the following updates to this section. Please
review.
i) We have separated this list item into two separate entries for clarity and
have updated their definitions for consistency with RFC 4760:
Original:
* AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers.
Current:
AFI: Address Family Identifier
SAFI: Subsequent Address Family Identifier
ii) We have added list entries for the following terms so that they do
not need to be expanded when they appear in figures or other list items.
ABR: Area Border Router
ASBR: Autonomous System Border Router
RD: Route Distinguisher
-->
<dl spacing="normal" newline="true">
<dt>Intent (in routing):</dt>
<dd>
<t>Any behaviors to influence routing or path selection, including
any combination of the following behaviors:</t>
<ol type="a" spacing="compact">
<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>
<dt>Color:</dt>
<dd>A non-zero 32-bit integer value associated with an intent
(e.g., low cost, low delay, or avoid some resources) as defined in
<xref target="RFC9256" sectionFormat="of" section="2.1"/>. Color assig
nment is managed by
the operator.</dd>
<dt>Colored service route:</dt>
<dd>An egress PE (e.g., E2) colors its BGP service (e.g., VPN) route
(e.g., V/v) to indicate the intent that it requests for the traffic
bound to V/v. The color is encoded as a BGP Color
Extended-Community <xref target="RFC9012"/>, used as per <xref target=
"RFC9256"/>,
or represented by the locator part of SRv6 Service SID <xref
target="RFC9252"/>.</dd>
<dt>Color-aware path to (E2, C):</dt>
<dd>A path to forward packets towards E2 that satisfies the intent
associated with color C. Several technologies may provide a
color-aware path to (E2, C), such as SR Policy <xref target="RFC9256"/
>, IGP
Flex-Algo <xref target="RFC9350"/>, and BGP CAR (as specified in this
document).</dd>
<dt>Color-aware route (E2, C):</dt>
<dd>A distributed or signaled route that builds a color-aware path to
E2 for
color C.</dd>
<dt>Service route automated steering on color-aware path:</dt>
<dd>An ingress PE (or ASBR) E1 automatically steers traffic for a
C-colored service route V/v from E2 onto an (E2, C) color-aware
path. If several such paths exist, a preference scheme is used to
select the best path (for example, IGP Flex-Algo is preferred over SR
Policy, and SR Policy is preferred over BGP CAR).</dd>
<dt>Color domain:</dt>
<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 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 (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 mapping on nodes is set by configuration. Color re-mapping and filteri ng may happen
at color domain boundaries. Refer to at color domain boundaries. Refer to
<xref target="I-D.hr-spring-intentaware-routing-using-color"/>.</c> <xref target="I-D.hr-spring-intentaware-routing-using-color"/>.</dd>
<c></c> <dt>Resolution of a BGP CAR route (E, C):</dt>
<c></c> <dd>An inter-domain BGP CAR route (E, C) via N is resolved on an
intra-domain color-aware path (N, C) where N is the next hop of the
BGP CAR route.</dd>
<c>Resolution of a BGP CAR route (E, C)</c> <dt>Resolution versus steering:</dt>
<c>An inter-domain BGP CAR route (E, C) via N is resolved on an <dd>
intra-domain color-aware path (N, C) where N is the next hop of the BG <t>Consistent with the terminology used in the SR Policy document
P CAR (<xref target="RFC9256" sectionFormat="of" section="8"/>), in
route.</c> 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 traditional 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></c> <dt>Intra-domain resolution:</dt>
<c></c> <dd>BGP CAR route maps to an intra-domain color-aware path (e.g., S
R
Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE path
(e.g., RSVP-TE, IGP/LDP, BGP-LU).</dd>
</dl>
</dd>
<c>Resolution vs Steering</c> <dt>Transport network:</dt>
<c>In this document, and consistent with the terminology used in the S <dd>A network that comprises of multiple cooperating domains managed
R Policy by one or more operators, and uses routing technologies such as IP,
document <xref target="RFC9256"/> Section 8, (Service route) steering MPLS, and SR to forward packets for connectivity and
is used other services. In an SR deployment, the transport network is
to describe the mapping of the traffic for a service route onto a BGP within a trusted domain as per <xref target="RFC8402"/>.</dd>
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>Transport layer:</dt>
<c></c> <dd>Refers to an underlay network layer (e.g., MPLS LSPs between
PEs) that gets used by an overlay or service layer (e.g., MPLS
VPNs).</dd>
<c></c> <dt>Transport RR:</dt>
<c>Service Steering: Service route maps traffic to a BGP CAR path (or <dd>A BGP Route Reflector (RR) used to distribute transport/underlay r
other Color-Aware outes within a domain or
Path: e.g. SR Policy). If a Color-Aware Path is not available, local across domains.</dd>
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>Service RR:</dt>
<c></c> <dd>A BGP Route Reflector (RR) used to distribute service/overlay rout
es
within a domain or across domains.</dd>
</dl>
<c></c> <t>Abbreviations:</t>
<c>Intra-Domain Resolution: BGP CAR route maps to intra-domain color a <dl spacing="normal" newline="false">
ware path <dt>ABR:</dt>
(e.g. SR Policy, IGP Flex-Algo, BGP CAR) or traditional routing/TE pat <dd>Area Border Router</dd>
h (e.g.
RSVP-TE, IGP/LDP, BGP-LU).</c>
<c></c> <dt>AFI:</dt>
<c></c> <dd>Address Family Identifier</dd>
<c>Transport Network</c>
<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>AIGP:</dt>
<dd>Accumulated IGP Metric Attribute <xref target="RFC7311"/></dd>
<t>Abbreviations:</t> <dt>ASBR:</dt>
<t><list style="symbols"> <dd>Autonomous System Border Router</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>BGP-LU:</dt>
</t> <dd>BGP Labeled Unicast SAFI <xref target="RFC8277"/></dd>
<dt>BGP-IP:</dt>
<dd>BGP IPv4/IPv6 Unicast AFI/SAFIs <xref
target="RFC4271"/> <xref target="RFC4760"/></dd>
<dt>BR:</dt><dd>Border Router (either for an IGP area (an ABR) or a BGP
autonomous system (an ASBR))</dd>
<dt>Color-EC:</dt>
<dd>BGP Color Extended-Community <xref target="RFC9012"/></dd>
<dt>E:</dt>
<dd>Generic representation of a transport endpoint such
as a PE, ABR, or ASBR</dd>
<dt>LCM-EC:</dt>
<dd>BGP Local Color Mapping Extended-Community</dd>
<dt>NLRI:</dt>
<dd>Network Layer Reachability Information <xref target="RFC4271"/></dd
>
<dt>P node:</dt>
<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 FA1 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 FA2 is mapped to "low delay and avoid resource R",
and 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 BGP CAR color-aware path</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 SR Policy color-aware path</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 color-aware path that is itself r
esolved
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>
<t>MPLS data-plane: with 300k PEs and 5 colors, the BGP CAR solution
ensures
that no single node needs to support a data-plane scaling in the order of 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/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 Flex-Algo)</t>
<t>Native support for multiple transport encapsulations (e.g., MPLS, S </li>
R, <li>
<t>Native support 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">
<name>BGP CAR SAFI</name>
<section anchor="SECDATAMODEL">
<name>Data Model</name>
<t>The BGP CAR data model is:</t>
<dl spacing="normal" newline="false">
<dt>NLRI key:</dt><dd><t>Falls into two categories to accommodate the
use cases described
in the introduction:</t>
<dl spacing="normal" newline="false">
<dt>Type-1:</dt><dd>Key is IP Prefix and Color (E, C). Color in
NLRI key distinguishes a color-aware route for a common IP
prefix, one per intent. Color also indicates the intent
associated with the route.</dd>
<dt>Type-2:</dt><dd>Key is IP Prefix (E). The unique IP prefix
assigned for an intent (i.e, IP Prefix == intent or Color)
distinguishes the color-aware route. Color is not needed in
NLRI key as a distinguisher.</dd>
</dl>
</dd>
<!-- [rfced] Section 2.1: For consistency with the rest of the list items in
this section, what definition/content should appear for "BGP Next Hop"?
<section anchor="CARSAFI" title="BGP CAR SAFI"> Original:
<section anchor="SECDATAMODEL" title="Data Model"> * BGP Next Hop.
<t>The BGP CAR data model is: -->
<list style="symbols"> <dt>NLRI non-key encapsulation data:</dt><dd>Data such as MPLS label
<t>NLRI Key: Falls into two categories, to accommodate the use-cases d stack, Label Index, and SRv6 SID list associated with NLRI. Contained
escribed in TLVs as described in <xref target="NLRITLVs"/>.</dd>
in the introduction: <dt>BGP next hop.</dt>
<list style="symbols"> <dd></dd>
<t>Type-1: Key is IP Prefix and Color (E, C). Color in NLRI key dist <dt>AIGP metric <xref target="RFC7311"/>:</dt><dd>Accumulates a metric
inguishes value specific to color/intent
a color-aware route for a common IP prefix, one per intent. Color al for a CAR route across multiple BGP hops.</dd>
so <dt>Local-Color-Mapping Extended-Community (LCM-EC):</dt><dd><t>Option
indicates the intent associated with the route. al non-zero 32-bit Color
</t> value used to represent the intent associated with a CAR route:</t>
<t>Type-2: Key is IP Prefix (E). The unique IP prefix assigned for a <ul spacing="normal">
n <li>
intent (i.e, IP Prefix == Intent or Color) distinguishes the color-a <t>when the CAR route propagates between different color domains
ware route. .</t>
Color is not needed in NLRI key as a distinguisher. </li>
</t> <li>
</list> <t>when the CAR route has a unique IP prefix for an intent.</t>
</t> </li>
<t>NLRI non-key encapsulation data: Data such as MPLS label stack, Lab </ul>
el Index </dd>
and SRv6 SID list associated with NLRI. Contained in TLVs as described <dt>BGP Color Extended-Community (Color-EC) <xref
in target="RFC9012"/>:</dt><dd>Optional non-zero 32-bit Color value
<xref target="NLRITLVs"/></t> used to represent the intent associated with the BGP CAR next
<t>BGP Next Hop.</t> hop. It is used as per <xref target="RFC9256"/> for automated route
<t>AIGP Metric <xref target="RFC7311"/>: accumulates color/intent spec resolution, when intent/color used for the next hop is different
ific metric value than the CAR route's intent/color. </dd>
for a CAR route across multiple BGP hops.</t> </dl>
<t>Local-Color-Mapping Extended-Community (LCM-EC): Optional non-zero <t>
32-bit Color
value used to represent the intent associated with a CAR route:
<list style="symbols">
<t>when the CAR route propagates between different color domains.</t
>
<t>when the CAR route has a unique IP prefix for an intent.</t>
</list>
</t>
<t>BGP Color Extended-Community (Color-EC) <xref target="RFC9012"/>: O
ptional non-zero 32-bit Color value
used to represent the intent associated with the BGP CAR next hop. It
is
used as per <xref target="RFC9256"/> for automated route resolution, w
hen
intent/color used for the next hop is different than the CAR route's i
ntent/color. </t>
</list>
</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 Flex-Algo, 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 Flex-Algo <xref target="RFC9350"/>, SR policy (<xref target="RFC9256"
f target="RFC9350"/>, sectionFormat="of" section="2.2"/>), or recursively by BGP CAR.
SR policy <xref target="RFC9256"/> Section 2.2, or recursively by BGP CA When multiple producers of (N, C1) are available, the default
R. preference is: IGP Flex-Algo, SR Policy, BGP CAR.
When multiple producers of (N, C1) are available,
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).</t>
<ul spacing="normal">
<li>
<t>Local policy SHOULD provide additional control: <!-- [rfced] Please clarify the last two points; we suggest making them
<list style="symbols"> complete sentences and consistent with one another. More specifically,
<t>A BGP color-aware route (E2, C1) with next hop N may be resolved ov what is the outcome of the "if" clause in the final list item below (the
er a item that begins with "Another example is:")?
color-aware route (N, C2): i.e., the local policy maps the resolution
of C1 Original:
over a different color C2. * A BGP color-aware route (E2, C1) with next hop N may be resolved
<list style="symbols"> over a color-aware route (N, C2): i.e., the local policy maps the
<t>For example, in a domain where resource R is known to not be resolution of C1 over a different color C2.
present, the inter-domain intent C1="low delay and avoid R"
may be resolved over an intra-domain path of intent C2="l - For example, in a domain where resource R is known to not be
ow delay".</t> present, the inter-domain intent C1="low delay and avoid R" may
<t>Another example is: if no (N, C1) path is available an be resolved over an intra-domain path of intent C2="low delay".
d the
- Another example is: if no (N, C1) path is available and the user has
allowed resolution to fallback to a C2 path.
Perhaps:
- For example, 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 over an intra-domain path of intent C2="low delay".
- For another example, if no (N, C1) path is available, and the user has
allowed resolution to fallback to a C2 path, then ... [what outcome occ
urs]?
-->
<t>For example, 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 over an intra-domain path of intent C2="low
delay".</t>
</li>
<li>
<t>Another example is: if no (N, C1) path is available and the
user has allowed resolution to fallback to a C2 path.</t> user has allowed resolution to fallback to a C2 path.</t>
</list> </li>
</t> </ul>
<t> </li>
<li>
<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 v6LOCencap"/>). Flex Algo or BGP CAR IP Prefix route itself (e.g., <xref target="SECSR v6LOCencap"/>).
</t> </t>
<t>Local policy may map the CAR route to traditional mechanisms that a </li>
re unaware of <li>
<t>Local policy may map the CAR route to traditional mechanisms that
are unaware of
color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP LU/IP (e.g., color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP LU/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
attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging automated
steering as described in Section <xref target="RFC9256"
sectionFormat="bare" section="8.4"/> of "Segment Routing Policy
Architecture" <xref target="RFC9256"/> for BGP CAR routes. This
mechanism is illustrated in <xref target="APPENDIXNM"/>. This
mechanism <bcp14>SHOULD</bcp14> be supported.</t>
<t>Route resolution via a different color C2 can be automated by attachi <!-- [rfced] How may we clarify how the content in parentheses relates to
ng the rest of the sentence?
BGP Color-EC C2 to CAR route (E2, C1), leveraging Automated
steering as described in Section 8.4 of Segment Routing Policy Architect Original:
ure For CAR route resolution, Color-EC color if present takes precedence
<xref target="RFC9256"/> for BGP CAR routes. This mechanism is illustrat over the route's intent color (LCM-EC if present (Section 2.9.5), or
ed else NLRI color).
in <xref target="APPENDIXNM"/>. This mechanism SHOULD be supported.</t>
Perhaps:
If present, Color-EC color takes precedence over the route's intent color
(which, if present, is LCM-EC (see Section 2.9.5) or else NLRI color) for
CAR route resolution.
-->
<t>For CAR route resolution, Color-EC color if present takes precedence over <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"/>), the route's intent color (LCM-EC if present (<xref target="SECLCMEC"/>),
or else NLRI color).</t> or else NLRI color).</t>
<t>Local policy takes precedence over the color-based automated resoluti
<t>Local policy takes precedence over the color based automated resoluti on specified above.</t>
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>
<!-- [rfced] What is the subject of "or appropriately incremented" in the text b
elow?
Original:
The value set (or appropriately incremented) in the AIGP TLV
corresponds to the metric associated with the underlying intent of
the color.
Perhaps:
The value that is set (or appropriately incremented) in the AIGP TLV
corresponds to the metric associated with the underlying intent of
the color.
-->
<t>The value set (or appropriately incremented) in the AIGP TLV correspo nds <t>The value set (or appropriately incremented) in the AIGP TLV correspo 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>Native 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 o signal multiple <t>BGP ADD-PATH <xref target="RFC7911"/> <bcp14>SHOULD</bcp14> be enable d for BGP CAR to signal multiple
next hops through a transport RR.</t> next hops through a transport RR.</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 <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 routers of Domain 2 and Domain 1, respectively. Let us assume that these two
domains do not share the same color-to-intent mapping (i.e., they belong to different 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 color domains). Low-delay in Domain 2 is color C2, while it is C1 in
domain 1 (C1 &lt;> C2).</t> Domain 1 (C1 &lt;&gt; C2).</t>
<t>It is not expected to be a typical scenario to have an underlay
<t>It is not expected to be a typical scenario to have an underlay trans transport path (e.g., an MPLS LSP) extend across different color
port path (e.g., an MPLS LSP) extend across domains. However, the BGP CAR solution seamlessly supports this rare
different color domains. However, the BGP CAR solution seamlessly suppor scenario while maintaining the separation and independence of the
ts this rare scenario while administrative authority in different color domains.</t>
maintaining the separation and independence of the administrative author <t>The solution works as described below:</t>
ity in different color domains.</t> <ul spacing="normal">
<li>
<t>The solution works as described below: <t>Within Domain 2, the BGP CAR route is (E2, C2) via E2.</t>
<list style="symbols"> </li>
<t>Within domain 2, the BGP CAR route is (E2, C2) via E2.</t> <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 multi-protocol 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> (multi-protocol 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> <dt>Type code:</dt><dd>Remaining 6 bits contain the type of the
TLV.</dd>
<t>Length: 1 octet field that contains the length of the value </dl>
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
<bcp14>MUST</bcp14> be either less than or equal to 16, or be a
multiple of 16.</dd>
<dt>SRv6 SID Information:</dt><dd><t>Field of size as indicated by
the
length that either carries the SRv6 SID(s) for the advertised
CAR route as one of the following:</t>
<ul spacing="normal">
<li><t>A single 128-bit SRv6 SID or an ordered list of
128-bit SRv6 SIDs.</t></li>
<li><t>A transposed portion (refer to <xref
target="RFC9252"/>) of the SRv6 SID that <bcp14>MUST</bcp14>
be of size in multiples of one octet and less than 16.</t>
</li>
</ul>
</dd>
</dl>
<t>Length: In octets. Length is variable, MUST be either less than <!-- [rfced] FYI - We adjusted these list items to make them parallel
or equal to 16, and consistent. Please review and let us know any further updates.
or be a multiple of 16.</t>
<t>SRv6 SID Information: field of size as indicated by the Original:
length that either carries the SRv6 SID(s) for the advertised BGP CAR SRv6 SID TLV definitions provide the following benefits:
CAR route as one of the following:
<list style="symbols">
<t>A single 128-bit SRv6 SID or an ordered list of 128-bit SRv6
SIDs.</t>
<t>A transposed portion (refer <xref * Native encoding of SIDs avoids robustness issue caused by
target="RFC9252"/>) of the SRv6 SID that overloading of MPLS label fields.
MUST be of size in multiples of one octet and less than
16.</t> * Simple encoding to signal Unique SIDs (non-transposition),
</list> maintaining BGP update prefix packing.
</t>
</list> * Highly efficient transposition scheme (12-14 bytes saved per
</t> NLRI), also maintaining BGP update prefix packing.
Current:
BGP CAR SRv6 SID TLV definitions provide the following benefits:
* The native encoding of SIDs avoids robustness issues caused by the
overloading of MPLS label fields.
* The simple encoding to signal Unique SIDs (non-transposition)
maintains BGP update prefix packing.
* The highly efficient transposition scheme (12-14 bytes saved per
NLRI) also maintains BGP update prefix packing.
-->
<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 native encoding of SIDs avoids robustness issues caused by
the
overloading of MPLS label fields.</li>
<li>The simple encoding to signal Unique SIDs (non-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>Received MPLS information can map to SRv6 and vice versa.
<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 an extension to BGP CAR routes. </t>
</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 ncoding:</t> The LCM is a Transitive Opaque Extended-Community with the following e ncoding:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 NLRI length and Key length MUST be valid, failures in following <!-- [rfced] May we update the list below as follows for consistency?
checks result in 'AFI/SAFI disable' or 'session reset': Is it intentional that the first "must" is lowercase, or should it be the
<list style="symbols"> all-caps requirement keyword "MUST" (which is used in the other bullet point)?
<t>Minimum NLRI length (must be atleast 2, as key length and NLRI type
are required fields).</t>
<t>Key Length MUST be at least two less than NLRI Length.</t>
</list>
</t>
<t>NLRI Type specific error handling: Original:
<list style="symbols"> Given NLRI length and Key length MUST be valid, failures in following
<t>By default, a speaker SHOULD discard unrecognized or unsupported NLRI checks result in 'AFI/SAFI disable' or 'session reset':
type
and move to next NLRI.</t>
<t>Key length and key errors of known NLRI type SHOULD result in discard
of
NLRI similar to unrecognized NLRI type. (This MUST be logged for
trouble shooting).</t>
</list>
</t>
<t>Transparent propagation of unrecognized NLRI type: * Minimum NLRI length (must be atleast 2, as key length and NLRI
<list style="symbols"> type are required fields).
<t>Key length allows unrecognized route types to transit through RR * Key Length MUST be at least two less than NLRI Length.
Perhaps:
Given the NLRI length and Key length MUST be valid, failures in the following
checks result in 'AFI/SAFI disable' or 'session reset':
* The minimum NLRI length MUST be at least 2, as key length and NLRI
type are required fields.
* The Key Length MUST be at least 2 less than NLRI Length.
-->
<t>Given NLRI length and Key length <bcp14>MUST</bcp14> be valid, failur
es in the following
checks result in 'AFI/SAFI disable' or 'session reset':
</t>
<ul spacing="normal">
<li>
<t>Minimum NLRI length (must be at least 2, as key length and NLRI
type are required fields).</t>
</li>
<li>
<t>Key Length <bcp14>MUST</bcp14> be at least two less than NLRI Len
gth.</t>
</li>
</ul>
<t>NLRI type-specific error handling:
</t>
<ul spacing="normal">
<li>
<t>By default, a speaker <bcp14>SHOULD</bcp14> discard an
unrecognized or unsupported NLRI type and move to the next
NLRI.</t>
</li>
<li>
<t>Key length and key errors of a known NLRI type
<bcp14>SHOULD</bcp14> result in the discard of NLRI similar to an
unrecognized NLRI type. (This <bcp14>MUST</bcp14> be logged for
trouble shooting.)</t>
</li>
</ul>
<t>Transparent propagation of unrecognized NLRI type:</t>
<ul spacing="normal">
<li>
<t>Key length allows unrecognized route types to transit through the
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 scheme is used <xref target="SECCARIllus"/>. If several such paths exist, a preference sc heme is used
to select the best path. The default preference scheme is IGP Flex-Algo fi rst, then to select the best path. The default preference scheme is IGP Flex-Algo fi rst, 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 <!-- [rfced] FYI, for clarity, we added the word 'steering' twice
SR Policy (a routing solution providing color-aware path) defined in and changed 'path' to 'paths'. Please review whether this conveys
<xref target="RFC9256"/>. All the steering variations described in <xref t this intended meaning.
arget="RFC9256"/>
are applicable to BGP CAR color-aware path: on-demand steering, per-destin Original:
ation, All the steering variations described in [RFC9256] are applicable to BGP
per-flow, color-only steering. For brevity, please refer to <xref target=" CAR color-aware path: on-demand steering, per- destination, per-flow,
RFC9256"/> Section 8.</t> color-only steering.
Current:
All the steering variations described in [RFC9256] are applicable to BGP
CAR color-aware paths: on-demand steering, per-destination steering,
per-flow steering, and color-only steering.
-->
<t>This is consistent with the automated service route steering on SR
Policy (a routing solution providing color-aware paths) defined in <xref
target="RFC9256"/>. All the steering variations described in <xref
target="RFC9256"/> are applicable to BGP CAR color-aware paths:
on-demand steering, per-destination steering, per-flow steering, and
color-only steering. For brevity, please refer to <xref target="RFC9256"
sectionFormat="of" 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 d to constrain distribution and Route Target (RT) Extended-Communities <xref target="RFC4360"/> can be use d to constrain distribution and
automate filtering of CAR routes. RT assignment may be via user policy, fo r example an RT automate filtering of CAR routes. RT assignment may be via user policy; fo 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>
<t>A BGP CAR route (E2, C1) is advertised by egress BRM node 451. Th
e route is
sourced locally from redistribution from IGP-FA 128.</t> sourced locally from redistribution from IGP-FA 128.</t>
<t>Not shown for simplicity, node 452 will also advertise (E2, C1).</t </li>
> <li>
<t>When a transport RR is used within the domain or across domains, <t>Not shown for simplicity, node 452 will also advertise (E2, C1).<
ADD-PATH is enabled to advertise paths from both egress BRs to it's /t>
</li>
<li>
<t>When a transport RR 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 1771
| |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 FA128 path to 121 (label 1681
</list> 21).</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 1851
| +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ +---+ |
| 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 FA128 path to 231 (label 1682
</t> 31).</t>
<t>451 advertises BGP CAR route (E2, C1) via 451 to transport RR T-R </li>
R2, which </ul>
</li>
<li>
<t>451 advertises BGP CAR route (E2, C1) via 451 to transport RR T
-RR2, which
reflects it to transport RR T-RR1, which reflects it to 121.</t> reflects it to transport RR T-RR1, which reflects it to 121.</t>
<t>121 receives BGP CAR route (E2, C1) via 451 with label 168002. </li>
<list> <li>
<t>Let's assume 121 selects that path.</t> <t>121 receives BGP CAR route (E2, C1) via 451 with label 168002.
</list> </t>
</t> <ul spacing="normal">
<t>121 resolves BGP CAR route (E2, C1) via 451 on color-aware path ( <li>
451, C1). <t>Let's assume 121 selects that path.</t>
<list> </li>
<t>Color-aware path (451, C1) is BGP CAR path to 451 (label 168451 </ul>
).</t> </li>
</list> <li>
</t> <t>121 resolves BGP CAR route (E2, C1) via 451 on color-aware path
<t>121 imposition of color-aware label stack for (E2, C1) is thus (451, C1).
<list> </t>
<t>168002 &lt;=> (E2, C1)</t> <ul spacing="normal">
<t>168451 &lt;=> (451, C1)</t> <li>
<t>168231 &lt;=> (231, C1)</t> <t>Color-aware path (451, C1) is BGP CAR path to 451 (label 16
</list> 8451).</t>
</t> </li>
<t>121 advertises (E2, C1) to E1 with next hop self (121) and label </ul>
168002</t> </li>
<t>E1 constructs same imposition color-aware label-stack for V/v via <li>
(E2, C1) <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 1973
| | | | | | | | | | | |
| 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>
<t>451 advertises BGP CAR route (E2, C1) to transport RR T-RR2, wh
ich
reflects it to transport RR T-RR1, which reflects it to 121.</t> reflects it to transport RR T-RR1, which reflects it to 121.</t>
<t>Node 121 advertises (E2, C1) to E1 with next hop as 451; i.e., </li>
next-hop-unchanged.</t> <li>
<t>121 also advertises (451, C1) to E1 with next hop self (121) and <t>Node 121 advertises (E2, C1) to E1 with next hop as 451
label (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 FA128 path to 121 (label 1681
<list> 21).</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
scales with (451, C) where there may be thousands of 451s and 5 Cs.
Therefore,
this scaling is well under the 1 million MPLS labels data-plane limi t.</t> this scaling is well under the 1 million MPLS labels data-plane limi t.</t>
<t>They also aid faster convergence by allowing the PE routes to </li>
be distributed via out-of-band RRs that can be scaled <li>
independent of the transport BRs.</t> <t>They also aid faster convergence by allowing the PE routes
</list> to be distributed via out-of-band RRs that can be scaled
</t> independent of the transport BRs.</t>
<t>The next-hop-self option at ingress BRM (e.g. 121) hides the hierar </li>
chical </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 <xref target="RFC9350"/> by underlay IP routing. Underlay IP routing can include IGP Flex-Algo <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 Flex-Algo, or it may be assigned specific 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-FlexAlgo
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 FlexAlgo
).</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> <!-- [rfced] What is the subject of "may be shared" in the text below?
</list>
</t>
<t>An ingress BR encapsulates SRv6 egress PE destined packets with Original:
encapsulation to BGP next hop, ie. the egress BR. </t> - If MPLS/SR-MPLS transport, the route will carry label/prefix-
</list> SID allocated by the next hop, may be shared.
</t> -->
<t>Benefits of this scheme are: <t>If MPLS/SR-MPLS transport, the route will carry the label/P
<list style="symbols"> refix-SID allocated
<t>P nodes do not need to learn or install BGP SRv6 prefixes in this by the next hop, may be shared.</t>
(BGP-free core) design.</t> </li>
<t>No per-PE SID allocation and installation on any BGP hop.</t> </ul>
</list> </li>
<li>
<t>An ingress BR encapsulates SRv6 egress PE destined packets with
encapsulation to BGP next hop (i.e., the egress BR).</t>
</li>
</ul>
<t>The benefits of this scheme are:
</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>
<li>
<t>Priority handling of infrastructure routes over service (Inte
rnet) routes.</t>
</li>
</ul>
</li>
<li>
<t>CAR SAFI also supports inter-domain distribution of (E, C) routes
sourced from SR-Policy, in addition to SRv6 locator IPv6 prefixes.</t> sourced from SR-Policy, in addition to SRv6 locator IPv6 prefixes.</t>
<t>CAR SAFI may also be used for best-effort routes in addition to intent- </li>
aware <li>
routes as described in the next section.</t> <t>CAR SAFI may also be used for best-effort routes in addition to
</list> intent-aware routes as described in the next section.</t>
</t> </li>
</ul>
<t>Note: If infrastructure routes such as SRv6 locator routes are carried <t>Note: If infrastructure routes such as SRv6 locator routes are
in carried in both BGP-IP <xref target="RFC4271"/> / BGP-LU <xref
both BGP-IP [RFC4271] / BGP-LU [RFC8277, RFC4798], and BGP CAR, <xref targ target="RFC8277"/> <xref target="RFC4798"/>, and BGP CAR, <xref
et="CARIPPREFIX"/> describes target="CARIPPREFIX"/> describes the path selection preference between
the path selection preference between them.</t> 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 traditional 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>
<!--[rfced] Will it be clear to the reader what "color CP" and "color CPT"
mean here? If not, please provide text to explain. We note that some other
examples use "color C1" and "color C2".
CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V Current:
* Provider publishes to customer that intent 'low-delay' is mapped
to color CP on its inbound peering links.
]]></artwork> * Within its infrastructure, provider maps intent 'low-delay' to
</figure> color CPT.
<t> -->
<list style="symbols"> <li>
<t>BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions</t> <t>Provider publishes to customer that intent 'low-delay' is mapped to
<t>BGP VPN CAR SAFI is enabled between PE1 and PE2</t> color CP on its
<t>Provider publishes to customer that intent 'low-delay' is mapped to c inbound peering links.</t>
olor CP on its </li>
inbound peering links</t> <li>
<t>Within its infrastructure, Provider maps intent 'low-delay' to color <t>Within its infrastructure, provider maps intent 'low-delay' to colo
CPT</t> r CPT.</t>
<t>On CE1 and CE2, intent 'low-delay' is mapped to CC</t> </li>
</list> <li>
</t> <t>On CE1 and CE2, intent 'low-delay' is mapped to CC.</t>
</li>
</ul>
<t>(V, CC) is a color-aware route originated by CE2.</t>
<t>(V, CC) is a Color-Aware route originated by CE2</t> <!-- [rfced] FYI - Section 9: We have updated this artwork (containing
<figure> numbered items) to to an ordered list. Please review. If you prefer to
<artwork><![CDATA[ have the "[(V, CC)" portions aligned vertically, we can insert line
breaks (as shown in 'Perhaps' below). For example (showing only two items):
Original:
1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with LCM-EC (CP) 1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with LCM-EC (CP)
as per peering agreement as per peering agreement
2. PE2 installs in VRF A: [(V, CC), L1] via CE2 2. PE2 installs in VRF A: [(V, CC), L1] via CE2
which resolves on (CE2, CP) which resolves on (CE2, CP)
or connected OIF
3 PE2 allocates VPN Label L2 and programs swap entry for (V, CC)
4. PE2 sends to PE1 : [(RD, V, CC), L2] via PE2, LCM-EC(CP)
with regular Color-EC (CPT)
5. PE1 installs in VRF A: [(V, CC), L2] via (PE2, CPT)
steered on (PE2, CPT)
6. PE1 allocates Label L3 and programs swap entry for (V, CC)
7. PE1 sends to CE1 : [(V, CC), L3] via PE1
after removing LCM-EC through route-policy
8. CE1 installs : [(V, CC), L3] via PE1
which resolves on (PE1, CC)
or connected OIF or connected OIF
9. Label L3 is installed as the imposition label for (V, CC)
]]></artwork> Current:
</figure> 1. CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as
<t>VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows per peering agreement.
2. PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on
(CE2, CP) or connected Outgoing Interface (OIF).
Perhaps:
1. CE2 sends to PE2:
[(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering
agreement.
2. PE2 installs in VRF A:
[(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected
Outgoing Interface (OIF).
-->
<ol>
<li>CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peer
ing agreement.</li>
<li>PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on (CE2, CP)
or connected Outgoing Interface (OIF).</li>
<li>PE2 allocates VPN Label L2 and programs swap entry for (V, CC).</li>
<li>PE2 sends to PE1: [(RD, V, CC), L2] via PE2, LCM-EC (CP) with regular Colo
r-EC (CPT).</li>
<li>PE1 installs in VRF A: [(V, CC), L2] via (PE2, CPT) steered on (PE2, CPT).
</li>
<li>PE1 allocates Label L3 and programs swap entry for (V, CC).</li>
<li>PE1 sends to CE1: [(V, CC), L3] via PE1 after removing LCM-EC through rout
e policy.</li>
<li>CE1 installs: [(V, CC), L3] via PE1, which resolves on (PE1, CC) or connec
ted OIF.</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
in
<xref target="STEERING"/> and illustrated in the example above.</t>
<t>VPN CAR SAFI routes follow color based steering techniques as described <!-- [rfced] Is citing Section 9 of RFC 4364 correct here? We note "L3VPN"
in does not appear in RFC 4364. ("L3" appears only once in Section 14;
<xref target="STEERING"/> and illustrated in example above.</t> zero instances of "layer 3".)
<t>VPN CAR SAFI routes may also be advertised with a specific BGP next hop Original:
per color, Example use-cases are intent-aware L3VPN CsC ([RFC4364] Section 9) and SRv6
with a TEA or Tunnel Encapsulation EC and follow the procedures of [RFC901 over a provider network.
2]
Section 6.</t> Current:
Example use cases are intent-aware L3VPN Carriers' Carriers (Section 9 of
[RFC4364]) and SRv6 over a provider network.
-->
<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 <xref
target="RFC9012" sectionFormat="of" 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 multi-protocol 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> (multi-protocol 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 2766
| 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 2794
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>
<table>
<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 <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 Flex-Algo</name>
title="E2E BGP transport CAR intent realized using IGP Flex-Algo"> <figure anchor="FAUSECASE">
<figure anchor="FAUSECASE" title="BGP FA Aware transport CAR path"> <name>BGP FA 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 2705 skipping to change at line 3120
---------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 FA 128 is running in each domain, and mapped to color 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 border routers 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 FA 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 AIGP over FA 128 LSP to next hop providing intent in each IGP domain. The AIGP
metric should be updated to reflect FA 128 metric to next hop.</t> metric should be updated to reflect FA 128 metric to next hop.</t>
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored </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 FA 128 top label provides intent within each domain.</t>
</list> </li>
</t> <li>
<t>BGP CAR label (e.g., 168002) carries end-to-end
intent. Thus, it stitches intent over intra-domain FA 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 +-----+ :
: : : :
: : : :
: : : :
+-:-----------------------+----------------------+------------------:-+ +-:-----------------------+----------------------+------------------:-+
| : | | : | | : | | : |
skipping to change at line 2782 skipping to change at line 3213
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+ +------+ +------+
|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 border routers 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
SR policy (C1, next hop). The BGP CAR label swap entry is installed
that goes
over SR policy segment list.</t> over SR policy segment list.</t>
<t>Ingress PE E1 learns CAR route (E2, C1). It steers colored </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 Flex-Algo</name>
rt CAR path"> <figure anchor="HDFAUSECASE">
<artwork><![CDATA[ <name>BGP Hybrid Flex-Algo 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 3321
---------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 FA 128 is only enabled in core (e.g., WAN network),
<t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-E mapped to C1. Access network domain only has Base Algo
C C1 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>
<li>
<t>BGP CAR route (E2, C1) with next hop, label index, and labe
l as
shown above are advertised through border routers in each domain. shown above are advertised through border routers in each domain.
When a RR is used in the domain, ADD-PATH is enabled to advertise multiple 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 FA 128. The BGP CAR label
t> swap entry is installed that goes over FA 128 LSP to next
<t>Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to hop providing intent in Core IGP domain.</t>
resolve CAR route next hop over IGP Base Algo 0. It steers colored </li>
VPN route RD:V/v via (E2, C1)</t> <li>
</list> <t>Ingress PE E1 learns CAR route (E2, C1). It maps intent
</t> C1 to resolve CAR route next hop over IGP Base Algo 0. It
steers colored VPN route RD:V/v via (E2, C1).</t>
<t>Important: </li>
<list style="symbols"> </ul>
<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 <li>
realized in core domain.</t> <t>Important:
</list> </t>
</t> <ul spacing="normal">
</list> <li>
</t> <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 3422
---------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
E1.</t>
</li>
<li>
<t>BGP CAR route (E2, C1) with next hops and labels as
shown above is advertised through border routers in each shown above is advertised through border routers in each
domain. When a RR is used in the domain, ADD-PATH is enabled 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 Flex-Algo</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 Flex-Algo for Resource Avoidance 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 FA128 in Domain 2 is mapped to "minimize IGP metric", a
nd 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 FA129 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 FA128 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 FA128).</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 FA128, and</t>
</t> </li>
<t>(E2, C2) provided by BGP CAR with the following per-domain <li>
<t>Domain 2: over IGP FA128.</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 FA128, and</t>
</t> </li>
</list> <li>
</t> <t>Domain 2: over IGP FA129 (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>
<li>
<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 (FA128) in one <t>C1 and C2 are realized over a common intra-domain intent (FA128) 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> <!-- [rfced] Appendix A.7: Is there text missing in the example below? For
<t>Example-1: Anycast with forwarding to nearest instance, what does "nearest" refer to?
<list style="symbols">
<t>Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise Original:
Anycast (shared) IP (IP1, C1) with same label L1.</t> Example-1: Anycast with forwarding to nearest
<t>An ingress PE E1 receives by default the best path(s) for (IP1, C1) -->
<t>Example 1: Anycast with forwarding to nearest:</t>
<ul spacing="normal">
<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>
</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 3993
| +===+ +===+ | | +===+ +===+ |
| 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>
<li>
<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 FA 132 in access and FA 128 in core. It also a dvertises steer traffic through FA 132 in access and FA 128 in core. It also a dvertises
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> FA 132 in access and FA 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)| | FA 128 (B:C12::/32) | |FA128(B:C11::/32)|
| FA 0 (B:02::/32) | |FA0 (B:01::/32) | | FA 0 (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>
<t>ASBR 121 and 122 propagate the route in AS2 to all the P, ABRs, a
nd PEs
through transport RR.</t> through transport RR.</t>
<t>Every router in AS2 resolves BGP CAR prefix B:C11::/32 next hop </li>
s <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>
<t>Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4::
is
natively steered hop by hop along IPv6 routed path to B:C11::/32 p rovided natively steered hop by hop along IPv6 routed path to B:C11::/32 p rovided
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 natively steered along IPv6 route
d 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 FA path to E2
@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 FA path to E2
@E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
inner DA in the VRF the inner DA in the VRF
]]></artwork> ]]></artwork>
</figure>
</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 3638 skipping to change at line 4349
| +---+ +---+ | | +---+ +---+ |
| 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) | | FA 128 (B:C13::/32) | FA 128 (B:C12::/32) | FA128 (B:C11::/32) |
| FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA1 0 (B:01::/32) | | FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA1 0 (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 FA128 block in transit domain.</
</t> t>
</li>
<li>
<t>Prefix B:C13::/32 summarizes FA128 block in ingress domain.</
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, border routers set next-hop-self and app ropriately
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- domain path, locators for the C1 intent. (Note: IGP Flex-Algo is shown 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 border 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: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 FA path to E2
@E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the @E2: My SID table B:C11:2:DT4:: => Pop the outer header and look up
inner DA in the VRF the inner DA in the VRF
]]></artwork> ]]></artwork>
</figure>
</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:: | :
+-:|---------------------+---------------------|+------------------:--+ +-:|---------------------+---------------------|+------------------:--+
skipping to change at line 3725 skipping to change at line 4457
|----+ | | +-----| |----+ | | +-----|
| ^ 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) | | FA 0 (B:03::/32) | FA 0 (B:02::/32) | FA 0(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>
<ul spacing="normal">
<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 <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 Transport RR (TRR) or inline with
next hop next-hop-unchanged.</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 border router s.
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 <!-- [rfced] Appendix D: We have made several updates for clarity and
cy readability. Please carefully review and let us know if any additional
calculation"> updates are needed.
a) FYI, we made this sentence into a list. May we change "4k bytes"
to "4000 bytes" for clarity? (It seems fine for other instances of
'4k' to remain in this document, as they are not followed by the word
'bytes'.)
Original:
Scenarios considered are ideal packing (maximum number of routes
packed to update message limit of 4k bytes), practical deployment
case with average packing (5 routes share set of BGP path attributes
and hence packed in single update message) and worst-case of no
packing (each route in separate update message).
Current:
The packing scenarios considered are as follows:
* the ideal case (where the maximum number of routes are packed to
the update message limit of 4k bytes),
* the practical case of average packing (where 5 routes share a set
of BGP path attributes, and hence are packed in a single update
message), and
* the worst case of no packing (where each route is in a separate
update message).
b) Table 5: FYI, we updated the title and made other slight adjustments to
the table.
Original:
Figure 18: Summary of ideal, practical and no-packing BGP data in
each case
Current:
Table 5: Summary of the Ideal, Practical, and Worst Cases of
Packing BGP Data
c) To avoid using an RFC number as an adjective, may we update the
various instances of "[RFC8277] style" as follows?
Original:
It compares total BGP
data on the wire for CAR SAFI and [RFC8277] style encoding in MPLS
label (CASE A), SR extension with MPLS (per-prefix label index in
Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) cases.
|RFC-8277 style |
| NLRI |
No degradation from RFC8277 like encoding
CAR SAFI encoding more efficient by 88% in best case and 71% in average
case over RFC8277 style encoding
SAFI 128 8277 style encoding with label in NLRI
Perhaps:
It compares total BGP data on the wire for CAR SAFI and encoding as specified
in [RFC8277] in the following: an MPLS label (CASE A), an SR extension with M
PLS
(per-prefix label index in Prefix-SID attribute; see [RFC8669]) (CASE B), and
an SRv6 SID (CASE C).
| NLRI as |
| per RFC 8277 |
No degradation from encoding as specified in [RFC8277].
CAR SAFI encoding is more efficient by 88% in the best case and 71% in the
average case over the encoding as specified in [RFC8277] (which precludes
packing).
SAFI 128 encoded per RFC 8277 with label in NLRI
-->
<section anchor="UPDATEPACKING">
<name>CAR SAFI NLRI Update Packing Efficiency Calculation</name>
<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 AR SAFI and size in operational networks. It compares total BGP data on the wire for C AR SAFI and
<xref target="RFC8277"/> style encoding in MPLS label (CASE A), <xref target="RFC8277"/> style encoding in MPLS label (CASE A),
SR extension with MPLS (per-prefix label index in Prefix-SID attribute) SR extension with MPLS (per-prefix label index in Prefix-SID attribute)
<xref target="RFC8669"/> (CASE B) and SRv6 SID (CASE C) cases. <xref target="RFC8669"/> (CASE B) and SRv6 SID (CASE C) cases.
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><xref target="RFC8277"/> style NLRI</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 from <xref target="RFC8277"/> like encoding
(No packing) | 339 MB | 339 MB | .</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 <xref target="RFC8277"/> style encoding (whic
h 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</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</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[
<!--[rfced] Appendix D: We suggest adding a space between the
number and the units throughout the descriptions of Cases A, B, and C.
Please let us know if this update is acceptable. A few examples:
Original: ~86MB
~27.5MB
~339MB
Suggested: ~86 MB
~27.5 MB
~339 MB
-->
<t>CASE A: BGP data exchanged for the non-SR-MPLS case:</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 signal 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.5MB
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 = ~86MB
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 = ~325MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 8277 style encoding 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.9MB
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 = ~84MB
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 = ~324MB
]]></artwork> ]]></artwork>
</figure>
</t>
<t>CASE B: BGP data exchanged for SR label index <t>CASE B: BGP data exchanged for SR 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 signal Label 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 = ~42MB
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 = ~99MB
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 = ~339MB
SAFI 128 8277 style encoding with label in NLRI SAFI 128 8277 style encoding 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 = ~339MB
]]></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 signal Label 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 = ~49MB
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 = ~115MB
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 = ~378MB
SAFI 128 8277 style encoding with label in NLRI (No transposition) SAFI 128 8277 style encoding 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 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 + 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 = ~378MB
]]></artwork> ]]></artwork>
</figure>
</t>
<t>BGP data exchanged with SRv6 SID 4 bytes transposition into SRv6 SID TL <t>BGP data exchanged with SRv6 SID 4 bytes transposition into SRv6 SID TL
V V:</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 signal Label 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 = ~29MB
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 = ~98MB
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 = ~378MB
]]></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] Formatting:
a) FYI, we add line breaks in the artwork so it fits within 72-character line
limit. Specifically, please review the artworks in Appendices C.1, C.2, and
C.3 titled "Packet Forwarding" and let us know if the line breaks should be
changed.
In addition, please consider whether any artwork elements should be tagged as
sourcecode or a different element.
b) Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<!-- [rfced] FYI, we added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Autonomous Systems (ASes)
VPN Routing and Forwarding (VRF)
Provider Edge (PE)
Customer Edge (CE)
Segment Routing over MPLS (SR-MPLS)
Label Switched Paths (LSPs)
Network Layer Reachability Information (NLRI)
Network Function Virtualization (NFV)
Segment Routing Global Block (SRGB)
Outgoing Interface (OIF)
end-to-end (E2E)
Longest Prefix Match (LPM)
pseudowire (PW)
Penultimate Segment Pop (PSP)
-->
<!-- [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 Index vs. label index
Label vs. label
Color value vs. color value
NLRI Type vs. NLRI type
NLRI Length vs. NLRI length
Key Length vs. Key length vs. key length
b) "Flex Algo" appears in various forms. Please review and let us know
how to update for consistency:
Flex-Algo vs. Flex Algo vs. FlexAlgo
Flex Algo 128 vs. Flex-Algo 128 vs. Flex-Algo FA128 vs. FA 128 vs. FA128
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
d) We note different use of hyphens and quotation marks in the instances
below. How would you like these items to be stylized for consistency?
low-delay vs. 'low-delay' vs. "low-delay" vs. "low delay"
low-cost vs. low cost
-->
<!-- [rfced] Terminology: We have already updated (or plan to update) the
terms below for consistency. Please review and let us know any objections.
a) We note different uses of the terms below. For consistency, we plan to
update the item on the left of the arrow to the term on the right.
Non-Key TLVs -> non-key TLVs
multi-protocol -> multiprotocol (for consistency with RFC 4760)
Label Index TLV -> Label-Index TLV (for consistency with RFC 8669)
data-plane -> data plane
control-plane -> control plane
SR policy, SR-policy, SR-Policy -> SR Policy (for consistency with RFC 9256)
b) The terms "border router" and "transport RR" appear throughout the document
after their abbreviations "BR" and "TRR" are introduced. For consistency, may
we update to use the abbreviations (after they are first introduced)?
c) We note "Extended Community" and "Local Color Mapping" are hyphenated
differently throughout this document (some examples below). For consistency
with RFCs 9012 and 9256, may we update these instances to "Extended Community"
and "Local Color Mapping" (no hyphens)?
Local-Color-Mapping Extended-Community (LCM-EC)
Local Color Mapping (LCM) Extended Community
Local Color Mapping Extended-Community
Route Target (RT) Extended-Communities
Transitive Opaque Extended-Community
BGP Extended-Community
d) FYI - We have already updated the terms below as follows for consistency
with their relevant RFCs.
RT-Constrain -> RT Constrain (per RFC 4684)
Prefix-SID Attribute -> Prefix-SID attribute (per RFC 8669)
BGP Prefix-SID Attribute -> BGP Prefix-SID attribute (per RFC 8669)
SRv6 service SID -> SRv6 Service SID (per RFC 9252)
SR Domain -> SR domain (per RFC 8402)
END behavior -> End behavior (per RFC 8986)
Route Target (RT) Extended-Communities -> Route Target (RT) Extended Communities
(per RFC 4360)
AIGP Attribute -> AIGP attribute (per RFC 7311)
e) Is the term "CAR color-aware path" (3 instances) necessary, or should
it simply be "CAR path" (10 instances)?
Section 1.2
- V/v is steered on BGP CAR color-aware path
- V/v is steered on a BGP CAR color-aware path that is itself ...
Section 3:
All the steering variations described in [RFC9256] are
applicable to BGP CAR color-aware paths: on-demand steering, ...
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
a) For example, please consider whether "native" should be updated in the
instances below:
Section 2.7. Native MultiPath Capability
Native support for multiple transport encapsulations (e.g., MPLS, SR, SRv6, I
P)
Native encoding of SIDs avoids robustness issue...
Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is natively
steered hop by hop along IPv6 routed path...
Encapsulated service traffic is natively steered along IPv6 routed path...
b) In addition, please consider whether "traditional" should be updated for clar
ity.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
There are 4 instances currently:
If a color-aware path is not
available, local policy may map to a traditional routing/TE
path (e.g., BGP LU, RSVP-TE, IGP/LDP).
Intra-domain resolution:
BGP CAR route maps to an intra-domain color-aware path (e.g.,
SR Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE
path (e.g., RSVP-TE, IGP/LDP, BGP-LU).
* Local policy may map the CAR route to traditional mechanisms that
are unaware of color or that provide best-effort, such as RSVP-TE,
IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield
scenarios.
However, to be compatible
with traditional operational usage, the CAR IP Prefix route is
allowed to be without color for best-effort.
-->
 End of changes. 578 change blocks. 
3163 lines changed or deleted 4042 lines changed or added

This html diff was produced by rfcdiff 1.48.