rfc9252xml2.original.xml   rfc9252.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-bess-srv6-services-15"
ipr="trust200902">
<?xml-stylesheet 3type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-srv6-se
rvices-15" number="9252" submissionType="IETF" category="std" consensus="true" i
pr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs
="true" sortRefs="true" version="3">
<?rfc subcompact="no" ?> <!-- xml2rfc v2v3 conversion 3.12.2 -->
<front> <front>
<title abbrev="SRv6 BGP based Overlay Services">SRv6 BGP based Overlay <title abbrev="SRv6-Based BGP Overlay Services">BGP Overlay Services Based o
Services</title> n Segment Routing over IPv6 (SRv6)</title>
<seriesInfo name="RFC" value="9252"/>
<author fullname="Gaurav Dawra" initials="G" role="editor" surname="Dawra"> <author fullname="Gaurav Dawra" initials="G" role="editor" surname="Dawra">
<organization>LinkedIn</organization> <organization>LinkedIn</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>gdawra.ietf@gmail.com</email> <email>gdawra.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Tala
<author fullname="Ketan Talaulikar" initials="K" role="editor" ulikar">
surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk"> <author fullname="Robert Raszuk" initials="R" surname="Raszuk">
<organization>NTT Network Innovations</organization> <organization>NTT Network Innovations</organization>
<address> <address>
<postal> <postal>
<street>940 Stewart Dr</street> <street>940 Stewart Dr.</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>robert@raszuk.net</email> <email>robert@raszuk.net</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene"> <author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>France</country> <country>France</country>
</postal> </postal>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Shunwan Zhuang" initials="S" surname="Zhuang"> <author fullname="Shunwan Zhuang" initials="S" surname="Zhuang">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhuangshunwan@huawei.com</email> <email>zhuangshunwan@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Jorge Rabadan" initials="J" surname="Rabadan"> <author fullname="Jorge Rabadan" initials="J" surname="Rabadan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<date year="2022" month="July"/>
<date year=""/> <area>RTG</area>
<workgroup>BESS</workgroup>
<area>Routing</area>
<workgroup>BESS Working Group</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>SRv6</keyword> <keyword>SRv6</keyword>
<abstract> <abstract>
<t>This document defines procedures and messages for SRv6-based BGP <t>This document defines procedures and messages for SRv6-based BGP
services including L3VPN, EVPN, and Internet services. It builds on services, including Layer 3 Virtual Private Network (L3VPN),
RFC4364 &ldquo;BGP/MPLS IP Virtual Private Networks (VPNs)&rdquo; and Ethernet VPN (EVPN), and Internet services. It builds on
RFC7432 &ldquo;BGP MPLS-Based Ethernet VPN&rdquo;.</t> "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and
"BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>SRv6 refers to Segment Routing instantiated on the IPv6 dataplane <name>Introduction</name>
<xref target="RFC8402"/>.</t> <t>SRv6 refers to Segment Routing instantiated on the IPv6 data plane
<xref target="RFC8402" format="default"/>.</t>
<t>BGP is used to advertise the reachability of prefixes of a particular <t>BGP is used to advertise the reachability of prefixes of a particular
service from an egress PE to ingress PE nodes.</t> service from an egress Provider Edge (PE) to ingress PE nodes.</t>
<t>SRv6-based BGP services refer to the Layer 3 (L3) and Layer 2 (L2) over
<t>SRv6 based BGP services refers to the Layer-3 and Layer-2 overlay lay
services with BGP as control plane and SRv6 as dataplane. This document services with BGP as the control plane and SRv6 as the data plane. This do
defines procedures and messages for SRv6-based BGP services including cument
L3VPN, EVPN, and Internet services. It builds on <xref defines procedures and messages for SRv6-based BGP services, including
target="RFC4364"/> &ldquo;BGP/MPLS IP Virtual Private Networks L3VPN, EVPN, and Internet services. It builds on "BGP/MPLS IP Virtual
(VPNs)&rdquo; and <xref target="RFC7432"/> &ldquo;BGP MPLS-Based Private Networks (VPNs)" <xref target="RFC4364" format="default"/> and
Ethernet VPN&rdquo;.</t> "BGP MPLS-Based Ethernet VPN" <xref target="RFC7432" format="default"/>.</
t>
<t>SRv6 SID refers to an SRv6 Segment Identifier as defined in <xref <t>SRv6 SID refers to an SRv6 Segment Identifier, as defined in <xref
target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
<t>SRv6 Service SID refers to an SRv6 SID associated with one of the <t>SRv6 Service SID refers to an SRv6 SID associated with one of the
service-specific SRv6 Endpoint behaviors on the advertising Provider service-specific SRv6 Endpoint Behaviors on the advertising
Edge (PE) router, such as (but not limited to), End.DT (Table lookup in PE router, such as (but not limited to) End.DT (look up in the
a VRF) or End.DX (cross-connect to a nexthop) behaviors in the case of Virtual Routing and Forwarding (VRF) table) or End.DX (cross-connect to a
Layer-3 Virtual Private Network (L3VPN) service as defined in <xref next hop) behaviors in the case of
target="RFC8986"/>. This document describes how existing BGP messages L3VPN service, as defined in <xref
between PEs may carry SRv6 Service SIDs to interconnect PEs and form target="RFC8986" format="default"/>. This document describes how existing
VPNs.</t> BGP messages between PEs may carry SRv6 Service SIDs to interconnect PEs
and form VPNs.</t>
<t>To provide SRv6 service with best-effort connectivity, the egress PE <t>To provide SRv6 service with best-effort connectivity, the egress PE
signals an SRv6 Service SID with the BGP overlay service route. The signals an SRv6 Service SID with the BGP overlay service route. The
ingress PE encapsulates the payload in an outer IPv6 header where the ingress PE encapsulates the payload in an outer IPv6 header where the
destination address is the SRv6 Service SID provided by the egress destination address is the SRv6 Service SID provided by the egress
Provider Edge (PE). The underlay between the PEs only needs to support PE. The underlay between the PEs only needs to support
plain IPv6 forwarding <xref target="RFC8200"/>.</t> plain IPv6 forwarding <xref target="RFC8200" format="default"/>.</t>
<t>To provide SRv6 service in conjunction with an underlay Service Level A
<t>To provide SRv6 service in conjunction with an underlay SLA from the greement (SLA) from the
ingress PE to the egress PE, the egress PE colors the overlay service ingress PE to the egress PE, the egress PE colors the overlay service
route with a Color Extended Community <xref route with a Color Extended Community <xref target="RFC9012" format="defau
target="I-D.ietf-idr-segment-routing-te-policy"/> for steering of flows lt"/> for steering flows
for those routes as specified in section 8 of <xref for those routes, as specified in <xref target="I-D.ietf-spring-segment-ro
target="I-D.ietf-spring-segment-routing-policy"/>. The ingress PE uting-policy" section="8" sectionFormat="of" format="default"/>. The ingress PE
encapsulates the payload packet in an outer IPv6 header with the segment encapsulates the payload packet in an outer IPv6 header with the
list of SR policy associated with the related SLA along with the SRv6 SR Policy segment list associated with the related SLA along with the SRv6
Service SID associated with the route using the Segment Routing Header Service SID associated with the route using the Segment Routing Header
(SRH) <xref target="RFC8754"/>. The underlay nodes whose SRv6 (SRH) <xref target="RFC8754" format="default"/>. The underlay nodes whose
SID&rsquo;s are part of the SRH segment list MUST support SRv6 data SRv6
SIDs are part of the SRH segment list <bcp14>MUST</bcp14> support the SRv6
data
plane.</t> plane.</t>
<section anchor="REQ" numbered="true" toc="default">
<section anchor="REQ" title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> 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="SIDTLV" numbered="true" toc="default">
<section anchor="SIDTLV" title="SRv6 Services TLVs "> <name>SRv6 Services TLVs</name>
<t>This document extends the use of the BGP Prefix-SID attribute <xref <t>This document extends the use of the BGP Prefix-SID attribute <xref tar
target="RFC8669"/> to carry SRv6 SIDs and their associated information get="RFC8669" format="default"/> to carry SRv6 SIDs and their associated informa
with the BGP address-families that are listed further in this tion
with the BGP address families that are listed further in this
section.</t> section.</t>
<t>The SRv6 Service TLVs are defined as two new TLVs of the BGP <t>The SRv6 Service TLVs are defined as two new TLVs of the BGP
Prefix-SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2 Prefix-SID attribute to achieve signaling of SRv6 SIDs for L3 and L2
services.</t> services.</t>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>SRv6 L3 Service TLV:</dt>
<t>SRv6 L3 Service TLV: This TLV encodes Service SID information for <dd>This TLV encodes Service SID information for
SRv6 based L3 services. It corresponds to the equivalent SRv6-based L3 services. It corresponds to the equivalent
functionality provided by an MPLS Label when received with a Layer 3 functionality provided by an MPLS label when received with a Layer 3
service route as defined in <xref target="RFC4364"/> <xref service route, as defined in <xref target="RFC4364" format="default"/>
target="RFC4659"/> <xref target="RFC8950"/> <xref , <xref target="RFC4659" format="default"/>, <xref target="RFC8950" format="defa
target="RFC9136"/>. Some SRv6 Endpoint behaviors which may be ult"/>, and <xref target="RFC9136" format="default"/>. Some SRv6 Endpoint Behavi
encoded, but not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, ors that may be
and End.DT46.</t> encoded are, but not limited to, End.DX4, End.DT4, End.DX6, End.DT6,
and End.DT46.</dd>
<t>SRv6 L2 Service TLV: This TLV encodes Service SID information for <dt>SRv6 L2 Service TLV:</dt>
SRv6 based L2 services. It corresponds to the equivalent <dd>This TLV encodes Service SID information for
functionality provided by an MPLS Label1 for Ethernet VPN (EVPN) SRv6-based L2 services. It corresponds to the equivalent
Route-Types as defined in <xref target="RFC7432"/>. Some SRv6 functionality provided by an MPLS label for Ethernet VPN (EVPN)
Endpoint behaviors which may be encoded, but not limited to, are Route Types for Layer 2 services, as defined in <xref
End.DX2, End.DX2V, End.DT2U, and End.DT2M.</t> target="RFC7432" format="default"/>. Some SRv6
</list></t> Endpoint Behaviors that may be encoded are, but not limited to,
End.DX2, End.DX2V, End.DT2U, and End.DT2M.</dd>
<t>When an egress PE is enabled for BGP Services over SRv6 data-plane, </dl>
it signals one or more SRv6 Service SIDs enclosed in SRv6 Service TLV(s) <t>When an egress PE is enabled for BGP Services over the SRv6 data plane,
within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs defined in it signals one or more SRv6 Service SIDs enclosed in an SRv6 Service TLV(s
<xref target="RFC4760"/> <xref target="RFC4659"/> <xref )
target="RFC8950"/> <xref target="RFC7432"/> <xref target="RFC4364"/> within the BGP Prefix-SID attribute attached to Multiprotocol BGP (MP-BGP)
<xref target="RFC9136"/> where applicable as described in <xref Network Layer Reachability Information (NLRI) defined in
target="L3BGP"/> and <xref target="EVPNBGP"/>.</t> <xref target="RFC4760" format="default"/>, <xref target="RFC4659" format="
default"/>, <xref target="RFC8950" format="default"/>, <xref target="RFC7432" fo
<t>The support for BGP Multicast VPN (MVPN) Services <xref rmat="default"/>, <xref target="RFC4364" format="default"/>, and
target="RFC6513"/> with SRv6 is outside the scope of this document.</t> <xref target="RFC9136" format="default"/>, where applicable, as describe
d in Sections <xref target="L3BGP" format="counter"/> and <xref target="EVPNBGP"
format="counter"/>.</t>
<t>The support for BGP Multicast VPN (MVPN) Services <xref target="RFC6513
" format="default"/> with SRv6 is outside the scope of this document.</t>
<t>The following depicts the SRv6 Service TLVs encoded in the BGP <t>The following depicts the SRv6 Service TLVs encoded in the BGP
Prefix-SID Attribute:</t> Prefix-SID attribute:</t>
<figure anchor="SRV6SVCTLV">
<figure anchor="SRV6SVCTLV" title="SRv6 Service TLVs"> <name>SRv6 Service TLVs</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | RESERVED | | TLV Type | TLV Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Sub-TLVs // | SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>TLV Type (1 octet):</dt>
<t>TLV Type (1 octet): This field is assigned values from the IANA <dd>This field is assigned a value from IANA's
registry "BGP Prefix-SID TLV Types". It is set to 5 for SRv6 L3 "BGP Prefix-SID TLV Types" subregistry. It is set to 5 for the SRv6 L3
Service TLV. It is set to 6 for SRv6 L2 Service TLV.</t> Service TLV. It is set to 6 for the SRv6 L2 Service TLV.</dd>
<dt>TLV Length (2 octets):</dt>
<t>TLV Length (2 octets): Specifies the total length, in octets, of <dd>This field specifies the total length, in octets, of
the TLV Value.</t> the TLV Value.</dd>
<dt>RESERVED (1 octet):</dt>
<t>RESERVED (1 octet): This field is reserved; it MUST be set to 0 <dd>This field is reserved; it <bcp14>MUST</bcp14> be set to 0
by the sender and ignored by the receiver.</t> by the sender and ignored by the receiver.</dd>
<dt>SRv6 Service Sub-TLVs (variable):</dt>
<t>SRv6 Service Sub-TLVs (variable): This field contains SRv6 <dd>This field contains SRv6
Service related information and is encoded as an unordered list of service-related information and is encoded as an unordered list of
Sub-TLVs whose format is described below.</t> Sub-TLVs whose format is described below.</dd>
</list></t> </dl>
<t>A BGP speaker receiving a route containing the BGP Prefix-SID attribute
<t>A BGP speaker receiving a route containing BGP Prefix-SID Attribute
with one or more SRv6 Service TLVs observes the following rules when with one or more SRv6 Service TLVs observes the following rules when
advertising the received route to other peers:<list style="symbols"> advertising the received route to other peers:</t>
<t>if the nexthop is unchanged during the advertisement, the SRv6 <ul spacing="normal">
<li>If the BGP next hop is unchanged during the advertisement, the SRv6
Service TLVs, including any unrecognized Types of Sub-TLV and Service TLVs, including any unrecognized Types of Sub-TLV and
Sub-Sub-TLV, SHOULD be propagated further. In addition, all Reserved Sub-Sub-TLV, <bcp14>SHOULD</bcp14> be propagated further. In addition,
fields in the TLV or Sub-TLV or Sub-Sub-TLV MUST be propagated all Reserved
unchanged.</t> fields in the TLV, Sub-TLV, or Sub-Sub-TLV <bcp14>MUST</bcp14> be prop
agated
<t>if the nexthop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs unchanged.</li>
SHOULD be updated with the locally allocated SRv6 SID information. <li>If the BGP next hop is changed, the TLVs, Sub-TLVs, and Sub-Sub-TLVs
Any unrecognized received Sub-TLVs and Sub-Sub-TLVs MUST be <bcp14>SHOULD</bcp14> be updated with the locally allocated SRv6 SID i
removed.</t> nformation.
</list></t> Any received Sub-TLVs and Sub-Sub-TLVs that are unrecognized <bcp14>MU
ST</bcp14> be
removed.</li>
</ul>
</section> </section>
<section anchor="SRv6-TLV" numbered="true" toc="default">
<section anchor="SRv6-TLV" title="SRv6 Service Sub-TLVs"> <name>SRv6 Service Sub-TLVs</name>
<t>The format of a single SRv6 Service Sub-TLV is depicted below:</t> <t>The format of a single SRv6 Service Sub-TLV is depicted below:</t>
<figure anchor="SRV6SVCSTLV">
<figure anchor="SRV6SVCSTLV" title="SRv6 Service Sub-TLVs"> <name>SRv6 Service Sub-TLVs</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | SRv6 Service // | SRv6 Service | SRv6 Service | SRv6 Service //
| Sub-TLV | Sub-TLV | Sub-TLV // | Sub-TLV | Sub-TLV | Sub-TLV //
| Type | Length | value // | Type | Length | Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>SRv6 Service Sub-TLV Type (1 octet):</dt>
<t>SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6 <dd>This field identifies the type of SRv6
service information. It is assigned values from the IANA Registry service information. It is assigned a value from IANA's
"SRv6 Service Sub-TLV Types".</t> "SRv6 Service Sub-TLV Types" subregistry.</dd>
<dt>SRv6 Service Sub-TLV Length (2 octets):</dt>
<t>SRv6 Service Sub-TLV Length (2 octets): Specifies the total <dd>This field specifies the total
length, in octets, of the Sub-TLV Value field.</t> length, in octets, of the Sub-TLV Value field.</dd>
<dt>SRv6 Service Sub-TLV Value (variable):</dt>
<t>SRv6 Service Sub-TLV Value (variable): Contains data specific to <dd>This field contains data specific to
the Sub-TLV Type. In addition to fixed-length data, it contains the Sub-TLV Type. In addition to fixed-length data, it contains
other properties of the SRv6 Service encoded as a set of SRv6 other properties of the SRv6 service encoded as a set of SRv6
Service Data Sub-Sub-TLVs whose format is described in <xref Service Data Sub-Sub-TLVs whose format is described in <xref
target="SID-SERVICE-DATA-TLV"/> below.</t> target="SID-SERVICE-DATA-TLV" format="default"/> below.</dd>
</list></t> </dl>
<section anchor="SRv6-SID-INFO" numbered="true" toc="default">
<section anchor="SRv6-SID-INFO" title="SRv6 SID Information Sub-TLV"> <name>SRv6 SID Information Sub-TLV</name>
<t>SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information <t>SRv6 Service Sub-TLV Type 1 is assigned for the SRv6 SID Information
Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its Sub-TLV. This Sub-TLV contains a single SRv6 SID along with its
properties. Its encoding is depicted below:</t> properties. Its encoding is depicted below:</t>
<figure anchor="SRV6SIDINFO">
<figure anchor="SRV6SIDINFO" title="SRv6 SID Information Sub-TLV"> <name>SRv6 SID Information Sub-TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service | SRv6 Service | | | SRv6 Service | SRv6 Service | |
| Sub-TLV | Sub-TLV | | | Sub-TLV | Sub-TLV | |
| Type=1 | Length | RESERVED1 | | Type=1 | Length | RESERVED1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Value (16 octets) // | SRv6 SID Value (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 | | Svc SID Flags | SRv6 Endpoint Behavior | RESERVED2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 Service Data Sub-Sub-TLVs // | SRv6 Service Data Sub-Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
k> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>SRv6 Service Sub-TLV Type (1 octet):</dt>
<t>SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to <dd>This field is set to 1 to
represent SRv6 SID Information Sub-TLV.</t> represent the SRv6 SID Information Sub-TLV.</dd>
<dt>SRv6 Service Sub-TLV Length (2 octets):</dt>
<t>SRv6 Service Sub-TLV Length (2 octets): This field contains the <dd>This field contains the
total length, in octets, of the Value field of the Sub-TLV.</t> total length, in octets, of the Value field of the Sub-TLV.</dd>
<dt>RESERVED1 (1 octet):</dt>
<t>RESERVED1 (1 octet): MUST be set to 0 by the sender and ignored <dd>This field <bcp14>MUST</bcp14> be set to 0 by the sender and igno
by the receiver.</t> red
by the receiver.</dd>
<t>SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in <dt>SRv6 SID Value (16 octets):</dt>
<xref target="RFC8986"/></t> <dd>This field encodes an SRv6 SID, as defined in
<xref target="RFC8986" format="default"/>.</dd>
<t>SRv6 Service SID Flags (1 octet): Encodes SRv6 Service SID <dt>SRv6 Service SID Flags (1 octet):</dt>
Flags - none are currently defined. SHOULD be set to 0 by the <dd>This field encodes SRv6 Service SID
sender and any unknown flags MUST be ignored by the receiver.</t> Flags -- none are currently defined. It <bcp14>MUST</bcp14> be set t
o 0 by the
<t>SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint sender and any unknown flags <bcp14>MUST</bcp14> be ignored by the r
behavior codepoint value that is associated with SRv6 SID. The eceiver.</dd>
codepoints used are from the "SRv6 Endpoint Behavior" registry <dt>SRv6 Endpoint Behavior (2 octets):</dt>
under the IANA "Segment Routing" parameters registry that was <dd>This field encodes the SRv6 Endpoint
introduced by <xref target="RFC8986"/>. The opaque endpoint Behavior codepoint value that is associated with the SRv6 SID. The
behavior (i.e., value 0xFFFF) MAY be used when the advertising codepoints used are from IANA's "SRv6 Endpoint Behaviors" subregistr
router wishes to abstract the actual behavior of it's locally y
instantiated SRv6 SID.</t> under the "Segment Routing" registry that was
introduced by <xref target="RFC8986" format="default"/>. The opaque
<t>RESERVED2 (1 octet): MUST be set to 0 by the sender and ignored SRv6 Endpoint
by the receiver.</t> Behavior (i.e., value 0xFFFF) <bcp14>MAY</bcp14> be used when the ad
vertising
<t>SRv6 Service Data Sub-Sub-TLV Value (variable): Used to router wishes to abstract the actual behavior of its locally
instantiated SRv6 SID.</dd>
<dt>RESERVED2 (1 octet):</dt>
<dd>This field <bcp14>MUST</bcp14> be set to 0 by the sender and igno
red
by the receiver.</dd>
<dt>SRv6 Service Data Sub-Sub-TLV Value (variable):</dt>
<dd>This field is used to
advertise properties of the SRv6 SID. It is encoded as a set of advertise properties of the SRv6 SID. It is encoded as a set of
SRv6 Service Data Sub-Sub-TLVs.</t> SRv6 Service Data Sub-Sub-TLVs.</dd>
</list></t> </dl>
<t>The choice of SRv6 Endpoint Behavior of the SRv6 SID is entirely up
<t>The choice of SRv6 Endpoint behavior of the SRv6 SID is entirely up to the originator of the advertisement. While Sections <xref target="L3B
to the originator of the advertisement. While <xref target="L3BGP"/> GP"
and <xref target="EVPNBGP"/> list the SRv6 Endpoint Behaviors that are format="counter"/> and <xref target="EVPNBGP" format="counter"/> list the
SRv6 Endpoint Behaviors that are
normally expected to be used by the specific route advertisements, the normally expected to be used by the specific route advertisements, the
reception of other SRv6 Endpoint behaviors (e.g., new behaviors that reception of other SRv6 Endpoint Behaviors (e.g., new behaviors that
may be introduced in the future) is not considered an error. An may be introduced in the future) is not considered an error. An
unrecognized endpoint behavior MUST NOT be considered invalid by the unrecognized SRv6 Endpoint Behavior <bcp14>MUST NOT</bcp14> be considere
receiver except for behaviors that involve the use of arguments (refer d invalid by the
to <xref target="SRv6-SID-STRUCTURE"/> for details on argument receiver, except for behaviors that involve the use of arguments (refer
validation). An implementation MAY log a rate-limited warning when it to <xref target="SRv6-SID-STRUCTURE" format="default"/> for details on a
rgument
validation). An implementation <bcp14>MAY</bcp14> log a rate-limited war
ning when it
receives an unexpected behavior.</t> receives an unexpected behavior.</t>
<t>When multiple SRv6 SID Information Sub-TLVs are present, the <t>When multiple SRv6 SID Information Sub-TLVs are present, the
ingress PE SHOULD use the SRv6 SID from the first instance of the ingress PE <bcp14>SHOULD</bcp14> use the SRv6 SID from the first instanc
Sub-TLV. An implementation MAY provide a local policy to override this e of the
Sub-TLV. An implementation <bcp14>MAY</bcp14> provide a local policy to
override this
selection.</t> selection.</t>
</section> </section>
<section anchor="SID-SERVICE-DATA-TLV" numbered="true" toc="default">
<section anchor="SID-SERVICE-DATA-TLV" <name>SRv6 Service Data Sub-Sub-TLVs</name>
title="SRv6 Service Data Sub-Sub-TLVs">
<t>The format of the SRv6 Service Data Sub-Sub-TLV is depicted <t>The format of the SRv6 Service Data Sub-Sub-TLV is depicted
below:</t> below:</t>
<figure anchor="SRV6SVCDATASTLV">
<figure anchor="SRV6SVCDATASTLV" <name>SRv6 Service Data Sub-Sub-TLVs</name>
title="SRv6 Service Data Sub-Sub-TLVs"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Data | Sub-Sub-TLV Length |Sub-Sub TLV //
| Service Data | Sub-Sub-TLV Length |Sub-Sub TLV // | Sub-Sub-TLV | | Value //
| Sub-Sub-TLV | | Value // | Type | | //
| Type | | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artw ]]></artwork>
ork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>SRv6 Service Data Sub-Sub-TLV Type (1 octet):</dt>
<t>SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the <dd>This field identifies the
type of Sub-Sub-TLV. It is assigned values from the IANA Registry type of Sub-Sub-TLV. It is assigned a value from IANA's
"SRv6 Service Data Sub-Sub-TLVs".</t> "SRv6 Service Data Sub-Sub-TLV Types" subregistry.</dd>
<dt>SRv6 Service Data Sub-Sub-TLV Length (2 octets):</dt>
<t>SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the <dd>This field specifies the
total length, in octets, of the Sub-Sub-TLV Value field.</t> total length, in octets, of the Sub-Sub-TLV Value field.</dd>
<dt>SRv6 Service Data Sub-Sub-TLV Value (variable):</dt>
<t>SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data <dd>This field contains data
specific to the Sub-Sub-TLV Type.</t> specific to the Sub-Sub-TLV Type.</dd>
</list></t> </dl>
<section anchor="SRv6-SID-STRUCTURE" numbered="true" toc="default">
<section anchor="SRv6-SID-STRUCTURE" <name>SRv6 SID Structure Sub-Sub-TLV</name>
title="SRv6 SID Structure Sub-Sub-TLV"> <t>SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for the SRv6 SID
<t>SRv6 Service Data Sub-Sub-TLV Type 1 is assigned for SRv6 SID Structure Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV is used to
structure Sub-Sub-TLV. SRv6 SID Structure Sub-Sub-TLV is used to advertise the lengths of the individual parts of the SRv6 SID, as
advertise the lengths of the individual parts of the SRv6 SID as defined in <xref target="RFC8986" format="default"/>. The terms Locato
defined in <xref target="RFC8986"/>. The terms Locator Block and r Block and
Locator Node correspond to the B and N parts respectively of the Locator Node correspond to the B and N parts, respectively, of the
SRv6 Locator that are defined in section 3.1 of <xref SRv6 Locator that is defined in <xref target="RFC8986"
target="RFC8986"/>. It is carried as Sub-Sub-TLV in SRv6 SID section="3.1" sectionFormat="of" format="default"/>. It is
Information Sub-TLV</t> carried as Sub-Sub-TLV in the SRv6 SID Information Sub-TLV.</t>
<figure anchor="SRV6SIDSTRUCT">
<figure anchor="SRV6SIDSTRUCT" <name>SRv6 SID Structure Sub-Sub-TLV</name>
title="SRv6 SID Structure Sub-Sub-TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6 Service | SRv6 Service | Locator Block |
| SRv6 Service | SRv6 Service | Locator Block | | Data Sub-Sub | Data Sub-Sub-TLV | Length |
| Data Sub-Sub | Data Sub-Sub-TLV | Length | | -TLV Type=1 | Length | |
| -TLV Type=1 | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Node | Function | Argument | Transposition |
| Locator Node | Function | Argument | Transposition | | Length | Length | Length | Length |
| Length | Length | Length | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transposition |
| Transposition | | Offset |
| Offset | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>SRv6 Service Data Sub-Sub-TLV Type (1 octet):</dt>
<t>SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is <dd>This field is set to 1 to represent the SRv6 SID Structure Sub-Su
set to 1 to represent SRv6 SID Structure Sub-Sub-TLV.</t> b-TLV.</dd>
<dt>SRv6 Service Data Sub-Sub-TLV Length (2 octets):</dt>
<t>SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field <dd>This field contains a total length of 6 octets.</dd>
contains a total length of 6 octets.</t> <dt>Locator Block Length (1 octet):</dt>
<dd>This field contains the length of the SRv6 SID Locator Block in b
<t>Locator Block Length (1 octet): Contains the length of SRv6 its.</dd>
SID Locator Block in bits.</t> <dt>Locator Node Length (1 octet):</dt>
<dd>This field contains the length of the SRv6 SID Locator Node in bi
<t>Locator Node Length (1 octet): Contains the length of SRv6 ts.</dd>
SID Locator Node in bits.</t> <dt>Function Length (1 octet):</dt>
<dd>This field contains the length of the SRv6 SID Function in bits.<
<t>Function Length (1 octet): Contains the length of SRv6 SID /dd>
Function in bits.</t> <dt>Argument Length (1 octet):</dt>
<dd>This field contains the length of the SRv6 SID Argument in bits.<
<t>Argument Length (1 octet): Contains the length of SRv6 SID /dd>
Argument in bits.</t> <dt>Transposition Length (1 octet):</dt>
<dd>This field is the size in bits for the part of the
<t>Transposition Length (1 octet): Size in bits for the part of SID that has been transposed (or shifted) into an MPLS Label
SID that has been transposed (or shifted) into a MPLS label field.</dd>
field</t> <dt>Transposition Offset (1 octet):</dt>
<dd>This field is the offset position in bits
<t>Transposition Offset (1 octet): The offset position in bits for the part of the SID that has been transposed (or shifted) into
for the part of SID that has been transposed (or shifted) into a an
MPLS label field.</t> MPLS Label field.</dd>
</list></t> </dl>
<t><xref target="SIDENCODE" format="default"/> describes mechanisms fo
<t><xref target="SIDENCODE"/> describes mechanisms for signaling of r the signaling of
the SRv6 Service SID by transposing a variable part of the SRv6 SID the SRv6 Service SID by transposing a variable part of the SRv6 SID
value and carrying them in existing MPLS label fields to achieve value and carrying this variable part in existing MPLS Label fields to achieve
more efficient packing of those service prefix NLRIs in BGP update more efficient packing of those service prefix NLRIs in BGP update
messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate messages. The SRv6 SID Structure Sub-Sub-TLV contains appropriate
length fields when the SRv6 Service SID is signaled in split parts length fields when the SRv6 Service SID is signaled in split parts
to enable the receiver to put together the SID accurately.</t> to enable the receiver to put together the SID accurately.</t>
<t>Transposition Offset indicates the bit position, and Transposition
<t>Transposition Offset indicates the bit position and Transposition
Length indicates the number of bits that are being taken out of the Length indicates the number of bits that are being taken out of the
SRv6 SID value and put into high order bits of MPLS label field. The SRv6 SID value and encoded in the MPLS Label field. The
bits that have been shifted out MUST be set to 0 in the SID bits that have been shifted out <bcp14>MUST</bcp14> be set to 0 in the
SID
value.</t> value.</t>
<t>A Transposition Length of 0 indicates nothing is transposed and
<t>Transposition Length of 0 indicates nothing is transposed and
that the entire SRv6 SID value is encoded in the SID Information that the entire SRv6 SID value is encoded in the SID Information
Sub-TLV. In this case, the Transposition Offset MUST be set to Sub-TLV. In this case, the Transposition Offset <bcp14>MUST</bcp14> be set to
0.</t> 0.</t>
<t>The size of the MPLS Label field limits the bits transposed from
<t>The size of the MPLS label field limits the bits transposed from the SRv6 SID value into it. For example, the size of the MPLS Label fi
the SRv6 SID value into it. E.g., the size of MPLS label field in eld is 20 bits in
<xref target="RFC4364"/> <xref target="RFC8277"/> is 20 bits while <xref target="RFC4364" format="default"/> and <xref target="RFC8277"
in <xref target="RFC7432"/> is 24 bits.</t> format="default"/>, and the size is 24 bits in <xref target="RFC7432" f
ormat="default"/>.</t>
<t>As defined in <xref target="RFC8986"/>, the sum of the Locator <t>As defined in <xref target="RFC8986" format="default"/>, the sum of
the Locator
Block Length (LBL), Locator Node Length (LNL), Function Length (FL), Block Length (LBL), Locator Node Length (LNL), Function Length (FL),
and Argument Length (AL) fields MUST be less than or equal to 128 and Argument Length (AL) fields <bcp14>MUST</bcp14> be less than or eq ual to 128
and greater than the sum of Transposition Offset and Transposition and greater than the sum of Transposition Offset and Transposition
Length.</t> Length.</t>
<t>As an example, consider that the sum of the Locator Block and the <t>As an example, consider that the sum of the Locator Block and the
Locator Node parts is 64. For an SRv6 SID where the entire Function Locator Node parts is 64. For an SRv6 SID where the entire Function
part of size 16 bits is transposed, then the transposition offset is part of size 16 bits is transposed, the transposition offset is
set to 64 and the transposition length is set to 16. While for an set to 64 and the transposition length is set to 16. While for an
SRv6 SID where the Function length is 24 bits and only the lower SRv6 SID for which the FL is 24 bits and only the lower
order 20 bits are transposed (e.g. due to the limit of the MPLS order 20 bits are transposed (e.g., due to the limit of the MPLS
label field size), then the transposition offset is set to 68 and Label field size), the transposition offset is set to 68 and
the transposition length is set to 20.</t> the transposition length is set to 20.</t>
<t>BGP speakers that do not support this specification may <t>BGP speakers that do not support this specification may
misinterpret, on the reception of an SRv6-based BGP service route misinterpret, on the reception of an SRv6-based BGP service route
update, the part of the SRv6 SID encoded in MPLS label field(s) as update, the part of the SRv6 SID encoded in an MPLS Label field(s) as
MPLS label values for MPLS-based services. Implementations MPLS label values for MPLS-based services. Implementations
supporting this specification MUST provide a mechanism to control supporting this specification <bcp14>MUST</bcp14> provide a mechanism to control
the advertisement of SRv6-based BGP service routes on a per-neighbor the advertisement of SRv6-based BGP service routes on a per-neighbor
and per-service basis. The details of deployment designs and and per-service basis. The details of deployment designs and
implementation options are outside the scope of this document.</t> implementation options are outside the scope of this document.</t>
<t>Arguments may be generally applicable for SIDs of only specific <t>Arguments may be generally applicable for SIDs of only specific
SRv6 Endpoint behaviors (e.g., End.DT2M) and therefore the Argument SRv6 Endpoint Behaviors (e.g., End.DT2M); therefore, the AL
length MUST be set to 0 for SIDs where the Argument is not <bcp14>MUST</bcp14> be set to 0 for SIDs where the Argument is not
applicable. A receiver is unable to validate the applicability of applicable. A receiver is unable to validate the applicability of
arguments for SRv6 Endpoint behaviors that are unknown to it and arguments for SRv6 Endpoint Behaviors that are unknown to it and
hence MUST ignore SRv6 SIDs with arguments (indicated by non-zero hence <bcp14>MUST</bcp14> ignore SRv6 SIDs with arguments (indicated b
argument length) with unknown endpoint behaviors. For SIDs y a non-zero
corresponding to an endpoint behavior that is known, a receiver MUST AL) with unknown SRv6 Endpoint Behaviors. For SIDs
validate that the consistency of the argument length with the corresponding to an SRv6 Endpoint Behavior that is known, a receiver <
specific endpoint behavior definition.</t> bcp14>MUST</bcp14>
validate that the consistency of the AL with the
specific SRv6 Endpoint Behavior definition.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="SIDENCODE" numbered="true" toc="default">
<section anchor="SIDENCODE" title="Encoding SRv6 SID Information"> <name>Encoding SRv6 SID Information</name>
<t>The SRv6 Service SID(s) for a BGP Service Prefix are carried in the <t>The SRv6 Service SID(s) for a BGP service prefix is carried in the
SRv6 Services TLVs of the BGP Prefix-SID Attribute.</t> SRv6 Services TLVs of the BGP Prefix-SID attribute.</t>
<t>For certain types of BGP Services, like L3VPN where a per-VRF SID
<t>For certain types of BGP Services like L3VPN where a per-VRF SID
allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID is allocation is used (i.e., End.DT4 or End.DT6 behaviors), the same SID is
shared across multiple NLRIs thus providing efficient packing. However, shared across multiple NLRIs, thus providing efficient packing. However,
for certain other types of BGP Services like EVPN VPWS where a per-PW for certain other types of BGP Services, like EVPN Virtual Private Wire
Service (VPWS) where a per-PW
SID allocation is required (i.e., End.DX2 behavior), each NLRI would SID allocation is required (i.e., End.DX2 behavior), each NLRI would
have its own unique SID thereby resulting in inefficient packing.</t> have its own unique SID, thereby resulting in inefficient packing.</t>
<t> To achieve efficient packing, this document allows either 1) the
<t>To achieve efficient packing, this document allows the encoding of encoding of the SRv6 Service SID as a whole in the SRv6 Services
the SRv6 Service SID either as a whole in the SRv6 Services TLVs or the TLVs or 2) the encoding of only the common part of the SRv6 SID (e.g.,
encoding of only the common part of the SRv6 SID (e.g., Locator) in the Locator) in the SRv6 Services TLVs and the encoding of the variable
SRv6 Services TLVs and encoding the variable (e.g., Function or Argument (e.g., Function or Argument parts) in the existing label fields
parts) in the existing label fields specific to that service encoding. specific to that service encoding.
This later form of encoding is referred to as the Transposition Scheme This later form of encoding is referred to as the Transposition Scheme,
where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the
parts of the SRv6 SID and also indicates the offset of the variable part parts of the SRv6 SID and also indicates the offset of the variable part
along with its length in SRv6 SID value. The use of the Transposition along with its length in the SRv6 SID value. The use of the Transposition
Scheme is RECOMMENDED for the specific service encodings that allow it Scheme is <bcp14>RECOMMENDED</bcp14> for the specific service encodings th
as described further in <xref target="L3BGP"/> and <xref at allow it,
target="EVPNBGP"/>.</t> as described further in Sections <xref target="L3BGP" format="counter"/> a
nd <xref target="EVPNBGP" format="counter"/>.</t>
<t>As an example, for the EVPN VPWS service prefix described further in <t>As an example, for the EVPN VPWS service prefix described further in
<xref target="PEREVI"/>, the Function part of the SRv6 SID is encoded in <xref target="PEREVI" format="default"/>, the Function part of the SRv6 SI
the MPLS Label field of the NLRI and the SID value in the SRv6 Services D is encoded in
the MPLS Label field of the NLRI, and the SID value in the SRv6 Services
TLV carries only the Locator part with the SRv6 SID Structure TLV carries only the Locator part with the SRv6 SID Structure
Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of
Locator Block, Locator Node, and Function parts (Arguments are not Locator Block, Locator Node, and Function parts (Arguments are not
applicable for the End.DX2 behavior). Transposition Offset indicates the applicable for the End.DX2 behavior). Transposition Offset indicates the
bit position and Transposition Length indicates the number of bits that bit position, and Transposition Length indicates the number of bits that
are being taken out of the SID and put into the label field.</t> are being taken out of the SID and put into the label field.</t>
<t>In yet another example, for the EVPN Ethernet Auto-Discovery (A-D) per
<t>In yet another example, for the EVPN Ethernet A-D per Ethernet Ethernet
Segment (ES) route described further in <xref target="PERES"/>, only the Segment (ES) route described further in <xref target="PERES" format="defau
lt"/>, only the
Argument of the SID needs to be signaled. This Argument part of the SRv6 Argument of the SID needs to be signaled. This Argument part of the SRv6
SID MAY be transposed in the Ethernet Segment Identifier (ESI) Label SID <bcp14>MAY</bcp14> be transposed in the Ethernet Segment Identifier (E
field of the ESI Label Extended Community and the SID value in the SRv6 SI) Label
Services TLV is set to 0 along with the inclusion of SRv6 SID Structure field of the ESI Label extended community, and the SID value in the SRv6
Services TLV is set to 0 along with the inclusion of the SRv6 SID Structur
e
Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of Sub-Sub-TLV. The SRv6 SID Structure Sub-Sub-TLV defines the lengths of
Locator Block, Locator Node, Function and Argument parts. The offset and Locator Block, Locator Node, Function, and Argument parts. The offset and
length of the Argument part SID value moved to label field is set in length of the Argument part SID value moved to the label field is set in
transposition offset and length of SID structure TLV. The receiving transposition offset and length of the SID Structure TLV. The receiving
router is then able to put together the entire SRv6 Service SID (e.g., router is then able to put together the entire SRv6 Service SID (e.g.,
for the End.DT2M behavior) placing the label value received in the ESI for the End.DT2M behavior), placing the label value received in the ESI
Label field of the Ethernet A-D per ES route into the correct Label field of the Ethernet A-D per ES route into the correct
transposition offset and length in the SRv6 SID with the End.DT2M transposition offset and length in the SRv6 SID with the End.DT2M
behavior received for an EVPN Route Type 3 value.</t> behavior received for an EVPN Route Type 3 value.</t>
</section> </section>
<section anchor="L3BGP" numbered="true" toc="default">
<section anchor="L3BGP" title="BGP based L3 Service over SRv6"> <name>BGP-Based L3 Service over SRv6</name>
<t>BGP egress nodes (egress PEs) advertise a set of reachable prefixes. <t>BGP egress nodes (egress PEs) advertise a set of reachable prefixes.
Standard BGP update propagation schemes <xref target="RFC4271"/>, which Standard BGP update propagation schemes <xref target="RFC4271" format="def
may make use of route reflectors <xref target="RFC4456"/>, are used to ault"/>, which
may make use of route reflectors <xref target="RFC4456" format="default"/>
, are used to
propagate these prefixes. BGP ingress nodes (ingress PEs) receive these propagate these prefixes. BGP ingress nodes (ingress PEs) receive these
advertisements and may add the prefix to the RIB in an appropriate advertisements and may add the prefix to the RIB in an appropriate
VRF.</t> VRF.</t>
<t>Egress PEs that support SRv6-based L3 services advertise overlay
<t>Egress PEs which supports SRv6 based L3 services advertises overlay
service prefixes along with a Service SID enclosed in an SRv6 L3 Service service prefixes along with a Service SID enclosed in an SRv6 L3 Service
TLV within the BGP Prefix-SID Attribute. This TLV serves two purposes - TLV within the BGP Prefix-SID attribute. This TLV serves two purposes --
first, it indicates that the egress PE supports SRv6 overlay and the BGP first, it indicates that the egress PE supports SRv6 overlay, and the BGP
ingress PE receiving this route MUST perform IPv6 encapsulation and ingress PE receiving this route <bcp14>MUST</bcp14> perform IPv6 encapsula
insert an SRH <xref target="RFC8754"/> when required; second, it tion and
insert an SRH <xref target="RFC8754" format="default"/> when required; sec
ond, it
indicates the value of the Service SID to be used in the indicates the value of the Service SID to be used in the
encapsulation.</t> encapsulation.</t>
<t>Thus, the Service SID signaled only has local significance at the
<t>The Service SID thus signaled only has local significance at the egress PE, where it may be allocated or configured on a per-Customer-Edge
egress PE, where it may be allocated or configured on a per-CE or (CE) or
per-VRF basis. In practice, the SID may encode a cross-connect to a per-VRF basis. In practice, the SID may encode a cross-connect to a
specific Address Family table (End.DT) or next-hop/interface (End.DX) as specific address family table (End.DT) or next hop / interface (End.DX), a
defined in <xref target="RFC8986"/>.</t> s
defined in <xref target="RFC8986" format="default"/>.</t>
<t>The SRv6 Service SID SHOULD be routable (refer section 3.3 of <xref <t>The SRv6 Service SID <bcp14>SHOULD</bcp14> be routable (refer to <xref
target="RFC8986"/>) within the AS of the egress PE and serves the dual target="RFC8986" section="3.3" sectionFormat="of" format="default"/>) within the
Autonomous System (AS) of the egress PE and serves the dual
purpose of providing reachability between ingress PE and egress PE while purpose of providing reachability between ingress PE and egress PE while
also encoding the SRv6 Endpoint behavior.</t> also encoding the SRv6 Endpoint Behavior.</t>
<t>When steering for SRv6 services is based on shortest path forwarding <t>When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort or IGP Flexible Algorithm <xref (e.g., best effort or IGP Flexible Algorithm <xref target="I-D.ietf-lsr-fl
target="I-D.ietf-lsr-flex-algo"/>) to the egress PE, the ingress PE ex-algo" format="default"/>) to the egress PE, the ingress PE
encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header
(using H.Encaps or H.Encaps.Red flavors specified in <xref (using H.Encaps or H.Encaps.Red flavors specified in <xref target="RFC8986
target="RFC8986"/>) where the destination address is the SRv6 Service " format="default"/>), where the destination address is the SRv6 Service
SID associated with the related BGP route update. Therefore, the ingress SID associated with the related BGP route update. Therefore, the ingress
PE MUST perform resolvability check for the SRv6 Service SID before PE <bcp14>MUST</bcp14> perform a resolvability check for the SRv6 Service SID before
considering the received prefix for the BGP best path computation. The considering the received prefix for the BGP best path computation. The
resolvability is evaluated as per <xref target="RFC4271"/>. If the SRv6 resolvability is evaluated as per <xref target="RFC4271" format="default"/ >. If the SRv6
SID is reachable via more than one forwarding table, local policy is SID is reachable via more than one forwarding table, local policy is
used to determine which table to use. The result of an SRv6 Service SID used to determine which table to use. The result of an SRv6 Service SID
resolvability (e.g., when provided via IGP Flexible Algorithm) can be resolvability (e.g., when provided via IGP Flexible Algorithm) can be
ignored if the ingress PE has a local policy that allows an alternate ignored if the ingress PE has a local policy that allows an alternate
steering mechanism to reach the egress PE. The details of such steering steering mechanism to reach the egress PE. The details of such steering
mechanisms are outside the scope of this document.</t> mechanisms are outside the scope of this document.</t>
<t>For service over SRv6 core, the egress PE sets the BGP next hop to one
<t>For service over SRv6 core, the egress PE sets the next-hop to one of of
its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator its IPv6 addresses. Such an address <bcp14>MAY</bcp14> be covered by the S
from which the SRv6 Service SID is allocated. The next-hop is used for Rv6 Locator
from which the SRv6 Service SID is allocated. The BGP next hop is used for
tracking the reachability of the egress PE based on existing BGP tracking the reachability of the egress PE based on existing BGP
procedures.</t> procedures.</t>
<t>When the BGP route received at an ingress PE is colored with a
<t>When the BGP route is received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the
Color Extended community and a valid SRv6 Policy is available, the steering for service flows is performed as described in <xref target="I-D.
steering for service flows is performed as described in Section 8 of ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="defau
<xref target="I-D.ietf-spring-segment-routing-policy"/>. When the lt"/>. When the
ingress PE determines (with the help of SRv6 SID Structure) that the ingress PE determines (with the help of the SRv6 SID Structure) that the
Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of
the egress PE) in the SR Policy segment list, it MAY exclude that last the egress PE) in the SR Policy segment list, it <bcp14>MAY</bcp14> exclud e that last
SRv6 SID when steering the service flow. For example, the effective SRv6 SID when steering the service flow. For example, the effective
segment list of the SRv6 Policy associated with SID list &lt;S1, S2, segment list of the SRv6 Policy associated with SID list &lt;S1, S2,
S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t> S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t>
<section anchor="L3BGPVPNv4" numbered="true" toc="default">
<section anchor="L3BGPVPNv4" title="IPv4 VPN Over SRv6 Core"> <name>IPv4 VPN over SRv6 Core</name>
<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN <t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
Over IPv6 Core defined in <xref target="RFC8950"/>.</t> unicast over IPv6 core defined in <xref target="RFC8950" format="default"/>.<
/t>
<t>Label field of IPv4-VPN NLRI is encoded as specified in <xref <t>The label field of IPv4-VPN NLRI is encoded as specified in <xref tar
target="RFC8277"/> with the 20-bit Label Value set to the whole or a get="RFC8277" format="default"/> with the 20-bit Label Value set to the whole or
a
portion of the Function part of the SRv6 SID when the Transposition portion of the Function part of the SRv6 SID when the Transposition
Scheme of encoding (<xref target="SIDENCODE"/>) is used and otherwise Scheme of encoding (<xref target="SIDENCODE" format="default"/>) is used
set to Implicit NULL. When using the Transposition Scheme, the ; otherwise,
Transposition Length MUST be less than or equal to 20 and less than or it is set to Implicit NULL. When using the Transposition Scheme, the
equal to the Function Length.</t> Transposition Length <bcp14>MUST</bcp14> be less than or equal to 20 and
less than or
<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The equal to the FL.</t>
SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. T
he
SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX4, E
nd.DT4, or
End.DT46.</t> End.DT46.</t>
</section> </section>
<section anchor="L3BGPVPNv6" numbered="true" toc="default">
<section anchor="L3BGPVPNv6" title="IPv6 VPN Over SRv6 Core "> <name>IPv6 VPN over SRv6 Core</name>
<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN <t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv6 VPN
over IPv6 Core is defined in <xref target="RFC4659"/>.</t> over IPv6 core, as defined in <xref target="RFC4659" format="default"/>.
</t>
<t>Label field of the IPv6-VPN NLRI is encoded as specified in <xref <t>The label field of the IPv6-VPN NLRI is encoded as specified in <xref
target="RFC8277"/> with the 20-bit Label Value set to the whole or a target="RFC8277" format="default"/> with the 20-bit Label Value set to the whol
e or a
portion of the Function part of the SRv6 SID when the Transposition portion of the Function part of the SRv6 SID when the Transposition
Scheme of encoding (<xref target="SIDENCODE"/>) is used and otherwise Scheme of encoding (<xref target="SIDENCODE" format="default"/>) is used
set to Implicit NULL. When using the Transposition Scheme, the ; otherwise,
Transposition Length MUST be less than or equal to 20 and less than or it is set to Implicit NULL. When using the Transposition Scheme, the
equal to the Function Length.</t> Transposition Length <bcp14>MUST</bcp14> be less than or equal to 20 and
less than or
<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The equal to the FL.</t>
SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, <t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. T
he
SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX6, E
nd.DT6, or
End.DT46.</t> End.DT46.</t>
</section> </section>
<section anchor="L3BGPINTv4" numbered="true" toc="default">
<section anchor="L3BGPINTv4" title="Global IPv4 over SRv6 Core"> <name>Global IPv4 over SRv6 Core</name>
<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over <t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 over
IPv6 Core is defined in <xref target="RFC8950"/>.</t> IPv6 core, as defined in <xref target="RFC8950" format="default"/>.</t>
<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The <t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4, SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX4, E nd.DT4, or
End.DT46.</t> End.DT46.</t>
</section> </section>
<section anchor="L3BGPINTv6" numbered="true" toc="default">
<section anchor="L3BGPINTv6" title="Global IPv6 over SRv6 Core"> <name>Global IPv6 over SRv6 Core</name>
<t>The MP_REACH_NLRI over SRv6 core is encoded according to <xref <t>The MP_REACH_NLRI over SRv6 core is encoded according to <xref target
target="RFC2545"> </xref></t> ="RFC2545" format="default"> </xref>.</t>
<t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. T
<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The he
SRv6 Endpoint behavior SHOULD be one of these: End.DX6, End.DT6, SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX6, E
nd.DT6, or
End.DT46.</t> End.DT46.</t>
</section> </section>
</section> </section>
<section anchor="EVPNBGP" numbered="true" toc="default">
<section anchor="EVPNBGP" title="BGP based Ethernet VPN (EVPN) over SRv6"> <name>BGP-Based Ethernet VPN (EVPN) over SRv6</name>
<t><xref target="RFC7432"/> provides an extendable method of building an <t><xref target="RFC7432" format="default"/> provides an extendable method
Ethernet VPN (EVPN) overlay. It primarily focuses on MPLS based EVPNs of building an
and <xref target="RFC8365"/> extends to IP-based EVPN overlays. <xref EVPN overlay. It primarily focuses on MPLS-based EVPNs,
target="RFC7432"/> defines Route Types 1, 2, and 3 which carry prefixes and <xref target="RFC8365" format="default"/> extends to IP-based EVPN ove
rlays. <xref target="RFC7432" format="default"/> defines Route Types 1, 2, and 3
, which carry prefixes
and MPLS Label fields; the Label fields have a specific use for MPLS and MPLS Label fields; the Label fields have a specific use for MPLS
encapsulation of EVPN traffic. Route Type 5 carrying MPLS label encapsulation of EVPN traffic. Route Type 5 carrying MPLS label
information (and thus encapsulation information) for EVPN is defined in information (and thus encapsulation information) for an EVPN is defined in
<xref target="RFC9136"/>. Route Types 6, 7, and 8 are defined in <xref <xref target="RFC9136" format="default"/>. Route Types 6, 7, and 8 are def
target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>.<list style="symbols"> ined in <xref target="RFC9251" format="default"/>.</t>
<t>Ethernet Auto-discovery Route (Route Type 1)</t> <ul spacing="normal">
<li>Ethernet Auto-Discovery (A-D) route (Route Type 1)</li>
<t>MAC/IP Advertisement Route (Route Type 2)</t> <li>MAC/IP Advertisement route (Route Type 2)</li>
<li>Inclusive Multicast Ethernet Tag route (Route Type 3)</li>
<t>Inclusive Multicast Ethernet Tag Route (Route Type 3)</t> <li>Ethernet Segment route (Route Type 4)</li>
<li>IP Prefix route (Route Type 5)</li>
<t>Ethernet Segment route (Route Type 4)</t> <li>Selective Multicast Ethernet Tag route (Route Type 6)</li>
<li>Multicast Membership Report Synch route (Route Type 7)</li>
<t>IP prefix route (Route Type 5)</t> <li>Multicast Leave Synch route (Route Type 8)</li>
</ul>
<t>Selective Multicast Ethernet Tag route (Route Type 6)</t>
<t>Multicast Membership Report Synch route (Route Type 7)</t>
<t>Multicast Leave Synch route (Route Type 8)</t>
</list></t>
<t>The specifications for other EVPN Route Types are outside the scope <t>The specifications for other EVPN Route Types are outside the scope
of this document.</t> of this document.</t>
<t>To support SRv6-based EVPN overlays, one or more SRv6 Service SIDs
<t>To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs are advertised with Route Types 1, 2, 3, and 5. The SRv6 Service SID(s)
are advertised with Route Type 1, 2, 3, and 5. The SRv6 Service SID(s) per Route Type is advertised in SRv6 L3/L2 Service TLVs within the BGP
per Route Type are advertised in SRv6 L3/L2 Service TLVs within the BGP Prefix-SID attribute. Signaling of the SRv6 Service SID(s) serves two
Prefix-SID Attribute. Signaling of SRv6 Service SID(s) serves two purposes -- first, it indicates that the BGP egress device supports SRv6
purposes - first, it indicates that the BGP egress device supports SRv6 overlay, and the BGP ingress device receiving this route <bcp14>MUST</bcp1
overlay and the BGP ingress device receiving this route MUST perform 4> perform
IPv6 encapsulation and insert an SRH <xref target="RFC8754"/> when IPv6 encapsulation and insert an SRH <xref target="RFC8754" format="defaul
t"/> when
required; second, it indicates the value of the Service SID(s) to be required; second, it indicates the value of the Service SID(s) to be
used in the encapsulation.</t> used in the encapsulation.</t>
<t>The SRv6 Service SID <bcp14>SHOULD</bcp14> be routable (refer to <xref
<t>The SRv6 Service SID SHOULD be routable (refer section 3.3 of <xref target="RFC8986" section="3.3" sectionFormat="of" format="default"/>) within the
target="RFC8986"/>) within the AS of the egress PE and serves the dual AS of the egress PE and serves the dual
purpose of providing reachability between ingress PE and egress PE while purpose of providing reachability between the ingress PE and egress PE whi
also encoding the SRv6 Endpoint behavior.</t> le
also encoding the SRv6 Endpoint Behavior.</t>
<t>When steering for SRv6 services is based on shortest path forwarding <t>When steering for SRv6 services is based on shortest path forwarding
(e.g., best-effort or IGP Flexible Algorithm <xref (e.g., best effort or IGP Flexible Algorithm <xref target="I-D.ietf-lsr-fl
target="I-D.ietf-lsr-flex-algo"/>) to the egress PE, the ingress PE ex-algo" format="default"/>) to the egress PE, the ingress PE
encapsulates the customer Layer 2 Ethernet packet in an outer IPv6 encapsulates the customer Layer 2 Ethernet packet in an outer IPv6
header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in <xref header (using H.Encaps.L2 or H.Encaps.L2.Red flavors specified in <xref ta
target="RFC8986"/>) where the destination address is the SRv6 Service rget="RFC8986" format="default"/>) where the destination address is the SRv6 Ser
vice
SID associated with the related BGP route update. Therefore, the ingress SID associated with the related BGP route update. Therefore, the ingress
PE MUST perform resolvability check for the SRv6 Service SID before PE <bcp14>MUST</bcp14> perform a resolvability check for the SRv6 Service SID before
considering the received prefix for the BGP best path computation. The considering the received prefix for the BGP best path computation. The
resolvability is evaluated as per <xref target="RFC4271"/>. If the SRv6 resolvability is evaluated as per <xref target="RFC4271" format="default"/ >. If the SRv6
SID is reachable via more than one forwarding table, local policy is SID is reachable via more than one forwarding table, local policy is
used to determine which table to use. The result of an SRv6 Service SID used to determine which table to use. The result of an SRv6 Service SID
resolvability (e.g., when provided via IGP Flexible Algorithm) can be resolvability (e.g., when provided via IGP Flexible Algorithm) can be
ignored if the ingress PE has a local policy that allows an alternate ignored if the ingress PE has a local policy that allows an alternate
steering mechanism to reach the egress PE. The details of such steering steering mechanism to reach the egress PE. The details of such steering
mechanisms are outside the scope of this document.</t> mechanisms are outside the scope of this document.</t>
<t>For service over SRv6 core, the egress PE sets the BGP next hop to one
<t>For service over SRv6 core, the egress PE sets the next-hop to one of of its IPv6 addresses. Such an address <bcp14>MAY</bcp14> be covered by
its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator the SRv6 Locator
from which the SRv6 Service SID is allocated. The next-hop is used for from which the SRv6 Service SID is allocated. The BGP next hop is used for
tracking the reachability of the egress PE based on existing BGP tracking the reachability of the egress PE based on existing BGP
procedures.</t> procedures.</t>
<t>When the BGP route received at an ingress PE is colored with a
<t>When the BGP route is received at an ingress PE is colored with a Color Extended Community and a valid SRv6 Policy is available, the
Color Extended community and a valid SRv6 Policy is available, the steering for service flows is performed as described in <xref target="I-D.
steering for service flows is performed as described in Section 8 of ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="defau
<xref target="I-D.ietf-spring-segment-routing-policy"/>. When the lt"/>. When the
ingress PE determines (with the help of SRv6 SID Structure) that the ingress PE determines (with the help of the SRv6 SID Structure) that the
Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of Service SID belongs to the same SRv6 Locator as the last SRv6 SID (of
the egress PE) in the SR Policy segment list, it MAY exclude that last the egress PE) in the SR Policy segment list, it <bcp14>MAY</bcp14> exclud e that last
SRv6 SID when steering the service flow. For example, the effective SRv6 SID when steering the service flow. For example, the effective
segment list of the SRv6 Policy associated with SID list &lt;S1, S2, segment list of the SRv6 Policy associated with SID list &lt;S1, S2,
S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t> S3&gt; would be &lt;S1, S2, S3-Service-SID&gt;.</t>
<section anchor="RT1" numbered="true" toc="default">
<section anchor="RT1" <name>Ethernet Auto-Discovery Route over SRv6 Core</name>
title="Ethernet Auto-discovery Route over SRv6 Core "> <t>Ethernet A-D routes are Route Type 1, as defined in
<t>Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in <xref target="RFC7432" format="default"/>, and may be used to achieve
<xref target="RFC7432"/> and may be used to achieve split-horizon split-horizon filtering, fast convergence, and aliasing.
filtering, fast convergence, and aliasing. EVPN Route Type 1 is also EVPN Route Type 1 is also used in EVPN-VPWS as well as in EVPN-flexible
used in EVPN- VPWS as well as in EVPN flexible cross-connect; mainly cross-connect, mainly to advertise point-to-point service IDs.</t>
used to advertise point-to-point services ID.</t>
<t>As a reminder, EVPN Route Type 1 is encoded as follows:</t> <t>As a reminder, EVPN Route Type 1 is encoded as follows:</t>
<figure anchor="EVPNRT1">
<figure anchor="EVPNRT1" title="EVPN Route Type 1"> <name>EVPN Route Type 1</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS label (3 octets) | | MPLS label (3 octets) |
+---------------------------------------+ +-----------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="PERES" numbered="true" toc="default">
<section anchor="PERES" title="Ethernet A-D per ES Route"> <name>Ethernet A-D per ES Route</name>
<t>Ethernet A-D per ES route NLRI encoding over SRv6 core is as per <t>Ethernet A-D per ES route NLRI encoding over SRv6 core is as per
<xref target="RFC7432"/>.</t> <xref target="RFC7432" format="default"/>.</t>
<t>The 24-bit ESI Label field of the ESI Label extended community
<t>The 24-bit ESI label field of the ESI label extended community
carries the whole or a portion of the Argument part of the SRv6 SID carries the whole or a portion of the Argument part of the SRv6 SID
when the ESI filtering approach is used along with the Transposition when the ESI filtering approach is used along with the Transposition
Scheme of encoding (<xref target="SIDENCODE"/>) and otherwise set to Scheme of encoding (<xref target="SIDENCODE" format="default"/>);
Implicit NULL value. In either case, the value is set in the high otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.e.
order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). When , as 0x000030). In either case, the value is set in the 24 bits. When
using the Transposition Scheme, the Transposition Length MUST be using the Transposition Scheme, the Transposition Length <bcp14>MUST</
less than or equal to 24 and less than or equal to the Argument bcp14> be
Length.</t> less than or equal to 24 and less than or equal to the AL.</t>
<t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be End.DT2M. When the ESI filtering SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be End.DT2M. When the ESI
approach is used, the Service SID is used to signal Arg.FE2 SID filtering
Argument for applicable End.DT2M behavior <xref target="RFC8986"/>. approach is used, the Service SID is used to signal the Arg.FE2 SID
When the local-bias approach <xref target="RFC8365"/> is used, the Argument for applicable End.DT2M behavior <xref target="RFC8986" forma
Service SID MAY be of value 0.</t> t="default"/>.
When the local-bias approach <xref target="RFC8365" format="default"/>
is used, the
Service SID <bcp14>MAY</bcp14> be of value 0.</t>
</section> </section>
<section anchor="PEREVI" numbered="true" toc="default">
<section anchor="PEREVI" title="Ethernet A-D per EVI Route"> <name>Ethernet A-D per EVI Route</name>
<t>Ethernet A-D per EVI route NLRI encoding over SRv6 core is <t>Ethernet A-D per EVPN Instance (EVI) route NLRI encoding over SRv6
similar to <xref target="RFC7432"/> and <xref target="RFC8214"/> core is
similar to what is described in <xref target="RFC7432" format="default
"/> and <xref target="RFC8214" format="default"/>
with the following change:</t> with the following change:</t>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>MPLS Label:</dt>
<t>MPLS Label: 24-bit field carries the whole or a portion of <dd>The 24-bit field carries the whole or a portion of
the Function part of the SRv6 SID when the Transposition Scheme the Function part of the SRv6 SID when the Transposition Scheme
of encoding (<xref target="SIDENCODE"/>) is used and otherwise of encoding (<xref target="SIDENCODE" format="default"/>) is used;
set to Implicit NULL value. In either case, the value is set in otherwise, it is set to Implicit NULL in the higher-order 20 bits
the high order 20 bits (e.g., as 0x000030 in the case of (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using
Implicit NULL). When using the Transposition Scheme, the the Transposition Scheme, the
Transposition Length MUST be less than or equal to 24 and less Transposition Length <bcp14>MUST</bcp14> be less than or equal to
than or equal to the Function Length.</t> 24 and less
</list></t> than or equal to the FL.</dd>
</dl>
<t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the A-D route. The Prefix-SID attribute is advertised along with the A-D route. The
SRv6 Endpoint behavior SHOULD be one of these: End.DX2, End.DX2V, SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX2, End.DX2V, or
End.DT2U.</t> End.DT2U.</t>
</section> </section>
</section> </section>
<section anchor="RT2" numbered="true" toc="default">
<section anchor="RT2" title="MAC/IP Advertisement Route over SRv6 Core"> <name>MAC/IP Advertisement Route over SRv6 Core</name>
<t>EVPN Route Type 2 is used to advertise unicast traffic MAC+IP <t>EVPN Route Type 2 is used to advertise unicast traffic Media Access C
address reachability through MP-BGP to all other PEs in a given EVPN ontrol (MAC)
+ IP address reachability through MP-BGP to all other PEs in a given EVPN
instance.</t> instance.</t>
<t>As a reminder, EVPN Route Type 2 is encoded as follows:</t> <t>As a reminder, EVPN Route Type 2 is encoded as follows:</t>
<figure anchor="EVPNRT2">
<figure anchor="EVPNRT2" title="EVPN Route Type 2"> <name>EVPN Route Type 2</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| MAC Address Length (1 octet) | | MAC Address Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| MAC Address (6 octets) | | MAC Address (6 octets) |
+---------------------------------------+ +-----------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| IP Address (0, 4, or 16 octets) | | IP Address (0, 4, or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label1 (3 octets) | | MPLS Label1 (3 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label2 (0 or 3 octets) | | MPLS Label2 (0 or 3 octets) |
+---------------------------------------+ +-----------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>NLRI encoding over SRv6 core is similar to what is described in <xref
<t>NLRI encoding over SRv6 core is similar to <xref target="RFC7432"/> target="RFC7432"
with the following changes:</t> format="default"/> with the following changes:</t>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>MPLS Label1:</dt>
<t>MPLS Label1: Is associated with the SRv6 L2 Service TLV. This <dd>This is associated with the SRv6 L2 Service TLV. This
24-bit field carries the whole or a portion of the Function part 24-bit field carries the whole or a portion of the Function part
of the SRv6 SID when the Transposition Scheme of encoding (<xref of the SRv6 SID when the Transposition Scheme of encoding (<xref tar
target="SIDENCODE"/>) is used and otherwise set to Implicit NULL get="SIDENCODE" format="default"/>) is used; otherwise, it is set to Implicit NU
value. In either case, the value is set in the high order 20 bits LL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is
(e.g., as 0x000030 in the case of Implicit NULL). When using the set in the 24 bits. When using the
Transposition Scheme, the Transposition Length MUST be less than Transposition Scheme, the Transposition Length <bcp14>MUST</bcp14> b
or equal to 24 and less than or equal to the Function Length.</t> e less than
or equal to 24 and less than or equal to the FL.</dd>
<t>MPLS Label2: Is associated with the SRv6 L3 Service TLV. This <dt>MPLS Label2:</dt>
<dd>This is associated with the SRv6 L3 Service TLV. This
24-bit field carries the whole or a portion of the Function part 24-bit field carries the whole or a portion of the Function part
of the SRv6 SID when the Transposition Scheme of encoding (<xref of the SRv6 SID when the Transposition Scheme of encoding (<xref tar
target="SIDENCODE"/>) is used and otherwise set to Implicit NULL get="SIDENCODE" format="default"/>) is used; otherwise, it is set to Implicit NU
value. In either case, the value is set in the high order 20 bits LL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value is
(e.g., as 0x000030 in the case of Implicit NULL). When using the set in the 24 bits. When using the
Transposition Scheme, the Transposition Length MUST be less than Transposition Scheme, the Transposition Length <bcp14>MUST</bcp14> b
or equal to 24 and less than or equal to the Function Length.</t> e less than
</list></t> or equal to 24 and less than or equal to the FL.</dd>
</dl>
<t>Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6 <t>Service SIDs enclosed in the SRv6 L2 Service TLV and optionally in th
L3 Service TLV within the BGP Prefix-SID attribute is advertised along e SRv6
L3 Service TLV within the BGP Prefix-SID attribute are advertised along
with the MAC/IP Advertisement route.</t> with the MAC/IP Advertisement route.</t>
<t>Described below are different types of Route Type 2 <t>Described below are different types of Route Type 2
advertisements.</t> advertisements.</t>
<section numbered="true" toc="default">
<section title="MAC/IP Advertisement Route with MAC Only"> <name>MAC/IP Advertisement Route with MAC Only</name>
<t><list style="symbols"> <dl newline="true" spacing="normal">
<t>MPLS Label1: Is associated with the SRv6 L2 Service TLV. This <dt>MPLS Label1:</dt>
<dd>This is associated with the SRv6 L2 Service TLV. This
24-bit field carries the whole or a portion of the Function part 24-bit field carries the whole or a portion of the Function part
of the SRv6 SID when the Transposition Scheme of encoding (<xref of the SRv6 SID when the Transposition Scheme of encoding (<xref t
target="SIDENCODE"/>) is used and otherwise set to Implicit NULL arget="SIDENCODE" format="default"/>) is used; otherwise, it is set to Implicit
value. In either case, the value is set in the high order 20 NULL in the higher-order 20 bits (i.e., as 0x000030). In either case, the value
bits (e.g., as 0x000030 in the case of Implicit NULL). When is set in the 24 bits. When
using the Transposition Scheme, the Transposition Length MUST be using the Transposition Scheme, the Transposition Length <bcp14>MU
less than or equal to 24 and less than or equal to the Function ST</bcp14> be
Length.</t> less than or equal to 24 and less than or equal to the FL.</dd>
</list></t> </dl>
<t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP <t>A Service SID enclosed in an SRv6 L2 Service TLV within the BGP
Prefix-SID attribute is advertised along with the route. The SRv6 Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be one of these: End.DX2, End.DT2U.</t> Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DX2 or En d.DT2U.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="MAC/IP Advertisement Route with MAC+IP"> <name>MAC/IP Advertisement Route with MAC+IP</name>
<t><list style="symbols"> <dl newline="true" spacing="normal">
<t>MPLS Label1: Is associated with the SRv6 L2 Service TLV. This <dt>MPLS Label1:</dt>
<dd>This is associated with the SRv6 L2 Service TLV. This
24-bit field carries the whole or a portion of the Function part 24-bit field carries the whole or a portion of the Function part
of the SRv6 SID when the Transposition Scheme of encoding (<xref of the SRv6 SID when the Transposition Scheme of encoding (<xref
target="SIDENCODE"/>) is used and otherwise set to Implicit NULL target="SIDENCODE" format="default"/>) is used; otherwise, it is se
value. In either case, the value is set in the high order 20 t to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either ca
bits (e.g., as 0x000030 in the case of Implicit NULL). When se, the value is set in the 24 bits. When
using the Transposition Scheme, the Transposition Length MUST be using the Transposition Scheme, the Transposition Length <bcp14>MU
less than or equal to 24 and less than or equal to the Function ST</bcp14> be
Length.</t> less than or equal to 24 and less than or equal to the FL.</dd>
<dt>MPLS Label2:</dt>
<t>MPLS Label2: Is associated with the SRv6 L3 Service TLV. This <dd>This is associated with the SRv6 L3 Service TLV. This
24-bit field carries the whole or a portion of the Function part 24-bit field carries the whole or a portion of the Function part
of the SRv6 SID when the Transposition Scheme of encoding (<xref of the SRv6 SID when the Transposition Scheme of encoding (<xref
target="SIDENCODE"/>) is used and otherwise set to Implicit NULL target="SIDENCODE" format="default"/>) is used; otherwise, it is se
value. In either case, the value is set in the high order 20 t to Implicit NULL in the higher-order 20 bits (i.e., as 0x000030). In either ca
bits (e.g., as 0x000030 in the case of Implicit NULL). When se, the value is set in the 24 bits. When
using the Transposition Scheme, the Transposition Length MUST be using the Transposition Scheme, the Transposition Length <bcp14>MU
less than or equal to 24 and less than or equal to the Function ST</bcp14> be
Length.</t> less than or equal to 24 and less than or equal to the FL.</dd>
</list></t> </dl>
<t>An L2 Service SID enclosed in an SRv6 L2 Service TLV within the <t>An L2 Service SID enclosed in an SRv6 L2 Service TLV within the
BGP Prefix-SID attribute is advertised along with the route. In BGP Prefix-SID attribute is advertised along with the route. In
addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV addition, an L3 Service SID enclosed in an SRv6 L3 Service TLV
within the BGP Prefix-SID attribute MAY also be advertised along within the BGP Prefix-SID attribute <bcp14>MAY</bcp14> also be adverti
with the route. The SRv6 Endpoint behavior SHOULD be one of these: sed along
for the L2 Service SID - End.DX2, End.DT2U; for the L3 Service SID - with the route. The SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be on
End.DT46, End.DT4, End.DT6, End.DX4, End.DX6.</t> e of these:
for the L2 Service SID, End.DX2 or End.DT2U and for the L3 Service SID
,
End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6.</t>
</section> </section>
</section> </section>
<section anchor="RT3" numbered="true" toc="default">
<section anchor="RT3" <name>Inclusive Multicast Ethernet Tag Route over SRv6 Core</name>
title="Inclusive Multicast Ethernet Tag Route over SRv6 Core">
<t>EVPN Route Type 3 is used to advertise multicast traffic <t>EVPN Route Type 3 is used to advertise multicast traffic
reachability information through MP-BGP to all other PEs in a given reachability information through MP-BGP to all other PEs in a given
EVPN instance.</t> EVPN instance.</t>
<t>As a reminder, EVPN Route Type 3 is encoded as follows:</t> <t>As a reminder, EVPN Route Type 3 is encoded as follows:</t>
<figure anchor="EVPNRT3">
<t><figure anchor="EVPNRT3" title="EVPN Route Type 3"> <name>EVPN Route Type 3</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
skipping to change at line 971 skipping to change at line 835
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>NLRI encoding over SRv6 core is similar to what is described in <xref
<t>NLRI encoding over SRv6 core is similar to <xref target="RFC7432" format="default"/>.</t>
target="RFC7432"/>.</t> <t>The P-Multicast Service Interface (PMSI) Tunnel Attribute <xref targe
t="RFC6514" format="default"/> is used to identify
<t>PMSI Tunnel Attribute <xref target="RFC6514"/> is used to identify the Provider tunnel (P-tunnel) used for sending Broadcast, Unknown Unica
the P-tunnel used for sending broadcast, unknown unicast, or multicast st, or Multicast
(BUM) traffic. The format of PMSI Tunnel Attribute is encoded as (BUM) traffic. The format of the PMSI Tunnel Attribute is encoded as
follows over SRv6 Core: <figure anchor="PMSITA" follows over SRv6 core: </t>
title="PMSI Tunnel Attribute"> <figure anchor="PMSITA">
<artwork><![CDATA[ +---------------------------------- <name>PMSI Tunnel Attribute</name>
-----+ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+
| Flag (1 octet) | | Flag (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Type (1 octet) | | Tunnel Type (1 octet) |
+---------------------------------------+ +---------------------------------------+
| MPLS label (3 octet) | | MPLS label (3 octets) |
+---------------------------------------+ +---------------------------------------+
| Tunnel Identifier (variable) | | Tunnel Identifier (variable) |
+---------------------------------------+ +---------------------------------------+
]]></artwork> ]]></artwork>
</figure><list style="symbols"> </figure>
<t>Flag: zero value defined per <xref target="RFC7432"/></t> <dl newline="true" spacing="normal">
<dt>Flag:</dt>
<t>Tunnel Type: defined per <xref target="RFC6514"/></t> <dd>This field has a value of 0, as defined per <xref target="RFC7432"
format="default"/>.</dd>
<t>MPLS label: This 24-bit field carries the whole or a portion of <dt>Tunnel Type:</dt>
<dd>This field is defined per <xref target="RFC6514" format="default"/>
.</dd>
<dt>MPLS label:</dt>
<dd>This 24-bit field carries the whole or a portion of
the Function part of the SRv6 SID when ingress replication is used the Function part of the SRv6 SID when ingress replication is used
and the Transposition Scheme of encoding (<xref and the Transposition Scheme of encoding (<xref target="SIDENCODE"
target="SIDENCODE"/>) is used and otherwise, it is set as defined format="default"/>) is used; otherwise, it is set as defined
in <xref target="RFC6514"/>. When using the Transposition Scheme, in <xref target="RFC6514" format="default"/>. When using the Transpo
the Transposition Length MUST be less than or equal to 24 and less sition Scheme,
than or equal to the Function Length.</t> the Transposition Length <bcp14>MUST</bcp14> be less than or equal t
o 24 and less
<t>Tunnel Identifier: IP address of egress PE</t> than or equal to the FL.</dd>
</list>A Service SID enclosed in an SRv6 L2 Service TLV within the <dt>Tunnel Identifier:</dt>
<dd>This field is the IP address of egress PE.</dd>
</dl>
<t>A Service SID enclosed in an SRv6 L2 Service TLV within the
BGP Prefix-SID attribute is advertised along with the route. The SRv6 BGP Prefix-SID attribute is advertised along with the route. The SRv6
Endpoint behavior SHOULD be End.DT2M.<list style="symbols"> Endpoint Behavior <bcp14>SHOULD</bcp14> be End.DT2M.</t>
<t>When ESI-based filtering is used for Multi-Homing or E-Tree <ul spacing="normal">
<li>When ESI-based filtering is used for multihoming or Ethernet Tree
(E-Tree)
procedures, the ESI Filtering Argument (the Arg.FE2 notation procedures, the ESI Filtering Argument (the Arg.FE2 notation
introduced in <xref target="RFC8986"/>) of the Service SID carried introduced in <xref target="RFC8986" format="default"/>) of the Serv
along with EVPN Route Type 1 route SHOULD be merged with the ice SID carried
applicable End.DT2M SID of Type 3 route advertised by remote PE by along with EVPN Route Type 1 <bcp14>SHOULD</bcp14> be merged with th
doing a bit-wise logical-OR operation to create a single SID on e
the ingress PE. Details of split-horizon ESI-based filtering applicable End.DT2M SID of Route Type 3 advertised by the remote PE
mechanisms for multihoming are described in <xref by
target="RFC7432"/>. Details of filtering mechanisms for doing a bitwise logical-OR operation to create a single SID on
the ingress PE. Details of split-horizon, ESI-based filtering
mechanisms for multihoming are described in <xref target="RFC7432" f
ormat="default"/>. Details of filtering mechanisms for
Leaf-originated BUM traffic in EVPN E-Tree services are provided Leaf-originated BUM traffic in EVPN E-Tree services are provided
in <xref target="RFC8317"/>.</t> in <xref target="RFC8317" format="default"/>.</li>
<li>When "local-bias" is used as the multihoming
<t>When &ldquo;local-bias&rdquo; is used as the Multi-Homing split-horizon method, the ESI Filtering Argument <bcp14>SHOULD NOT</
split-horizon method, the ESI Filtering Argument SHOULD NOT be bcp14> be
merged with the corresponding End.DT2M SID on the ingress PE. merged with the corresponding End.DT2M SID on the ingress PE.
Details of the &ldquo;local-bias&rdquo; procedures are described Details of the local-bias procedures are described
in <xref target="RFC8365"/>.</t> in <xref target="RFC8365" format="default"/>.</li>
</list></t> </ul>
<t>Usage of multicast trees as P-tunnels is outside the scope of this <t>Usage of multicast trees as P-tunnels is outside the scope of this
document.</t> document.</t>
</section> </section>
<section anchor="RT4" numbered="true" toc="default">
<section anchor="RT4" title="Ethernet Segment Route over SRv6 Core"> <name>Ethernet Segment Route over SRv6 Core</name>
<t>As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4) <t>As a reminder, an Ethernet Segment route (i.e., EVPN Route Type 4)
is encoded as follows: <figure anchor="EVPNRT4" is encoded as follows: </t>
title="EVPN Route Type 4"> <figure anchor="EVPNRT4">
<artwork><![CDATA[ <name>EVPN Route Type 4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
skipping to change at line 1049 skipping to change at line 914
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Address | | Originating Router's IP Address |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>NLRI encoding over SRv6 core is similar to what is described in <xref
<t>NLRI encoding over SRv6 core is similar to <xref target="RFC7432" format="default"/>.</t>
target="RFC7432"/>.</t>
<t>SRv6 Service TLVs within the BGP Prefix-SID attribute are not <t>SRv6 Service TLVs within the BGP Prefix-SID attribute are not
advertised along with this route. The processing of the route has not advertised along with this route. The processing of the route has not
changed - it remains as described in <xref target="RFC7432"/>.</t> changed -- it remains as described in <xref target="RFC7432" format="def ault"/>.</t>
</section> </section>
<section anchor="RT5" numbered="true" toc="default">
<section anchor="RT5" title="IP Prefix Route over SRv6 Core"> <name>IP Prefix Route over SRv6 Core</name>
<t>EVPN Route Type 5 is used to advertise IP address reachability <t>EVPN Route Type 5 is used to advertise IP address reachability
through MP-BGP to all other PEs in a given EVPN instance. The IP through MP-BGP to all other PEs in a given EVPN instance. The IP
address may include a host IP prefix or any specific subnet.</t> address may include a host IP prefix or any specific subnet.</t>
<t>As a reminder, EVPN Route Type 5 is encoded as follows: </t>
<t>As a reminder, EVPN Route Type 5 is encoded as follows: <figure <figure anchor="EVPNRT5">
anchor="EVPNRT5" title="EVPN Route Type 5"> <name>EVPN Route Type 5</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------+ +-----------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +-----------------------------------------+
|Ethernet Segment Identifier (10 octets)| | Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +-----------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +-----------------------------------------+
| IP Prefix Length (1 octet) | | IP Prefix Length (1 octet) |
+---------------------------------------+ +-----------------------------------------+
| IP Prefix (4 or 16 octets) | | IP Prefix (4 or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| GW IP Address (4 or 16 octets) | | GW IP Address (4 or 16 octets) |
+---------------------------------------+ +-----------------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +-----------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>NLRI encoding over SRv6 core is similar to what is described in <xref
<t>NLRI encoding over SRv6 core is similar to <xref target="RFC9136"/> target="RFC9136" format="default"/>
with the following change:</t> with the following change:</t>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>MPLS Label:</dt>
<t>MPLS Label: This 24-bit field carries the whole or a portion of <dd>This 24-bit field carries the whole or a portion of
the Function part of the SRv6 SID when the Transposition Scheme of the Function part of the SRv6 SID when the Transposition Scheme of
encoding (<xref target="SIDENCODE"/>) is used and otherwise set to encoding (<xref target="SIDENCODE" format="default"/>) is used;
Implicit NULL value. In either case, the value is set in the high otherwise, it is set to Implicit NULL in the higher-order 20 bits (i.
order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). e., as 0x000030). In either case, the value is set in the 24 bits.
When using the Transposition Scheme, the Transposition Length MUST When using the Transposition Scheme, the Transposition Length <bcp14
be less than or equal to 24 and less than or equal to the Function >MUST</bcp14>
Length.</t> be less than or equal to 24 and less than or equal to the FL.</dd>
</list></t> </dl>
<t>The SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. T
<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The he
SRv6 Endpoint behavior SHOULD be one of these: End.DT4, End.DT6, SRv6 Endpoint Behavior <bcp14>SHOULD</bcp14> be one of these: End.DT4, E
End.DT46, End.DX4, End.DX6.</t> nd.DT6,
End.DT46, End.DX4, or End.DX6.</t>
</section> </section>
<section anchor="RT678" numbered="true" toc="default">
<section anchor="RT678" <name>EVPN Multicast Routes (Route Types 6, 7, and 8) over SRv6 Core</na
title="EVPN Multicast Routes (Route Types 6, 7, 8) over SRv6 Core me>
">
<t>These routes do not require the advertisement of SRv6 Service TLVs <t>These routes do not require the advertisement of SRv6 Service TLVs
along with them. Similar to EVPN Route Type 4, the BGP Nexthop is along with them. Similar to EVPN Route Type 4, the BGP next hop is
equal to the IPv6 address of egress PE.</t> equal to the IPv6 address of egress PE.</t>
</section> </section>
</section> </section>
<section anchor="ERROR" numbered="true" toc="default">
<section anchor="IMPL" title="Implementation Status"> <name>Error Handling</name>
<t>[Note to RFC Editor: This section needs to be removed before
publication as RFC.]</t>
<t>The <xref target="I-D.matsushima-spring-srv6-deployment-status"/>
describes the current deployment and implementation status of SRv6 which
also includes the BGP services over SRv6 as specified in this
document.</t>
</section>
<section anchor="ERROR" title="Error Handling">
<t>In case of any errors encountered while processing SRv6 Service TLVs, <t>In case of any errors encountered while processing SRv6 Service TLVs,
the details of the error SHOULD be logged for further analysis.</t> the details of the error <bcp14>SHOULD</bcp14> be logged for further analy
sis.</t>
<t>If multiple instances of SRv6 L3 Service TLV are encountered, all but <t>If multiple instances of the SRv6 L3 Service TLV are encountered, all b
the first instance MUST be ignored.</t> ut
the first instance <bcp14>MUST</bcp14> be ignored.</t>
<t>If multiple instances of SRv6 L2 Service TLV are encountered, all but <t>If multiple instances of the SRv6 L2 Service TLV are encountered, all b
the first instance MUST be ignored.</t> ut
the first instance <bcp14>MUST</bcp14> be ignored.</t>
<t>An SRv6 Service TLV is considered malformed in the following cases: <t>An SRv6 Service TLV is considered malformed in the following cases:</t>
<list style="symbols"> <ul spacing="normal">
<t>the TLV Length is less than 1</t> <li>The TLV Length is less than 1.</li>
<li>The TLV Length is inconsistent with the length of the BGP Prefix-SID
<t>the TLV Length is inconsistent with the length of BGP Prefix-SID attribute.</li>
attribute</t> <li>At least one of the constituent Sub-TLVs is malformed.</li>
</ul>
<t>at least one of the constituent Sub-TLVs is malformed</t>
</list></t>
<t>An SRv6 Service Sub-TLV is considered malformed in the following <t>An SRv6 Service Sub-TLV is considered malformed in the following
cases: <list style="symbols"> case:</t>
<t>the Sub-TLV Length is inconsistent with the length of the <ul spacing="normal">
enclosing SRv6 Service TLV</t> <li>The Sub-TLV Length is inconsistent with the length of the
</list></t> enclosing SRv6 Service TLV.</li>
</ul>
<t>An SRv6 SID Information Sub-TLV is considered malformed in the <t>An SRv6 SID Information Sub-TLV is considered malformed in the
following cases:<list>
<t><list style="symbols">
<t>the Sub-TLV Length is less than 21</t>
<t>the Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 Service TLV</t>
<t>at least one of the constituent Sub-Sub-TLVs is malformed</t>
</list></t>
</list></t>
<t>An SRv6 Service Data Sub-Sub-TLV is considered malformed in the
following cases:</t> following cases:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The Sub-TLV Length is less than 21.</li>
<t>the Sub-Sub-TLV Length is inconsistent with the length of the <li>The Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 service Sub-TLV</t> enclosing SRv6 Service TLV.</li>
</list></t> <li>At least one of the constituent Sub-Sub-TLVs is malformed.</li>
</ul>
<t>Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because <t>An SRv6 Service Data Sub-Sub-TLV is considered malformed in the
following case:</t>
<ul spacing="normal">
<li>The Sub-Sub-TLV Length is inconsistent with the length of the
enclosing SRv6 service Sub-TLV.</li>
</ul>
<t>Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
its Type is unrecognized.</t> its Type is unrecognized.</t>
<t>Any TLV, Sub-TLV, or Sub-Sub-TLV is not considered malformed because
<t>Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because
of failing any semantic validation of its Value field.</t> of failing any semantic validation of its Value field.</t>
<t>The SRv6 overlay service requires the Service SID for forwarding. The
<t>SRv6 overlay service requires Service SID for forwarding. The treat-as-withdraw action <xref target="RFC7606" format="default"/> <bcp14>
treat-as-withdraw action <xref target="RFC7606"/> MUST be performed when MUST</bcp14> be performed when
at least one malformed SRV6 Service TLV is present in the BGP Prefix-SID at least one malformed SRv6 Service TLV is present in the BGP Prefix-SID
attribute.</t> attribute.</t>
<t>The SRv6 SID value in the SRv6 SID Information Sub-TLV is invalid when
<t>SRv6 SID value in SRv6 SID Information Sub-TLV is invalid when SID the SID
Structure Sub-Sub-TLV transposition length is greater than the number of Structure Sub-Sub-TLV transposition length is greater than the number of
bits of the label field or if any of the conditions for the fields of bits of the label field or if any of the conditions for the fields of
the sub-sub-TLV as specified in <xref target="SRv6-SID-STRUCTURE"/> is the Sub-Sub-TLV, as specified in <xref target="SRv6-SID-STRUCTURE" format=
not met. The transposition offset and length MUST be 0 when the "default"/>, is
Sub-Sub-TLV is advertised along with routes where transposition scheme not met. The transposition offset and length <bcp14>MUST</bcp14> be 0 when
is not applicable (e.g., for Global IPv6 Service <xref the
target="RFC2545"/> where there is no label field). The path having such Sub-Sub-TLV is advertised along with routes where the Transposition Scheme
Prefix-SID Attribute without any valid SRv6 SID information MUST be is not applicable (e.g., for global IPv6 service <xref target="RFC2545" fo
rmat="default"/> where there is no label field). The path having any such
Prefix-SID attribute without any valid SRv6 SID information <bcp14>MUST</b
cp14> be
considered ineligible during the selection of the best path for the considered ineligible during the selection of the best path for the
corresponding prefix.</t> corresponding prefix.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="BGP Prefix-SID TLV Types Registry"> <section numbered="true" toc="default">
<name>BGP Prefix-SID TLV Types Registry</name>
<t>This document introduces two new TLV Types of the BGP Prefix-SID <t>This document introduces two new TLV Types of the BGP Prefix-SID
attribute. IANA has assigned Type values in the registry "BGP attribute. IANA has assigned Type values in the "BGP
Prefix-SID TLV Types" as follows: <figure anchor="IANAPFXSIDTYPES" Prefix-SID TLV Types" subregistry as follows: </t>
title="BGP Prefix-SID TLV Types"> <table anchor="IANAPFXSIDTYPES" align="center">
<artwork><![CDATA[ Value Type Reference <name>BGP Prefix-SID TLV Types Subregistry</name>
-------------------------------------------- <thead>
4 Deprecated <this document> <tr>
5 SRv6 L3 Service TLV <this document> <th>Value</th>
6 SRv6 L2 Service TLV <this document>]]></artwork> <th>Type</th>
</figure></t> <th>Reference</th>
</tr>
<t>The value 4 previously corresponded to the SRv6-VPN SID TLV, which </thead>
was specified in previous versions of this document and used by early <tbody>
<tr>
<td>4</td>
<td>Deprecated</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>5</td>
<td>SRv6 L3 Service TLV</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>6</td>
<td>SRv6 L2 Service TLV</td>
<td>RFC 9252</td>
</tr>
</tbody>
</table>
<t>Value 4 previously corresponded to the SRv6-VPN SID TLV, which
was specified in earlier draft versions of this document and used by ear
ly
implementations of this specification. It was deprecated and replaced implementations of this specification. It was deprecated and replaced
by the SRv6 L3 Service and SRv6 L2 Service TLVs.</t> by the SRv6 L3 Service and SRv6 L2 Service TLVs.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6 Service Sub-TLV Types Registry"> <name>SRv6 Service Sub-TLV Types Registry</name>
<t>IANA is requested to create and maintain a new registry called <t>IANA has created and now maintains a new subregistry called
"SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP) "SRv6 Service Sub-TLV Types" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy for this registry is: Parameters" registry. The registration procedures, per <xref target="RFC
<figure anchor="IANASRV6SVCTYPESAP" 8126"/>, for this subregistry are according to <xref target="IANASRV6SVCTYPESAP"
title="SRv6 Service Sub-TLV Types Allocation Policy"> />.
<artwork><![CDATA[ 0 : Reserved </t>
1-127 : IETF Review <table anchor="IANASRV6SVCTYPESAP" align="center">
128-254 : First Come First Served <name>SRv6 Service Sub-TLV Types Subregistry Registration Procedures</
255 : Reserved]]></artwork> name>
</figure></t> <thead>
<tr>
<t>The following Sub-TLV Type is defined in this document: <figure <th>Range</th>
anchor="IANASRV6DATATYPES" title="SRv6 Service Sub-TLV Types"> <th>Registration Procedures</th>
<artwork><![CDATA[ Value Type Refer </tr>
ence </thead>
---------------------------------------------------- <tbody>
1 SRv6 SID Information Sub-TLV <this document>]]></artwork> <tr>
</figure></t> <td>1-127</td>
<td>IETF Review</td>
</tr>
<tr>
<td>128-254</td>
<td>First Come First Served</td>
</tr>
<tr>
<td>255</td>
<td>IETF Review</td>
</tr>
</tbody>
</table>
<t>IANA has populated this subregistry as follows. Note that the SRv6 SI
D Information Sub-TLV
is defined in this document: </t>
<table anchor="IANASRV6DATATYPES" align="center">
<name>SRv6 Service Sub-TLV Types Subregistry Initial Contents</name>
<thead>
<tr>
<th>Value</th>
<th>Type</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>1</td>
<td>SRv6 SID Information Sub-TLV</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td>RFC 9252</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6 Service Data Sub-Sub-TLV Types Registry"> <name>SRv6 Service Data Sub-Sub-TLV Types Registry</name>
<t>IANA is requested to create and maintain a new registry called <t>IANA has created and now maintains a new subregistry called
"SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway "SRv6 Service Data Sub-Sub-TLV Types" under the "Border Gateway
Protocol (BGP) Parameters" registry. The allocation policy for this Protocol (BGP) Parameters" registry. The registration procedures for thi
registry is: <figure anchor="IANASRV6DATASSTYPESAP" s
title="SRv6 Service Data Sub-Sub-TLV Types Allocation Policy"> subregistry are according to <xref target="IANASRV6DATASSTYPESAP"/>. </t
<artwork><![CDATA[ 0 : Reserved >
1-127 : IETF Review <table anchor="IANASRV6DATASSTYPESAP" align="center">
128-254 : First Come First Served <name>SRv6 Service Data Sub-Sub-TLV Types Subregistry Registration Pro
255 : Reserved]]></artwork> cedures</name>
</figure></t> <thead>
<tr>
<t>The following Sub-Sub-TLV Type is defined in this document: <figure <th>Range</th>
anchor="IANASRV6DATASSTYPES" <th>Registration Procedure</th>
title="SRv6 Service Data Sub-Sub-TLV Types"> </tr>
<artwork><![CDATA[ Value Type Ref </thead>
erence <tbody>
---------------------------------------------------- <tr>
1 SRv6 SID Structure Sub-Sub-TLV <this document>]]></artwork> <td>1-127</td>
</figure></t> <td>IETF Review</td>
</tr>
<tr>
<td>128-254</td>
<td>First Come First Served</td>
</tr>
<tr>
<td>255</td>
<td>IETF Review</td>
</tr>
</tbody>
</table>
<t>The following Sub-Sub-TLV Type is defined in this document: </t>
<table anchor="IANASRV6DATASSTYPES" align="center">
<name>SRv6 Service Data Sub-Sub-TLV Types Subregistry Initial Contents
</name>
<thead>
<tr>
<th>Value</th>
<th>Type</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>1</td>
<td>SRv6 SID Structure Sub-Sub-TLV</td>
<td>RFC 9252</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td>RFC 9252</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="BGP SRv6 Service SID Flags Registry"> <name>BGP SRv6 Service SID Flags Registry</name>
<t>IANA is requested to create and maintain a new registry called "BGP <t>IANA has created and now maintains a new subregistry called "BGP
SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP) SRv6 Service SID Flags" under the "Border Gateway Protocol (BGP)
Parameters" registry. The allocation policy for this registry is IETF Parameters" registry. The registration procedure for this subregistry is
Review and all 8 bit positions of the flags are currently IETF
Review, and all 8-bit positions of the flags are currently
unassigned.</t> unassigned.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Subsequent Address Family Identifiers (SAFI) Parameters Re <name>SAFI Values Registry</name>
gistry"> <t>IANA has added this document as a reference for value 128
<t>IANA is requested to add this document as a reference for value 128 ("MPLS-labeled VPN address") in the "SAFI Values" subregistry
in the "Subsequent Address Family Identifiers (SAFI) Parameters" under the "Subsequent Address Family Identifiers
registry.</t> (SAFI) Parameters" registry.</t>
</section> </section>
</section> </section>
<section anchor="SEC" numbered="true" toc="default">
<section anchor="SEC" title="Security Considerations"> <name>Security Considerations</name>
<t>This document specifies extensions to the BGP protocol for signaling <t>This document specifies extensions to the BGP protocol for the signalin
g
of services for SRv6. These specifications leverage existing BGP of services for SRv6. These specifications leverage existing BGP
protocol mechanisms for the signaling of various types of services. It protocol mechanisms for the signaling of various types of services. It
also builds upon existing elements of the SR architecture (more also builds upon existing elements of the SR architecture (more
specifically SRv6). As such, this section largely provides pointers (as specifically, SRv6). As such, this section largely provides pointers (as
a reminder) to the security considerations of those existing a reminder) to the security considerations of those existing
specifications while also covering certain newer security aspects for specifications while also covering certain, newer security aspects for
the specifications newly introduced by this document.</t> the specifications newly introduced by this document.</t>
<section anchor="SECSESS" numbered="true" toc="default">
<section anchor="SECSESS" title="BGP Session Related Considerations"> <name>Considerations Related to BGP Sessions</name>
<t>Techniques related to authentication of BGP sessions for securing <t>Techniques related to authentication of BGP sessions for securing
messages between BGP peers as discussed in the BGP specification <xref messages between BGP peers, as discussed in the BGP specification <xref
target="RFC4271"/> and, in the security analysis for BGP <xref target="RFC4271" format="default"/> and in the security analysis for BGP <xref t
target="RFC4272"/> apply. The discussion of the use of the TCP arget="RFC4272" format="default"/>, apply. The discussion of the use of the TCP
Authentication option to protect BGP sessions is found in <xref Authentication Option to protect BGP sessions is found in <xref target="
target="RFC5925"/>, while <xref target="RFC6952"/> includes an RFC5925" format="default"/>, while <xref target="RFC6952" format="default"/> inc
ludes an
analysis of BGP keying and authentication issues. This document does analysis of BGP keying and authentication issues. This document does
not introduce any additional BGP session security considerations.</t> not introduce any additional BGP session security considerations.</t>
</section> </section>
<section anchor="SECSVC" numbered="true" toc="default">
<section anchor="SECSVC" title="BGP Services Related Considerations"> <name>Considerations Related to BGP Services</name>
<t>This document does not introduce new services or BGP NLRI types but <t>This document does not introduce new services or BGP NLRI types but
extends the signaling of existing ones for SRv6. Therefore, the extends the signaling of existing ones for SRv6. Therefore, the
security considerations for the respective BGP services <xref security considerations for the respective BGP services, such as <xref t
target="RFC8950">BGP IPv4 over IPv6 NH</xref>, <xref arget="RFC8950" format="default">BGP IPv4 over IPv6 NH</xref>, <xref target="RFC
target="RFC4659">BGP IPv6 L3VPN</xref>, <xref target="RFC2545">BGP 4659" format="default">BGP IPv6 L3VPN</xref>, <xref target="RFC2545" format="def
IPv6</xref>, <xref target="RFC7432">BGP EVPN</xref> and <xref ault">BGP
target="RFC9136">IP EVPN</xref> apply as discussed in their respective IPv6</xref>, <xref target="RFC7432" format="default">BGP EVPN</xref>, an
documents. <xref target="RFC8669"/> discusses mechanisms to prevent d <xref target="RFC9136" format="default">IP EVPN</xref>, apply as discussed in
leaking of BGP Prefix-SID attribute, that carries SR information, their respective
documents.
<xref target="RFC8669" format="default"/> discusses mechanisms to prevent
the leaking of the BGP Prefix-SID attribute, which carries SR informatio
n,
outside the SR domain.</t> outside the SR domain.</t>
<t>As a reminder, several of the BGP services (i.e., the AFI/SAFI used <t>As a reminder, several of the BGP services (i.e., the AFI/SAFI used
for their signaling) were initially introduced for one encapsulation for their signaling) were initially introduced for one encapsulation
mechanism and later extended for others e.g., EVPN MPLS <xref mechanism and later extended for others, e.g., EVPN MPLS <xref target="R
target="RFC7432"/> was extended for VXLAN/NVGRE encapsulation <xref FC7432" format="default"/> was extended for Virtual eXtensible Local Area Networ
target="RFC8365"/>. <xref target="RFC9012"/> enables the use of k (VXLAN) encapsulation and Network Virtualization Using Generic Routing Encapsu
lation (NVGRE) <xref target="RFC8365" format="default"/>. <xref target="RFC9012"
format="default"/> enables the use of
various IP encapsulation mechanisms along with different BGP SAFIs for various IP encapsulation mechanisms along with different BGP SAFIs for
their respective services. The existing filtering mechanisms for their respective services. The existing filtering mechanisms for
preventing the leak of the encapsulation information (carried in BGP preventing the leak of the encapsulation information (carried in BGP
attributes) and to prevent the advertisement of prefixes from the attributes) and preventing the advertisement of prefixes from the
provider's internal address space (especially the SRv6 Block as provider's internal address space (especially the SRv6 Block, as
discussed in <xref target="RFC8986"/>) to external peers (or into the discussed in <xref target="RFC8986" format="default"/>) to external peer
s (or into the
Internet) also apply in the case of SRv6.</t> Internet) also apply in the case of SRv6.</t>
<t>Specific to SRv6, a misconfiguration or error in the BGP
<t>Specific to SRv6, a misconfig or error in the above mentioned BGP filtering mechanisms mentioned above may result in exposing information,
filtering mechanisms may result in exposing information such as SRv6 such as SRv6
Service SIDs to external peers or other unauthorized entities. Service SIDs to external peers or other unauthorized entities.
However, an attempt to exploit this information or to raise an attack However, an attempt to exploit this information or to raise an attack
by injecting packets into the network (e.g. customer networks in case by injecting packets into the network (e.g., customer networks in case
of VPN services) is mitigated by the existing SRv6 data plane security of VPN services) is mitigated by the existing SRv6 data plane security
mechanisms as described in the next section.</t> mechanisms, as described in the next section.</t>
</section> </section>
<section anchor="SECSRV6" numbered="true" toc="default">
<section anchor="SECSRV6" <name>Considerations Related to SR over IPv6 Data Plane</name>
title="SR over IPv6 Data Plane Related Considerations">
<t>This section provides a brief reminder and an overview of the <t>This section provides a brief reminder and an overview of the
security considerations related to SRv6 with pointers to existing security considerations related to SRv6 with pointers to existing
specifications. This document introduces no new security specifications. This document introduces no new security
considerations of its own from the SRv6 data plane perspective.</t> considerations of its own from the SRv6 data plane perspective.</t>
<t>SRv6 operates within a trusted SR domain. The data packets <t>SRv6 operates within a trusted SR domain. The data packets
corresponding to service flows between PE routers are encapsulated corresponding to service flows between PE routers are encapsulated
(using SRv6 SIDs advertised via BGP) and carried within this trusted (using SRv6 SIDs advertised via BGP) and carried within this trusted
SR domain (e.g., within a single AS or between multiple ASes within a SR domain (e.g., within a single AS or between multiple ASes within a
single provider network).</t> single provider network).</t>
<t>The security considerations of the SR architecture are
covered by <xref target="RFC8402" format="default"/>. More detailed secu
rity
considerations, specifically of SRv6 and SRH, are covered by <xref targe
t="RFC8754" format="default"/> as they relate to SR Attacks (Section <xref targe
t="RFC8754" section="7.1" sectionFormat="bare"/>), Service
Theft (Section <xref target="RFC8754" section="7.2" sectionFormat="bare"
/>), and Topology Disclosure (Section <xref target="RFC8754" section="7.3" secti
onFormat="bare"/>).
<t>The security considerations of the Segment Routing architecture are As such, an
covered by <xref target="RFC8402"/>. More detailed security operator deploying SRv6 <bcp14>MUST</bcp14> follow the considerations de
considerations specifically of SRv6 and SRH are covered by <xref scribed in
target="RFC8754"/> as they relate to SR Attacks (section 7.1), Service <xref target="RFC8754" section="7" sectionFormat="of" format="default"/>
Theft (section 7.2) and Topology Disclosure (section 7.3). As such an to implement the infrastructure
operator deploying SRv6 MUST follow the considerations described in Access Control Lists (ACLs) and the recommendations described in <xref t
<xref target="RFC8754"/> section 7 to implement the infrastructure arget="RFC2827" format="default">BCP 38</xref> and <xref target="RFC3704" format
ACLs, <xref target="RFC2827">BCP 38</xref> and <xref ="default">BCP 84</xref>.</t>
target="RFC3704">BCP 84</xref> recommendations.</t> <t>The SRv6 deployment and SID allocation guidelines, as described in
<xref target="RFC8986" format="default"/>, simplify the deployment of th
<t>The SRv6 deployment and SID allocation guidelines as described in e ACL filters
<xref target="RFC8986"/> simplify the deployment of the ACL filters
(e.g., a single ACL corresponding to the SRv6 Block applied to the (e.g., a single ACL corresponding to the SRv6 Block applied to the
external interfaces on border nodes is sufficient to block packets external interfaces on border nodes is sufficient to block packets
destined to any SRv6 SID in the domain from external/unauthorized destined to any SRv6 SID in the domain from external/unauthorized
networks). While there is an assumed trust model within a SR domain networks). While there is an assumed trust model within an SR domain,
such that any node sending packet to an SRv6 SID is assumed to be such that any node sending a packet to an SRv6 SID is assumed to be
allowed to do so, there is also the option of using SRH HMAC TLV <xref allowed to do so, there is also the option of using an SRH Hashed Messag
target="RFC8754"/> as described in <xref target="RFC8986"/> for e Authentication
validation.</t> Code (HMAC) TLV <xref target="RFC8754" format="default"/>, as described i
n <xref
<t>The SRv6 SID Endpoint behaviors implementing the services signalled target="RFC8986" format="default"/>, for validation.</t>
in this document are defined in <xref target="RFC8986"/> and hence the <t> The SRv6 Endpoint Behaviors implementing the services signaled
security considerations of that document apply. These considerations in this document are defined in <xref target="RFC8986" format="default"/>; he
are independent of the protocol used for service deployment, i.e. nce, the security
considerations of that document apply. These considerations
are independent of the protocol used for service deployment, i.e.,
independent of BGP signaling of SRv6 services.</t> independent of BGP signaling of SRv6 services.</t>
<t>These considerations help protect transit traffic as well as <t>These considerations help protect transit traffic as well as
services, such as VPNs, to avoid service theft or injection of traffic services, such as VPNs, to avoid service theft or injection of traffic
into customer VPN.</t> into customer VPNs.</t>
</section> </section>
</section> </section>
<section anchor="ACK" title="Acknowledgments">
<t>The authors of this document would like to thank Stephane Litkowski,
Rishabh Parekh, Xiejingrong, Rajesh M, Mustapha Aissaoui, Alexander
Vainshtein, Eduard Metz, Shraddha Hegde, Eduard Vasilenko, Ron Bonica,
and Joel Halpern for their comments and review of this document. The
authors would also like to thank Matthew Bocci for his document shepherd
review and Martin Vigoureux for his AD review that resulted in helpful
comments for improving this document.</t>
</section>
<section title="Contributors">
<figure>
<artwork><![CDATA[Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Satoru Matsushima
SoftBank
Email: satoru.matsushima@g.softbank.co.jp
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Dirk Steinberg
Steinberg Consulting
Email: dirk@lapishills.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Jonn Leddy
Individual
Email: john@leddy.net
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Swadesh Agrawal
Cisco
Email: swaagraw@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Patrice Brissette
Cisco
Email: pbrisset@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Ali Sajassi
Cisco
Email: sajassi@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Darren Dukes
Cisco
Email: ddukes@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Pablo Camarilo
Cisco
Email: pcamaril@cisco.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Shyam Sethuram
Cisco
Email: shyam.ioml@gmail.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Zafar Ali
Cisco
Email: zali@cisco.com
]]></artwork>
</figure>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-spring-segment-routing-policy" to="SEGMEN
<?rfc include='reference.RFC.8986.xml'?> T-ROUTING-POLICY"/>
<displayreference target="I-D.ietf-lsr-flex-algo" to="IGP-FLEX-ALGO"/>
<?rfc include='reference.RFC.8754.xml'?> <references>
<name>References</name>
<?rfc include='reference.RFC.7432.xml'?> <references>
<name>Normative References</name>
<?rfc include='reference.RFC.8200.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8986.xml"/>
<?rfc include='reference.RFC.7606.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8754.xml"/>
<?rfc include='reference.RFC.6514.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7432.xml"/>
<?rfc include='reference.RFC.4456.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<?rfc include='reference.RFC.2119.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7606.xml"/>
<?rfc include='reference.RFC.8669.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6514.xml"/>
<?rfc include='reference.RFC.8402.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4456.xml"/>
<?rfc include='reference.RFC.9136.xml' ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<?rfc include='reference.I-D.ietf-bess-evpn-igmp-mld-proxy.xml' ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8669.xml"/>
<?rfc include='reference.RFC.8950.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<?rfc include='reference.RFC.8365.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9136.xml"/>
<?rfc include='reference.RFC.8174.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9251.xml"/>
<?rfc include='reference.RFC.2545.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8950.xml"/>
<?rfc include='reference.RFC.4271.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8365.xml"/>
<?rfc include='reference.RFC.4364.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2545.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4659.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8317.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8214.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8277.xml"/>
</references>
<references>
<name>Informative References</name>
<?rfc include='reference.RFC.4659.xml'?> <reference anchor="I-D.ietf-spring-segment-routing-policy">
<front>
<title>Segment Routing Policy Architecture</title>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="D." surname="Voyer" fullname="Daniel Voyer">
<organization>Bell Canada</organization>
</author>
<author initials="A." surname="Bogdanov" fullname="Alex Bogdanov">
<organization>British Telecom</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<date month="March" day="22" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-segment-routing-po
licy-22" />
</reference>
<?rfc include='reference.RFC.4760.xml'?> <reference anchor="I-D.ietf-lsr-flex-algo">
<front>
<title>IGP Flexible Algorithm</title>
<author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor
">
<organization>Cisco Systems</organization>
</author>
<author initials="S" surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks</organization>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
<organization>Arrcus, Inc</organization>
</author>
<author initials="A" surname="Gulko" fullname="Arkadiy Gulko">
<organization>Edward Jones</organization>
</author>
<date month="May" day="18" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-flex-algo-20"/>
</reference>
<?rfc include='reference.RFC.8317.xml'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2827.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3704.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9012.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6513.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml"/>
</references>
</references>
<section anchor="ACK" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors of this document would like to thank <contact fullname="Ste
phane
Litkowski"/>, <contact fullname="Rishabh Parekh"/>, <contact fullname="Xie
jingrong"/>,
<contact fullname="Rajesh M."/>, <contact fullname="Mustapha Aissaoui"/>,
<contact fullname="Alexander Vainshtein"/>, <contact fullname="Eduard Metz
"/>,
<contact fullname="Shraddha Hegde"/>, <contact fullname="Eduard Vasilenko"
/>,
<contact fullname="Ron Bonica"/>, and <contact fullname="Joel Halpern"/>
for their comments and review of this document. The
authors would also like to thank Document Shepherd <contact fullname="Matt
hew Bocci"/> for his review and AD <contact fullname="Martin Vigoureux"/> for hi
s review that
resulted in helpful comments for improving this document.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Clarence Filsfils">
<organization>Cisco</organization>
<address>
<postal/>
<email>cfilsfil@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.8214.xml'?> <contact fullname="Satoru Matsushima">
<organization>SoftBank</organization>
<address>
<postal/>
<email>satoru.matsushima@g.softbank.co.jp</email>
</address>
</contact>
<?rfc include='reference.RFC.8277.xml'?> <contact fullname="Dirk Steinberg">
</references> <organization>Steinberg Consulting</organization>
<address>
<postal/>
<email>dirk@lapishills.com</email>
</address>
</contact>
<references title="Informative References"> <contact fullname="Daniel Bernier">
<?rfc include='reference.I-D.matsushima-spring-srv6-deployment-status'?> <organization>Bell Canada</organization>
<address>
<postal/>
<email>daniel.bernier@bell.ca</email>
</address>
</contact>
<?rfc include='reference.I-D.ietf-idr-segment-routing-te-policy'?> <contact fullname="Daniel Voyer">
<organization>Bell Canada</organization>
<address>
<postal/>
<email> daniel.voyer@bell.ca</email>
</address>
</contact>
<?rfc include='reference.I-D.ietf-spring-segment-routing-policy.xml'?> <contact fullname="Jonn Leddy">
<organization>Individual</organization>
<address>
<postal/>
<email>john@leddy.net</email>
</address>
</contact>
<?rfc include='reference.I-D.ietf-lsr-flex-algo.xml'?> <contact fullname="Swadesh Agrawal">
<organization>Cisco</organization>
<address>
<postal/>
<email>swaagraw@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.2827.xml'?> <contact fullname="Patrice Brissette">
<organization>Cisco</organization>
<address>
<postal/>
<email>pbrisset@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.3704.xml'?> <contact fullname="Ali Sajassi">
<organization>Cisco</organization>
<address>
<postal/>
<email>sajassi@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.5925.xml'?> <contact fullname="Bart Peirens">
<organization>Proximus</organization>
<address>
<postal>
<country>Belgium</country>
</postal>
<email>bart.peirens@proximus.com</email>
</address>
</contact>
<?rfc include='reference.RFC.4272.xml'?> <contact fullname="Darren Dukes">
<organization>Cisco</organization>
<address>
<postal/>
<email>ddukes@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.6952.xml'?> <contact fullname="Pablo Camarilo">
<organization>Cisco</organization>
<address>
<postal/>
<email>pcamaril@cisco.com</email>
</address>
</contact>
<?rfc include='reference.RFC.9012.xml'?> <contact fullname="Shyam Sethuram">
<organization>Cisco</organization>
<address>
<postal/>
<email>shyam.ioml@gmail.com</email>
</address>
</contact>
<?rfc include='reference.RFC.6513.xml'?> <contact fullname="Zafar Ali">
</references> <organization>Cisco</organization>
<address>
<postal/>
<email>zali@cisco.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 233 change blocks. 
1191 lines changed or deleted 1363 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/