Diff: rfc9252xml2.original.xml

	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" ?>	<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>
		<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 symrefs="yes" ?>	<!-- xml2rfc v2v3 conversion 3.12.2 -->


	<?rfc sortrefs="yes" ?>	<front>
		<!--[rfced] We notice that the Abstract and Introduction use
		"SRv6-based BGP services" but the title and short title across
		the header in the pdf use "SRv6 BGP-based Overlay
		Services". Should the titles be updated per Option A or B below,
		or should the text in the Abstract and Introduction be updated
		to reflect "SRv6 BGP-based Overlay Services" for consistency?


	<?rfc iprnotified="no" ?>	Also note that the abbreviations in the title have been expanded
		per Section 3.6 of RFC 7332 ("RFC Style Guide"). Please review.


	<?rfc strict="yes" ?>	Original:
		SRv6 BGP based Overlay Services


	<?rfc compact="yes" ?>	Perhaps:
		A)
		Title: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
		Short title: SRv6-Based BGP Overlay Services


	<?rfc subcompact="no" ?>	or


	<front>	B)
	<title abbrev="SRv6 BGP based Overlay Services">SRv6 BGP based Overlay	Title: Segment Routing over IPv6 (SRv6) Overlay Services Based on BGP
	Services</title>	Short Title: SRv6 BGP-Based Overlay Services
		-->


		<title abbrev="SRv6 BGP-Based Overlay Services">Segment Routing over IPv6 (S
		Rv6) BGP-Based Overlay Services</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="June"/>
	<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 “BGP/MPLS IP Virtual Private Networks (VPNs)” and	Ethernet VPN (EVPN), and Internet services. It builds on
	RFC7432 “BGP MPLS-Based Ethernet VPN”.</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"/> “BGP/MPLS IP Virtual Private Networks	L3VPN, EVPN, and Internet services. It builds on "BGP/MPLS IP Virtual
	(VPNs)” and <xref target="RFC7432"/> “BGP MPLS-Based	Private Networks (VPNs)" <xref target="RFC4364" format="default"/> and
	Ethernet VPN”.</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 (table look up in
	a VRF) or End.DX (cross-connect to a nexthop) behaviors in the case of	VPN Routing and Forwarding (VRF)) or End.DX (cross-connect to a next hop)
	Layer-3 Virtual Private Network (L3VPN) service as defined in <xref	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="IDR-SEGMENT-ROUTING-TE
	target="I-D.ietf-idr-segment-routing-te-policy"/> for steering of flows	-POLICY" format="default"/> 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’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 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
		ors that may be
	encoded, but not limited to, are End.DX4, End.DT4, End.DX6, End.DT6,	encoded, but not limited to, are End.DX4, End.DT4, End.DX6, End.DT6,

	and End.DT46.</t>	and End.DT46.</dd>
		<dt>SRv6 L2 Service TLV:</dt>
	<t>SRv6 L2 Service TLV: This TLV encodes Service SID information for	<dd>This TLV encodes Service SID information for
	SRv6 based L2 services. It corresponds to the equivalent	SRv6-based L2 services. It corresponds to the equivalent
	functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)	functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)

	Route-Types as defined in <xref target="RFC7432"/>. Some SRv6	Route Types, as defined in <xref target="RFC7432" format="default"/>.
	Endpoint behaviors which may be encoded, but not limited to, are	Some SRv6
	End.DX2, End.DX2V, End.DT2U, and End.DT2M.</t>	Endpoint behaviors that may be encoded are, but not limited to,
	</list></t>	End.DX2, End.DX2V, End.DT2U, and End.DT2M.</dd>
		</dl>
	<t>When an egress PE is enabled for BGP Services over SRv6 data-plane,	<t>When an egress PE is enabled for BGP Services over the SRv6 data plane,
	it signals one or more SRv6 Service SIDs enclosed in SRv6 Service TLV(s)	it signals one or more SRv6 Service SIDs enclosed in an SRv6 Service TLV(s
	within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs defined in	)
	<xref target="RFC4760"/> <xref target="RFC4659"/> <xref	within the BGP Prefix-SID attribute attached to Multiprotocol BGP (MP-BGP)
	target="RFC8950"/> <xref target="RFC7432"/> <xref target="RFC4364"/>	Network Layer Reachability Information (NLRI) defined in
	<xref target="RFC9136"/> where applicable as described in <xref	<xref target="RFC4760" format="default"/>, <xref target="RFC4659" format="
	target="L3BGP"/> and <xref target="EVPNBGP"/>.</t>	default"/>, <xref target="RFC8950" format="default"/>, <xref target="RFC7432" fo
		rmat="default"/>, <xref target="RFC4364" format="default"/>, and
	<t>The support for BGP Multicast VPN (MVPN) Services <xref	<xref target="RFC9136" format="default"/>, where applicable, as describe
	target="RFC6513"/> with SRv6 is outside the scope of this document.</t>	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 values 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 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 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 unrecognized, received Sub-TLVs and Sub-Sub-TLVs <bcp14>MUST</bcp1
		4> 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 values 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>SHOULD</bcp14> be set
		to 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	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 <xref target="L3BGP"/>	to the originator of the advertisement. While Sections <xref target="L3B
	and <xref target="EVPNBGP"/> list the SRv6 Endpoint Behaviors that are	GP"
		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 endpoint behavior <bcp14>MUST NOT</bcp14> be considered inv
	receiver except for behaviors that involve the use of arguments (refer	alid 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 values 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">
		<dt>SRv6 Service Data Sub-Sub-TLV Type (1 octet):</dt>
		<dd>This field is set to 1 to represent the SRv6 SID Structure Sub-Su
		b-TLV.</dd>
		<dt>SRv6 Service Data Sub-Sub-TLV Length (2 octets):</dt>
		<dd>This field contains a total length of 6 octets.</dd>
		<dt>Locator Block Length (1 octet):</dt>
		<dd>This field contains the length of the SRv6 SID Locator Block in b
		its.</dd>
		<dt>Locator Node Length (1 octet):</dt>
		<dd>This field contains the length of the SRv6 SID Locator Node in bi
		ts.</dd>
		<dt>Function Length (1 octet):</dt>
		<dd>This field contains the length of the SRv6 SID Function in bits.<
		/dd>
		<dt>Argument Length (1 octet):</dt>
		<dd>This field contains the length of the SRv6 SID Argument in bits.<
		/dd>
		<dt>Transposition Length (1 octet):</dt>
		<dd>This field is the size in bits for the part of the
		SID that has been transposed (or shifted) into an MPLS label
		field.</dd>
		<dt>Transposition Offset (1 octet):</dt>
		<dd>This field is the offset position in bits
		for the part of the SID that has been transposed (or shifted) into
		an
		MPLS label field.</dd>
		</dl>


	<t><list style="symbols">	<!--[rfced] In this sentence, does "them" refer to "mechanisms" or "a variable
	<t>SRv6 Service Data Sub-Sub-TLV Type (1 octet): This field is	part"? Please review and let us know how to update.
	set to 1 to represent SRv6 SID Structure Sub-Sub-TLV.</t>

	<t>SRv6 Service Data Sub-Sub-TLV Length (2 octets): This field
	contains a total length of 6 octets.</t>

	<t>Locator Block Length (1 octet): Contains the length of SRv6
	SID Locator Block in bits.</t>

	<t>Locator Node Length (1 octet): Contains the length of SRv6
	SID Locator Node in bits.</t>

	<t>Function Length (1 octet): Contains the length of SRv6 SID
	Function in bits.</t>


	<t>Argument Length (1 octet): Contains the length of SRv6 SID	Original:
	Argument in bits.</t>	Section 4 describes mechanisms for signaling of the SRv6 Service SID
		by transposing a variable part of the SRv6 SID value and carrying
		them in existing MPLS label fields to achieve more efficient packing
		of those service prefix NLRIs in BGP update messages.


	<t>Transposition Length (1 octet): Size in bits for the part of	Perhaps:
	SID that has been transposed (or shifted) into a MPLS label	A) (if referring to "mechanisms"):
	field</t>	Section 4 describes mechanisms for the signaling of the SRv6 Service
		SID by transposing a variable part of the SRv6 SID value and carrying
		the mechanism in existing MPLS label fields to achieve more efficient
		packing of those service prefix NLRIs in BGP update messages.
		Or


	<t>Transposition Offset (1 octet): The offset position in bits	B) (if referring to "a variable part"):
	for the part of SID that has been transposed (or shifted) into a	Section 4 describes mechanisms for the signaling of the SRv6 Service
	MPLS label field.</t>	SID by transposing a variable part of the SRv6 SID value and carrying
	</list></t>	the variable part in existing MPLS label fields to achieve more efficient
		packing of those service prefix NLRIs in BGP update messages.
		-->


	<t><xref target="SIDENCODE"/> describes mechanisms for signaling of	<t><xref target="SIDENCODE" format="default"/> describes mechanisms fo 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 them 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 put into high order bits of the MPLS label field. T
	bits that have been shifted out MUST be set to 0 in the SID	he
		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. E.g., the size of MPLS label field in	the SRv6 SID value into it. For example, the size of the MPLS label fi
	<xref target="RFC4364"/> <xref target="RFC8277"/> is 20 bits while	eld is 20 bits in
	in <xref target="RFC7432"/> is 24 bits.</t>	<xref target="RFC4364" format="default"/> and <xref target="RFC8277"
		format="default"/> and 24 bits in <xref target="RFC7432" format="defaul
	<t>As defined in <xref target="RFC8986"/>, the sum of the Locator	t"/>.</t>
		<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, where 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 endpoint behaviors. For SIDs
	validate that the consistency of the argument length with the	corresponding to an endpoint behavior that is known, a receiver <bcp14
		>MUST</bcp14>
		validate that the consistency of the AL with the
	specific endpoint behavior definition.</t>	specific 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>

		<!--[rfced] This sentence is a bit tough to read. Please review the
		suggested text and let us know if this is agreeable or if you
		prefer otherwise.

		Original:
		To achieve efficient packing, this document allows the encoding of
		the SRv6 Service SID either as a whole in the SRv6 Services TLVs or
		the encoding of only the common part of the SRv6 SID (e.g., Locator)
		in the SRv6 Services TLVs and encoding the variable (e.g., Function
		or Argument parts) in the existing label fields specific to that
		service encoding.


		Perhaps:
		To achieve efficient packing, this document allows 1) the encoding of
		the SRv6 Service SID as a whole in either the SRv6 Services TLVs or
		the encoding of only the common part of the SRv6 SID (e.g., Locator)
		in the SRv6 Services TLVs and 2) the encoding of the variable
		(e.g., Function or Argument parts) in the existing label fields
		specific to that service encoding.
		-->
	<t>To achieve efficient packing, this document allows the encoding of	<t>To achieve efficient packing, this document allows the encoding of

	the SRv6 Service SID either as a whole in the SRv6 Services TLVs or the	the SRv6 Service SID as a whole in either the SRv6 Services TLVs or the
	encoding of only the common part of the SRv6 SID (e.g., Locator) in the	encoding of only the common part of the SRv6 SID (e.g., Locator) in the
	SRv6 Services TLVs and encoding the variable (e.g., Function or Argument	SRv6 Services TLVs and encoding the variable (e.g., Function or Argument
	parts) in the existing label fields specific to that service encoding.	parts) in the existing label fields 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="LSR-FLEX-ALGO"
	target="I-D.ietf-lsr-flex-algo"/>) to the egress PE, the ingress PE	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 next hop to one of
	<t>For service over SRv6 core, the egress PE sets the next-hop to one of	its IPv6 addresses. Such an address <bcp14>MAY</bcp14> be covered by the S
	its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator	Rv6 Locator
	from which the SRv6 Service SID is allocated. The next-hop is used for	from which the SRv6 Service SID is allocated. The 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>


		<!--[rfced] We are having some difficulty parsing the following sentence
		that appears in Sections 5 and 6. Please review and let us know how to update.

		Original:
		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
		steering for service flows is performed as described in Section 8 of
		[I-D.ietf-spring-segment-routing-policy].

		Perhaps:
		When the BGP route is received at an ingress PE and colored with a
		Color Extended Community while a valid SRv6 Policy is available, the
		steering for service flows is performed as described in Section 8 of
		[IGMP-MLD-EVPN].
		-->

	<t>When the BGP route is 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 Section 8 of	steering for service flows is performed, as described in <xref target="I-D
	<xref target="I-D.ietf-spring-segment-routing-policy"/>. When the	.ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="defa
	ingress PE determines (with the help of SRv6 SID Structure) that the	ult"/>. When 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 <S1, S2,	segment list of the SRv6 Policy associated with SID list <S1, S2,
	S3> would be <S1, S2, S3-Service-SID>.</t>	S3> would be <S1, S2, S3-Service-SID>.</t>

		<section anchor="L3BGPVPNv4" numbered="true" toc="default">
		<name>IPv4 VPN over SRv6 Core</name>


	<section anchor="L3BGPVPNv4" title="IPv4 VPN Over SRv6 Core">	<!--[rfced] We note that RFC 8950 includes "IPv4 VPN Unicast over IPv6
	<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN	Core" and "IPv4 VPN Multicast over IPv6 Core". Is "IPv4 VPN over
	Over IPv6 Core defined in <xref target="RFC8950"/>.</t>	IPv6 Core" okay as is, or should it be updated to reflect either
		of these forms?


	<t>Label field of IPv4-VPN NLRI is encoded as specified in <xref	Original:
	target="RFC8277"/> with the 20-bit Label Value set to the whole or a	The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
	portion of the Function part of the SRv6 SID when the Transposition	Over IPv6 Core defined in [RFC8950].
	Scheme of encoding (<xref target="SIDENCODE"/>) is used and otherwise
	set to Implicit NULL. When using the Transposition Scheme, the
	Transposition Length MUST be less than or equal to 20 and less than or
	equal to the Function Length.</t>


	<t>SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The	Perhaps:
	SRv6 Endpoint behavior SHOULD be one of these: End.DX4, End.DT4,	A) The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
		unicast over IPv6 core defined in [RFC8950].

		Or

		B) The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
		multicast over IPv6 core defined in [RFC8950].
		-->

		<t>The MP_REACH_NLRI over SRv6 core is encoded according to IPv4 VPN
		over IPv6 core defined in <xref target="RFC8950" format="default"/>.</t>
		<t>The label field of IPv4-VPN NLRI is encoded as specified in <xref tar
		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
		Scheme of encoding (<xref target="SIDENCODE" format="default"/>) is used
		; otherwise,
		it is set to Implicit NULL. When using the Transposition Scheme, the
		Transposition Length <bcp14>MUST</bcp14> be less than or equal to 20 and
		less than or
		equal to the FL.</t>
		<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">
		<name>BGP-Based Ethernet VPN (EVPN) over SRv6</name>


	<section anchor="EVPNBGP" title="BGP based Ethernet VPN (EVPN) over SRv6">	<!--[rfced] The following text mentions where Route Types 1,2,3,5,6,7,
	<t><xref target="RFC7432"/> provides an extendable method of building an	and 8 are defined, but it does not mention where Route Type 4 is
	Ethernet VPN (EVPN) overlay. It primarily focuses on MPLS based EVPNs	defined. Is this intentional, or would you like to include a
	and <xref target="RFC8365"/> extends to IP-based EVPN overlays. <xref	citation where Route Type 4 is defined? If so, please
	target="RFC7432"/> defines Route Types 1, 2, and 3 which carry prefixes	provide that reference.
	and MPLS Label fields; the Label fields have a specific use for MPLS
	encapsulation of EVPN traffic. Route Type 5 carrying MPLS label
	information (and thus encapsulation information) for EVPN is defined in
	<xref target="RFC9136"/>. Route Types 6, 7, and 8 are defined in <xref
	target="I-D.ietf-bess-evpn-igmp-mld-proxy"/>.<list style="symbols">
	<t>Ethernet Auto-discovery Route (Route Type 1)</t>

	<t>MAC/IP Advertisement Route (Route Type 2)</t>

	<t>Inclusive Multicast Ethernet Tag Route (Route Type 3)</t>

	<t>Ethernet Segment route (Route Type 4)</t>

	<t>IP prefix route (Route Type 5)</t>

	<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>	Original:
	</list></t>	[RFC7432] defines Route
		Types 1, 2, and 3 which carry prefixes and MPLS Label fields; the
		Label fields have a specific use for MPLS encapsulation of EVPN
		traffic. Route Type 5 carrying MPLS label information (and thus
		encapsulation information) for EVPN is defined in [RFC9136]. Route
		Types 6, 7, and 8 are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy].
		-->


		<t><xref target="RFC7432" format="default"/> provides an extendable method
		of building an
		EVPN overlay. It primarily focuses on MPLS-based EVPNs,
		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
		encapsulation of EVPN traffic. Route Type 5 carrying MPLS label
		information (and thus encapsulation information) for an EVPN is defined in
		<xref target="RFC9136" format="default"/>. Route Types 6, 7, and 8 are def
		ined in <xref target="RFC9251" format="default"/>.</t>
		<ul spacing="normal">
		<li>Ethernet Auto-Discovery (A-D) route (Route Type 1)</li>
		<li>MAC/IP Advertisement route (Route Type 2)</li>
		<li>Inclusive Multicast Ethernet Tag route (Route Type 3)</li>
		<li>Ethernet Segment route (Route Type 4)</li>
		<li>IP Prefix route (Route Type 5)</li>
		<li>Selective Multicast Ethernet Tag route (Route Type 6)</li>
		<li>Multicast Membership Report Synch route (Route Type 7)</li>
		<li>Multicast Leave Synch route (Route Type 8)</li>
		</ul>
	<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
		le
	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="LSR-FLEX-ALGO"
	target="I-D.ietf-lsr-flex-algo"/>) to the egress PE, the ingress PE	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 next hop to one of
	<t>For service over SRv6 core, the egress PE sets the next-hop to one of	its IPv6 addresses. Such an address <bcp14>MAY</bcp14> be covered by the S
	its IPv6 addresses. Such an address MAY be covered by the SRv6 Locator	Rv6 Locator
	from which the SRv6 Service SID is allocated. The next-hop is used for	from which the SRv6 Service SID is allocated. The 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 is 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 Section 8 of	steering for service flows is performed as described in <xref target="I-D.
	<xref target="I-D.ietf-spring-segment-routing-policy"/>. When the	ietf-spring-segment-routing-policy" section="8" sectionFormat="of" format="defau
	ingress PE determines (with the help of SRv6 SID Structure) that the	lt"/>. When 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 <S1, S2,	segment list of the SRv6 Policy associated with SID list <S1, S2,
	S3> would be <S1, S2, S3-Service-SID>.</t>	S3> would be <S1, S2, S3-Service-SID>.</t>

		<section anchor="RT1" numbered="true" toc="default">
		<name>Ethernet Auto-Discovery Route over SRv6 Core</name>
		<t>Ethernet A-D routes are Route Type 1, as defined in
		<xref target="RFC7432" format="default"/>, and may be used to achieve sp
		lit-horizon
		filtering, fast convergence, and aliasing.


	<section anchor="RT1"	<!--[rfced] May we update this sentence from "point-to-point
	title="Ethernet Auto-discovery Route over SRv6 Core ">	services ID" to "point-to-point service IDs"?
	<t>Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in
	<xref target="RFC7432"/> and may be used to achieve split-horizon
	filtering, fast convergence, and aliasing. EVPN Route Type 1 is also
	used in EVPN- VPWS as well as in EVPN flexible cross-connect; mainly
	used to advertise point-to-point services ID.</t>


	<t>As a reminder, EVPN Route Type 1 is encoded as follows:</t>	Original:
		EVPN Route Type 1 is also used in EVPN-
		VPWS as well as in EVPN flexible cross-connect; mainly used to
		advertise point-to-point services ID.


	<figure anchor="EVPNRT1" title="EVPN Route Type 1">	Perhaps:
	<artwork><![CDATA[	EVPN Route Type 1 is also used in EVPN-
	+---------------------------------------+	VPWS as well as in EVPN-flexible cross-connect, mainly to
	\| RD (8 octets) \|	advertise point-to-point service IDs.
	+---------------------------------------+	-->
	\|Ethernet Segment Identifier (10 octets)\|
	+---------------------------------------+
	\| Ethernet Tag ID (4 octets) \|
	+---------------------------------------+
	\| MPLS label (3 octets) \|
	+---------------------------------------+


		EVPN Route Type 1 is also
		used in EVPN-VPWS as well as in EVPN-flexible cross-connect, mainly
		to advertise point-to-point services ID.</t>
		<t>As a reminder, EVPN Route Type 1 is encoded as follows:</t>
		<figure anchor="EVPNRT1">
		<name>EVPN Route Type 1</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
		+-----------------------------------------+
		\| RD (8 octets) \|
		+-----------------------------------------+
		\| Ethernet Segment Identifier (10 octets)\|
		+-----------------------------------------+
		\| Ethernet Tag ID (4 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"/>);
		otherwise, it is set to the
	Implicit NULL value. In either case, the value is set in the high	Implicit NULL value. In either case, the value is set in the high
	order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). When	order 20 bits (e.g., as 0x000030 in the case of Implicit NULL). 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 the Implicit NULL value. In either case, the value is set i
		n
	the high order 20 bits (e.g., as 0x000030 in the case of	the high order 20 bits (e.g., as 0x000030 in the case of
	Implicit NULL). When using the Transposition Scheme, the	Implicit NULL). When using 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 the Implici
		t NULL
	value. In either case, the value is set in the high order 20 bits	value. In either case, the value is set in the high order 20 bits
	(e.g., as 0x000030 in the case of Implicit NULL). When using the	(e.g., as 0x000030 in the case of Implicit NULL). 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 the Implici
		t NULL
	value. In either case, the value is set in the high order 20 bits	value. In either case, the value is set in the high order 20 bits
	(e.g., as 0x000030 in the case of Implicit NULL). When using the	(e.g., as 0x000030 in the case of Implicit NULL). 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 the Impli
		cit NULL
	value. In either case, the value is set in the high order 20	value. In either case, the value is set in the high order 20
	bits (e.g., as 0x000030 in the case of Implicit NULL). When	bits (e.g., as 0x000030 in the case of Implicit NULL). 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
		set to the Implicit NULL
	value. In either case, the value is set in the high order 20	value. In either case, the value is set in the high order 20
	bits (e.g., as 0x000030 in the case of Implicit NULL). When	bits (e.g., as 0x000030 in the case of Implicit NULL). 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
	value. In either case, the value is set in the high order 20	set to the Implicit
		NULL value. In either case, the value is set in the high order 20
	bits (e.g., as 0x000030 in the case of Implicit NULL). When	bits (e.g., as 0x000030 in the case of Implicit NULL). 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 988 ¶
	+---------------------------------------+	+---------------------------------------+
	\| 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 “local-bias” 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 “local-bias” 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 1067 ¶
	+---------------------------------------+	+---------------------------------------+
	\| 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;
		otherwise, it is set to the
	Implicit NULL value. In either case, the value is set in the high	Implicit NULL value. In either case, the value is set in the high
	order 20 bits (e.g., as 0x000030 in the case of Implicit NULL).	order 20 bits (e.g., as 0x000030 in the case of Implicit NULL).

	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">
		<name>IANA Considerations</name>
		<section numbered="true" toc="default">


	<section anchor="IANA" title="IANA Considerations">	<!--[rfced] We have included some specific information about the IANA
	<section title="BGP Prefix-SID TLV Types Registry">	text below (mainly FYIs). In addition to reviewing those changes, please
	<t>This document introduces two new TLV Types of the BGP Prefix-SID	review all of the IANA-related updates carefully and let us know
	attribute. IANA has assigned Type values in the registry "BGP	if any further updates are needed.
	Prefix-SID TLV Types" as follows: <figure anchor="IANAPFXSIDTYPES"
	title="BGP Prefix-SID TLV Types">
	<artwork><![CDATA[ Value Type Reference
	--------------------------------------------
	4 Deprecated <this document>
	5 SRv6 L3 Service TLV <this document>
	6 SRv6 L2 Service TLV <this document>]]></artwork>
	</figure></t>


	<t>The value 4 previously corresponded to the SRv6-VPN SID TLV, which	A) FYI: For values 5 and 6, the Type names do not include "TLV" in the
	was specified in previous versions of this document and used by early	"BGP Prefix-SID TLV Types" subregistry. We will ask IANA to add "TLV"
		to the subregistry accordingly.

		Current (Table 1):
		\| 5 \| SRv6 L3 Service TLV \| RFC 9252 \|
		+ - - - - - - - - - - - - - - - - - - - - +
		\| 6 \| SRv6 L2 Service TLV \| RFC 9252 \|

		Current (IANA registry):
		\| 5 \| SRv6 L3 Service \| RFC 9252 \|
		+ - - - - - - - - - - - - - - - - - - - - +
		\| 6 \| SRv6 L2 Service \| RFC 9252 \|

		B) FYI: The registration procedures in Tables 2 and 4 do not match IANA's
		registration procedures under the "SRv6 Service Sub-TLV Types" and
		"SRv6 Service Sub-Sub-TLV Types" subregistries. We updated these
		tables to match the registries by changing the "Value" and "Type"
		headings to "Range" and "Registration Procedures", respectively;
		moving the value "0" and its corresponding information to Tables 3
		and 5; and changing "Reserved" to "IETF Review" for value 255.

		Original:
		Value Type
		- - - - - - - - - - - - - - - - - -
		0 Reserved
		0-127 IETF Review
		128-254 First Come First Served
		255 Reserved

		Current (for Tables 2 and 4):
		Range Registration Procedures
		- - - - - - - - - - - - - - - - - -
		0-127 IETF Review
		128-254 First Come First Served
		255 IETF Review

		C) FYI: Tables 3 and 5 have been updated to match the
		relevant IANA registries. Please review.
		-->

		<name>BGP Prefix-SID TLV Types Registry</name>
		<t>This document introduces two new TLV Types of the BGP Prefix-SID
		attribute. IANA has assigned Type values in the "BGP
		Prefix-SID TLV Types" subregistry as follows: </t>
		<table anchor="IANAPFXSIDTYPES" align="center">
		<name>BGP Prefix-SID TLV Types Subregistry</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Type</th>
		<th>Reference</th>
		</tr>
		</thead>
		<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 Procedure</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
		target="RFC8986" format="default"/>, for validation.</t>


	<t>The SRv6 SID Endpoint behaviors implementing the services signalled	<!--[rfced] May we update "SRv6 SID Endpoint" to be "SRv6 Endpoint" to
	in this document are defined in <xref target="RFC8986"/> and hence the	reflect usage throughout the document?

		Original:
		The SRv6 SID Endpoint behaviors implementing the services signalled
		in this document are defined in [RFC8986] and hence the security
		considerations of that document apply.

		Perhaps:
		The SRv6 Endpoint behaviors implementing the services signaled
		in this document are defined in [RFC8986]; hence, the security
		considerations of that document apply.
		-->
		<t>The SRv6 SID Endpoint behaviors implementing the services signaled
		in this document are defined in <xref target="RFC8986" format="default"/
		>; hence, the
	security considerations of that document apply. These considerations	security considerations of that document apply. These considerations

	are independent of the protocol used for service deployment, i.e.	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="IGMP-MLD-
	<?rfc include='reference.RFC.8986.xml'?>	EVPN"/>
		<references>
	<?rfc include='reference.RFC.8754.xml'?>	<name>References</name>
		<references>
	<?rfc include='reference.RFC.7432.xml'?>	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.8200.xml'?>	FC.8986.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.7606.xml'?>	FC.8754.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.6514.xml'?>	FC.7432.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.4456.xml'?>	FC.8200.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.2119.xml'?>	FC.7606.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<?rfc include='reference.RFC.8669.xml'?>	FC.6514.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4456.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8669.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8402.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.9136.xml"/>


	<?rfc include='reference.RFC.8402.xml'?>	<!-- [I-D.ietf-bess-evpn-igmp-mld-proxy] in RFC-EDITOR state as of 06/9/22; comp
		anion document -->
		<reference anchor='RFC9251' target="https://www.rfc-editor.org/info/rfc9251">
		<front>
		<title>Internet Group Management Protocol (IGMP) and Multicast Listener Discover
		y (MLD) Proxies for Ethernet VPN (EVPN)</title>
		<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
		<organization />
		</author>
		<author initials='S' surname='Thoria' fullname='Samir Thoria'>
		<organization />
		</author>
		<author initials='M' surname='Mishra' fullname='Mankamana Mishra'>
		<organization />
		</author>
		<author initials='K' surname='Patel' fullname='Keyur Patel'>
		<organization />
		</author>
		<author initials='J' surname='Drake' fullname='John Drake'>
		<organization />
		</author>
		<author initials='W' surname='Lin' fullname='Wen Lin'>
		<organization />
		</author>
		<date year='2022' month='June'/>
		</front>
		<seriesInfo name="RFC" value="RFC9251"/>
		<seriesInfo name="DOI" value="10.17487/RFC9251"/>
		</reference>


	<?rfc include='reference.RFC.9136.xml' ?>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8950.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8365.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.I-D.ietf-bess-evpn-igmp-mld-proxy.xml' ?>	<!-- [rfced] FYI: The following reference has been deleted from the
		References section as it was only mentioned within the
		Implementation Status section, which has been deleted per your
		request.


	<?rfc include='reference.RFC.8950.xml'?>	Removed:
		[I-D.matsushima-spring-srv6-deployment-status]
		Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
		K., and A. Dhamija, "SRv6 Implementation and Deployment
		Status", draft-matsushima-spring-srv6-deployment-status-13
		(work in progress), March 2022.
		-->


	<?rfc include='reference.RFC.8365.xml'?>	<!-- [I-D.ietf-idr-segment-routing-te-policy] IESG state I-D Exists; included th
		e long way as the editor role was missing -->
		<reference anchor="IDR-SEGMENT-ROUTING-TE-POLICY">
		<front>
		<title>Advertising Segment Routing Policies in BGP</title>
		<author fullname="Stefano Previdi">
		<organization>Huawei Technologies</organization>
		</author>
		<author fullname="Clarence Filsfils">
		<organization>Cisco Systems</organization>
		</author>
		<author fullname="Ketan Talaulikar" role="editor">
		<organization>Arrcus Inc</organization>
		</author>
		<author fullname="Paul Mattes">
		<organization>Microsoft</organization>
		</author>
		<author fullname="Dhanendra Jain">
		<organization>Google</organization>
		</author>
		<author fullname="Steven Lin">
		<organization>Google</organization>
		</author>
		<date month="April" day="14" year="2022" />
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-idr-segment-routing-te-po
		licy-17" />
		</reference>


	<?rfc include='reference.RFC.8174.xml'?>	<!-- [I-D.ietf-spring-segment-routing-policy] WIP in RFC-EDITOR state as of 06/1
		/22, but RFC # not assigned yet. Added long form as editor role was missing -->
		<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.2545.xml'?>	<!--<reference anchor='RFCYYY2' target="https://www.rfc-editor.org/info/rfcYYY2"
		>
		<front>
		<title>Segment Routing Policy Architecture</title>
		<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
		<organization />
		</author>
		<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='edit
		or'>
		<organization />
		</author>
		<author initials='D' surname='Voyer' fullname='Dan Voyer'>
		<organization />
		</author>
		<author initials='A' surname='Bogdanov' fullname='Alex Bogdanov'>
		<organization />
		</author>
		<author initials='P' surname='Mattes' fullname='Paul Mattes'>
		<organization />
		</author>
		<date year='2022' month='June'/>
		</front>
		<seriesInfo name="RFC" value="YYY2"/>
		<seriesInfo name="DOI" value="10.17487/RFCYYY2"/>
		</reference>-->


	<?rfc include='reference.RFC.4271.xml'?>	<!-- [I-D.ietf-lsr-flex-algo] IESG state AD Evaluation; entered it the long way
		as the editor role was missing -->
		<reference anchor="LSR-FLEX-ALGO">
		<front>
		<title>IGP Flexible Algorithm</title>
		<author fullname="Peter Psenak" role="editor">
		<organization>Cisco Systems</organization>
		</author>
		<author fullname="Shraddha Hegde">
		<organization>Juniper Networks</organization>
		</author>
		<author fullname="Clarence Filsfils">
		<organization>Cisco Systems</organization>
		</author>
		<author fullname="Ketan Talaulikar">
		<organization>Arrcus, Inc</organization>
		</author>
		<author 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.4364.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.4659.xml'?>	<contact fullname="Satoru Matsushima">
		<organization>SoftBank</organization>
		<address>
		<postal/>
		<email>satoru.matsushima@g.softbank.co.jp</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.4760.xml'?>	<contact fullname="Dirk Steinberg">
		<organization>Steinberg Consulting</organization>
		<address>
		<postal/>
		<email>dirk@lapishills.com</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.8317.xml'?>	<contact fullname="Daniel Bernier">
		<organization>Bell Canada</organization>
		<address>
		<postal/>
		<email>daniel.bernier@bell.ca</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.8214.xml'?>	<contact fullname="Daniel Voyer">
		<organization>Bell Canada</organization>
		<address>
		<postal/>
		<email> daniel.voyer@bell.ca</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.8277.xml'?>	<contact fullname="Jonn Leddy">
	</references>	<organization>Individual</organization>
		<address>
		<postal/>
		<email>john@leddy.net</email>
		</address>
		</contact>


	<references title="Informative References">	<contact fullname="Swadesh Agrawal">
	<?rfc include='reference.I-D.matsushima-spring-srv6-deployment-status'?>	<organization>Cisco</organization>
		<address>
		<postal/>
		<email>swaagraw@cisco.com</email>
		</address>
		</contact>


	<?rfc include='reference.I-D.ietf-idr-segment-routing-te-policy'?>	<contact fullname="Patrice Brissette">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>pbrisset@cisco.com</email>
		</address>
		</contact>


	<?rfc include='reference.I-D.ietf-spring-segment-routing-policy.xml'?>	<contact fullname="Ali Sajassi">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>sajassi@cisco.com</email>
		</address>
		</contact>


	<?rfc include='reference.I-D.ietf-lsr-flex-algo.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.2827.xml'?>	<contact fullname="Darren Dukes">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>ddukes@cisco.com</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.3704.xml'?>	<contact fullname="Pablo Camarilo">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>pcamaril@cisco.com</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.5925.xml'?>	<contact fullname="Shyam Sethuram">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>shyam.ioml@gmail.com</email>
		</address>
		</contact>


	<?rfc include='reference.RFC.4272.xml'?>	<contact fullname="Zafar Ali">
		<organization>Cisco</organization>
		<address>
		<postal/>
		<email>zali@cisco.com</email>
		</address>
		</contact>
		</section>


	<?rfc include='reference.RFC.6952.xml'?>	<!--[rfced] Please review the "Inclusive Language" portion of the
		online Style Guide
		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Note that our script
		did not flag any words in particular, but this should still be
		reviewed as a best practice. -->


	<?rfc include='reference.RFC.9012.xml'?>	<!--[rfced] Throughout the text, the following terminology appears to be used
		inconsistently. Please review these occurrences and let us know if/how they
		may be made consistent.


	<?rfc include='reference.RFC.6513.xml'?>	- SRv6 Service vs. SRv6 service
	</references>	- MPLS Label field vs. MPLS label field
		- Endpoint Behavior vs. Endpoint behavior vs. endpoint behavior
		- BGP Service vs. BGP service
		- Transposition Offset vs. transposition offset
		- Transposition Length vs. transposition length
		- Transposition Scheme vs. transposition scheme
		-->
	</back>	</back>
	</rfc>	</rfc>

End of changes. 279 change blocks.
	1128 lines changed or deleted	1627 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/

mirror server hosted at Truenetwork, Russian Federation.