Diff: rfc9830xml2.original.xml

	rfc9830xml2.original.xml	rfc9830.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc comments="yes"?>	<!DOCTYPE rfc [
	<?rfc compact="yes"?>	<!ENTITY nbsp " ">
	<?rfc inline="yes"?>	<!ENTITY zwsp "">
	<?rfc sortrefs="yes"?>	<!ENTITY nbhy "‑">
	<?rfc subcompact="no"?>	<!ENTITY wj "⁠">
	<?rfc symrefs="yes"?>	]>
	<?rfc toc="yes"?>
	<?rfc tocdepth="3"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	<?rfc tocindent="yes"?>	tf-idr-sr-policy-safi-13" number="9830" ipr="trust200902" consensus="true" updat
	<?rfc tocompact="yes"?>	es="9012" obsoletes="" submissionType="IETF" xml:lang="en" sortRefs="true" symRe
	<rfc category="std" docName="draft-ietf-idr-sr-policy-safi-13"	fs="true" tocInclude="true" tocDepth="3" version="3">
	ipr="trust200902" updates="9012">
	<front>	<front>
	<title abbrev="Segment Routing Policies in BGP">Advertising Segment	<title abbrev="Segment Routing Policies in BGP">Advertising Segment
	Routing Policies in BGP</title>	Routing Policies in BGP</title>

		<seriesInfo name="RFC" value="9830"/>
	<author fullname="Stefano Previdi" initials="S." surname="Previdi">	<author fullname="Stefano Previdi" initials="S." surname="Previdi">
	<organization>Huawei Technologies</organization>	<organization>Huawei Technologies</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>	<country>Italy</country>

	<city/>

	<code/>

	<country>IT</country>
	</postal>	</postal>


	<email>stefano@previdi.net</email>	<email>stefano@previdi.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city>Brussels</city>	<city>Brussels</city>

		<country>Belgium</country>
	<region/>

	<code/>

	<country>BE</country>
	</postal>	</postal>


	<email>cfilsfil@cisco.com</email>	<email>cfilsfil@cisco.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
	<author fullname="Ketan Talaulikar" initials="K." role="editor"	aulikar">
	surname="Talaulikar">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>

	<street/>

	<city/>

	<region/>

	<code/>

	<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="Paul Mattes" initials="P." surname="Mattes">	<author fullname="Paul Mattes" initials="P." surname="Mattes">
	<organization>Microsoft</organization>	<organization>Microsoft</organization>


	<address>	<address>
	<postal>	<postal>
	<street>One Microsoft Way</street>	<street>One Microsoft Way</street>


	<city>Redmond</city>	<city>Redmond</city>


	<region>WA</region>	<region>WA</region>


	<code>98052</code>	<code>98052</code>

		<country>United States of America</country>
	<country>USA</country>
	</postal>	</postal>


	<email>pamattes@microsoft.com</email>	<email>pamattes@microsoft.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Dhanendra Jain" initials="D." surname="Jain">	<author fullname="Dhanendra Jain" initials="D." surname="Jain">
	<organization>Google</organization>	<organization>Google</organization>


	<address>	<address>
	<email>dhanendra.ietf@gmail.com</email>	<email>dhanendra.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>

		<date month="July" year="2025"/>
		<area>RTG</area>
		<workgroup>idr</workgroup>


	<date/>	<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

	<abstract>	<abstract>
	<t>A Segment Routing (SR) Policy is an ordered list of segments (also	<t>A Segment Routing (SR) Policy is an ordered list of segments (also

	referred to as instructions) that define a source-routed policy. An SR	referred to as "instructions") that define a source-routed policy. An SR
	Policy consists of one or more candidate paths, each comprising one or	Policy consists of one or more candidate paths, each comprising one or
	more segment lists. A headend can be provisioned with these candidate	more segment lists. A headend can be provisioned with these candidate

	paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP.</t>	paths using various mechanisms such as Command-Line Interface (CLI), Netwo
		rk Configuration Protocol (NETCONF), Path Computation Element Communication Prot
		ocol (PCEP), or BGP.</t>
	<t>This document specifies how BGP can be used to distribute SR Policy	<t>This document specifies how BGP can be used to distribute SR Policy
	candidate paths. It introduces a BGP SAFI for advertising a candidate	candidate paths. It introduces a BGP SAFI for advertising a candidate
	path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation	path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation
	Attribute to signal information related to these candidate paths.</t>	Attribute to signal information related to these candidate paths.</t>

		<t>Furthermore, this document updates RFC 9012 by extending the Color
	<t>Furthermore, this document updates RFC9012 by extending the Color
	Extended Community to support additional steering modes over SR	Extended Community to support additional steering modes over SR
	Policy.</t>	Policy.</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="INTRO" title="Introduction">	<section anchor="INTRO" numbered="true" toc="default">
	<t>Segment Routing (SR) <xref target="RFC8402"/> allows a headend node	<name>Introduction</name>
		<t>Segment Routing (SR) <xref target="RFC8402" format="default"/> allows a
		headend node
	to steer a packet flow along a specific path. Intermediate per-path	to steer a packet flow along a specific path. Intermediate per-path
	states are eliminated thanks to source routing.</t>	states are eliminated thanks to source routing.</t>

		<t>The headend node is said to steer a flow into an SR Policy <xref target
	<t>The headend node is said to steer a flow into an SR Policy <xref	="RFC9256" format="default"/>.</t>
	target="RFC9256"/>.</t>

	<t>The packets steered into an SR Policy carry an ordered list of	<t>The packets steered into an SR Policy carry an ordered list of
	segments associated with that SR Policy.</t>	segments associated with that SR Policy.</t>

		<t><xref target="RFC9256" format="default"/> further details the concepts
	<t><xref target="RFC9256"/> further details the concepts of SR Policy	of SR Policy
	and steering into an SR Policy. These apply equally to the SR-MPLS and	and steering into an SR Policy. These apply equally to the SR-MPLS and

	Segment Routing for IPv6 (SRv6) data-plane instantiations of Segment	Segment Routing for IPv6 (SRv6) data plane instantiations of Segment
	Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described	Routing using SR-MPLS and SRv6 Segment Identifiers (SIDs) as described

	in <xref target="RFC8402"/>. <xref target="RFC8660"/> describes the	in <xref target="RFC8402" format="default"/>. <xref target="RFC8660" forma t="default"/> describes the
	representation and processing of this ordered list of segments as an	representation and processing of this ordered list of segments as an

	MPLS label stack for SR-MPLS. While <xref target="RFC8754"/> and <xref	MPLS label stack for SR-MPLS. <xref target="RFC8754" format="default"/> an
	target="RFC8986"/> describe the same for SRv6 with the use of the	d <xref target="RFC8986" format="default"/> describe the same for SRv6 with the
		use of the
	Segment Routing Header (SRH).</t>	Segment Routing Header (SRH).</t>

		<t>The functionality related to SR Policy described in <xref target="RFC92
	<t>The SR Policy related functionality described in <xref	56" format="default"/> can be conceptually viewed as being incorporated in
	target="RFC9256"/> can be conceptually viewed as being incorporated in	an SR Policy Module (SRPM). The following is a reminder of the high-level
	an SR Policy Module (SRPM). Following is a reminder of the high-level	functionality of SRPM: </t>
	functionality of SRPM: <list style="symbols">	<ul spacing="normal">
	<t>Learning multiple candidate paths (CP) for an SR Policy via	<li>
		<t>Learning multiple candidate paths (CPs) for an SR Policy via
	various mechanisms (CLI, NETCONF, PCEP, or BGP).</t>	various mechanisms (CLI, NETCONF, PCEP, or BGP).</t>

		</li>
		<li>
	<t>Selection of the best candidate path for an SR Policy.</t>	<t>Selection of the best candidate path for an SR Policy.</t>

		</li>
		<li>
	<t>Associating a Binding SID (BSID) to the selected candidate path	<t>Associating a Binding SID (BSID) to the selected candidate path
	of an SR Policy.</t>	of an SR Policy.</t>

		</li>
		<li>
	<t>Installation of the selected candidate path and its BSID in the	<t>Installation of the selected candidate path and its BSID in the
	forwarding plane.</t>	forwarding plane.</t>

	</list></t>	</li>
		</ul>
	<t>This document specifies the use of BGP to distribute one or more of	<t>This document specifies the use of BGP to distribute one or more of

	the candidate paths of an SR Policy to the headend of that policy. The	the candidate paths of an SR Policy to the headend of that SR Policy. The
	document describes the functionality provided by BGP and, as	document describes the functionality provided by BGP and, as

	appropriate, provides references for the functionality which is outside	appropriate, provides references for the functionality, which is outside
	the scope of BGP (i.e. resides within SRPM on the headend node).</t>	the scope of BGP (i.e., resides within SRPM on the headend node).</t>

	<t>This document specifies a way of representing SR Policy candidate	<t>This document specifies a way of representing SR Policy candidate
	paths in BGP UPDATE messages. BGP can then be used to propagate the SR	paths in BGP UPDATE messages. BGP can then be used to propagate the SR
	Policy candidate paths to the headend nodes in a network. The usual BGP	Policy candidate paths to the headend nodes in a network. The usual BGP
	rules for BGP propagation and best-path selection are used. At the	rules for BGP propagation and best-path selection are used. At the
	headend of a specific policy, this will result in one or more candidate	headend of a specific policy, this will result in one or more candidate
	paths being installed into the "BGP table". These paths are then passed	paths being installed into the "BGP table". These paths are then passed
	to the SRPM. The SRPM may compare them to candidate paths learned via	to the SRPM. The SRPM may compare them to candidate paths learned via
	other mechanisms and will choose one or more paths to be installed in	other mechanisms and will choose one or more paths to be installed in
	the data plane. BGP itself does not install SR Policy candidate paths	the data plane. BGP itself does not install SR Policy candidate paths
	into the data plane.</t>	into the data plane.</t>

		<t>This document introduces a BGP Subsequent Address Family Identifier (SA
	<t>This document introduces a BGP subsequent address family (SAFI) for	FI) for
	IPv4 and IPv6 address families. In UPDATE messages of those AFI/SAFIs,	IPv4 and IPv6 address families. In UPDATE messages of those AFI/SAFIs,
	the Network Layer Reachability Information (NLRI) identifies an SR	the Network Layer Reachability Information (NLRI) identifies an SR
	Policy Candidate Path while the attributes encode the segment lists and	Policy Candidate Path while the attributes encode the segment lists and
	other details of that SR Policy Candidate Path.</t>	other details of that SR Policy Candidate Path.</t>

		<t>While, for simplicity, the text in this document states that BGP
	<t>While for simplicity the text in this document states that BGP
	advertises an SR Policy, it is to be understood that BGP advertises a	advertises an SR Policy, it is to be understood that BGP advertises a
	candidate path of an SR policy and that this SR Policy might have	candidate path of an SR policy and that this SR Policy might have
	several other candidate paths provided via BGP (via an NLRI with a	several other candidate paths provided via BGP (via an NLRI with a

	different distinguisher as defined in <xref target="SRPOLICYSAFI"/>),	different distinguisher as defined in <xref target="SRPOLICYSAFI" format=" default"/>),
	PCEP, NETCONF, or local policy configuration.</t>	PCEP, NETCONF, or local policy configuration.</t>

		<t>Typically, an SR Policy Controller <xref target="RFC9256" format="defau
	<t>Typically, a SR Policy Controller <xref target="RFC9256"/> defines	lt"/> defines
	the set of policies and advertises them to policy headend routers	the set of policies and advertises them to policy headend routers
	(typically ingress routers). These policy advertisements use the BGP	(typically ingress routers). These policy advertisements use the BGP
	extensions defined in this document. In most cases, the policy	extensions defined in this document. In most cases, the policy
	advertisement is tailored for a specific policy headend; consequently,	advertisement is tailored for a specific policy headend; consequently,
	it may be transmitted over a direct BGP session (i.e., without	it may be transmitted over a direct BGP session (i.e., without
	intermediate BGP hops) to that headend and is not propagated any	intermediate BGP hops) to that headend and is not propagated any
	further. In such cases, the policy advertisements will not traverse any	further. In such cases, the policy advertisements will not traverse any

	Route Reflector (RR, <xref target="RFC4456"/>) (see <xref	Route Reflector (RR) (see <xref target="RFC4456" format="default"/> and <x
	target="PROPAGATE"/>).</t>	ref target="PROPAGATE" format="default"/>).</t>

		<!--[rfced] Should "itself" be "themselves"? If neither of the
		following capture your intended meaning, please rephrase.

		Original:
		Alternatively, a BGP egress router may advertise SR Policies that
		represent paths terminating on itself.

		Perhaps A:
		Alternatively, a BGP egress router may advertise SR Policies that
		represent paths terminating on themselves.

		Perhaps B:
		Alternatively, a BGP egress router may advertise SR Policies that
		represent paths that terminate on it.

		-->

	<t>Alternatively, a BGP egress router may advertise SR Policies that	<t>Alternatively, a BGP egress router may advertise SR Policies that
	represent paths terminating on itself. In such cases, the router can	represent paths terminating on itself. In such cases, the router can
	send these policies directly to each headend over a dedicated BGP	send these policies directly to each headend over a dedicated BGP
	session, without necessitating any further propagation of the	session, without necessitating any further propagation of the
	policy.</t>	policy.</t>


	<t>In some situations, it is undesirable for a controller or BGP egress	<t>In some situations, it is undesirable for a controller or BGP egress
	router to have a BGP session to each policy headend. In these	router to have a BGP session to each policy headend. In these
	situations, BGP Route Reflectors may be used to propagate the	situations, BGP Route Reflectors may be used to propagate the
	advertisements. In certain other deployments, it may be necessary for	advertisements. In certain other deployments, it may be necessary for

	the advertisement to propagate through a sequence of one or more ASes	the advertisement to propagate through a sequence of one or more Autonomou
	within an SR Domain (refer to <xref target="Security"/> for the	s Systems (ASes)
		within an SR Domain (refer to <xref target="Security" format="default"/> f
		or the
	associated security considerations). To make this possible, an attribute	associated security considerations). To make this possible, an attribute
	needs to be attached to the advertisement that enables a BGP speaker to	needs to be attached to the advertisement that enables a BGP speaker to
	determine whether it is intended to be a headend for the advertised	determine whether it is intended to be a headend for the advertised
	policy. This is done by attaching one or more Route Target Extended	policy. This is done by attaching one or more Route Target Extended

	Communities to the advertisement <xref target="RFC4360"/>.</t>	Communities to the advertisement <xref target="RFC4360" format="default"/>
		.</t>
	<t>The BGP extensions for the advertisement of SR Policies include	<t>The BGP extensions for the advertisement of SR Policies include

	following components: <list style="symbols">	following components: </t>
		<ul spacing="normal">
		<li>
	<t>A Subsequent Address Family Identifier (SAFI) whose NLRIs	<t>A Subsequent Address Family Identifier (SAFI) whose NLRIs

	identifies an SR Policy candidate path.</t>	identify an SR Policy candidate path.</t>
		</li>
	<t>A Tunnel Type identifier for SR Policy, and a set of sub-TLVs to	<li>
		<t>A Tunnel Type identifier for SR Policy and a set of sub-TLVs to
	be inserted into the Tunnel Encapsulation Attribute (as defined in	be inserted into the Tunnel Encapsulation Attribute (as defined in

	<xref target="RFC9012"/>) specifying segment lists of the SR Policy	<xref target="RFC9012" format="default"/>) specifying segment lists of
	candidate path, as well as other information about the SR	the SR Policy
		candidate path as well as other information about the SR
	Policy.</t>	Policy.</t>

		</li>
		<li>
	<t>One or more IPv4 address-specific format route target extended	<t>One or more IPv4 address-specific format route target extended

	community (<xref target="RFC4360"/>) attached to the SR Policy	community (<xref target="RFC4360" format="default"/>) attached to the
	Candidate Path advertisement and that indicates the intended headend	SR Policy
		Candidate Path advertisement that indicates the intended headend
	of such an SR Policy Candidate Path advertisement.</t>	of such an SR Policy Candidate Path advertisement.</t>

	</list></t>	</li>
		</ul>
	<t>The SR Policy SAFI route updates utilize the Tunnel Encapsulation	<t>The SR Policy SAFI route updates utilize the Tunnel Encapsulation
	Attribute to signal an SR Policy, which itself functions as a tunnel.	Attribute to signal an SR Policy, which itself functions as a tunnel.

	This usage differs notably from the approach described in <xref	This usage differs notably from the approach described in <xref target="RF
	target="RFC9012"/>, where the Tunnel Encapsulation Attribute is	C9012" format="default"/>, where the Tunnel Encapsulation Attribute is
	associated with a BGP route update (e.g., for Internet or VPN routes) to	associated with a BGP route update (e.g., for Internet or VPN routes) to
	specify the tunnel used for forwarding traffic. This document does not	specify the tunnel used for forwarding traffic. This document does not
	modify or supersede the usage of the Tunnel Encapsulation Attribute for	modify or supersede the usage of the Tunnel Encapsulation Attribute for

	existing AFI/SAFIs as defined in <xref target="RFC9012"/>. Details	existing AFIs/SAFIs as defined in <xref target="RFC9012" format="default"/ >. Details
	regarding the processing of the Tunnel Encapsulation Attribute for the	regarding the processing of the Tunnel Encapsulation Attribute for the

	SR Policy SAFI are provided in <xref target="ENCAPSATTR"/> and <xref	SR Policy SAFI are provided in Sections <xref target="ENCAPSATTR" format="
	target="ENDCOLOR"/>.</t>	counter"/> and <xref target="ENDCOLOR" format="counter"/>.</t>

	<t>The northbound advertisement of the operational state of the SR	<t>The northbound advertisement of the operational state of the SR

	Policy Candidate Paths as part of BGP-LS <xref target="RFC9552"/>	Policy Candidate Paths as part of BGP - Link State (BGP-LS) <xref target="
	topology information is specified in <xref	RFC9552" format="default"/>
	target="I-D.ietf-idr-bgp-ls-sr-policy"/>.</t>	topology information is specified in <xref target="I-D.ietf-idr-bgp-ls-sr-
		policy" format="default"/>.</t>
	<t>The signaling of Dynamic and Composite Candidate Paths (sections 5.2	<t>The signaling of Dynamic and Composite Candidate Paths (Sections
	and 5.3 respectively of <xref target="RFC9256"/>) is outside the scope	<xref target="RFC9256" sectionFormat="bare" section="5.2"/> and <xref
	of this document.</t>	target="RFC9256" sectionFormat="bare" section="5.3"/>, respectively, of
		<xref target="RFC9256" format="default"/>) is outside the scope of this
	<t>The Color Extended Community (as defined in <xref target="RFC9012"/>)	document.</t>
	is used to steer traffic into an SR Policy, as described in section 8.8	<t>The Color Extended Community (as defined in <xref target="RFC9012"
	of <xref target="RFC9256"/>. The <xref target="EXTCOLOR"/> of this	format="default"/>) is used to steer traffic into an SR Policy, as
	document updates <xref target="RFC9012"/> with modifications to the	described in <xref target="RFC9256" sectionFormat="of"
	format of the Flags field of the Color Extended Community by using the	section="8.8"/>. <xref target="EXTCOLOR" format="default"/> of this
	two leftmost bits of that field.</t>	document updates <xref target="RFC9012" format="default"/> with
		modifications to the format of the Flags field of the Color Extended
	<section title="Requirements Language">	Community by using the two leftmost bits of that field.</t>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<section numbered="true" toc="default">
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	<name>Requirements Language</name>
	"OPTIONAL" in this document are to be interpreted as described in BCP	<t>
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	when, they appear in all capitals, as shown here.</t>	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 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="ENCODING" numbered="true" toc="default">
		<name>SR Policy Encoding</name>
		<section anchor="SRPOLICYSAFI" numbered="true" toc="default">
		<name>SR Policy SAFI and NLRI</name>
		<t>The SR Policy SAFI with
		code point 73 is introduced in this document. The AFI used <bcp14>MUST</
		bcp14> be IPv4(1) or IPv6(2).</t>
		<t>The SR Policy SAFI uses the NLRI format defined as follows: </t>


	<section anchor="ENCODING" title="SR Policy Encoding">	<figure>
	<section anchor="SRPOLICYSAFI" title="SR Policy SAFI and NLRI">	<name>SR Policy SAFI Format</name>
	<t>A SAFI is introduced in this document: the SR Policy SAFI with	<artwork align="left" name="" type="" alt=""><![CDATA[
	codepoint 73. The AFI used MUST be IPv4(1) or IPv6(2).</t>

	<t>The SR Policy SAFI uses the NLRI format defined as follows: <figure
	align="center">
	<artwork align="left"><![CDATA[
	+------------------+	+------------------+
	\| NLRI Length \| 1 octet	\| NLRI Length \| 1 octet
	+------------------+	+------------------+
	\| Distinguisher \| 4 octets	\| Distinguisher \| 4 octets
	+------------------+	+------------------+
	\| Policy Color \| 4 octets	\| Policy Color \| 4 octets
	+------------------+	+------------------+
	\| Endpoint \| 4 or 16 octets	\| Endpoint \| 4 or 16 octets
	+------------------+	+------------------+

		]]></artwork>
		</figure>


	Figure 1: SR Policy SAFI Format	<t>Where:</t>
		<dl spacing="normal">
		<dt>NLRI Length:</dt><dd>1 octet indicating the length expressed in bi
		ts as
		defined in <xref target="RFC4760" format="default"/>. When AFI = 1,
		the value <bcp14>MUST</bcp14> be 96; when AFI = 2, the value
		<bcp14>MUST</bcp14> be 192.</dd>


	where: ]]></artwork>	<!--[rfced] The following sentence is long and difficult to parse. In
	</figure><list style="symbols">	particular, what is being made unique? How may we rephrase?
	<t>NLRI Length: 1 octet indicating the length expressed in bits as
	defined in <xref target="RFC4760"/>. When AFI = 1 the value MUST
	be 96 and when AFI = 2 the value MUST be 192.</t>


	<t>Distinguisher: 4-octet value uniquely identifying the policy in	Original:
	the context of <color, endpoint> tuple. The distinguisher	The distinguisher has no semantic value and is solely used by the SR
	has no semantic value and is solely used by the SR Policy	Policy originator to make unique (from an NLRI perspective) both for
	originator to make unique (from an NLRI perspective) both for	multiple candidate paths of the same SR Policy as well as candidate
	multiple candidate paths of the same SR Policy as well as	paths of different SR Policies (i.e. with different segment lists)
	candidate paths of different SR Policies (i.e. with different	with the same Color and Endpoint but meant for different headends.
	segment lists) with the same Color and Endpoint but meant for
	different headends. The distinguisher is the discriminator of the
	SR Policy candidate path as specified in section 2.5 of <xref
	target="RFC9256"/>.</t>


	<t>Policy Color: 4 octets that carry an unsigned non-zero integer	-->
	value indicating the color of the SR Policy as specified in
	section 2.1 of <xref target="RFC9256"/>. The color is used to
	match the color of the destination prefixes to steer traffic into
	the SR Policy as specified in section 8 of <xref
	target="RFC9256"/>.</t>


	<t>Endpoint: value identifies the endpoint of a policy. The	<dt>Distinguisher:</dt><dd>4-octet value uniquely identifying the poli
	Endpoint may represent a single node or a set of nodes (e.g., an	cy in
	anycast address). The Endpoint is an IPv4 (4-octet) address or an	the context of <color, endpoint> tuple. The distinguisher has
	IPv6 (16-octet) address according to the AFI of the NLRI. The	no semantic value and is solely used by the SR Policy originator to
	address can be either a unicast or an unspecified address (0.0.0.0	make unique (from an NLRI perspective) both for multiple candidate
	for IPv4, :: for IPv6), known as null endpoint, as specified in	paths of the same SR Policy as well as candidate paths of different
	section 2.1 of <xref target="RFC9256"/>.</t>	SR Policies (i.e., with different segment lists) with the same Color
	</list></t>	and Endpoint but meant for different headends. The distinguisher is
		the discriminator of the SR Policy candidate path as specified in
		<xref target="RFC9256" sectionFormat="of" section="2.5"/>.</dd>
		<dt>Policy Color:</dt><dd>4 octets that carry an unsigned non-zero int
		eger
		value indicating the color of the SR Policy as specified in <xref
		target="RFC9256" sectionFormat="of" section="2.1"/>. The color is
		used to match the color of the destination prefixes to steer traffic
		into the SR Policy as specified in <xref target="RFC9256"
		sectionFormat="of" section="8"/>.</dd>
		<dt>Endpoint:</dt><dd>a value that identifies the endpoint of a policy
		. The
		Endpoint may represent a single node or a set of nodes (e.g., an
		anycast address). The Endpoint is an IPv4 (4-octet) address or an
		IPv6 (16-octet) address according to the AFI of the NLRI. The
		address can be either unicast or an unspecified address (0.0.0.0
		for IPv4, :: for IPv6), known as a null endpoint as specified in
		<xref target="RFC9256" sectionFormat="of" section="2.1"/>.</dd>
		</dl>

	<t>The color and endpoint are used to automate the steering of BGP	<t>The color and endpoint are used to automate the steering of BGP

	service routes on SR Policy as described in section 8 of <xref	service routes on an SR Policy as described in <xref target="RFC9256" se
	target="RFC9256"/>.</t>	ctionFormat="of" section="8"/>.</t>

	<t>The NLRI containing an SR Policy candidate path is carried in a BGP	<t>The NLRI containing an SR Policy candidate path is carried in a BGP

	UPDATE message <xref target="RFC4271"/> using BGP multi-protocol	UPDATE message <xref target="RFC4271" format="default"/> using BGP multi
	extensions <xref target="RFC4760"/> with an AFI of 1 or 2 (IPv4 or	protocol
		extensions <xref target="RFC4760" format="default"/> with an AFI of 1 or
		2 (IPv4 or
	IPv6) and with a SAFI of 73. The fault management and error handling	IPv6) and with a SAFI of 73. The fault management and error handling

	in the encoding of the NLRI is specified in <xref	in the encoding of the NLRI are specified in <xref target="ERROR" format
	target="ERROR"/>.</t>	="default"/>.</t>

	<t>An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI	<t>An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI

	attribute with the SR Policy SAFI MUST also carry the BGP mandatory	attribute with the SR Policy SAFI <bcp14>MUST</bcp14> also carry the BGP
	attributes. In addition, the BGP update message MAY also contain any	mandatory
		attributes. In addition, the BGP update message <bcp14>MAY</bcp14> also
		contain any
	of the BGP optional attributes.</t>	of the BGP optional attributes.</t>


	<t>The next-hop network address field in SR Policy SAFI (73) updates	<t>The next-hop network address field in SR Policy SAFI (73) updates
	may be either a 4-octet IPv4 address or a 16-octet IPv6 address,	may be either a 4-octet IPv4 address or a 16-octet IPv6 address,
	independent of the SR Policy AFI. The length field of the next-hop	independent of the SR Policy AFI. The length field of the next-hop
	address specifies the next-hop address family. If the next-hop length	address specifies the next-hop address family. If the next-hop length

	is 4, then the next-hop is an IPv4 address; if the next-hop length is	is 4, then the next-hop is an IPv4 address. If the next-hop length is
	16, then it is a global IPv6 address; if the next-hop length is 32,	16, then it is a global IPv6 address. If the next-hop length is 32,
	then it has a global IPv6 address followed by a link-local IPv6	then it has a global IPv6 address followed by a link-local IPv6
	address. The setting of the next-hop field and its attendant	address. The setting of the next-hop field and its attendant
	processing is governed by standard BGP procedures as described in	processing is governed by standard BGP procedures as described in

	section 3 of <xref target="RFC4760"/> and section 3 of <xref	<xref target="RFC4760" sectionFormat="of" section="3"/> and <xref target
	target="RFC2545"/>.</t>	="RFC2545" sectionFormat="of" section="3"/>.</t>

	<t>It is important to note that at any BGP speaker receiving BGP	<t>It is important to note that at any BGP speaker receiving BGP
	updates with SR Policy NLRIs, the SRPM processes only the best path as	updates with SR Policy NLRIs, the SRPM processes only the best path as
	per the BGP best-path selection algorithm. In other words, this	per the BGP best-path selection algorithm. In other words, this
	document leverages the existing BGP propagation and best-path	document leverages the existing BGP propagation and best-path

	selection rules. Details of the procedures are described in <xref	selection rules. Details of the procedures are described in <xref target
	target="OPERATIONS"/>.</t>	="OPERATIONS" format="default"/>.</t>

	<t>It has to be noted that if several candidate paths of the same SR	<t>It has to be noted that if several candidate paths of the same SR
	Policy (endpoint, color) are signaled via BGP to a headend, then it is	Policy (endpoint, color) are signaled via BGP to a headend, then it is

	RECOMMENDED that each NLRI uses a different distinguisher. If BGP has	<bcp14>RECOMMENDED</bcp14> that each NLRI use a different distinguisher. If BGP has
	installed into the BGP table two advertisements whose respective NLRIs	installed into the BGP table two advertisements whose respective NLRIs
	have the same color and endpoint, but different distinguishers, both	have the same color and endpoint, but different distinguishers, both
	advertisements are passed to the SRPM as different candidate paths	advertisements are passed to the SRPM as different candidate paths

	along with their respective originator information (i.e., ASN and BGP	along with their respective originator information (i.e., Autonomous Sys
	Router-ID) as described in section 2.4 of <xref target="RFC9256"/>.	tem Number (ASN) and BGP
		Router-ID) as described in <xref target="RFC9256" sectionFormat="of" sec
		tion="2.4"/>.
	The ASN would be the ASN of the origin and the BGP Router-ID is	The ASN would be the ASN of the origin and the BGP Router-ID is

	determined in the following order:<list style="symbols">	determined in the following order:</t>
	<t>From the Route Origin Community <xref target="RFC4360"/> if	<ul spacing="normal">
		<li>
		<t>From the Route Origin Community <xref target="RFC4360" format="de
		fault"/> if
	present and carrying an IP Address, or</t>	present and carrying an IP Address, or</t>

		</li>
		<li>


	<t>As the BGP Originator ID <xref target="RFC4456"/> if present,	<!-- [rfced] We note that [RFC4456] uses the term "ORIGINATOR_ID"
		rather than "Originator ID". Please review and let us know if any
		updates are necessary. -->
		<t>As the BGP Originator ID <xref target="RFC4456" format="default"/
		> if present,
	or</t>	or</t>

		</li>
		<li>
	<t>As the BGP Router-ID of the peer from which the update was	<t>As the BGP Router-ID of the peer from which the update was
	received as a last resort.</t>	received as a last resort.</t>

	</list></t>	</li>
		</ul>
	<t>The Section 2.9 of <xref target="RFC9256"/> specifies the selection	<t><xref target="RFC9256" sectionFormat="of" section="2.9"/> specifies t
		he selection
	of the active candidate path of the SR Policy by the SRPM based on the	of the active candidate path of the SR Policy by the SRPM based on the
	information provided to it by BGP.</t>	information provided to it by BGP.</t>
	</section>	</section>

		<section anchor="ENCAPSATTR" numbered="true" toc="default">
		<name>SR Policy and Tunnel Encapsulation Attribute</name>


	<section anchor="ENCAPSATTR"
	title="SR Policy and Tunnel Encapsulation Attribute">
	<t>The content of the SR Policy Candidate Path is encoded in the	<t>The content of the SR Policy Candidate Path is encoded in the

	Tunnel Encapsulation Attribute defined in <xref target="RFC9012"/>	Tunnel Encapsulation Attribute defined in <xref target="RFC9012" format=
	using a Tunnel-Type called SR Policy Type with codepoint 15. The use	"default"/>
	of SR Policy Tunnel-type is applicable only for the AFI/SAFI pairs of	using a Tunnel-Type called the "SR Policy" type with code point 15. The
		use
		of the SR Policy Tunnel-type is applicable only for the AFI/SAFI pairs o
		f
	(1/73, 2/73). This document specifies the use of the Tunnel	(1/73, 2/73). This document specifies the use of the Tunnel
	Encapsulation Attribute with the SR Policy Tunnel-Type and the use of	Encapsulation Attribute with the SR Policy Tunnel-Type and the use of

	any other Tunnel-Type with the SR Policy SAFI MUST be considered	any other Tunnel-Type with the SR Policy SAFI <bcp14>MUST</bcp14> be con
	malformed and handled by the "Treat-as-Withdraw" strategy <xref	sidered
	target="RFC7606"/>.</t>	malformed and handled by the "treat-as-withdraw" strategy <xref target="
		RFC7606" format="default"/>.</t>
		<t>The SR Policy Encoding structure is as follows: </t>


	<t>The SR Policy Encoding structure is as follows: <figure	<figure>
	align="center">	<name>SR Policy Encoding</name>
	<artwork align="left"><![CDATA[SR Policy SAFI NLRI: <Distinguisher,	<artwork align="left" name="" type="" alt=""><![CDATA[
	Policy-Color, Endpoint>	SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
	Attributes:	Attributes:
	Tunnel Encapsulation Attribute (23)	Tunnel Encapsulation Attribute (23)
	Tunnel Type: SR Policy (15)	Tunnel Type: SR Policy (15)
	Binding SID	Binding SID
	Preference	Preference
	Priority	Priority
	Policy Name	Policy Name
	Policy Candidate Path Name	Policy Candidate Path Name
	Explicit NULL Label Policy (ENLP)	Explicit NULL Label Policy (ENLP)
	Segment List	Segment List
	Weight	Weight
	Segment	Segment
	Segment	Segment
	...	...
	...	...

		]]></artwork>
		</figure>


	Figure 2: SR Policy Encoding	<t>Where:</t>
		<ul spacing="normal">
	where:]]></artwork>	<li>
	</figure><list style="symbols">	<t>The SR Policy SAFI NLRI is defined in <xref target="SRPOLICYSAFI"
	<t>SR Policy SAFI NLRI is defined in <xref	format="default"/>.</t>
	target="SRPOLICYSAFI"/>.</t>	</li>
		<li>
	<t>Tunnel Encapsulation Attribute is defined in <xref	<t>The Tunnel Encapsulation Attribute is defined in <xref target="RF
	target="RFC9012"/>.</t>	C9012" format="default"/>.</t>
		</li>
	<t>Tunnel-Type is set to 15.</t>	<li>
		<t>The Tunnel-Type is set to 15.</t>
		</li>
		<li>
	<t>Preference, Binding SID, Priority, Policy Name, Policy	<t>Preference, Binding SID, Priority, Policy Name, Policy
	Candidate Path Name, ENLP, Segment-List, Weight, and Segment	Candidate Path Name, ENLP, Segment-List, Weight, and Segment

	sub-TLVs are defined in <xref target="SRPOLICYTLV"/>.</t>	sub-TLVs are defined in <xref target="SRPOLICYTLV" format="default"/
		>.</t>
		</li>
		<li>
	<t>Additional sub-TLVs may be defined in the future.</t>	<t>Additional sub-TLVs may be defined in the future.</t>

	</list></t>	</li>
		</ul>
	<t>A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV
	of type "SR Policy"; such updates MUST be considered malformed and
	handled by the "Treat-as-Withdraw" strategy <xref
	target="RFC7606"/>.</t>


		<t>A Tunnel Encapsulation Attribute <bcp14>MUST NOT</bcp14> contain more
		than one TLV
		of type "SR Policy"; such updates <bcp14>MUST</bcp14> be considered malf
		ormed and
		handled by the "treat-as-withdraw" strategy <xref target="RFC7606" forma
		t="default"/>.</t>
	<t>BGP does not need to perform the validation of the tunnel (i.e., SR	<t>BGP does not need to perform the validation of the tunnel (i.e., SR

	Policy) itself as indicated in section 6 of <xref target="RFC9012"/>.	Policy) itself as indicated in <xref target="RFC9012" sectionFormat="of" section="6"/>.
	The validation of the SR Policy information that is advertised using	The validation of the SR Policy information that is advertised using

	the sub-TLVs specified in <xref target="SRPOLICYTLV"/> is performed by	the sub-TLVs specified in <xref target="SRPOLICYTLV" format="default"/> is performed by
	the SRPM.</t>	the SRPM.</t>
	</section>	</section>

		<section anchor="ENDCOLOR" numbered="true" toc="default">
	<section anchor="ENDCOLOR"	<name>Applicability of Tunnel Encapsulation Attribute Sub-TLVs</name>
	title="Applicability of Tunnel Encapsulation Attribute Sub-TLVs">
	<t>The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel	<t>The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel

	Encapsulation Attribute, as defined in <xref target="RFC9012"/>, are	Encapsulation Attribute, as defined in <xref target="RFC9012" format="de fault"/>, are
	not utilized for SR Policy encodings. Consequently, their values are	not utilized for SR Policy encodings. Consequently, their values are
	not relevant within the context of the SR Policy SAFI NLRI. If these	not relevant within the context of the SR Policy SAFI NLRI. If these

	sub-TLVs are present, a BGP speaker MUST ignore them and MAY remove	sub-TLVs are present, a BGP speaker <bcp14>MUST</bcp14> ignore them and <bcp14>MAY</bcp14> remove
	them from the Tunnel Encapsulation Attribute during propagation.</t>	them from the Tunnel Encapsulation Attribute during propagation.</t>

		<t>Similarly, any other sub-TLVs, including those specified in <xref tar
	<t>Similarly, any other sub-TLVs, including those specified in <xref	get="RFC9012" format="default"/>, that do not have explicitly defined applicabil
	target="RFC9012"/>, that do not have explicitly defined applicability	ity
	to the SR Policy SAFI MUST be ignored by the BGP speaker and MAY be	to the SR Policy SAFI <bcp14>MUST</bcp14> be ignored by the BGP speaker
		and <bcp14>MAY</bcp14> be
	removed from the Tunnel Encapsulation Attribute during	removed from the Tunnel Encapsulation Attribute during
	propagation.</t>	propagation.</t>
	</section>	</section>

		<section anchor="SRPOLICYTLV" numbered="true" toc="default">
	<section anchor="SRPOLICYTLV" title="SR Policy Sub-TLVs">	<name>SR Policy Sub-TLVs</name>
	<t>This section specifies the sub-TLVs defined for encoding the	<t>This section specifies the sub-TLVs defined for encoding the
	information about the SR Policy Candidate Path.</t>	information about the SR Policy Candidate Path.</t>


	<t>Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority,	<t>Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority,
	Policy Name, Policy Candidate Path Name, and Explicit NULL Label	Policy Name, Policy Candidate Path Name, and Explicit NULL Label
	Policy are all optional sub-TLVs introduced for the BGP Tunnel	Policy are all optional sub-TLVs introduced for the BGP Tunnel

	Encapsulation Attribute <xref target="RFC9012"/> being defined in this	Encapsulation Attribute <xref target="RFC9012" format="default"/> being defined in this
	section.</t>	section.</t>


	<t>Weight and Segment are sub-TLVs of the Segment-List sub-TLV	<t>Weight and Segment are sub-TLVs of the Segment-List sub-TLV
	mentioned above.</t>	mentioned above.</t>

		<t>An early draft version of this document included only the Binding SID
	<t>An early version of this document included only the Binding SID
	sub-TLV that could be used for both SR-MPLS and SRv6 Binding SIDs. The	sub-TLV that could be used for both SR-MPLS and SRv6 Binding SIDs. The
	SRv6 Binding SID TLV was introduced in later versions to support the	SRv6 Binding SID TLV was introduced in later versions to support the
	advertisement of additional SRv6 capabilities without affecting	advertisement of additional SRv6 capabilities without affecting
	backward compatibility for early implementations.</t>	backward compatibility for early implementations.</t>


	<t>The fault management and error handling in the encoding of the	<t>The fault management and error handling in the encoding of the

	sub-TLVs defined in this section are specified in <xref	sub-TLVs defined in this section are specified in <xref target="ERROR" f
	target="ERROR"/>. For the TLVs/sub-TLVs that are specified as single	ormat="default"/>. For the TLVs/sub-TLVs that are specified as single
	instance, only the first instance of that TLV/sub-TLV is used and the	instance, only the first instance of that TLV/sub-TLV is used: the
	other instances MUST be ignored and MUST NOT considered to be	other instances <bcp14>MUST</bcp14> be ignored and <bcp14>MUST NOT</bcp1
		4> considered to be
	malformed.</t>	malformed.</t>

		<t>None of the sub-TLVs defined in the following subsections have any
	<t>None of the sub-TLVs defined in the following sub-sections have any
	effect on the BGP best-path selection or propagation procedures. These	effect on the BGP best-path selection or propagation procedures. These
	sub-TLVs are not used by the BGP path selection process and are	sub-TLVs are not used by the BGP path selection process and are
	instead passed on to SRPM as SR Policy Candidate Path information for	instead passed on to SRPM as SR Policy Candidate Path information for

	further processing described in section 2 of <xref	further processing as described in <xref target="RFC9256" sectionFormat=
	target="RFC9256"/>.</t>	"of" section="2"/>.</t>

	<t>The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI	<t>The use of SR Policy Sub-TLVs is applicable only for the AFI/SAFI
	pairs of (1/73, 2/73). Future documents may extend their applicability	pairs of (1/73, 2/73). Future documents may extend their applicability
	to other AFI/SAFI.</t>	to other AFI/SAFI.</t>

		<section anchor="PREFTLV" numbered="true" toc="default">
	<section anchor="PREFTLV" title="Preference Sub-TLV">	<name>Preference Sub-TLV</name>
	<t>The Preference sub-TLV is used to carry the Preference of an SR	<t>The Preference sub-TLV is used to carry the Preference of an SR
	Policy candidate path. The contents of this sub-TLV are used by the	Policy candidate path. The contents of this sub-TLV are used by the

	SRPM as described in section 2.7 of <xref target="RFC9256"/>.</t>	SRPM as described in <xref target="RFC9256" sectionFormat="of" section
		="2.7"/>.</t>
	<t>The Preference sub-TLV is OPTIONAL and it MUST NOT appear more	<t>The Preference sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST N
		OT</bcp14> appear more
	than once in the SR Policy encoding.</t>	than once in the SR Policy encoding.</t>

		<t>The Preference sub-TLV has the following format: </t>


	<t>The Preference sub-TLV has following format: <figure	<figure>
	align="center">	<name>Preference Sub-TLV</name>
	<artwork align="left"><![CDATA[ 0 1	<artwork align="left" name="" type="" alt=""><![CDATA[
	2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Preference (4 octets) \|	\| Preference (4 octets) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 3: Preference sub-TLV	<t>Where:</t>
		<dl spacing="normal">


	where: ]]></artwork>	<dt>Type:</dt><dd>12</dd>
	</figure><list style="symbols">
	<t>Type: 12</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e., n ot
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	MUST be 6.</t>	<bcp14>MUST</bcp14> be 6.</dd>


	<t>Flags: 1 octet of flags. No flags are defined in this	<dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
	document. The Flags field MUST be set to zero on transmission	document. The Flags field <bcp14>MUST</bcp14> be set to zero on tr
	and MUST be ignored on receipt.</t>	ansmission
		and <bcp14>MUST</bcp14> be ignored on receipt.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	zero on transmission and MUST be ignored on receipt.</t>	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>


	<t>Preference: a 4-octet value indicating the Preference of the	<dt>Preference:</dt><dd>a 4-octet value indicating the Preference
	SR Policy Candidate Path as described in section 2.7 of <xref	of the
	target="RFC9256"/>.</t>	SR Policy Candidate Path as described in <xref target="RFC9256" se
	</list></t>	ctionFormat="of" section="2.7"/>.</dd>
	</section>


	<section anchor="BINDINGSIDTLV" title="Binding SID Sub-TLV">	</dl>
	<t>The Binding SID sub-TLV is used to signal the binding SID related
	information of the SR Policy candidate path. The contents of this
	sub-TLV are used by the SRPM as described in section 6 in <xref
	target="RFC9256"/>.</t>


	<t>The Binding SID sub-TLV is OPTIONAL and it MUST NOT appear more	</section>
		<section anchor="BINDINGSIDTLV" numbered="true" toc="default">
		<name>Binding SID Sub-TLV</name>
		<t>The Binding SID sub-TLV is used to signal the BSID-related
		information of the SR Policy candidate path. The contents of this
		sub-TLV are used by the SRPM as described in <xref target="RFC9256" se
		ctionFormat="of" section="6"/>.</t>
		<t>The Binding SID sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST
		NOT</bcp14> appear more
	than once in the SR Policy encoding.</t>	than once in the SR Policy encoding.</t>


	<t>When the Binding SID sub-TLV is used to signal an SRv6 SID, the	<t>When the Binding SID sub-TLV is used to signal an SRv6 SID, the

	selection of the corresponding SRv6 Endpoint Behavior <xref	selection of the corresponding SRv6 Endpoint Behavior <xref target="RF
	target="RFC8986"/> to be instantiated is determined by the headend	C8986" format="default"/> to be instantiated is determined by the headend
	node. It is RECOMMENDED that the SRv6 Binding SID sub-TLV, as	node. It is <bcp14>RECOMMENDED</bcp14> that the SRv6 Binding SID sub-T
	defined in Section 2.4.3, be used when signaling an SRv6 Binding SID	LV, as
		defined in <xref target="SRV6BINDINGSIDTLV" format="default"/>, be use
		d when signaling an SRv6 Binding SID
	for an SR Policy candidate path. The support for the use of this	for an SR Policy candidate path. The support for the use of this

	Binding SID sub-TLV for signaling of SRv6 Binding SID is retained	Binding SID sub-TLV for the signaling of an SRv6 Binding SID is retain ed
	primarily for backward compatibility with implementations that	primarily for backward compatibility with implementations that

	followed early versions of this document that had not defined the	followed early draft versions of this document that had not defined th e
	SRv6 Binding SID sub-TLV.</t>	SRv6 Binding SID sub-TLV.</t>

		<t>The Binding SID sub-TLV has the following format: </t>


	<t>The Binding SID sub-TLV has the following format: <figure	<figure>
	align="center">	<name>Binding SID Sub-TLV</name>
	<artwork align="left"><![CDATA[ 0 1	<artwork align="left" name="" type="" alt=""><![CDATA[
	2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Binding SID (variable, optional) \|	\| Binding SID (variable, optional) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
	Figure 4: Binding SID sub-TLV	</figure>
		<t>Where:</t>
	where: ]]></artwork>	<dl spacing="normal">
	</figure><list style="symbols">	<dt>Type:</dt><dd>13</dd>
	<t>Type: 13</t>	<dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
		not
	<t>Length: Specifies the length of the value field (i.e., not
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	MUST be one of: 18 when a SRv6 BSID is present, 6 when a SR-MPLS	<bcp14>MUST</bcp14> be 18 when a SRv6 BSID is present, 6 when an S
	BSID is present, or 2 when no BSID is present.</t>	R-MPLS
		BSID is present, or 2 when no BSID is present.</dd>
		<dt>Flags:</dt><dd><t>1 octet of flags. The following flags are de
		fined in
		the registry "SR Policy Binding SID Flags" as described in <xref t
		arget="IANABSIDFLAGS" format="default"/>:</t>


	<t>Flags: 1 octet of flags. The following flags are defined in	<figure>
	the registry "SR Policy Binding SID Flags" as described in <xref	<name>SR Policy Binding SID Flags</name>
	target="IANABSIDFLAGS"/>: <figure align="center">	<artwork align="left" name="" type="" alt=""><![CDATA[
	<artwork align="left"><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|S\|I\| \|	\|S\|I\| \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+


	Figure 5: SR Policy Binding SID Flags

	]]></artwork>	]]></artwork>

	</figure>where:<list>	</figure>
	<t>S-Flag: This flag encodes the "Specified-BSID-only"	<t>Where:</t>
	behavior. It is used by SRPM as described in section 6.2.3	<ul spacing="normal">
	in <xref target="RFC9256"/>.</t>


	<t>I-Flag: This flag encodes the "Drop Upon Invalid"	<li>The S-Flag encodes the "Specified-BSID-Only"
	behavior. It is used by SRPM as described in section 8.2 in	behavior. It is used by SRPM as described in <xref
	<xref target="RFC9256"/> to define a specific SR Policy	target="RFC9256" sectionFormat="of" section="6.2.3"/>.</li>
	forwarding behavior. The flag indicates that the SR Policy	<li>The I-Flag encodes the "Drop Upon Invalid"
	is to perform the "drop upon invalid" behavior when no valid	behavior. It is used by SRPM as described in <xref
	candidate path (CP) is available for this SR Policy. In this	target="RFC9256" sectionFormat="of" section="8.2"/> to
	situation, the CP with the highest preference amongst those	define a specific SR Policy forwarding behavior. The flag
	with the "drop upon invalid" config is made active to drop	indicates that the SR Policy is to perform the "drop upon
	traffic steered over the SR Policy.</t>	invalid" behavior when no valid candidate path (CP) is
		available for this SR Policy. In this situation, the CP with
		the highest preference amongst those with the "drop upon
		invalid" config is made active to drop traffic steered over
		the SR Policy.</li>


	<t>The unassigned bits in the Flag octet MUST be set to zero	<li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14>
	upon transmission and MUST be ignored upon receipt.</t>	be set to zero
	</list></t>	upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
		ipt.
		</li>
		</ul></dd>


	<t>RESERVED: 1 octet of reserved bits. MUST be set to zero on	<dt>RESERVED:</dt><dd>1 octet of reserved bits. <bcp14>MUST</bcp14
	transmission and MUST be ignored on receipt.</t>	> be set to zero on
		transmission and <bcp14>MUST</bcp14> be ignored on receipt.
		</dd>


	<t>Binding SID: If the length is 2, then no Binding SID is	<dt>Binding SID:</dt><dd><t>If the length is 2, then no Binding SI
	present. If the length is 6 then the Binding SID is encoded in 4	D is
		present. If the length is 6, then the Binding SID is encoded in 4
	octets using the format below. Traffic Class (TC), S, and TTL	octets using the format below. Traffic Class (TC), S, and TTL

	(Total of 12 bits) are RESERVED and MUST be set to zero and MUST	(Total of 12 bits) are RESERVED and <bcp14>MUST</bcp14> be set to
	be ignored. <figure>	zero and <bcp14>MUST</bcp14>
	<artwork><![CDATA[ 0 1	be ignored.</t>
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label \| TC \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Figure 6: Binding SID Label Encoding


		<figure>
		<name>Binding SID Label Encoding</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
		0 1 2 3
		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Label \| TC \|S\| TTL \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>The Label field is validated by the SRPM, but MUST	</figure>
	NOT contain the reserved MPLS label values (0-15). If the length	<t>The Label field is validated by the SRPM but <bcp14>MUST
	is 18 then the Binding SID contains a 16-octet SRv6 SID.</t>	NOT</bcp14> contain the reserved MPLS label values (0-15). If the
	</list></t>	length
		is 18, then the Binding SID contains a 16-octet SRv6 SID.</t>
		</dd>
		</dl>
	</section>	</section>

		<section anchor="SRV6BINDINGSIDTLV" numbered="true" toc="default">
	<section anchor="SRV6BINDINGSIDTLV" title="SRv6 Binding SID Sub-TLV">	<name>SRv6 Binding SID Sub-TLV</name>
	<t>The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding	<t>The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding
	SID related information of an SR Policy candidate path. It enables	SID related information of an SR Policy candidate path. It enables
	the specification of the SRv6 Endpoint Behavior <xref	the specification of the SRv6 Endpoint Behavior <xref

	target="RFC8986"/> to be instantiated on the headend node. The	target="RFC8986" format="default"/> to be instantiated on the
	contents of this sub-TLV are used by the SRPM as described in	headend node. The contents of this sub-TLV are used by the SRPM as
	section 6 in <xref target="RFC9256"/>.</t>	described in <xref target="RFC9256" sectionFormat="of"
		section="6"/>.</t>
	<t>The SRv6 Binding SID sub-TLV is OPTIONAL. More than one SRv6	<t>The SRv6 Binding SID sub-TLV is <bcp14>OPTIONAL</bcp14>. More than
	Binding SID sub-TLVs MAY be signaled in the same SR Policy encoding	one SRv6
		Binding SID sub-TLV <bcp14>MAY</bcp14> be signaled in the same SR Poli
		cy encoding
	to indicate one or more SRv6 SIDs, each with potentially different	to indicate one or more SRv6 SIDs, each with potentially different
	SRv6 Endpoint Behaviors to be instantiated.</t>	SRv6 Endpoint Behaviors to be instantiated.</t>

		<t>The SRv6 Binding SID sub-TLV has the following format:</t>


	<t>The SRv6 Binding SID sub-TLV has the following format: <figure	<figure>
	align="center">	<name>SRv6 Binding SID Sub-TLV</name>
	<artwork align="left"><![CDATA[ 0 1	<artwork align="left" name="" type="" alt=""><![CDATA[
	2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SRv6 Binding SID (16 octets) \|	\| SRv6 Binding SID (16 octets) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SRv6 Endpoint Behavior and SID Structure (optional) //	// SRv6 Endpoint Behavior and SID Structure (optional) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 7: SRv6 Binding SID sub-TLV	<t>Where:</t>
		<dl spacing="normal">


	where: ]]></artwork>	<dt>Type:</dt><dd>20</dd>
	</figure><list style="symbols">
	<t>Type: 20</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is	<bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Behavior and SID
	present else it MUST be 18.</t>	Structure is
		present; else, it <bcp14>MUST</bcp14> be 18.</dd>


	<t>Flags: 1 octet of flags. The following flags are defined in	<dt>Flags:</dt><dd><t>1 octet of flags. The following flags are de fined in
	the registry "SR Policy SRv6 Binding SID Flags" as described in	the registry "SR Policy SRv6 Binding SID Flags" as described in

	<xref target="IANASRV6BSIDFLAGS"/>: <figure align="center">	<xref target="IANASRV6BSIDFLAGS" format="default"/>:</t>
	<artwork align="left"><![CDATA[
		<figure>
		<name>SR Policy SRv6 Binding SID Flags</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|S\|I\|B\| \|	\|S\|I\|B\| \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+


	Figure 8: SR Policy SRv6 Binding SID Flags

	]]></artwork>	]]></artwork>

	</figure> where:<list>	</figure>
	<t>S-Flag: This flag encodes the "Specified-BSID-only"	<t>Where:</t>
	behavior. It is used by SRPM as described in section 6.2.3	<ul spacing="normal">
	in <xref target="RFC9256"/>.</t>	<li>The S-Flag encodes the "Specified-BSID-Only"
		behavior. It is used by SRPM as described
		in <xref target="RFC9256" sectionFormat="of" section="6.2.3"/>
		.</li>


	<t>I-Flag: This flag encodes the "Drop Upon Invalid"	<li>The I-Flag encodes the "Drop Upon Invalid"
	behavior. It is used by SRPM as described in section 8.2 in	behavior. It is used by SRPM as described in
	<xref target="RFC9256"/>.</t>	<xref target="RFC9256" sectionFormat="of" section="8.2"/>.</li
		>


	<t>B-Flag: This flag, when set, indicates the presence of	<li>The B-Flag, when set, indicates the presence of
	the SRv6 Endpoint Behavior and SID Structure encoding	the "SRv6 Endpoint Behavior & SID Structure" encoding
	specified in <xref target="BEHAVIORSTRUCT"/>.</t>	specified in <xref target="BEHAVIORSTRUCT" format="default"/>.
		</li>


	<t>The unassigned bits in the Flag octet MUST be set to zero	<li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14>
	upon transmission and MUST be ignored upon receipt.</t>	be set to zero
	</list></t>	upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
		ipt.</li>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	</ul></dd>
	zero on transmission and MUST be ignored on receipt.</t>


	<t>SRv6 Binding SID: Contains a 16-octet SRv6 SID. The value 0	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	MAY be used when the controller wants to indicate the desired	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>

		<dt>SRv6 Binding SID:</dt><dd>Contains a 16-octet SRv6 SID. The va
		lue 0
		<bcp14>MAY</bcp14> be used when the controller wants to indicate t
		he desired
	SRv6 Endpoint Behavior, SID Structure, or flags without	SRv6 Endpoint Behavior, SID Structure, or flags without

	specifying the BSID.</t>	specifying the BSID.</dd>


	<t>SRv6 Endpoint Behavior and SID Structure: Optional, as	<dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional, as
	defined in <xref target="BEHAVIORSTRUCT"/>. The SRv6 Endpoint	defined in <xref target="BEHAVIORSTRUCT" format="default"/>. The S
	Behavior and SID Structure MUST NOT be included when the SRv6	Rv6 Endpoint
	SID has not been included.</t>	Behavior and SID Structure <bcp14>MUST NOT</bcp14> be included whe
	</list></t>	n the SRv6
	</section>	SID has not been included.</dd>


	<section anchor="SLTLV" title="Segment List Sub-TLV ">	</dl>
		</section>
		<section anchor="SLTLV" numbered="true" toc="default">
		<name>Segment List Sub-TLV</name>
	<t>The Segment List sub-TLV encodes a single explicit path towards	<t>The Segment List sub-TLV encodes a single explicit path towards

	the endpoint as described in section 5.1 of <xref	the endpoint as described in <xref target="RFC9256"
	target="RFC9256"/>. The Segment List sub-TLV includes the elements	sectionFormat="of" section="5.1"/>. The Segment List sub-TLV
	of the paths (i.e., segments) as well as an optional Weight	includes the elements of the paths (i.e., segments) as well as an
	sub-TLV.</t>	optional Weight sub-TLV.</t>

	<t>The Segment List sub-TLV may exceed 255 bytes in length due to a	<t>The Segment List sub-TLV may exceed 255 bytes in length due to a
	large number of segments. A 2-octet length is thus required.	large number of segments. A 2-octet length is thus required.

	According to section 2 of <xref target="RFC9012"/>, the sub-TLV type	According to <xref target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV type
	defines the size of the length field. Therefore, for the Segment	defines the size of the length field. Therefore, for the Segment
	List sub-TLV, a code point of 128 or higher is used.</t>	List sub-TLV, a code point of 128 or higher is used.</t>

		<t>The Segment List sub-TLV is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY<
	<t>The Segment List sub-TLV is OPTIONAL and MAY appear multiple	/bcp14> appear multiple
	times in the SR Policy encoding. The ordering of Segment List	times in the SR Policy encoding. The ordering of Segment List
	sub-TLVs does not matter since each sub-TLV encodes a Segment	sub-TLVs does not matter since each sub-TLV encodes a Segment
	List.</t>	List.</t>


	<t>The Segment List sub-TLV contains zero or more Segment sub-TLVs	<t>The Segment List sub-TLV contains zero or more Segment sub-TLVs

	and MAY contain a Weight sub-TLV.</t>	and <bcp14>MAY</bcp14> contain a Weight sub-TLV.</t>
		<t>The Segment List sub-TLV has the following format: </t>


	<t>The Segment List sub-TLV has the following format: <figure	<figure>
	align="center">	<name>Segment List Sub-TLV</name>
	<artwork align="left"><![CDATA[ 0 1	<artwork align="left" name="" type="" alt=""><![CDATA[
	2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| RESERVED \|	\| Type \| Length \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// sub-TLVs //	// sub-TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 9: Segment List sub-TLV	<t>Where:</t>
		<dl spacing="normal">


	where:]]></artwork>	<dt>Type:</dt><dd>128</dd>
	</figure><list style="symbols">
	<t>Type: 128.</t>


	<t>Length: the total length (not including the Type and Length	<dt>Length:</dt><dd>The total length (not including the Type and L ength
	fields) of the sub-TLVs encoded within the Segment List sub-TLV	fields) of the sub-TLVs encoded within the Segment List sub-TLV

	in terms of octets.</t>	in terms of octets.</dd>

	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to
	zero on transmission and MUST be ignored on receipt.</t>


	<t>sub-TLVs currently defined: <list>	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	<t>An optional single Weight sub-TLV.</t>	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>


	<t>Zero or more Segment sub-TLVs.</t>	<dt>sub-TLVs currently defined: </dt><dd>
	</list></t>	<ul spacing="normal">
	</list></t>	<li>
		<t>An optional single Weight sub-TLV</t>
		</li>
		<li>
		<t>Zero or more Segment sub-TLVs</t>
		</li>
		</ul>
		</dd>
		</dl>

	<t>Validation of an explicit path encoded by the Segment List	<t>Validation of an explicit path encoded by the Segment List
	sub-TLV is beyond the scope of BGP and performed by the SRPM as	sub-TLV is beyond the scope of BGP and performed by the SRPM as

	described in section 5 of <xref target="RFC9256"/>.</t>	described in <xref target="RFC9256" sectionFormat="of" section="5"/>.<
		/t>
	<section anchor="WEIGHTTLV" title="Weight Sub-TLV">	<section anchor="WEIGHTTLV" numbered="true" toc="default">
		<name>Weight Sub-TLV</name>
	<t>The Weight sub-TLV specifies the weight associated with a given	<t>The Weight sub-TLV specifies the weight associated with a given
	segment list. The contents of this sub-TLV are used only by the	segment list. The contents of this sub-TLV are used only by the

	SRPM as described in section 2.11 of <xref target="RFC9256"/>.</t>	SRPM as described in <xref target="RFC9256" sectionFormat="of" secti
		on="2.11"/>.</t>
	<t>The Weight sub-TLV is OPTIONAL and it MUST NOT appear more than	<t>The Weight sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT
		</bcp14> appear more than
	once inside the Segment List sub-TLV.</t>	once inside the Segment List sub-TLV.</t>

		<t>The Weight sub-TLV has the following format: </t>


	<t>The Weight sub-TLV has the following format: <figure	<figure>
	align="center">	<name>Weight Sub-TLV</name>
	<artwork align="left"><![CDATA[ 0 1	<artwork align="left" name="" type="" alt=""><![CDATA[
	2 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Weight \|	\| Weight \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 10: Weight sub-TLV	<t>Where:</t>
		<dl spacing="normal">
	where:]]></artwork>
	</figure></t>


	<t><list style="symbols">	<dt>Type:</dt><dd>9</dd>
	<t>Type: 9.</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e ., not
	including Type and Length fields) in terms of octets. The	including Type and Length fields) in terms of octets. The

	value MUST be 6.</t>	value <bcp14>MUST</bcp14> be 6.</dd>


	<t>Flags: 1 octet of flags. No flags are defined in this	<dt>Flags:</dt><dd>1 octet of flags. No flags are defined in thi
	document. The Flags field MUST be set to zero on transmission	s
	and MUST be ignored on receipt.</t>	document. The Flags field <bcp14>MUST</bcp14> be set to zero on
		transmission
		and <bcp14>MUST</bcp14> be ignored on receipt.
		</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp1
	to zero on transmission and MUST be ignored on receipt.</t>	4>MUST</bcp14> be set
		to zero on transmission and <bcp14>MUST</bcp14> be ignored on re
		ceipt.</dd>


	<t>Weight: 4 octets an unsigned integer value indicating the	<!--[rfced] Please review the following for how "4 octets" connects to
	weight associated with a segment list as described in section	the rest of the sentence (perhaps text is missing as we generally
	2.11 of <xref target="RFC9256"/>. A weight value of zero is	see "octets of foo" in previous descriptions)?
	invalid.</t>
	</list></t>
	</section>


	<section anchor="SEGMENTTLV" title="Segment Sub-TLVs">	Original:

		Weight: 4 octets an unsigned integer value indicating the weight
		associated with a segment list...

		-->

		<dt>Weight:</dt><dd>4 octets an unsigned integer value indicatin
		g the
		weight associated with a segment list as described in
		<xref target="RFC9256" sectionFormat="of" section="2.11"/>. A we
		ight value of zero is
		invalid.</dd>

		</dl>
		</section>
		<section anchor="SEGMENTTLV" numbered="true" toc="default">
		<name>Segment Sub-TLVs</name>
	<t>A Segment sub-TLV describes a single segment in a segment list	<t>A Segment sub-TLV describes a single segment in a segment list
	(i.e., a single element of the explicit path). One or more Segment	(i.e., a single element of the explicit path). One or more Segment
	sub-TLVs constitute an explicit path of the SR Policy candidate	sub-TLVs constitute an explicit path of the SR Policy candidate
	path. The contents of these sub-TLVs are used only by the SRPM as	path. The contents of these sub-TLVs are used only by the SRPM as

	described in section 4 in <xref target="RFC9256"/>.</t>	described in <xref target="RFC9256" sectionFormat="of" section="4"/>
		.</t>
	<t>The Segment sub-TLVs are OPTIONAL and MAY appear multiple times	<t>The Segment sub-TLVs are <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</
		bcp14> appear multiple times
	in the Segment List sub-TLV.</t>	in the Segment List sub-TLV.</t>

		<t><xref target="RFC9256" sectionFormat="of" section="4"/> defines s
		everal Segment
		Types:</t>
		<dl>


	<t>Section 4 of <xref target="RFC9256"/> defines several Segment	<dt>Type A:</dt><dd>SR-MPLS Label</dd>
	Types:<figure align="center">	<dt>Type B:</dt><dd>SRv6 SID</dd>
	<artwork align="left"><![CDATA[Type A: SR-MPLS Label	<dt>Type C:</dt><dd>IPv4 Prefix with optional SR Algorithm</dd>
	Type B: SRv6 SID	<dt>Type D:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SR-MPLS</d
	Type C: IPv4 Prefix with optional SR Algorithm	d>
	Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS	<dt>Type E:</dt><dd>IPv4 Prefix with Local Interface ID</dd>
	Type E: IPv4 Prefix with Local Interface ID	<dt>Type F:</dt><dd>IPv4 Addresses for link endpoints as Local, Remote pair</dd>
	Type F: IPv4 Addresses for link endpoints as Local, Remote pair	<dt>Type G:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Re
	Type G: IPv6 Prefix and Interface ID for link endpoints as Local,	mote pair for SR-MPLS</dd>
	Remote pair for SR-MPLS	<dt>Type H:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for
	Type H: IPv6 Addresses for link endpoints as Local, Remote pair	SR-MPLS</dd>
	for SR-MPLS	<dt>Type I:</dt><dd>IPv6 Global Prefix with optional SR Algorithm for SRv6</dd>
	Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6	<dt>Type J:</dt><dd>IPv6 Prefix and Interface ID for link endpoints as Local, Re
	Type J: IPv6 Prefix and Interface ID for link endpoints as Local,	mote pair for SRv6</dd>
	Remote pair for SRv6	<dt>Type K:</dt><dd>IPv6 Addresses for link endpoints as Local, Remote pair for
	Type K: IPv6 Addresses for link endpoints as Local, Remote pair	SRv6</dd>
	for SRv6	</dl>

	]]></artwork>
	</figure></t>


	<t>The following sub-sections specify the sub-TLVs used for	<t>The following subsections specify the sub-TLVs used for
	Segment Types A and B. The other segment types are specified in	Segment Types A and B. The other segment types are specified in

	<xref target="I-D.ietf-idr-bgp-sr-segtypes-ext"/>. As specified in	<xref target="RFC9831" format="default"/>. As specified in
	section 5.1 of <xref target="RFC9256"/>, a mix of SR-MPLS and SRv6	<xref target="RFC9256" sectionFormat="of" section="5.1"/>, a mix of
		SR-MPLS and SRv6
	segments make the segment-list invalid.</t>	segments make the segment-list invalid.</t>

		<section anchor="TYPEA" numbered="true" toc="default">
	<section anchor="TYPEA" title="Segment Type A">	<name>Segment Type A</name>
	<t>The Type A Segment Sub-TLV encodes a single SR-MPLS SID. The	<t>The Type A Segment sub-TLV encodes a single SR-MPLS SID. The
	format is as follows and is used to encode MPLS Label fields as	format is as follows and is used to encode MPLS Label fields as

	specified in <xref target="RFC3032"/> <xref target="RFC5462"/>.:	specified in <xref target="RFC3032" format="default"/> and <xref t
	<figure align="center">	arget="RFC5462" format="default"/>:
	<artwork align="left"><![CDATA[ 0 1	</t>
	2 3
		<figure>
		<name>Type A Segment Sub-TLV</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label \| TC \|S\| TTL \|	\| Label \| TC \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 11: Type A Segment sub-TLV	<t>Where:</t>
		<dl spacing="normal">


	where:]]></artwork>	<dt>Type:</dt><dd>1</dd>
	</figure><list style="symbols">
	<t>Type: 1.</t>


	<t>Length: Specifies the length of the value field (i.e.,	<dt>Length:</dt><dd>Specifies the length of the value field (i .e.,
	not including Type and Length fields) in terms of octets.	not including Type and Length fields) in terms of octets.

	The value MUST be 6.</t>	The value <bcp14>MUST</bcp14> be 6.</dd>

	<t>Flags: 1 octet of flags as defined in <xref
	target="SEGMENTFLAGS"/>.</t>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be	<dt>Flags:</dt><dd>1 octet of flags as defined in <xref target
	set to zero on transmission and MUST be ignored on	="SEGMENTFLAGS" format="default"/>.</dd>
	receipt.</t>


	<t>Label: 20 bits of label value.</t>	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bc
		p14>MUST</bcp14> be
		set to zero on transmission and <bcp14>MUST</bcp14> be ignored
		on
		receipt.</dd>


	<t>TC: 3 bits of traffic class.</t>	<dt>Label:</dt><dd>20 bits of label value.</dd>
		<dt>TC:</dt><dd>3 bits of traffic class.</dd>


	<t>S: 1 bit of bottom-of-stack.</t>	<dt>S:</dt><dd>1 bit of bottom-of-stack.</dd>


	<t>TTL: 1 octet of TTL.</t>	<dt>TTL:</dt><dd>1 octet of TTL.</dd>
	</list></t>


	<t>The following applies to the Type-1 Segment sub-TLV:<list	</dl>
	style="symbols">	<t>The following applies to the Type-1 Segment sub-TLV:</t>
	<t>The S bit MUST be zero upon transmission and MUST be	<ul spacing="normal">
		<li>
		<t>The S bit <bcp14>MUST</bcp14> be zero upon transmission and
		<bcp14>MUST</bcp14> be
	ignored upon reception.</t>	ignored upon reception.</t>

		</li>
		<li>
	<t>If the originator wants the receiver to choose the TC	<t>If the originator wants the receiver to choose the TC
	value, it sets the TC field to zero.</t>	value, it sets the TC field to zero.</t>

		</li>
		<li>
	<t>If the originator wants the receiver to choose the TTL	<t>If the originator wants the receiver to choose the TTL
	value, it sets the TTL field to 255.</t>	value, it sets the TTL field to 255.</t>

		</li>
		<li>
	<t>If the originator wants to recommend a value for these	<t>If the originator wants to recommend a value for these
	fields, it puts those values in the TC and/or TTL	fields, it puts those values in the TC and/or TTL
	fields.</t>	fields.</t>

		</li>
	<t>The receiver MAY override the originator's values for	<li>
		<t>The receiver <bcp14>MAY</bcp14> override the originator's v
		alues for
	these fields. This would be determined by local policy at	these fields. This would be determined by local policy at
	the receiver. One possible policy would be to override the	the receiver. One possible policy would be to override the
	fields only if the fields have the default values specified	fields only if the fields have the default values specified
	above.</t>	above.</t>

	</list></t>	</li>
		</ul>
	</section>	</section>

		<section anchor="TYPEB" numbered="true" toc="default">
	<section anchor="TYPEB" title="Segment Type B">	<name>Segment Type B</name>
	<t>The Type B Segment Sub-TLV encodes a single SRv6 SID. The	<t>The Type B Segment Sub-TLV encodes a single SRv6 SID. The

	format is as follows: <figure align="center">	format is as follows: </t>
	<artwork align="left"><![CDATA[ 0 1
	2 3	<figure>
		<name>Type B Segment Sub-TLV</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SRv6 SID (16 octets) //	// SRv6 SID (16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SRv6 Endpoint Behavior and SID Structure //	// SRv6 Endpoint Behavior and SID Structure //
	// (optional, 8 octets) //	// (optional, 8 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 12: Type B Segment sub-TLV	<t>Where:</t>
		<dl spacing="normal">


	where:]]></artwork>	<dt>Type:</dt><dd>13</dd>
	</figure><list style="symbols">
	<t>Type: 13.</t>


	<t>Length: Specifies the length of the value field (i.e.,	<dt>Length:</dt><dd>Specifies the length of the value field (i .e.,
	not including Type and Length fields) in terms of octets.	not including Type and Length fields) in terms of octets.

	The value MUST be 26 when the SRv6 Endpoint Behavior and SID	The value <bcp14>MUST</bcp14> be 26 when the SRv6 Endpoint Beh
	Structure is present else it MUST be 18.</t>	avior and SID
		Structure is present; else, it <bcp14>MUST</bcp14> be 18.
		</dd>


	<t>Flags: 1 octet of flags as defined in <xref	<dt>Flags:</dt><dd>1 octet of flags as defined in <xref target
	target="SEGMENTFLAGS"/>.</t>	="SEGMENTFLAGS" format="default"/>.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bc
	set to zero on transmission and MUST be ignored on	p14>MUST</bcp14> be
	receipt.</t>	set to zero on transmission and <bcp14>MUST</bcp14> be ignored
		on
		receipt.</dd>


	<t>SRv6 SID: 16 octets of IPv6 address.</t>	<dt>SRv6 SID:</dt><dd>16 octets of IPv6 address.</dd>


	<t>SRv6 Endpoint Behavior and SID Structure: Optional, as	<dt>SRv6 Endpoint Behavior and SID Structure:</dt><dd>Optional
	defined in <xref target="BEHAVIORSTRUCT"/>. The SRv6	, as
	Endpoint Behavior and SID Structure MUST NOT be included	defined in <xref target="BEHAVIORSTRUCT" format="default"/>. T
	when the SRv6 SID has not been included.</t>	he SRv6
	</list></t>	Endpoint Behavior and SID Structure <bcp14>MUST NOT</bcp14> be
		included
		when the SRv6 SID has not been included.</dd>


		</dl>
	<t>The Sub-TLV code point 2 defined for the advertisement of	<t>The Sub-TLV code point 2 defined for the advertisement of

	Segment Type B in the earlier versions of this document has been	Segment Type B in the earlier draft versions of this document has been
	deprecated to avoid backward compatibility issues.</t>	deprecated to avoid backward compatibility issues.</t>
	</section>	</section>

		<section anchor="SEGMENTFLAGS" numbered="true" toc="default">
	<section anchor="SEGMENTFLAGS" title="SR Policy Segment Flags">	<name>SR Policy Segment Flags</name>
	<t>The Segment Types sub-TLVs described above may contain the	<t>The Segment Types sub-TLVs described above may contain the
	following SR Policy Segment Flags in their "Flags" field. Also	following SR Policy Segment Flags in their "Flags" field. Also

	refer to <xref target="IANASIDFLAGS"/>: <figure align="center">	refer to <xref target="IANASIDFLAGS" format="default"/>: </t>
	<artwork align="left"><![CDATA[
		<figure>
		<name>SR Policy Segment Flags</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|V\| \|B\| \|	\|V\| \|B\| \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>
		<t>Where:</t>
		<ul spacing="normal">


	Figure 22: SR Policy Segment Flags	<li> When the V-Flag is set, it is used by SRPM for "SID
		verification" as described in <xref target="RFC9256" sectionFo
		rmat="of" section="5.1"/>.</li>


	]]></artwork>	<li>When the B-Flag is set, it indicates the presence of
	</figure> where:<list>	the "SRv6 Endpoint Behavior & SID Structure" encoding
	<t>V-Flag: This flag, when set, is used by SRPM for "SID	specified in <xref target="BEHAVIORSTRUCT" format="default"/>.
	verification" as described in Section 5.1 of <xref	</li>
	target="RFC9256"/>.</t>


	<t>B-Flag: This flag, when set, indicates the presence of	<li>The unassigned bits in the Flag octet <bcp14>MUST</bcp14>
	the SRv6 Endpoint Behavior and SID Structure encoding	be set to zero
	specified in <xref target="BEHAVIORSTRUCT"/>.</t>	upon transmission and <bcp14>MUST</bcp14> be ignored upon rece
		ipt.</li>


	<t>The unassigned bits in the Flag octet MUST be set to zero	</ul>
	upon transmission and MUST be ignored upon receipt.</t>
	</list></t>


	<t>The following applies to the Segment Flags:<list	<t>The following applies to the Segment Flags:</t>
	style="symbols">
	<t>V-Flag applies to all Segment Types.</t>


	<t>B-Flag applies to Segment Type B. If B-Flag appears with	<ul spacing="normal">
	Segment Type A it MUST be ignored.</t>	<li>
	</list></t>	V-Flag applies to all Segment Types.
		</li>
		<li>
		B-Flag applies to Segment Type B. If B-Flag appears with
		Segment Type A, it <bcp14>MUST</bcp14> be ignored.
		</li>
		</ul>
	</section>	</section>

		<section anchor="BEHAVIORSTRUCT" numbered="true" toc="default">
		<name>SRv6 SID Endpoint Behavior and Structure</name>
		<t>The Segment Types sub-TLVs described above <bcp14>MAY</bcp14> c
		ontain the
		SRv6 Endpoint Behavior and SID Structure <xref target="RFC8986" fo
		rmat="default"/> encoding as described below: </t>


	<section anchor="BEHAVIORSTRUCT"	<figure>
	title="SRv6 SID Endpoint Behavior and Structure">	<name>SRv6 SID Endpoint Behavior and Structure</name>
	<t>The Segment Types sub-TLVs described above MAY contain the	<artwork align="left" name="" type="" alt=""><![CDATA[
	SRv6 Endpoint Behavior and SID Structure <xref	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	target="RFC8986"/> encoding as described below: <figure
	align="center">
	<artwork align="left"><![CDATA[+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Endpoint Behavior \| Reserved \|	\| Endpoint Behavior \| Reserved \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| LB Length \| LN Length \| Fun. Length \| Arg. Length \|	\| LB Length \| LN Length \| Fun. Length \| Arg. Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>
		<t>Where:</t>
		<dl spacing="normal">


	Figure 23: SRv6 SID Endpoint Behavior and Structure	<dt>Endpoint Behavior:</dt><dd>2 octets. It carries the SRv6 E
		ndpoint
		Behavior code point for this SRv6 SID as defined in <xref
		target="RFC8986" sectionFormat="of" section="10.2"/>. When
		set with the value 0xFFFF (i.e., Opaque), the choice of SRv6
		Endpoint Behavior is left to the headend.</dd>


	]]></artwork>	<dt>Reserved:</dt><dd>2 octets of reserved bits. This field <b
	</figure> where:<list>	cp14>MUST</bcp14> be
	<t>Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint	set to zero on transmission and <bcp14>MUST</bcp14> be ignored
	Behavior code point for this SRv6 SID as defined in section	on
	10.2 of <xref target="RFC8986"/>. When set with the value	receipt.</dd>
	0xFFFF (i.e., Opaque), the choice of SRv6 Endpoint Behavior
	is left to the headend.</t>


	<t>Reserved: 2 octets of reserved bits. This field MUST be	<dt>Locator Block Length:</dt><dd>1 octet. SRv6 SID Locator Bl
	set to zero on transmission and MUST be ignored on	ock
	receipt.</t>	length in bits.</dd>


	<t>Locator Block Length: 1 octet. SRv6 SID Locator Block	<dt>Locator Node Length:</dt><dd>1 octet. SRv6 SID Locator Nod
	length in bits.</t>	e
		length in bits.</dd>


	<t>Locator Node Length: 1 octet. SRv6 SID Locator Node	<dt>Function Length:</dt><dd>1 octet. SRv6 SID Function length
	length in bits.</t>	in
		bits.</dd>


	<t>Function Length: 1 octet. SRv6 SID Function length in	<dt>Argument Length:</dt><dd>1 octet. SRv6 SID Arguments lengt
	bits.</t>	h in
		bits.</dd>


	<t>Argument Length: 1 octet. SRv6 SID Arguments length in	</dl>
	bits.</t>
	</list></t>

	<t>The total of the locator block, locator node, function, and	<t>The total of the locator block, locator node, function, and

	argument lengths MUST be less than or equal to 128.</t>	argument lengths <bcp14>MUST</bcp14> be less than or equal to 128. </t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="ENLPTLV" numbered="true" toc="default">
	<section anchor="ENLPTLV" title="Explicit NULL Label Policy Sub-TLV">	<name>Explicit NULL Label Policy Sub-TLV</name>
	<t>To steer an unlabeled IP packet into an SR policy for the MPLS	<t>To steer an unlabeled IP packet into an SR policy for the MPLS
	data plane, it is necessary to push a label stack of one or more	data plane, it is necessary to push a label stack of one or more
	labels on that packet.</t>	labels on that packet.</t>


	<t>The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate	<t>The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate

	whether an Explicit NULL Label <xref target="RFC3032"/> must be	whether an Explicit NULL Label <xref target="RFC3032" format="default" /> must be
	pushed on an unlabeled IP packet before any other labels.</t>	pushed on an unlabeled IP packet before any other labels.</t>


	<t>If an ENLP Sub-TLV is not present, the decision of whether to	<t>If an ENLP Sub-TLV is not present, the decision of whether to
	push an Explicit NULL label on a given packet is a matter of local	push an Explicit NULL label on a given packet is a matter of local
	configuration.</t>	configuration.</t>

		<t>The ENLP sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT</bc
	<t>The ENLP sub-TLV is OPTIONAL and it MUST NOT appear more than	p14> appear more than
	once in the SR Policy encoding.</t>	once in the SR Policy encoding.</t>


	<t>The contents of this sub-TLV are used by the SRPM as described in	<t>The contents of this sub-TLV are used by the SRPM as described in

	section 4.1 of <xref target="RFC9256"/>.</t>	<xref target="RFC9256" sectionFormat="of" section="4.1"/>.</t>


	<figure align="center">	<figure>
	<artwork><![CDATA[0 1 2	<name>ELNP Sub-TLV</name>
	3	<artwork name="" type="" align="left" alt=""><![CDATA[
		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| ENLP \|	\| ENLP \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+


	Figure 24: ELNP sub-TLV

	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>Where:</t>
		<dl spacing="normal">


	<t>Where:<list>	<dt>Type:</dt><dd>14</dd>
	<t>Type: 14.</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	MUST be 3.</t>	<bcp14>MUST</bcp14> be 3.</dd>


	<t>Flags: 1 octet of flags. No flags are defined in this	<dt>Flags:</dt><dd>1 octet of flags. No flags are defined in this
	document. The Flags field MUST be set to zero on transmission	document. The Flags field <bcp14>MUST</bcp14> be set to zero on tr
	and MUST be ignored on receipt.</t>	ansmission
		and <bcp14>MUST</bcp14> be ignored on receipt.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	zero on transmission and MUST be ignored on receipt.</t>	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>


	<t>ENLP (Explicit NULL Label Policy): Indicates whether Explicit	<dt>ENLP (Explicit NULL Label Policy):</dt><dd><t>Indicates whethe r Explicit
	NULL labels are to be pushed on unlabeled IP packets that are	NULL labels are to be pushed on unlabeled IP packets that are
	being steered into a given SR policy. The following values have	being steered into a given SR policy. The following values have

	been currently defined for this field:<list>	been currently defined for this field:</t>
	<t>1: Push an IPv4 Explicit NULL label on an unlabeled IPv4
	packet, but do not push an IPv6 Explicit NULL label on an
	unlabeled IPv6 packet.</t>


	<t>2: Push an IPv6 Explicit NULL label on an unlabeled IPv6	<dl spacing="normal" indent="6">
	packet, but do not push an IPv4 Explicit NULL label on an
	unlabeled IPv4 packet.</t>


	<t>3: Push an IPv4 Explicit NULL label on an unlabeled IPv4	<dt>1:</dt><dd>Push an IPv4 Explicit NULL label on an unlabele
	packet, and push an IPv6 Explicit NULL label on an unlabeled	d IPv4
	IPv6 packet.</t>	packet but do not push an IPv6 Explicit NULL label on an
		unlabeled IPv6 packet.</dd>


	<t>4: Do not push an Explicit NULL label.</t>	<dt>2:</dt><dd>Push an IPv6 Explicit NULL label on an unlabele
	</list>This field can have one of the values as specified in	d IPv6
	<xref target="IANAENLP"/>. The ENLP unassigned values may be	packet but do not push an IPv4 Explicit NULL label on an
	used for future extensions. Implementations adhering to this	unlabeled IPv4 packet.</dd>
	document MUST ignore the ENLP Sub-TLV with unrecognized values
	(viz. other than 1 through 4). The behavior signaled in this
	Sub-TLV MAY be overridden by local configuration by the network
	operator based on their deployment requirements. The section 4.1
	of <xref target="RFC9256"/> describes the behavior on the
	headend for the handling of the explicit null label.</t>
	</list></t>
	</section>


	<section anchor="POLICYPRIORITY" title="Policy Priority Sub-TLV">	<dt>3:</dt><dd>Push an IPv4 Explicit NULL label on an unlabele
	<t>An operator MAY set the Policy Priority sub-TLV to indicate the	d IPv4
	order in which the SR policies are re-computed upon topological	packet and push an IPv6 Explicit NULL label on an unlabeled
	change. The contents of this sub-TLV are used by the SRPM as	IPv6 packet.</dd>
	described in section 2.12 of <xref target="RFC9256"/>.</t>


	<t>The Priority sub-TLV is OPTIONAL and it MUST NOT appear more than	<dt>4:</dt><dd>Do not push an Explicit NULL label.</dd></dl>
	once in the SR Policy encoding.</t>


	<t>The Priority sub-TLV has following format:</t>	<t>This field can have one of the values as specified in <xref
		target="IANAENLP" format="default"/>. The ENLP unassigned values
		may be used for future extensions. Implementations adhering to
		this document <bcp14>MUST</bcp14> ignore the ENLP Sub-TLV with
		unrecognized values (viz. other than 1 through 4). The behavior
		signaled in this Sub-TLV <bcp14>MAY</bcp14> be overridden by
		local configuration by the network operator based on their
		deployment requirements. <xref target="RFC9256"
		sectionFormat="of" section="4.1"/> describes the behavior on the
		headend for the handling of the explicit null label.</t></dd>


	<figure align="center">	</dl>
	<artwork><![CDATA[0 1 2	</section>
	3	<section anchor="POLICYPRIORITY" numbered="true" toc="default">
		<name>Policy Priority Sub-TLV</name>
		<t>An operator <bcp14>MAY</bcp14> set the Policy Priority sub-TLV to i
		ndicate the
		order in which the SR policies are recomputed upon topological
		change. The contents of this sub-TLV are used by the SRPM as
		described in <xref target="RFC9256" sectionFormat="of" section="2.12"
		/>.</t>
		<t>The Priority sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST NOT
		</bcp14> appear more than
		once in the SR Policy encoding.</t>
		<t>The Priority sub-TLV has the following format:</t>

		<figure>
		<name>Priority Sub-TLV</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Priority \| RESERVED \|	\| Type \| Length \| Priority \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Figure 25: Priority sub-TLV

	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>Where:</t>
		<dl spacing="normal">


	<t>Where:<list>	<dt>Type:</dt><dd>15</dd>
	<t>Type: 15</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e.,
	including Type and Length fields) in terms of octets.The value	not
	MUST be 2.</t>	including Type and Length fields) in terms of octets. The value
		<bcp14>MUST</bcp14> be 2.</dd>


	<t>Priority: a 1-octet value indicating the priority as	<dt>Priority:</dt><dd>A 1-octet value indicating the priority as
	specified in section 2.12 of <xref target="RFC9256"/>.</t>	specified in <xref target="RFC9256" sectionFormat="of" section="2.
		12"/>.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	zero on transmission and MUST be ignored on receipt.</t>	MUST</bcp14> be set to
	</list></t>	zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
	</section>	.</dd>


	<section anchor="POLICYCPNAME"	</dl>
	title="Policy Candidate Path Name Sub-TLV">	</section>
	<t>An operator MAY set the Policy Candidate Path Name sub-TLV to	<section anchor="POLICYCPNAME" numbered="true" toc="default">
		<name>Policy Candidate Path Name Sub-TLV</name>
		<t>An operator <bcp14>MAY</bcp14> set the Policy Candidate Path Name s
		ub-TLV to
	attach a symbolic name to the SR Policy candidate path.</t>	attach a symbolic name to the SR Policy candidate path.</t>

		<t>Usage of the Policy Candidate Path Name sub-TLV is described in
	<t>Usage of Policy Candidate Path Name sub-TLV is described in	<xref target="RFC9256" sectionFormat="of" section="2.6"/>.</t>
	section 2.6 of <xref target="RFC9256"/>.</t>

	<t>The Policy Candidate Path Name sub-TLV may exceed 255 bytes in	<t>The Policy Candidate Path Name sub-TLV may exceed 255 bytes in
	length due to a long name. A 2-octet length is thus required.	length due to a long name. A 2-octet length is thus required.

	According to section 2 of <xref target="RFC9012"/>, the sub-TLV type	According to <xref target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV type
	defines the size of the length field. Therefore, for the Policy	defines the size of the length field. Therefore, for the Policy

	Candidate Path Name sub-TLV a code point of 128 or higher is	Candidate Path Name sub-TLV, a code point of 128 or higher is
	used.</t>	used.</t>

		<t>It is <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name
	<t>It is RECOMMENDED that the size of the symbolic name for the	for the
	candidate path is limited to 255 bytes. Implementations MAY choose	candidate path be limited to 255 bytes. Implementations <bcp14>MAY</bc
		p14> choose
	to truncate long names to 255 bytes when signaling via BGP.</t>	to truncate long names to 255 bytes when signaling via BGP.</t>

		<t>The Policy Candidate Path Name sub-TLV is <bcp14>OPTIONAL</bcp14>;
		it <bcp14>MUST
		NOT</bcp14> appear more than once in the SR Policy encoding.</t>
		<t>The Policy Candidate Path Name sub-TLV has the following format:</t
		>


	<t>The Policy Candidate Path Name sub-TLV is OPTIONAL and it MUST	<figure>
	NOT appear more than once in the SR Policy encoding.</t>	<name>Policy Candidate Path Name Sub-TLV</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	<t>The Policy Candidate Path Name sub-TLV has following format:</t>	0 1 2 3

	<figure align="center">
	<artwork><![CDATA[0 1 2
	3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| RESERVED \|	\| Type \| Length \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Policy Candidate Path Name //	// Policy Candidate Path Name //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Figure 26: Policy Candidate Path Name sub-TLV

	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>Where:</t>
		<dl spacing="normal">


	<t>Where:<list>	<dt>Type:</dt><dd>129</dd>
	<t>Type: 129.</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	is variable.</t>	is variable.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	zero on transmission and MUST be ignored on receipt.</t>	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>


	<t>Policy Candidate Path Name: Symbolic name for the SR Policy	<dt>Policy Candidate Path Name:</dt><dd>Symbolic name for the SR P olicy
	candidate path without a NULL terminator with encoding as	candidate path without a NULL terminator with encoding as

	specified in section 2.6 of <xref target="RFC9256"/>.</t>	specified in <xref target="RFC9256" sectionFormat="of" section="2.
	</list></t>	6"/>.</dd>
	</section>


	<section anchor="POLICYNAME" title="Policy Name Sub-TLV">	</dl>
	<t>An operator MAY set the Policy Name sub-TLV to associate a	</section>
		<section anchor="POLICYNAME" numbered="true" toc="default">
		<name>Policy Name Sub-TLV</name>
		<t>An operator <bcp14>MAY</bcp14> set the Policy Name sub-TLV to assoc
		iate a
	symbolic name with the SR Policy for which the candidate path is	symbolic name with the SR Policy for which the candidate path is
	being advertised via the SR Policy NLRI.</t>	being advertised via the SR Policy NLRI.</t>

		<t>Usage of the Policy Name sub-TLV is described in <xref target="RFC9
	<t>Usage of Policy Name sub-TLV is described in section 2.1 of <xref	256" sectionFormat="of" section="2.1"/>.</t>
	target="RFC9256"/>.</t>

	<t>The Policy Name sub-TLV may exceed 255 bytes in length due to a	<t>The Policy Name sub-TLV may exceed 255 bytes in length due to a
	long policy name. A 2-octet length is thus required. According to	long policy name. A 2-octet length is thus required. According to

	section 2 of <xref target="RFC9012"/>, the sub-TLV type defines the	<xref target="RFC9012" sectionFormat="of" section="2"/>, the sub-TLV
	size of the length field. Therefore, for the Policy Name sub-TLV a	type defines the size of the length field. Therefore, for the Policy
	code point of 128 or higher is used.</t>	Name sub-TLV, a code point of 128 or higher is used.</t>
		<t>It is <bcp14>RECOMMENDED</bcp14> that the size of the symbolic name
	<t>It is RECOMMENDED that the size of the symbolic name for the SR	for the SR
	Policy is limited to 255 bytes. Implementations MAY choose to	Policy be limited to 255 bytes. Implementations <bcp14>MAY</bcp14> cho
		ose to
	truncate long names to 255 bytes when signaling via BGP.</t>	truncate long names to 255 bytes when signaling via BGP.</t>

		<t>The Policy Name sub-TLV is <bcp14>OPTIONAL</bcp14>; it <bcp14>MUST
	<t>The Policy Name sub-TLV is OPTIONAL and it MUST NOT appear more	NOT</bcp14> appear more
	than once in the SR Policy encoding.</t>	than once in the SR Policy encoding.</t>

		<t>The Policy Name sub-TLV has the following format:</t>


	<t>The Policy Name sub-TLV has following format:</t>	<figure>
		<name>Policy Name Sub-TLV</name>
	<figure align="center">	<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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| RESERVED \|	\| Type \| Length \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Policy Name //	// Policy Name //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Figure 27: Policy Name sub-TLV

	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>Where:</t>
		<dl spacing="normal">


	<t>Where:<list>	<dt>Type:</dt><dd>130</dd>
	<t>Type: 130</t>


	<t>Length: Specifies the length of the value field (i.e., not	<dt>Length:</dt><dd>Specifies the length of the value field (i.e., not
	including Type and Length fields) in terms of octets. The value	including Type and Length fields) in terms of octets. The value

	is variable.</t>	is variable.</dd>


	<t>RESERVED: 1 octet of reserved bits. This field MUST be set to	<dt>RESERVED:</dt><dd>1 octet of reserved bits. This field <bcp14>
	zero on transmission and MUST be ignored on receipt.</t>	MUST</bcp14> be set to
		zero on transmission and <bcp14>MUST</bcp14> be ignored on receipt
		.</dd>

		<dt>Policy Name:</dt><dd>Symbolic name for the SR Policy without a
		NULL
		terminator with encoding as specified in <xref target="RFC9256" se
		ctionFormat="of" section="2.1"/>.</dd>

		</dl>


	<t>Policy Name: Symbolic name for the SR Policy without a NULL
	terminator with encoding as specified in section 2.1 of <xref
	target="RFC9256"/>.</t>
	</list></t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="EXTCOLOR" numbered="true" toc="default">
	<section anchor="EXTCOLOR" title="Color Extended Community">	<name>Color Extended Community</name>
	<t>The Color Extended Community <xref target="RFC9012"/> is used to	<t>The Color Extended Community <xref target="RFC9012" format="default"/>
		is used to
	steer traffic corresponding to BGP routes into an SR Policy with	steer traffic corresponding to BGP routes into an SR Policy with

	matching color value. The Color Extended Community MAY be carried in any	matching color value. The Color Extended Community <bcp14>MAY</bcp14> be c arried in any
	BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6	BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
	Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128	Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128
	(VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70	(VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70
	(Ethernet VPN, usually known as EVPN). Use of the Color Extended	(Ethernet VPN, usually known as EVPN). Use of the Color Extended
	Community in BGP UPDATE messages of other AFI/SAFIs is not covered by	Community in BGP UPDATE messages of other AFI/SAFIs is not covered by

	<xref target="RFC9012"/> and is hence outside the scope of this document	<xref target="RFC9012" format="default"/>; hence, it is outside the scope of this document
	as well.</t>	as well.</t>


	<t>Two bits from the Flags field of the Color Extended Community are	<t>Two bits from the Flags field of the Color Extended Community are
	used as follows to support the requirements of Color-Only steering as	used as follows to support the requirements of Color-Only steering as

	specified in Section 8.8 of <xref target="RFC9256"/>: <figure	specified in <xref target="RFC9256" sectionFormat="of" section="8.8"/>: </
	align="center">	t>
	<artwork><![CDATA[ 1
		<figure>
		<name>Color Extended Community Flags</name>
		<artwork name="" type="" align="left" alt=""><![CDATA[
		1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|C O\| Unassigned \|	\|C O\| Unassigned \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		]]></artwork>
		</figure>


	Figure 28: Color Extended Community Flags	<t>The C and O bits together form the Color-Only Type field, which
		indicates the various matching criteria between the BGP NH and the SR Poli
		cy
		endpoint in addition to the matching of the color value. The following typ
		es
		are defined:</t>
		<dl spacing="normal">


	]]></artwork>	<dt>Type 0 (bits 00):</dt><dd>Specific Endpoint Match. Request a match
	</figure>The CO bits together form the Color-Only Type field which	for the
	indicates the various matching criteria between BGP NH and SR Policy	endpoint that is the BGP NH.</dd>
	endpoint in addition to the matching of the color value. Following types
	are defined:<list style="symbols">
	<t>Type 0 (bits 00): Specific Endpoint Match: Request match for the
	endpoint that is the BGP NH</t>


	<t>Type 1 (bits 01): Specific or Null Endpoint Match: Request match	<dt>Type 1 (bits 01):</dt><dd>Specific or Null Endpoint Match. Request a match
	for either the endpoint that is the BGP NH or a null endpoint (e.g.,	for either the endpoint that is the BGP NH or a null endpoint (e.g.,

	like a default gateway)</t>	a default gateway).</dd>


	<t>Type 2 (bits 10): Specific, Null, or Any Endpoint Match: Request	<dt>Type 2 (bits 10):</dt><dd>Specific, Null, or Any Endpoint Match. R
	match for either the endpoint that is the BGP NH or with a null or	equest
	any endpoint</t>	a match for either the endpoint that is the BGP NH or a null or
		any endpoint.</dd>


	<t>Type 3 (bits 11): reserved for future use and SHOULD NOT be used.	<dt>Type 3 (bits 11):</dt><dd>Reserved for future use and <bcp14>SHOUL
	Upon reception, an implementation MUST treat it like Type 0.</t>	D NOT</bcp14> be used.
	</list></t>	Upon reception, an implementation <bcp14>MUST</bcp14> treat it like Ty
		pe 0.</dd>


		</dl>
	<t>The details of the SR Policy steering mechanisms based on these	<t>The details of the SR Policy steering mechanisms based on these

	Color-Only types are specified in section 8.8 of <xref	Color-Only types are specified in <xref target="RFC9256" sectionFormat="of
	target="RFC9256"/>.</t>	" section="8.8"/>.</t>
		<t>One or more Color Extended Communities <bcp14>MAY</bcp14> be
	<t>One or more Color Extended Communities MAY be associated with a BGP	associated with a BGP route update. Sections <xref target="RFC9256"
	route update. Sections 8.4.1, 8.5.1, and 8.8.2 of <xref	sectionFormat="bare" section="8.4.1"/>, <xref target="RFC9256"
	target="RFC9256"/> specify the steering behaviors over SR Policies when	sectionFormat="bare" section="8.5.1"/>, and <xref target="RFC9256"
		sectionFormat="bare" section="8.8.2"/> of <xref target="RFC9256"
		format="default"/> specify the steering behaviors over SR Policies when
	multiple Color Extended Communities are associated with a BGP route.</t>	multiple Color Extended Communities are associated with a BGP route.</t>
	</section>	</section>

		<section anchor="OPERATIONS" numbered="true" toc="default">
	<section anchor="OPERATIONS" title="SR Policy Operations">	<name>SR Policy Operations</name>
	<t>As mentioned in <xref target="INTRO"/>, BGP is not the actual	<t>As mentioned in <xref target="INTRO" format="default"/>, BGP is not the
		actual
	consumer of an SR Policy NLRI. BGP is in charge of the origination and	consumer of an SR Policy NLRI. BGP is in charge of the origination and

	propagation of the SR Policy NLRI but its installation and use are	propagation of the SR Policy NLRI, but its installation and use are
	outside the scope of BGP. The details of SR Policy installation and use	outside the scope of BGP. The details of SR Policy installation and use

	are specified in <xref target="RFC9256"/>.</t>	are specified in <xref target="RFC9256" format="default"/>.</t>
		<section anchor="CONFIG" numbered="true" toc="default">
	<section anchor="CONFIG" title="Advertisement of SR Policies">	<name>Advertisement of SR Policies</name>
	<t>Typically, but not limited to, an SR Policy is computed by a	<t>Typically, but not limited to, an SR Policy is computed by a

	controller or a path computation engine (PCE) and originated by a BGP	controller or a Path Computation Engine (PCE) and originated by a BGP
	speaker on its behalf.</t>	speaker on its behalf.</t>


	<t>Multiple SR Policy NLRIs may be present with the same <color,	<t>Multiple SR Policy NLRIs may be present with the same <color,
	endpoint> tuple but with different distinguishers when these SR	endpoint> tuple but with different distinguishers when these SR
	policies are intended for different headends.</t>	policies are intended for different headends.</t>


	<t>The distinguisher of each SR Policy NLRI prevents undesired BGP	<t>The distinguisher of each SR Policy NLRI prevents undesired BGP
	route selection among these SR Policy NLRIs and allows their	route selection among these SR Policy NLRIs and allows their

	propagation across route reflectors <xref target="RFC4456"/>.</t>	propagation across route reflectors <xref target="RFC4456" format="defau
		lt"/>.</t>
	<t>Moreover, one or more route targets SHOULD be attached to the	<t>Moreover, one or more route targets <bcp14>SHOULD</bcp14> be attached
		to the
	advertisement, where each route target identifies one or more intended	advertisement, where each route target identifies one or more intended
	headends for the advertised SR Policy update.</t>	headends for the advertised SR Policy update.</t>


	<t>If no route target is attached to the SR Policy NLRI, then it is	<t>If no route target is attached to the SR Policy NLRI, then it is
	assumed that the originator sends the SR Policy update directly (e.g.,	assumed that the originator sends the SR Policy update directly (e.g.,
	through a BGP session) to the intended receiver. In such a case, the	through a BGP session) to the intended receiver. In such a case, the

	NO_ADVERTISE community <xref target="RFC1997"/> MUST be attached to	NO_ADVERTISE community <xref target="RFC1997" format="default"/> <bcp14>
	the SR Policy update (see further details in <xref	MUST</bcp14> be attached to
	target="PROPAGATE"/>).</t>	the SR Policy update (see further details in <xref target="PROPAGATE" fo
		rmat="default"/>).</t>
	</section>	</section>

		<section anchor="RECEPT" numbered="true" toc="default">
	<section anchor="RECEPT" title="Reception of an SR Policy NLRI">	<name>Reception of an SR Policy NLRI</name>
	<t>On reception of an SR Policy NLRI, a BGP speaker first determines	<t>On reception of an SR Policy NLRI, a BGP speaker first determines

	if it is valid as described in <xref target="ACCEPT"/> and then	if it is valid as described in <xref target="ACCEPT"
	performs the decision process for selection of the best route (Section	format="default"/>; then, the BGP speaker performs the decision process
	9.1 of <xref target="RFC4271"/>). The key difference from the base BGP	for
	decision process is that BGP does not download the selected best	selection of the best route (<xref target="RFC4271" sectionFormat="of"
	routes of SR Policy SAFI into the forwarding and instead considers	section="9.1"/>). The key difference from the base BGP decision
	them "usable" for passing on to the SRPM for further processing as	process is that BGP does not download the selected best routes of the SR
	described in <xref target="USABLE"/>. The selected best route is	Policy SAFI into the forwarding; instead, it considers them "usable"
	"propagated" (Section 9.1.3 of <xref target="RFC4271"/>) as described	for passing on to the SRPM for further processing as described in
	in <xref target="PROPAGATE"/> irrespective of its "usability" by the	<xref target="USABLE" format="default"/>. The selected best route is
	local router.</t>	"propagated" (<xref target="RFC4271" sectionFormat="of"
		section="9.1.3"/>) as described in <xref target="PROPAGATE"
	<section anchor="ACCEPT" title="Validation of an SR Policy NLRI">	format="default"/>, irrespective of its "usability" by the local
	<t>When a BGP speaker receives an SR Policy NLRI from a neighbor it	router.</t>
	MUST first perform validation based on the following rules in	<section anchor="ACCEPT" numbered="true" toc="default">
	addition to the validation described in <xref target="ERROR"/>:	<name>Validation of an SR Policy NLRI</name>
	<list style="symbols">	<t>When a BGP speaker receives an SR Policy NLRI from a neighbor, it
	<t>The SR Policy NLRI MUST include a distinguisher, color, and	<bcp14>MUST</bcp14> first perform validation based on the following ru
	endpoint field which implies that the length of the NLRI MUST be	les in
		addition to the validation described in <xref target="ERROR" format="d
		efault"/>:
		</t>
		<ul spacing="normal">
		<li>
		<t>The SR Policy NLRI <bcp14>MUST</bcp14> include a distinguisher,
		color, and
		endpoint field that implies that the length of the NLRI <bcp14>MUS
		T</bcp14> be
	either 12 or 24 octets (depending on the address family of the	either 12 or 24 octets (depending on the address family of the
	endpoint).</t>	endpoint).</t>

		</li>
	<t>The SR Policy update MUST have either the NO_ADVERTISE	<li>
	community or at least one route target extended community in	<t>The SR Policy update <bcp14>MUST</bcp14> have either the NO_ADV
	IPv4-address format or both. If a router supporting this	ERTISE
		community, at least one route target extended community in
		IPv4-address format, or both. If a router supporting this
	specification receives an SR Policy update with no route target	specification receives an SR Policy update with no route target
	extended communities and no NO_ADVERTISE community, the update	extended communities and no NO_ADVERTISE community, the update

	MUST be considered as malformed.</t>	<bcp14>MUST</bcp14> be considered to be malformed.</t>
		</li>
	<t>The Tunnel Encapsulation Attribute MUST be attached to the	<li>
	BGP Update and MUST have a Tunnel Type TLV set to SR Policy	<t>The Tunnel Encapsulation Attribute <bcp14>MUST</bcp14> be attac
	(codepoint is 15).</t>	hed to the
	</list></t>	BGP Update and <bcp14>MUST</bcp14> have a Tunnel Type TLV set to S
		R Policy
		(code point is 15).</t>
		</li>
		</ul>
	<t>A router that receives an SR Policy update that is not valid	<t>A router that receives an SR Policy update that is not valid

	according to these criteria MUST treat the update as malformed and	according to these criteria <bcp14>MUST</bcp14> treat the update as ma
	the SR Policy candidate path MUST NOT be passed to the SRPM.</t>	lformed, and
		the SR Policy candidate path <bcp14>MUST NOT</bcp14> be passed to the
		SRPM.</t>
	</section>	</section>

		<section anchor="USABLE" numbered="true" toc="default">
	<section anchor="USABLE"	<name>Eligibility for Local Use of an SR Policy NLRI</name>
	title="Eligibility for Local Use of an SR Policy NLRI">	<t>An SR Policy NLRI update that does not have a route target extended
	<t>An SR Policy NLRI update without any route target extended	community but does have the NO_ADVERTISE community is considered
	community but having the NO_ADVERTISE community is considered
	usable.</t>	usable.</t>


	<t>If one or more route targets are present, then at least one route	<t>If one or more route targets are present, then at least one route

	target MUST match the BGP Identifier of the receiver for the update	target <bcp14>MUST</bcp14> match the BGP Identifier of the receiver fo
	to be considered usable. The BGP Identifier is defined in <xref	r the update
	target="RFC4271"/> as a 4-octet IPv4 address and updated by <xref	to be considered usable. The BGP Identifier is defined in <xref target
	target="RFC6286"/> as a 4-octet, unsigned, non-zero integer.	="RFC4271" format="default"/> as a 4-octet IPv4 address and is updated by <xref
	Therefore, the route target extended community MUST be of the same	target="RFC6286" format="default"/> as a 4-octet, unsigned, non-zero integer.
		Therefore, the route target extended community <bcp14>MUST</bcp14> be
		of the same
	format.</t>	format.</t>


		<!--[rfced] Please clarify "it" in the following text:

		Original:

		If one or more route targets are present and none matches the local
		BGP Identifier, then, while the SR Policy NLRI is valid, it is not
		usable on the receiver node.

		Perhaps:

		If one or more route targets are present, and none matches the
		local BGP Identifier, then, while the SR Policy NLRI is valid, the
		route targets are not usable on the receiver node.
		-->

	<t>If one or more route targets are present and none matches the	<t>If one or more route targets are present and none matches the
	local BGP Identifier, then, while the SR Policy NLRI is valid, it is	local BGP Identifier, then, while the SR Policy NLRI is valid, it is
	not usable on the receiver node.</t>	not usable on the receiver node.</t>


	<t>When the SR Policy tunnel type includes any sub-TLV that is	<t>When the SR Policy tunnel type includes any sub-TLV that is

	unrecognized or unsupported, the update SHOULD NOT be considered	unrecognized or unsupported, the update <bcp14>SHOULD NOT</bcp14> be c
	usable. An implementation MAY provide an option for ignoring	onsidered
		usable. An implementation <bcp14>MAY</bcp14> provide an option for ign
		oring
	unsupported sub-TLVs.</t>	unsupported sub-TLVs.</t>


	<t>Once BGP on the receiving node has determined that the SR Policy	<t>Once BGP on the receiving node has determined that the SR Policy
	NLRI is usable, it passes the SR Policy candidate path to the SRPM.	NLRI is usable, it passes the SR Policy candidate path to the SRPM.
	Note that, along with the candidate path details, BGP also passes	Note that, along with the candidate path details, BGP also passes
	the originator information for breaking ties in the candidate path	the originator information for breaking ties in the candidate path

	selection process as described in section 2.4 of <xref	selection process as described in <xref target="RFC9256" sectionFormat
	target="RFC9256"/>.</t>	="of" section="2.4"/>.</t>

	<t>When an update for an SR Policy NLRI results in its becoming	<t>When an update for an SR Policy NLRI results in its becoming

	unusable, BGP MUST delete its corresponding SR Policy candidate path	unusable, BGP <bcp14>MUST</bcp14> delete its corresponding SR Policy c andidate path
	from the SRPM.</t>	from the SRPM.</t>

		<t>The SRPM applies the rules defined in <xref target="RFC9256"
	<t>The SRPM applies the rules defined in section 2 of <xref	sectionFormat="of" section="2"/> to determine whether the SR Policy
	target="RFC9256"/> to determine whether the SR Policy candidate path	candidate path is valid and to select the active candidate path for
	is valid and to select the active candidate path for a given SR	a given SR Policy.</t>
	Policy.</t>
	</section>	</section>

		<section anchor="PROPAGATE" numbered="true" toc="default">
	<section anchor="PROPAGATE" title="Propagation of an SR Policy">	<name>Propagation of an SR Policy</name>
	<t>SR Policy NLRIs that have the NO_ADVERTISE community attached to	<t>SR Policy NLRIs that have the NO_ADVERTISE community attached to

	them MUST NOT be propagated.</t>	them <bcp14>MUST NOT</bcp14> be propagated.</t>
		<t>By default, a BGP node receiving an SR Policy NLRI <bcp14>MUST NOT<
	<t>By default, a BGP node receiving an SR Policy NLRI MUST NOT	/bcp14>
	propagate it to any EBGP neighbor. An implementation MAY provide an	propagate it to any External BGP (EBGP) neighbor. An implementation <b
		cp14>MAY</bcp14> provide an
	explicit configuration to override this and enable the propagation	explicit configuration to override this and enable the propagation
	of valid SR Policy NLRIs to specific EBGP neighbors where the SR	of valid SR Policy NLRIs to specific EBGP neighbors where the SR

	domain comprises multiple-ASes within a single service provider	domain comprises multiple ASes within a single service provider
	domain (see <xref target="Security"/> for details).</t>	domain (see <xref target="Security" format="default"/> for details).</
		t>
	<t>A BGP node advertises a received SR Policy NLRI to its IBGP	<t>A BGP node advertises a received SR Policy NLRI to its Internal BGP
		(IBGP)
	neighbors according to normal IBGP propagation rules.</t>	neighbors according to normal IBGP propagation rules.</t>

		<t>By default, a BGP node receiving an SR Policy NLRI <bcp14>SHOULD NO
	<t>By default, a BGP node receiving an SR Policy NLRI SHOULD NOT	T</bcp14>
	remove route target extended community before propagation. An	remove the route target extended community before propagation. An
	implementation MAY provide support for configuration to filter	implementation <bcp14>MAY</bcp14> provide support for configuration to
	and/or remove route target extended community before	filter
		and/or remove the route target extended community before
	propagation.</t>	propagation.</t>

		<t>A BGP node <bcp14>MUST NOT</bcp14> alter the SR Policy information
	<t>A BGP node MUST NOT alter the SR Policy information carried in	carried in
	the Tunnel Encapsulation Attribute during propagation.</t>	the Tunnel Encapsulation Attribute during propagation.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="ERROR" numbered="true" toc="default">
	<section anchor="ERROR" title="Error Handling and Fault Management">	<name>Error Handling and Fault Management</name>
	<t>This section describes the error handling actions, as described in	<t>This section describes the error-handling actions, as described in
	<xref target="RFC7606"/>, that are to be performed for the handling of	<xref target="RFC7606" format="default"/>, that are to be performed for th
	the BGP update messages for BGP SR Policy SAFI.</t>	e handling of
		the BGP update messages for the BGP SR Policy SAFI.</t>
	<t>A BGP Speaker MUST perform the following syntactic validation of the	<t>A BGP speaker <bcp14>MUST</bcp14> perform the following syntactic valid
		ation of the
	SR Policy NLRI to determine if it is malformed. This includes the	SR Policy NLRI to determine if it is malformed. This includes the
	validation of the length of each NLRI and the total length of the	validation of the length of each NLRI and the total length of the
	MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the	MP_REACH_NLRI and MP_UNREACH_NLRI attributes. It also includes the
	validation of the consistency of the NLRI length with the AFI and the	validation of the consistency of the NLRI length with the AFI and the

	endpoint address as specified in <xref target="SRPOLICYSAFI"/>.</t>	endpoint address as specified in <xref target="SRPOLICYSAFI" format="defau
		lt"/>.</t>
	<t>When the error determined allows for the router to skip the malformed	<t>When the error determined allows for the router to skip the malformed
	NLRI(s) and continue the processing of the rest of the update message,	NLRI(s) and continue the processing of the rest of the update message,

	then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In	then it <bcp14>MUST</bcp14> handle such malformed NLRIs as 'treat-as-withd raw'. In
	other cases, where the error in the NLRI encoding results in the	other cases, where the error in the NLRI encoding results in the

	inability to process the BGP update message (e.g. length related	inability to process the BGP update message (e.g., length-related
	encoding errors), then the router SHOULD handle such malformed NLRIs as	encoding errors), then the router <bcp14>SHOULD</bcp14> handle such malfor
	'AFI/SAFI disable' when other AFI/SAFI besides SR Policy are being	med NLRIs as
	advertised over the same session. Alternately, the router MUST perform	"AFI/SAFI disable" when other AFIs/SAFIs besides SR Policy are being
	'session reset' when the session is only being used for SR Policy or	advertised over the same session. Alternately, the router <bcp14>MUST</bcp
	when it 'AFI/SAFI disable' action is not possible.</t>	14> perform
		"session reset" when the session is only being used for SR Policy or
		when a "AFI/SAFI disable" action is not possible.</t>
	<t>The validation of the TLVs/sub-TLVs introduced in this document and	<t>The validation of the TLVs/sub-TLVs introduced in this document and

	defined in their respective sub-sections of <xref target="SRPOLICYTLV"/>	defined in their respective subsections of <xref target="SRPOLICYTLV" form
	MUST be performed to determine if they are malformed or invalid. The	at="default"/>
		<bcp14>MUST</bcp14> be performed to determine if they are malformed or inv
		alid. The
	validation of the Tunnel Encapsulation Attribute itself and the other	validation of the Tunnel Encapsulation Attribute itself and the other

	TLVs/sub-TLVs specified in Section 13 of <xref target="RFC9012"/> MUST	TLVs/sub-TLVs specified in <xref target="RFC9012" sectionFormat="of" secti on="13"/> <bcp14>MUST</bcp14>
	be done as described in that document. In case of any error detected,	be done as described in that document. In case of any error detected,
	either at the attribute or its TLV/sub-TLV level, the	either at the attribute or its TLV/sub-TLV level, the

	"treat-as-withdraw" strategy MUST be applied. This is because an SR	"treat-as-withdraw" strategy <bcp14>MUST</bcp14> be applied. This is becau
	Policy update without a valid Tunnel Encapsulation Attribute (comprising	se an SR
		Policy update without a valid Tunnel Encapsulation Attribute (comprised
	of all valid TLVs/sub-TLVs) is not usable.</t>	of all valid TLVs/sub-TLVs) is not usable.</t>

		<t>An SR Policy update that is determined not to be valid (and, therefore,
	<t>An SR Policy update that is determined to be not valid, and therefore	malformed) based on the rules described in <xref target="ACCEPT" format="d
	malformed, based on rules described in <xref target="ACCEPT"/> MUST be	efault"/> <bcp14>MUST</bcp14> be
	handled by the "treat-as-withdraw" strategy.</t>	handled by the "treat-as-withdraw" strategy.</t>


	<t>The validation of the individual fields of the TLVs/sub-TLVs defined	<t>The validation of the individual fields of the TLVs/sub-TLVs defined

	in <xref target="SRPOLICYTLV"/> are beyond the scope of BGP as they are	in <xref target="SRPOLICYTLV" format="default"/> are beyond the scope of B GP as they are
	handled by the SRPM as described in the individual TLV/sub-TLV	handled by the SRPM as described in the individual TLV/sub-TLV

	sub-sections. A BGP implementation MUST NOT perform semantic	subsections. A BGP implementation <bcp14>MUST NOT</bcp14> perform semantic
	verification of such fields nor consider the SR Policy update to be	verification of such fields nor consider the SR Policy update to be
	invalid or not usable based on such validation.</t>	invalid or not usable based on such validation.</t>

		<t>An implementation <bcp14>SHOULD</bcp14> log any errors found during the
	<t>An implementation SHOULD log any errors found during the above	above
	validation for further analysis.</t>	validation for further analysis.</t>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
		<name>IANA Considerations</name>

		<!--[rfced] We note that the IANA Considerations section (Section 6)
		starts with a summary of all of the actions that follow in the
		subsections. We had a few questions/comments related to this use:

		a) Note that we have consolidated mentions of the registry group names
		in the introductory text for each type of action in order to reduce
		redundancy. Please review these changes and let us know any
		objections.

		b) To further reduce redundancy, might it be agreeable to delete the
		registry group names from the subsections that follow? They were used
		inconsistently in the original, and the reader would be able to find
		that information in Section 6 itself if desired.

		c) Would you like to add section pointers to the corresponding
		subsections where the actions are further described?

		d) Please note that any changes to text that appears in any IANA
		registries mentioned in this document will be communicated to IANA by
		the RPC prior to publication but after the completion of AUTH48.
		-->


	<section anchor="IANA" title="IANA Considerations">
	<t>This document uses code point allocations from the following existing	<t>This document uses code point allocations from the following existing

	registries:<list style="symbols">	registries in the "Subsequent Address Family Identifiers (SAFI) Parameters
	<t>Subsequent Address Family Identifiers (SAFI) Parameters	" registry group:</t>
	registry</t>	<ul spacing="normal">
		<li>
		<t>The "SAFI Values" registry</t>
		</li>
		</ul>
		<t>This document uses code point allocations from the following existing r
		egistries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry g
		roup:</t>
		<ul spacing="normal">
		<li>
		<t>The "BGP Tunnel Encapsulation Attribute Tunnel Types" registry</t>
		</li>
		<li>
		<t>The "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry</t>
		</li>
		<li>
		<t>The "Color Extended Community Flags" registry</t>
		</li>
		</ul>
		<t>This document creates the following new
		registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" reg
		istry group: </t>
		<ul spacing="normal">
		<li>
		<t>The "SR Policy Segment List Sub-TLVs" registry</t>
		</li>
		<li>
		<t>The "SR Policy Binding SID Flags" registry</t>
		</li>
		<li>
		<t>The "SR Policy SRv6 Binding SID Flags" registry</t>
		</li>
		<li>
		<t>The "SR Policy Segment Flags" registry</t>
		</li>
		<li>
		<t>The "Color Extended Community Color-Only Types" registry</t>
		</li></ul>
		<t>This document creates the following new registry in the "Segment Routin
		g" registry group:</t>
		<ul spacing="normal">
		<li>
		<t>The "SR Policy ENLP Values" registry</t>
		</li>
		</ul>


	<t>BGP Tunnel Encapsulation Attribute Tunnel Types registry under	<!--[rfced] We had a few questions regarding Section 6.1 and the BGP
	the BGP Tunnel Encapsulation registry</t>	SAFI Code Point:


	<t>BGP Tunnel Encapsulation Attribute sub-TLVs registry under the	a) We received the following note from IANA. We do not see mention of
	BGP Tunnel Encapsulation registry</t>	this update in the IANA Considerations section of this document.
		Should anything be added?


	<t>Color Extended Community Flags registry under the BGP Tunnel	IANA's Note:
	Encapsulation registry</t>	NOTE: We've also updated the associated iana-routing-types YANG module
	</list></t>	to reflect the new description and enum variable.


	<t>This document also requests the creation of the following new	Please see
	registries: <list style="symbols">	https://www.iana.org/assignments/iana-routing-types
	<t>SR Policy Segment List Sub-TLVs under the BGP Tunnel
	Encapsulation registry</t>


	<t>SR Policy Binding SID Flags under the BGP Tunnel Encapsulation	b) We don't see any mention of "BGP" in the corresponding IANA
	registry</t>	registry. Should the title of Table 1 be updated?


	<t>SR Policy SRv6 Binding SID Flags under the BGP Tunnel	Currently in the document:
	Encapsulation registry</t>	Table 1: BGP SAFI Code Point


	<t>SR Policy Segment Flags under the BGP Tunnel Encapsulation	At https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml:
	registry</t>	SR Policy SAFI


	<t>Color Extended Community Color-Only Types registry under the BGP	c) The title of this section is "Subsequent Address Family Identifiers
	Tunnel Encapsulation registry</t>	(SAFI) Parameters". This is the title of registry group. Subsequent
		subsections in the document are titled using the subregistry. Should
		the title of Section 6.1 be updated to "SAFI Values"?


	<t>SR Policy ENLP Values under the Segment Routing registry</t>	-->
	</list></t>


	<section anchor="IANASAFI"	<section anchor="IANASAFI" numbered="true" toc="default">
	title="Subsequent Address Family Identifiers (SAFI) Parameters">	<name>Subsequent Address Family Identifiers (SAFI) Parameters</name>
	<t>This document introduces a SAFI in the registry "Subsequent Address	<t>This document registers a SAFI code point in the "SAFI Values" regist
	Family Identifiers (SAFI) Parameters" that has been assigned a code	ry of the "Subsequent Address
	point by IANA. The entry needs to be updated as follows:<figure	Family Identifiers (SAFI) Parameters" registry group as follows:</t>
	align="center">
	<artwork align="center"><![CDATA[Code Point Description
	Reference
	73 SR Policy SAFI This document


	Table 1: BGP SAFI Code Point	<table>
		<name>BGP SAFI Code Point</name>
		<thead>
		<tr>
		<th>Value</th><th>Description</th><th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>73</td><td>SR Policy SAFI</td><td>RFC 9830</td>
		</tr>
		</tbody>
		</table>


	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANATUNNEL" numbered="true" toc="default">
		<name>BGP Tunnel Encapsulation Attribute Tunnel Types</name>
		<t>This document registers a Tunnel-Type code point in the "BGP Tunnel
		Encapsulation Attribute Tunnel Types" registry under the "Border Gateway
		Protocol (BGP) Tunnel Encapsulation" registry group.</t>


	<section anchor="IANATUNNEL"	<table>
	title="BGP Tunnel Encapsulation Attribute Tunnel Types">	<name>Tunnel Type Code Point</name>
	<t>This document introduces a Tunnel-Type in the registry "BGP Tunnel	<thead>
	Encapsulation Attribute Tunnel Types" that has been assigned a	<tr>
	codepoint by IANA. The entry needs to be updated as follows:<figure	<th>Value</th><th>Description</th><th>Reference</th>
	align="center">	</tr>
	<artwork align="center"><![CDATA[Code Point Description	</thead>
	Reference	<tbody>
	15 SR Policy This document	<tr>
		<td>15</td><td>SR Policy</td><td>RFC 9830</td>
	Table 2: Tunnel Type Code Point	</tr>
		</tbody>
		</table>


	]]></artwork>
	</figure></t>
	</section>	</section>


	<section anchor="IANATUNNSUBTLV"	<!--[rfced] We had the following questions/comments regarding Section
	title="BGP Tunnel Encapsulation Attribute sub-TLVs">	6.3:
	<t>This document defines sub-TLVs in the registry "BGP Tunnel
	Encapsulation Attribute sub-TLVs" that have been assigned code points
	by IANA as follows via the early allocation process which needs to be
	made permanent:<figure align="center">
	<artwork align="center"><![CDATA[Code Point Description
	Reference
	12 Preference sub-TLV This document
	13 Binding SID sub-TLV This document
	14 ENLP sub-TLV This document
	15 Priority sub-TLV This document
	20 SRv6 Binding SID sub-TLV This document
	128 Segment List sub-TLV This document
	129 Policy Candidate Path Name sub-TLV This document
	130 Policy Name sub-TLV This document


	Table 3: BGP Tunnel Encapsulation Attribute Code Points	a) We note that the corresponding IANA registry
		(https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulat
		ion.xhtml#tunnel-sub-tlvs)
		also has a "Change Controller" column in which some of the code points
		listed by this document contain information (i.e., IETF). Should any
		mention of this be made in Table 3?

		b) Please review our update to the title of Table 3 and let us know
		any objections.

		Original:

		Table 3: BGP Tunnel Encapsulation Attribute Code Points

		Current:

		Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points
		-->
		<section anchor="IANATUNNSUBTLV" numbered="true" toc="default">
		<name>BGP Tunnel Encapsulation Attribute Sub-TLVs</name>
		<t>This document defines sub-TLVs in the "BGP Tunnel
		Encapsulation Attribute Sub-TLVs" registry under the "Border Gateway Pro
		tocol (BGP) Tunnel Encapsulation" registry group.</t>

		<table>
		<name>BGP Tunnel Encapsulation Attribute Sub-TLV Code Points</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>12</td>
		<td>Preference sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>13</td>
		<td>Binding SID sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>14</td>
		<td>ENLP sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>15</td>
		<td>Priority sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>20</td>
		<td>SRv6 Binding SID sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>128</td>
		<td>Segment List sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>129</td>
		<td>Policy Candidate Path Name sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>130</td>
		<td>Policy Name sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		</tbody>
		</table>


	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANAEXTCOM" numbered="true" toc="default">
		<name>Color Extended Community Flags</name>
		<t>This document defines the use of 2 bits in the
		"Color Extended Community Flags" registry under the "Border Gateway Prot
		ocol (BGP) Tunnel Encapsulation"
		registry group.</t>


	<section anchor="IANAEXTCOM" title="Color Extended Community Flags">	<table>
	<t>This document defines the use of 2 bits in the registry called	<name>Color Extended Community Flag Bits</name>
	"Color Extended Community Flags" under the "BGP Tunnel Encapsulation"	<thead>
	registry that have been assigned by IANA via the early allocation	<tr><th>Bit Position</th><th>Description</th><th>Reference</th></tr>
	process to form the Color-Only Types field which needs to be made	</thead>
	permanent:<figure align="center">	<tbody>
	<artwork align="center"><![CDATA[ Bit	<tr><td>0-1</td><td>Color-only Types Field</td><td>RFC 9830</td></tr>
	Position Description Reference	</tbody>
	0-1 Color-only Types Field This document	</table>


	Table 4: Color Extended Community Flag Bits
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANASIDLIST" numbered="true" toc="default">
		<name>SR Policy Segment List Sub-TLVs</name>
		<t>This document creates a new registry called "SR
		Policy Segment List Sub-TLVs" under the "Border Gateway Protocol (BGP) T
		unnel Encapsulation"
		registry group. The registration policy of this registry is "IETF Review
		"
		(see <xref target="RFC8126" format="default"/>).</t>
		<t>The following initial sub-TLV code points are assigned by this
		document:</t>


	<section anchor="IANASIDLIST" title="SR Policy Segment List Sub-TLVs">	<!--[rfced] We had the following questions/comments related to Table
	<t>This document requests the creation of a new registry called "SR	5:
	Policy Segment List Sub-TLVs" under the "BGP Tunnel Encapsulation"
	registry. The allocation policy of this registry is "IETF Review"
	according to <xref target="RFC8126"/>.</t>


	<t>Following initial Sub-TLV codepoints are assigned by this	a) Please review our update to the title to include "Sub-TLV".
	document:<figure align="center">
	<artwork align="center"><![CDATA[Value Description
	Reference
	0 Reserved This document
	1 Segment Type A sub-TLV This document
	2 Deprecated This document
	3-8 Unassigned
	9 Weight sub-TLV This document
	10 Deprecated This document
	11 Deprecated This document
	12 Deprecated This document
	13 Segment Type B sub-TLV This document
	14-255 Unassigned


	Table 5: SR Policy Segment List Code Points	Original:
		Table 5: SR Policy Segment List Code Points


	]]></artwork>	Current:
	</figure></t>	Table 5: SR Policy Segment List Sub-TLV Code Points
	</section>


	<section anchor="IANABSIDFLAGS" title="SR Policy Binding SID Flags">	b) We note that Table 5 includes "Segment Type A sub-TLV". Elsewhere
	<t>This document requests the creation of a new registry called "SR	in the document, we see "Type A Segment Sub-TLV". Further, we see
	Policy Binding SID Flags" under the "BGP Tunnel Encapsulation"	Type-1 (using a hyphen while lettered types do not). Please review
	registry. The allocation policy of this registry is "Standards Action"	all of these differences and let us know if/how these should be made
	according to <xref target="RFC8126"/>.</t>	consistent.


	<t>The following flags are defined:<figure align="center">	c) In the document, we see points 3-8 as "Unassigned". At
	<artwork align="center"><![CDATA[ Bit Description	https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulati
	Reference	on.xhtml#color-extended-community-flags,
	0 Specified-BSID-Only Flag (S-Flag) This document	we see Segment Type C - Type H sub-TLV. The same is true for points
	1 Drop Upon Invalid Flag (I-Flag) This document	14-16 (this document includes them in the 14-255 "Unassigned").
	2-7 Unassigned	Please review and let us know what, if any, updates are necessary.


	Table 6: SR Policy Binding SID Flags	-->

		<table>
		<name>SR Policy Segment List Sub-TLV Code Points</name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Reserved</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Segment Type A sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>2</td>
		<td>Deprecated</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>3-8</td>
		<td colspan="2">Unassigned</td>
		</tr>
		<tr>
		<td>9</td>
		<td>Weight sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>10</td>
		<td>Deprecated</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>11</td>
		<td>Deprecated</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>12</td>
		<td>Deprecated</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>13</td>
		<td>Segment Type B sub-TLV</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>14-255</td>
		<td colspan="2">Unassigned</td>
		</tr>
		</tbody>
		</table>


	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANABSIDFLAGS" numbered="true" toc="default">
		<name>SR Policy Binding SID Flags</name>
		<t>This document creates a new registry called "SR
		Policy Binding SID Flags" under the "Border Gateway Protocol (BGP) Tunne
		l Encapsulation"
		registry group. The registration policy of this registry is "Standards A
		ction"
		(see <xref target="RFC8126" format="default"/>).</t>
		<t>The following flags are defined:</t>


	<section anchor="IANASRV6BSIDFLAGS"	<table>
	title="SR Policy SRv6 Binding SID Flags">	<name>SR Policy Binding SID Flags</name>
	<t>This document requests the creation of a new registry called "SR	<thead>
	Policy SRv6 Binding SID Flags" under the "BGP Tunnel Encapsulation"	<tr>
	registry. The allocation policy of this registry is "Standards Action"	<th>Bit</th>
	according to <xref target="RFC8126"/>.</t>	<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Specified-BSID-Only Flag (S-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Drop Upon Invalid Flag (I-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>2-7</td>
		<td colspan="2">Unassigned</td>
		</tr>
		</tbody>
		</table>


	<t>The following flags are defined:<figure align="center">	</section>
	<artwork align="center"><![CDATA[ Bit Description	<section anchor="IANASRV6BSIDFLAGS" numbered="true" toc="default">
	Reference	<name>SR Policy SRv6 Binding SID Flags</name>
	0 Specified-BSID-Only Flag (S-Flag) This document	<t>This document creates a new registry called "SR
	1 Drop Upon Invalid Flag (I-Flag) This document	Policy SRv6 Binding SID Flags" under the "Border Gateway Protocol (BGP)
	2 SRv6 Endpoint Behavior &	Tunnel Encapsulation"
	SID Structure Flag (B-Flag) This document	registry group. The registration policy of this registry is "Standards A
	3-7 Unassigned	ction"
		(see <xref target="RFC8126" format="default"/>).</t>
		<t>The following flags are defined:</t>

		<table>
		<name>SR Policy SRv6 Binding SID Flags</name>
		<thead>
		<tr>
		<th>Bit</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Specified-BSID-Only Flag (S-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Drop Upon Invalid Flag (I-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>2</td>
		<td>SRv6 Endpoint Behavior & SID Structure Flag (B-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>3-7</td>
		<td colspan="2">Unassigned</td>
		</tr>
		</tbody>
		</table>


	Table 7: SR Policy SRv6 Binding SID Flags
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANASIDFLAGS" numbered="true" toc="default">
		<name>SR Policy Segment Flags</name>
		<t>This document creates a new registry called "SR
		Policy Segment Flags" under the "Border Gateway Protocol (BGP) Tunnel En
		capsulation" registry group.
		The registration policy of this registry is "IETF Review" (see <xref tar
		get="RFC8126" format="default"/>).</t>
		<t>The following flags are defined:</t>


	<section anchor="IANASIDFLAGS" title="SR Policy Segment Flags">	<!--[rfced] We had the following questions/comments regarding Section
	<t>This document requests the creation of a new registry called "SR	6.8 and the corresponding IANA registry at https://www.iana.org/assignments
	Policy Segment Flags" under the "BGP Tunnel Encapsulation" registry.	/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#sr-policy-segment-flags
	The allocation policy of this registry is "IETF Review" according to	:
	<xref target="RFC8126"/>.</t>


	<t>The following flags are defined:<figure align="center">	a) This document lists Bits 1-2 as "Unassigned" while the IANA
	<artwork align="center"><![CDATA[ Bit Description	registry lists entries for these values (the A-Flag and S-Flag).
	Reference	Please review and let us know what, if any, updates need to be made
	0 Segment Verification Flag (V-Flag) This document	for consistency.
	1-2 Unassigned
	3 SRv6 Endpoint Behavior &
	SID Structure Flag (B-Flag) This document
	4-7 Unassigned


	Table 8: SR Policy Segment Flags	-->
	]]></artwork>
	</figure></t>
	</section>


	<section anchor="IANAEXTCOMCOFIELD"	<table>
	title="Color Extended Community Color-Only Types">	<name>SR Policy Segment Flags</name>
	<t>This document requests the creation of a new registry called "Color	<thead>
	Extended Community Color-Only Types" under the "BGP Tunnel	<tr>
	Encapsulation" registry for assignment of codepoints (values 0 through	<th>Bit</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Segment Verification Flag (V-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1-2</td>
		<td colspan="2">Unassigned</td>
		</tr>
		<tr>
		<td>3</td>
		<td>SRv6 Endpoint Behavior & SID Structure Flag (B-Flag)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>4-7</td>
		<td colspan="2">Unassigned</td>
		</tr>
		</tbody>
		</table>

		</section>
		<section anchor="IANAEXTCOMCOFIELD" numbered="true" toc="default">
		<name>Color Extended Community Color-Only Types</name>
		<t>This document creates a new registry called "Color
		Extended Community Color-Only Types" under the "Border Gateway Protocol
		(BGP) Tunnel
		Encapsulation" registry group for assignment of code points (values 0 th
		rough
	3) in the Color-Only Type field of the Color Extended Community Flags	3) in the Color-Only Type field of the Color Extended Community Flags

	field. The allocation policy of this registry is "Standards Action"	field. The registration policy of this registry is "Standards Action"
	according to <xref target="RFC8126"/>.</t>	(see <xref target="RFC8126" format="default"/>).</t>
		<t>The following types are defined:</t>


	<t>The following types are defined:<figure align="center">	<table>
	<artwork align="center"><![CDATA[ Type Description	<name>Color Extended Community Color-Only Types</name>
	Reference	<thead>
	0 Specific Endpoint Match This document	<tr>
	1 Specific or Null Endpoint Match This document	<th>Type</th>
	2 Specific, Null, or Any Endpoint Match This document	<th>Description</th>
	3 Unassigned This document	<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Specific Endpoint Match</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Specific or Null Endpoint Match</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>2</td>
		<td>Specific, Null, or Any Endpoint Match</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>3</td>
		<td>Unassigned</td>
		<td>RFC 9830</td>
		</tr>
		</tbody>
		</table>


	Table 9: Color Extended Community Color-Only Types
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANAENLP" numbered="true" toc="default">
		<name>SR Policy ENLP Values</name>
		<t>IANA will maintain a new registry under the
		"Segment Routing" registry group with the registration policy of
		"Standards Action" (see <xref target="RFC8126" format="default"/>). The
		new registry is
		called "SR Policy ENLP Values" and contains the code points allocated
		to the "ENLP" field defined in <xref target="ENLPTLV" format="default"/>
		. The registry
		contains the following code points:</t>


	<section anchor="IANAENLP" title="SR Policy ENLP Values">	<!--[rfced] We had the following questions/comments related to Section
	<t>Note to IANA (RFC editor to remove this before publication): The	6.10 and its corresponding registry at:
	new registry creation request below is also present in the	https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#sr-p
	draft-ietf-pce-segment-routing-policy-cp. IANA is requested to process	olicy-enlp-values:
	the registry creation via the first of these two documents to reach
	publication stage and the authors of the other document would update
	the IANA considerations suitably.</t>


	<t>This document requests IANA to maintain a new registry under	a) There is a slight difference in the Description of Code Point 0.
	"Segment Routing" registry group with the allocation policy of	Please let us know if/how these may be made consistent.
	"Standards Action" <xref target="RFC8126"/>. The new registry is
	called "SR Policy ENLP Values" and contains the codepoints allocated
	to the "ENLP" field defined in <xref target="ENLPTLV"/>. The registry
	contains the following codepoints, with initial values, to be assigned
	by IANA with the reference set to this document:<figure>
	<artwork><![CDATA[+-------+-----------------------------------+-----
	----------+
	\| Code \| \| \|
	\| Point \| Description \| Reference \|
	+-------+-----------------------------------+---------------+
	\| 0 \| Reserved (not to be used) \| This document \|
	\| 1 \| Push an IPv4 Explicit NULL label \| This document \|
	\| \| on an unlabeled IPv4 packet, but \| \|
	\| \| do not push an IPv6 Explicit NULL \| \|
	\| \| label on an unlabeled IPv6 packet \| \|
	\| 2 \| Push an IPv6 Explicit NULL label \| This document \|
	\| \| on an unlabeled IPv6 packet, but \| \|
	\| \| do not push an IPv4 Explicit NULL \| \|
	\| \| label on an unlabeled IPv4 packet \| \|
	\| 3 \| Push an IPv6 Explicit NULL label \| This document \|
	\| \| on an unlabeled IPv6 packet, and \| \|
	\| \| push an IPv4 Explicit NULL label \| \|
	\| \| on an unlabeled IPv4 packet \| \|
	\| 4 \| Do not push an Explicit NULL \| This document \|
	\| \| label \| \|
	\| 5-255 \| Unassigned \| \|
	+-------+-----------------------------------+---------------+


	Table 10: SR Policy ENLP Values	This document:
		Reserved (not to be used)

		IANA registry:
		Reserved

		-->

		<table>
		<name>SR Policy ENLP Values</name>
		<thead>
		<tr>
		<th>Code Point</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Reserved (not to be used)</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do no
		t push an IPv6 Explicit NULL label on an unlabeled IPv6 packet</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>2</td>
		<td>Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do no
		t push an IPv4 Explicit NULL label on an unlabeled IPv4 packet</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>3</td>
		<td>Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet and push
		an IPv4 Explicit NULL label on an unlabeled IPv4 packet</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>4</td>
		<td>Do not push an Explicit NULL label</td>
		<td>RFC 9830</td>
		</tr>
		<tr>
		<td>5-255</td>
		<td colspan="2">Unassigned</td>
		</tr>
		</tbody>
		</table>


	]]></artwork>
	</figure></t>
	</section>	</section>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>The security mechanisms of the base BGP security model apply to the	<t>The security mechanisms of the base BGP security model apply to the
	extensions described in this document as well. See the Security	extensions described in this document as well. See the Security

	Considerations section of <xref target="RFC4271"/> for a discussion of	Considerations section of <xref target="RFC4271" format="default"/> for a
	BGP security. Also, refer to <xref target="RFC4272"/> and <xref	discussion of
	target="RFC6952"/> for analysis of security issues for BGP.</t>	BGP security. Also, refer to <xref target="RFC4272" format="default"/> and
		<xref target="RFC6952" format="default"/> for analysis of security issues for B
		GP.</t>

		<!--[rfced] In the following, how may we update to correct the
		connection between "address families" and "SAFI"? If our
		suggested text does not correctly capture your intent, please let
		us know how to rephrase.

		Original:
		BGP peering sessions for address-families other than SR Policy SAFI
		may be set up to routers outside the SR domain.

		Perhaps:
		BGP peering sessions for address families other than those that use
		the SR Policy SAFI may be set up to routers outside the SR domain.

		-->

	<t>The BGP SR Policy extensions specified in this document enable	<t>The BGP SR Policy extensions specified in this document enable

	traffic engineering and service programming use-cases within an SR	traffic engineering and service programming use cases within an SR
	domain as described in <xref target="RFC9256"/>. SR operates within a	domain as described in <xref target="RFC9256" format="default"/>. SR opera
	trusted SR domain <xref target="RFC8402"/> and its security	tes within a
		trusted SR domain <xref target="RFC8402" format="default"/>; its security
	considerations also apply to BGP sessions when carrying SR Policy	considerations also apply to BGP sessions when carrying SR Policy
	information. The SR Policies distributed by BGP are expected to be used	information. The SR Policies distributed by BGP are expected to be used

	entirely within this trusted SR domain which comprises a single AS or	entirely within this trusted SR domain, which comprises a single AS or
	multiple ASes/domains within a single provider network. Therefore,	multiple ASes / domains within a single provider network. Therefore,
	precaution is necessary to ensure that the SR Policy information	precaution is necessary to ensure that the SR Policy information
	advertised via BGP sessions is limited to nodes in a secure manner	advertised via BGP sessions is limited to nodes in a secure manner

	within this trusted SR domain. BGP peering sessions for address-families	within this trusted SR domain. BGP peering sessions for address families
	other than SR Policy SAFI may be set up to routers outside the SR	other than SR Policy SAFI may be set up to routers outside the SR
	domain. The isolation of BGP SR Policy SAFI peering sessions may be used	domain. The isolation of BGP SR Policy SAFI peering sessions may be used
	to ensure that the SR Policy information is not advertised by accident	to ensure that the SR Policy information is not advertised by accident

	or error to an EBGP peering session outside the SR domain.</t>	or in error to an EBGP peering session outside the SR domain.</t>
		<t>Additionally, it may be a consideration that the export of SR Policy
	<t>Additionally, it may be considered that the export of SR Policy
	information, as described in this document, constitutes a risk to	information, as described in this document, constitutes a risk to
	confidentiality of mission-critical or commercially sensitive	confidentiality of mission-critical or commercially sensitive
	information about the network (more specifically endpoint/node	information about the network (more specifically endpoint/node
	addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not	addresses, SR SIDs, and the SR Policies deployed). BGP peerings are not
	automatic and require configuration; thus, it is the responsibility of	automatic and require configuration; thus, it is the responsibility of
	the network operator to ensure that only trusted nodes (that include	the network operator to ensure that only trusted nodes (that include
	both routers and controller applications) within the SR domain are	both routers and controller applications) within the SR domain are
	configured to receive such information.</t>	configured to receive such information.</t>
	</section>	</section>

		<section anchor="Manageability" numbered="true" toc="default">
	<section anchor="Manageability" title="Manageability Considerations">	<name>Manageability Considerations</name>
	<t>The specification of BGP models is an ongoing work based on <xref	<t>The specification of BGP models is an ongoing work based on <xref targe
	target="I-D.ietf-idr-bgp-model"/> and its future extensions are expected	t="I-D.ietf-idr-bgp-model" format="default"/>; its future extensions are expecte
		d
	to cover the SR Policy SAFI. Existing BGP operational procedures also	to cover the SR Policy SAFI. Existing BGP operational procedures also
	apply to the SAFI specified in this document. The management,	apply to the SAFI specified in this document. The management,
	operations, and monitoring of BGP speakers and the SR Policy SAFI	operations, and monitoring of BGP speakers and the SR Policy SAFI
	sessions between them are not very different from other BGP sessions and	sessions between them are not very different from other BGP sessions and
	can be managed using the same data models.</t>	can be managed using the same data models.</t>

		<t>The YANG data model for the operation and management of SR Policies <xr
	<t>The YANG model for the operation and management of SR Policies <xref	ef target="I-D.ietf-spring-sr-policy-yang" format="default"/> reports the SR Pol
	target="I-D.ietf-spring-sr-policy-yang"/> reports the SR Policies	icies
	provisioned via BGP SR Policy SAFI along with their operational	provisioned via BGP SR Policy SAFI along with their operational
	states.</t>	states.</t>
	</section>	</section>


	<section title="Acknowledgments">	</middle>
	<t>The authors of this document would like to thank Shyam Sethuram, John	<back>
	Scudder, Przemyslaw Krol, Alex Bogdanov, Nandan Saha, Bruno Decraene,
	Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Jakob
	Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, John
	Scudder, Vincent Roca, Brian Haberman, Mohamed Boucadair, Shunwan
	Zhuang, Andrew Alston, Jeffrey (Zhaohui) Zhang, Nagendra Nainar, Rajesh
	Melarcode Venkateswaran, Nat Kao, Boris Hassanov, Vincent Roca, Russ
	Housley, and Dan Romascanu for their comments and review of this
	document. The authors would like to thank Susan Hares for her detailed
	shepherd review that helped in improving the document.</t>
	</section>


	<section anchor="Contributors" title="Contributors">	<displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG-MODEL"/>
	<figure>	<displayreference target="I-D.ietf-idr-bgp-ls-sr-policy" to="SR-BGP-LS"/>
	<artwork><![CDATA[Eric Rosen	<displayreference target="I-D.ietf-spring-sr-policy-yang" to="SR-POLICY-YANG"/>
	Juniper Networks	<references>
	US	<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
		997.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		126.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		545.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		462.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		760.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		271.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		286.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		360.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		606.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		032.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		012.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		402.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		660.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		754.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		256.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		986.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		272.xml"/>
		<!-- draft-ietf-idr-bgp-model-18
		IESG State: expired as of 2024-10-21. -->


	Email: erosen@juniper.net]]></artwork>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	</figure>	ietf-idr-bgp-model.xml"/>


	<figure>	<!-- draft-ietf-idr-bgp-ls-sr-policy-14
	<artwork><![CDATA[Arjun Sreekantiah	In queue: EDIT*R as of 2025-06-29-->
	Cisco Systems
	US


	Email: asreekan@cisco.com]]></artwork>	<reference anchor="I-D.ietf-idr-bgp-ls-sr-policy" target="https://datatracker.ie
	</figure>	tf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-16">
		<front>
		<title>Advertisement of Segment Routing Policies using BGP Link-State</tit
		le>
		<author initials="S." surname="Previdi" fullname="Stefano Previdi">
		<organization>Individual</organization>
		</author>
		<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
		e="editor">
		<organization>Cisco Systems</organization>
		</author>
		<author initials="J." surname="Dong" fullname="Jie Dong">
		<organization>Huawei Technologies</organization>
		</author>
		<author initials="H." surname="Gredler" fullname="Hannes Gredler">
		<organization>RtBrick Inc.</organization>
		</author>
		<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
		<organization>Nvidia</organization>
		</author>
		<date month="March" day="3" year="2025" />
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-sr-policy-16"
		/>


	<figure>	</reference>
	<artwork><![CDATA[Acee Lindem
	Cisco Systems
	US


	Email: acee@cisco.com]]></artwork>	<!-- draft-ietf-spring-sr-policy-yang-04
	</figure>	IESG State: I-D Exists as of 03/06/25. -->


	<figure>	<reference anchor="I-D.ietf-spring-sr-policy-yang" target="https://datatracker.i
	<artwork><![CDATA[Siva Sivabalan	etf.org/doc/html/draft-ietf-spring-sr-policy-yang-04">
	Cisco Systems	<front>
	US	<title>YANG Data Model for Segment Routing Policy</title>
		<author initials="K." surname="Raza" fullname="Syed Kamran Raza" role="edi
		tor">
		<organization>Cisco Systems</organization>
		</author>
		<author initials="T." surname="Saleh" fullname="Tarik Saleh">
		<organization>Cisco Systems</organization>
		</author>
		<author initials="Z." surname="Shunwan" fullname="Zhuang Shunwan">
		<organization>Huawei Technologies</organization>
		</author>
		<author initials="D." surname="Voyer" fullname="Daniel Voyer">
		<organization>Bell Canada</organization>
		</author>
		<author initials="M." surname="Durrani" fullname="Muhammad Durrani">
		<organization>Equinix</organization>
		</author>
		<author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
		<organization>SoftBank</organization>
		</author>
		<author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
		<organization>Juniper Networks</organization>
		</author>
		<date month="November" day="22" year="2024" />
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-policy-yang-04"
		/>


	Email: msiva@cisco.com]]></artwork>	</reference>
	</figure>


	<figure>	<!-- [I-D.ietf-idr-bgp-sr-segtypes-ext]
	<artwork><![CDATA[Imtiyaz Mohammad	draft-ietf-idr-bgp-sr-segtypes-ext-07 is a companion document moving throug
	Arista Networks	h the queue simultaneously -->
	India


	Email: imtiyaz@arista.com]]></artwork>	<!--[rfced] We note that this document has an Informative Reference
	</figure>	entry to draft-ietf-idr-bgp-sr-segtypes-ext-07, which is moving
		through the RFC Editor queue simultaneously.


	<figure>	We have updated this reference entry to use its RFC-to-be form as we
	<artwork><![CDATA[Gaurav Dawra	assume the intent is to publish them together.
	Cisco Systems
	US


	Email: gdawra.ietf@gmail.com]]></artwork>	However, since this dependency is not normative, please indicate if
	</figure>	your preference is not to wait if
		draft-ietf-idr-bgp-sr-segtypes-ext-07 has not completed AUTH48 prior
		to this document (in which case, we would revert to the I-D version of
		the reference entry). -->


	<figure>	<reference anchor="RFC9831" target="https://www.rfc-editor.org/info/rfc9831">
	<artwork><![CDATA[Peng Shaofu	<front>
	ZTE Corporation	<title>Segment Routing Segment Types Extensions for BGP SR Policy</title>
	China	<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
		e="editor">
		<organization>Cisco Systems</organization>
		</author>
		<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
		<organization>Cisco Systems</organization>
		</author>
		<author initials="S." surname="Previdi" fullname="Stefano Previdi">
		<organization>Huawei Technologies</organization>
		</author>
		<author initials="P." surname="Mattes" fullname="Paul Mattes">
		<organization>Microsoft</organization>
		</author>
		<author initials="D." surname="Jain" fullname="Dhanendra Jain">
		<organization>Google</organization>
		</author>
		<date month="July" year="2025" />
		</front>
		<seriesInfo name="RFC" value="9831" />
		<seriesInfo name='DOI' value='10.17487/RFC9831'/>


	Email: peng.shaofu@zte.com.cn]]></artwork>	</reference>
	</figure>


	<figure>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<artwork><![CDATA[Steven Lin	456.xml"/>
	Calix	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	USA	952.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		552.xml"/>
		</references>
		</references>


	Email: steven.lin@calix.com]]></artwork>	<section numbered="false" toc="default">
	</figure>	<name>Acknowledgments</name>
		<t>The authors of this document would like to thank <contact
		fullname="Shyam Sethuram"/>, <contact fullname="John Scudder"/>,
		<contact fullname="Przemyslaw Krol"/>, <contact fullname="Alex
		id Bogdanov"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Bruno
		Decraene"/>, <contact fullname="Gurusiddesh Nidasesi"/>, <contact
		fullname="Kausik Majumdar"/>, <contact fullname="Zafar Ali"/>, <contact
		fullname="Swadesh Agarwal"/>, <contact fullname="Jakob Heitz"/>,
		<contact fullname="Viral Patel"/>, <contact fullname="Peng Shaofu"/>,
		<contact fullname="Cheng Li"/>, <contact fullname="Martin Vigoureux"/>,
		<contact fullname="John Scudder"/>, <contact fullname="Vincent Roca"/>,
		<contact fullname="Brian Haberman"/>, <contact fullname="Mohamed
		Boucadair"/>, <contact fullname="Shunwan Zhuang"/>, <contact
		fullname="Andrew Alston"/>, <contact fullname="Jeffrey (Zhaohui)
		Zhang"/>, <contact fullname="Nagendra Nainar"/>, <contact
		fullname="Rajesh Melarcode Venkateswaran"/>, <contact fullname="Nat
		Kao"/>, <contact fullname="Boris Hassanov"/>, <contact fullname="Vincent
		Roca"/>, <contact fullname="Russ Housley"/>, and <contact fullname="Dan
		Romascanu"/> for their comments and review of this document. The authors
		would like to thank <contact fullname="Susan Hares"/> for her detailed
		shepherd review that helped in improving the document.</t>
	</section>	</section>

	</middle>	<section anchor="Contributors" numbered="false" toc="default">
		<name>Contributors</name>
	<back>
	<references title="Normative References">
	<?rfc include="reference.RFC.1997"?>


	<?rfc include="reference.RFC.2119"?>	<contact fullname="Eric Rosen">
		<organization>Juniper Networks</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>erosen@juniper.net</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.8174"?>	<contact fullname="Arjun Sreekantiah">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>asreekan@cisco.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.8126"?>	<contact fullname="Acee Lindem">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>acee@cisco.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.2545"?>	<contact fullname="Siva Sivabalan">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>msiva@cisco.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.5462"?>	<contact fullname="Imtiyaz Mohammad">
		<organization>Arista Networks</organization>
		<address>
		<postal>
		<country>India</country>
		</postal>
		<email>imtiyaz@arista.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.4760"?>	<contact fullname="Gaurav Dawra">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>gdawra.ietf@gmail.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.4271"?>	<contact fullname="Peng Shaofu">
		<organization>ZTE Corporation</organization>
		<address>
		<postal>
		<country>China</country>
		</postal>
		<email>peng.shaofu@zte.com.cn</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.6286"?>	<contact fullname="Steven Lin">
		<organization>Calix</organization>
		<address>
		<postal>
		<country>United States of America</country>
		</postal>
		<email>steven.lin@calix.com</email>
		</address>
		</contact>


	<?rfc include="reference.RFC.4360"?>	</section>


	<?rfc include="reference.RFC.7606"?>	<!-- [rfced] We had the following questions/comments related to
		abbreviation use throughout the document:


	<?rfc include="reference.RFC.3032"?>	a) FYI - We have added expansions for abbreviations upon first use per
		Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.


	<?rfc include="reference.RFC.9012"?>	b) We will update to have the abbreviation expanded upon first use and
		then use the abbreviation thereafter (per the guidance at
		https://www.rfc-editor.org/styleguide/part2/#exp_abbrev) *except when
		in a sub-TLV name* for the following abbreviations unless we hear
		objection.


	<?rfc include="reference.RFC.8402"?>	Segment Routing (SR)
		candidate path (CP)
		subsequent address family (SAFI)
		Route Reflectors (RR)
		Binding SID (BSID)
		Explicit NULL Label Policy (ENLP)


	<?rfc include="reference.RFC.8660"?>	c) May we expand NH as Next Hop?


	<?rfc include="reference.RFC.8754"?>	-->


	<?rfc include="reference.RFC.9256"?>	<!--[rfced] We had the following questions related to terminology use
		throughout the document.


	<?rfc include="reference.RFC.8986"?>	a) Should the following terms be made consistent with regard to
	</references>	capitalization, hyphenation, etc.? If so, please let us know how to
		update.


	<references title="Informational References">	SR Policy vs. SR policy vs. policy
	<?rfc include="reference.RFC.4272"?>	BGP UPDATE message vs. BGP update message vs. BGP Update
		Route Target Extended Community vs. route target extended community
		Tunnel Type vs. Tunnel-Type vs. Tunnel-type
		Flags field vs. Flag octet (singular and field vs. octet)
		Color vs. color
		Endpoint vs. endpoint
		Length field vs. length field (and simply length)
		"Drop Upon Invalid" behavior vs. "drop upon invalid" config
		Segment Type vs. segment type vs. Segment Types sub-TLV (plural)
		Explicit NULL Label vs. Explicit NULL label


	<?rfc include="reference.I-D.ietf-idr-bgp-model"?>	b) We see that some field names are in double quotes. Should this be
		made uniform throughout? If so, are quotation marks or no quotation
		marks preferred?


	<?rfc include="reference.I-D.ietf-idr-bgp-ls-sr-policy"?>	"Flags" field vs. Flags field


	<?rfc include="reference.I-D.ietf-spring-sr-policy-yang"?>	-->


	<?rfc include="reference.I-D.ietf-idr-bgp-sr-segtypes-ext"?>	<!--[rfced] Please review uses of the slash character "/" in the body
		of the document and consider whether "and", "or", or "and/or"
		might be clearer for the reader. -->


	<?rfc include="reference.RFC.4456"?>	<!-- [rfced] Please review the "Inclusive Language" portion of the
		online Style Guide
		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this
		nature typically result in more precise language, which is
		helpful for readers.


	<?rfc include="reference.RFC.6952"?>	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.9552"?>
	</references>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 457 change blocks.
	1222 lines changed or deleted	2018 lines changed or added
This html diff was produced by rfcdiff 1.48.