Diff: rfc8669xml2.original.xml

	rfc8669xml2.original.xml	rfc8669.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- One method to get references from the online citation libraries.	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8669"
	There has to be one entity for each item to be referenced.	category="std" consensus="true" submissionType="IETF"
	An alternate method (rfc include) is described in the references. -->	ipr="trust200902" docName="draft-ietf-idr-bgp-prefix-sid-27" obsoletes="" u
	]>	pdates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version
	<?rfc comments="yes"?>	="3">
	<?rfc compact="no"?>
	<?rfc inline="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="5"?>
	<?rfc tocindent="yes"?>
	<?rfc tocompact="yes"?>
	<rfc category="std" docName="draft-ietf-idr-bgp-prefix-sid-27"
	ipr="trust200902">
	<front>
	<title abbrev="">Segment Routing Prefix SID extensions for BGP</title>


		<front>
		<title abbrev="SR Prefix-SID Extensions for BGP">Segment Routing Prefix
		Segment Identifier Extensions for BGP</title>
		<seriesInfo name="RFC" value="8669"/>
	<author fullname="Stefano Previdi" initials="S." surname="Previdi">	<author fullname="Stefano Previdi" initials="S." surname="Previdi">

	<organization>Cisco Systems</organization>	<organization>Huawei Technologies</organization>

	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>


	<city/>	<city/>

		<country>Italy</country>
	<country>IT</country>

	<code/>	<code/>
	</postal>	</postal>


	<phone/>	<phone/>


	<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/>	<street/>


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


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


	<code/>	<code/>
	</postal>	</postal>


	<phone/>	<phone/>

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


	<author fullname="Acee Lindem" initials="A." surname="Lindem" role="editor">	<author fullname="Acee Lindem" initials="A." surname="Lindem" role="editor">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>
	<street>301 Midenhall Way</street>	<street>301 Midenhall Way</street>


	<city>Cary, NC</city>	<city>Cary, NC</city>

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

	<code>27513</code>	<code>27513</code>
	</postal>	</postal>


	<phone/>	<phone/>


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


	<author fullname="Arjun Sreekantiah" initials="A." surname="Sreekantiah">	<author fullname="Arjun Sreekantiah" initials="A." surname="Sreekantiah">
	<address>	<address>
	<email>arjunhrs@gmail.com</email>	<email>arjunhrs@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Hannes Gredler" initials="H." surname="Gredler">	<author fullname="Hannes Gredler" initials="H." surname="Gredler">
	<organization>RtBrick Inc.</organization>	<organization>RtBrick Inc.</organization>


	<address>	<address>
	<email>hannes@rtbrick.com</email>	<email>hannes@rtbrick.com</email>
	</address>	</address>
	</author>	</author>

		<date month="December" year="2019"/>
	<date/>

	<area>Routing</area>	<area>Routing</area>


	<workgroup>IDR</workgroup>	<workgroup>IDR</workgroup>


		<keyword>SR</keyword>
		<keyword>MPLS</keyword>
		<keyword>BGP</keyword>
		<keyword>Prefix-SID</keyword>
		<keyword>Label-Index</keyword>
		<keyword>SRGB</keyword>
	<abstract>	<abstract>

	<t>Segment Routing (SR) leverages the source routing paradigm. A node	<t>Segment Routing (SR) leverages the source-routing paradigm. A node
	steers a packet through an ordered list of instructions, called	steers a packet through an ordered list of instructions called
	segments. A segment can represent any instruction, topological or	"segments". A segment can represent any instruction, topological or
	service-based. The ingress node prepends an SR header to a packet	service based. The ingress node prepends an SR header to a packet
	containing a set of segment identifiers (SID). Each SID represents	containing a set of segment identifiers (SIDs). Each SID represents a
	a topological or a service-based instruction. Per-flow state is	topological or service-based instruction. Per-flow state is maintained
	maintained only on the ingress node of the SR domain. An SR domain	only on the ingress node of the SR domain. An "SR domain" is defined as a
	is defined as a single administrative domain for global SID assignment.</t	single administrative domain for global SID assignment.</t>
	>

	<t>This document defines an optional, transitive BGP attribute for	<t>This document defines an optional, transitive BGP attribute for

	announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)	announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SI
	information and the specification for SR-MPLS SIDs.</t>	Ds)
		and the specification for SR-MPLS SIDs.</t>
	</abstract>	</abstract>


	<note title="Requirements Language">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" 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>

	</note>
	</front>	</front>


	<middle>	<middle>

	<section anchor="intro" title="Introduction">	<section anchor="intro" numbered="true" toc="default">
	<t>The Segment Routing (SR) architecture leverages the source routing	<name>Introduction</name>
	paradigm. A segment represents either a topological instruction such as	<t>The Segment Routing (SR) architecture leverages the source-routing
	"go to prefix P following shortest path" or a service instruction.	paradigm. A segment represents either a topological instruction, such as
		"go to prefix P following shortest path", or a service instruction.
	Other types of segments may be defined in the future.</t>	Other types of segments may be defined in the future.</t>


	<t>A segment is identified through a Segment Identifier (SID).	<t>A segment is identified through a Segment Identifier (SID).

	An SR domain is defined as a single administrative domain for	An "SR domain" is defined as a single administrative domain for
	global SID assignment. It may be comprised of a single Autonomous System ( AS)	global SID assignment. It may be comprised of a single Autonomous System ( AS)
	or multiple ASes under consolidated global SID administration. Typically, the ingress	or multiple ASes under consolidated global SID administration. Typically, the ingress

	node of the SR domain prepends an SR header containing segments	node of the SR domain prepends an SR header containing SIDs to an incoming
	identifiers (SIDs) to an incoming packet.</t>	packet.</t>
		<t>As described in <xref target="RFC8402" format="default"/>,
	<t>As described in <xref target="I-D.ietf-spring-segment-routing"/>,	when SR is applied to the MPLS data plane (<xref target="RFC8660" format="
	when SR is applied to the MPLS dataplane (<xref	default"/>), the SID consists of a
	target="I-D.ietf-spring-segment-routing-mpls"/>), the SID consists of a
	label.</t>	label.</t>

		<t><xref target="RFC8402" format="default"/> also
	<t><xref target="I-D.ietf-spring-segment-routing"/> also	describes how Segment Routing can be applied to an IPv6 data plane (SRv6)
	describes how segment routing can be applied to an IPv6 dataplane (SRv6) u	using
	sing
	an IPv6 routing header containing a stack of SR SIDs encoded as	an IPv6 routing header containing a stack of SR SIDs encoded as

	IPv6 addresses <xref target="I-D.ietf-6man-segment-routing-header"/>.	IPv6 addresses <xref target="I-D.ietf-6man-segment-routing-header" format= "default"/>.
	The applicability and support for Segment Routing over IPv6 is beyond the	The applicability and support for Segment Routing over IPv6 is beyond the
	scope of this document.</t>	scope of this document.</t>

		<t>A BGP Prefix Segment is a BGP prefix with a Prefix-SID attached.
	<t>A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached.	A BGP Prefix-SID is always a global SID (<xref target="RFC8402" format="de
	A BGP Prefix-SID is always a global SID (<xref	fault"/>) within the SR domain
	target="I-D.ietf-spring-segment-routing"/>) within the SR domain
	and identifies an instruction to forward	and identifies an instruction to forward

	the packet over the Equal-Cost Multi-Path (ECMP) best-path	the packet over the Equal-Cost Multipath (ECMP) best path
	computed by BGP to the related	computed by BGP to the related

	prefix. The BGP Prefix-SID is the identifier of the BGP prefix segment.	prefix. The BGP Prefix-SID is the identifier of the BGP Prefix Segment.
	In this document, we always refer to the BGP-Prefix segment by the BGP	In this document, we always refer to the BGP Prefix Segment by the BGP
	Prefix-SID.</t>	Prefix-SID.</t>

		<t>This document describes the BGP extensions to signal the BGP
	<t>This document describes the BGP extension to signal the BGP
	Prefix-SID. Specifically, this document defines a BGP attribute	Prefix-SID. Specifically, this document defines a BGP attribute

	known as the BGP Prefix-SID attribute and specifies the rules to	known as the "BGP Prefix-SID attribute" and specifies the rules to
	originate, receive, and handle error conditions for the attribute.</t>	originate, receive, and handle error conditions for the attribute.</t>


	<t>The BGP Prefix-SID attribute defined in this document can be attached	<t>The BGP Prefix-SID attribute defined in this document can be attached
	to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled	to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled

	Unicast (<xref target="RFC4760"/>, <xref target="RFC8277"/>).	Unicast (<xref target="RFC4760" format="default"/> <xref target="RFC8277" format="default"/>).
	Usage of the BGP Prefix-SID attribute for other	Usage of the BGP Prefix-SID attribute for other

	Address Family Identifier (AFI)/ Subsequent Address	Address Family Identifier (AFI) / Subsequent Address
	Family Identifier (SAFI) combinations	Family Identifier (SAFI) combinations
	is not defined herein but may be specified in	is not defined herein but may be specified in
	future specifications.</t>	future specifications.</t>

		<t><xref target="RFC8670" format="default"/> describes
	<t><xref target="I-D.ietf-spring-segment-routing-msdc"/> describes
	example use cases where the BGP Prefix-SID is used for the above	example use cases where the BGP Prefix-SID is used for the above
	AFI/SAFI combinations.</t>	AFI/SAFI combinations.</t>

		<t>It should be noted that:</t>
	<t>It should be noted that:<list style="symbols">	<ul spacing="normal">
	<t>A BGP Prefix-SID will be global across ASes when the	<li>A BGP Prefix-SID will be global across ASes when the
	interconnected ASes are part of the same SR domain.	interconnected ASes are part of the same SR domain.
	Alternatively, when interconnecting ASes, the ASBRs of each	Alternatively, when interconnecting ASes, the ASBRs of each
	domain will have to handle the advertisement of unique SIDs. The	domain will have to handle the advertisement of unique SIDs. The
	mechanisms for such interconnection are outside the scope of the	mechanisms for such interconnection are outside the scope of the

	protocol extensions defined in this document.</t>	protocol extensions defined in this document.</li>
		<li>A BGP Prefix-SID <bcp14>MAY</bcp14> be attached to a BGP prefix.
	<t>A BGP Prefix-SID MAY be attached to a BGP prefix.
	This implies that each prefix is advertised individually, reducing the	This implies that each prefix is advertised individually, reducing the
	ability to pack BGP advertisements (when sharing common	ability to pack BGP advertisements (when sharing common

	attributes).</t>	attributes).</li>
	</list></t>	</ul>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		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" format="default"/> <xref target="
		RFC8174" format="default"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
	</section>	</section>

		<section anchor="MPLSPREFIXSID" numbered="true" toc="default">
		<name>MPLS BGP Prefix-SID</name>
		<t>The BGP Prefix-SID is realized on the MPLS data plane (<xref target="RF
		C8660" format="default"/>) in the following
		way:</t>


	<section anchor="MPLSPREFIXSID" title="MPLS BGP Prefix SID">	<ul empty="true" spacing="normal">
	<t>The BGP Prefix-SID is realized on the MPLS dataplane (<xref
	target="I-D.ietf-spring-segment-routing-mpls"/>) in the following	<li>The operator
	way:<list style="hanging">
	<t>The operator
	assigns a globally unique label index, L_I, to a locally originated	assigns a globally unique label index, L_I, to a locally originated

	prefix of a BGP speaker N which is advertised to all other BGP	prefix of a BGP speaker N, which is advertised to all other BGP
	speakers in the SR domain.</t>	speakers in the SR domain.</li>


	<t>According to <xref target="I-D.ietf-spring-segment-routing"/>,	<li>According to <xref target="RFC8402" format="default"/>,
	each BGP speaker is configured with a label block called the	each BGP speaker is configured with a label block called the

	Segment Routing Global Block (SRGB). While <xref	Segment Routing Global Block (SRGB). While <xref target="RFC8402" fo
	target="I-D.ietf-spring-segment-routing"/> recommends using the	rmat="default"/> recommends using the
	same SRGB across all the nodes within the SR domain, the SRGB of a	same SRGB across all the nodes within the SR domain, the SRGB of a
	node is a local property and could be different on different	node is a local property and could be different on different
	speakers. The drawbacks of the use case where BGP speakers have	speakers. The drawbacks of the use case where BGP speakers have

	different SRGBs are documented in <xref	different SRGBs are documented in <xref target="RFC8402" format="def
	target="I-D.ietf-spring-segment-routing"/> and <xref	ault"/> and <xref target="RFC8670" format="default"/>.</li>
	target="I-D.ietf-spring-segment-routing-msdc"/>.</t>


	<t>If traffic-engineering within the SR domain is required, each	<li>If traffic engineering within the SR domain is required, each
	node may also be required to advertise topological information and	node may also be required to advertise topological information and

	Peering SIDs for each of its links and peers. This information is	Peer SIDs for each of its links and peers. This information is
	required to perform the explicit path computation and to	required to perform the explicit path computation and to
	express an explicit path as a list of SIDs. The advertisement	express an explicit path as a list of SIDs. The advertisement
	of topological information and peer segments (Peer SIDs) is done	of topological information and peer segments (Peer SIDs) is done

	through <xref target="I-D.ietf-idr-bgpls-segment-routing-epe"/>.</t>	through <xref target="I-D.ietf-idr-bgpls-segment-routing-epe" format ="default"/>.</li>


	<t>If a prefix segment is to be included in an MPLS label stack,	<li>If a prefix segment is to be included in an MPLS label stack,
	e.g., for traffic engineering purposes, the knowledge of the SRGB	e.g., for traffic-engineering purposes, knowledge of the prefix
	of the originator of the prefix is required in order	originator's SRGB is required in order to compute the local label used
	to compute the local label used by the originator.</t>	by the originator.</li>


	<t>This document assumes that BGP-LS is the preferred method for	<li>This document assumes that Border Gateway Protocol - Link State
		(BGP-LS) is the preferred method for a
	collecting both peer segments (Peer SIDs) and SRGB	collecting both peer segments (Peer SIDs) and SRGB

	information through <xref target="RFC7752"/>, <xref	information through <xref target="RFC7752" format="default"/>, <xref
	target="I-D.ietf-idr-bgpls-segment-routing-epe"/>, and <xref	target="I-D.ietf-idr-bgpls-segment-routing-epe" format="default"/>, and <xref t
	target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>. However, as an	arget="I-D.ietf-idr-bgp-ls-segment-routing-ext" format="default"/>. However, as
		an
	optional alternative for the advertisement of the local SRGB	optional alternative for the advertisement of the local SRGB

	without the topology nor the peer SIDs, hence without	without the topology or the peer SIDs and, therefore, without
	applicability for TE, the Originator SRGB TLV of the BGP Prefix-SID	applicability for TE, the Originator SRGB TLV of the BGP Prefix-SID

	attribute is specified in <xref target="ORIGINSRGBTLV"/> of this	attribute is specified in <xref target="ORIGINSRGBTLV" format="defau
	document.</t>	lt"/> of this
		document.</li>


	<t>A BGP speaker will derive its local MPLS label L from the	<li>A BGP speaker will derive its local MPLS label L from the
	label index L_I and its local SRGB as	label index L_I and its local SRGB as

	described in <xref target="I-D.ietf-spring-segment-routing-mpls"/	described in <xref target="RFC8660" format="default"/>. The
	>. The	BGP speaker then programs the MPLS label L in its MPLS data plane
	BGP speaker then programs the MPLS label L in its MPLS dataplane	as
	as
	its incoming/local label for the prefix.	its incoming/local label for the prefix.

	See <xref target="RECMPLSLABEL"/> for more details.</t>	See <xref target="RECMPLSLABEL" format="default"/> for more detai ls.</li>


	<t>The outgoing label for the prefix is found in the	<li>The outgoing label for the prefix is found in the
	Network Layer Reachability Information (NLRI) of the	Network Layer Reachability Information (NLRI) of the
	Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement as	Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement as

	defined in <xref target="RFC8277"/>.	defined in <xref target="RFC8277" format="default"/>.
	The label index L_I is only used as a hint to derive the local/incom ing	The label index L_I is only used as a hint to derive the local/incom ing

	label.</t>	label.</li>


	<t><xref target="LABELINDEX"/> of this document specifies the	<li>
		<xref target="LABELINDEX" format="default"/> of this document specifie
		s the
	Label-Index TLV of the BGP Prefix-SID attribute; this TLV can be	Label-Index TLV of the BGP Prefix-SID attribute; this TLV can be

	used to advertise the label index for a given prefix.</t>	used to advertise the label index for a given prefix.</li>
	</list></t>	</ul>
	</section>	</section>

		<section anchor="PREFIXSIDATTR" numbered="true" toc="default">
	<section anchor="PREFIXSIDATTR" title="BGP Prefix-SID Attribute">	<name>BGP Prefix-SID Attribute</name>
	<t>The BGP Prefix-SID attribute is an optional, transitive BGP path	<t>The BGP Prefix-SID attribute is an optional, transitive BGP path
	attribute. The attribute type code 40 has been assigned by IANA (see	attribute. The attribute type code 40 has been assigned by IANA (see

	<xref target="IANA"/>).</t>	<xref target="IANA" format="default"/>).</t>

	<t>The BGP Prefix-SID attribute is defined here to be a set of elements	<t>The BGP Prefix-SID attribute is defined here to be a set of elements
	encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP	encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP
	Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet	Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet
	length. The following TLVs are defined in this	length. The following TLVs are defined in this

	document:<list style="symbols">	document:</t>
	<t>Label-Index TLV</t>	<ul spacing="normal">
		<li>Label-Index TLV</li>
	<t>Originator SRGB TLV</t>	<li>Originator SRGB TLV</li>
	</list></t>	</ul>

	<t>The Label-Index and Originator SRGB TLVs are used only when SR is appli ed	<t>The Label-Index and Originator SRGB TLVs are used only when SR is appli ed

	to the MPLS dataplane.</t>	to the MPLS data plane.</t>
		<t>For future extensibility, unknown TLVs <bcp14>MUST</bcp14> be ignored a
	<t>For future extensibility, unknown TLVs MUST be ignored and propagated	nd propagated
	unmodified.</t>	unmodified.</t>

		<section anchor="LABELINDEX" numbered="true" toc="default">
	<section anchor="LABELINDEX" title="Label-Index TLV">	<name>Label-Index TLV</name>
	<t>The Label-Index TLV MUST be present in the BGP Prefix-SID attribute	<t>The Label-Index TLV <bcp14>MUST</bcp14> be present in the BGP Prefix-
	attached to IPv4/IPv6 Labeled Unicast prefixes (<xref	SID attribute
	target="RFC8277"/>). It MUST be ignored when received for other	attached to IPv4/IPv6 Labeled Unicast prefixes (<xref target="RFC8277" f
		ormat="default"/>). It <bcp14>MUST</bcp14> be ignored when received for other
	BGP AFI/SAFI combinations. The Label-Index TLV has the	BGP AFI/SAFI combinations. The Label-Index TLV has the

	following format:<figure	following format:</t>
	align="center">	<artwork align="left" name="" type="" alt=""><![CDATA[ 0
	<artwork align="left"> 0 1 2	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \| Label Index \|	\| Flags \| Label Index \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label Index \|	\| Label Index \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	</figure>where: <list style="symbols">	<t>where: </t><ul empty="true"><li>
	<t>Type is 1.</t>	<dl newline="false" spacing="normal">
		<dt>Type:</dt>
	<t>Length: is 7, the total length in octets of the value portion	<dd>1</dd>
	of the TLV.</t>	<dt>Length:</dt><dd>7, the total length in octets of the value portion
		of the TLV.</dd>
	<t>RESERVED: 8-bit field. MUST be clear on transmission and MUST be	<dt>RESERVED:</dt><dd>8-bit field. It <bcp14>MUST</bcp14> be clear on
	ignored on reception.</t>	transmission and <bcp14>MUST</bcp14> be
		ignored on reception.</dd>
	<t>Flags: 16 bits of flags. None are defined by this document. The	<dt>Flags:</dt><dd>16 bits of flags. None are defined by this document
	flag field MUST be clear on transmission and MUST be ignored on	. The
	reception.</t>	Flags field <bcp14>MUST</bcp14> be clear on transmission and <bcp14>
		MUST</bcp14> be ignored on
	<t>Label Index: 32-bit value representing the index value in the	reception.</dd>
	SRGB space.</t>	<dt>Label Index:</dt><dd>32-bit value representing the index value in
	</list></t>	the
		SRGB space.</dd>
		</dl></li></ul>
	</section>	</section>

		<section anchor="ORIGINSRGBTLV" numbered="true" toc="default">
	<section anchor="ORIGINSRGBTLV" title="Originator SRGB TLV">	<name>Originator SRGB TLV</name>
	<t>The Originator SRGB TLV is an optional TLV and has the following	<t>The Originator SRGB TLV is an optional TLV and has the following

	format:<figure align="center">	format:</t>
	<artwork align="left"> 0 1 2	<artwork align="left" name="" type="" alt=""><![CDATA[ 0
	3	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 \|	\| Type \| Length \| Flags \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \|	\| Flags \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SRGB 1 (6 octets) \|	\| SRGB 1 (6 octets) \|
	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SRGB n (6 octets) \|	\| SRGB n (6 octets) \|
	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	</figure>where: <list style="symbols">	<t>where:</t><ul empty="true"><li>
	<t>Type is 3.</t>

	<t>Length is the total length in octets of the value portion of
	the TLV: 2 + (non-zero multiple of 6).</t>

	<t>Flags: 16 bits of flags. None are defined in this document.
	Flags MUST be clear on transmission and MUST be ignored on
	reception.</t>


	<t>SRGB: 3 octets specifying the first label in the range followed	<dl newline="false" spacing="normal">
		<dt>Type:</dt><dd>3</dd>
		<dt>Length:</dt><dd>The total length in octets of the value portion of
		the TLV: 2 + (non-zero multiple of 6).</dd>
		<dt>Flags:</dt><dd>16 bits of flags. None are defined in this document
		.
		The Flags field <bcp14>MUST</bcp14> be clear on transmission and <bc
		p14>MUST</bcp14> be ignored on
		reception.</dd>
		<dt>SRGB:</dt><dd>3 octets specifying the first label in the range fol
		lowed
	by 3 octets specifying the number of labels in the range. Note that	by 3 octets specifying the number of labels in the range. Note that

	the SRGB field MAY appear multiple times. If the SRGB field	the SRGB field <bcp14>MAY</bcp14> appear multiple times. If the SRGB field
	appears multiple times, the SRGB consists of multiple ranges	appears multiple times, the SRGB consists of multiple ranges

	that are concatenated.</t>	that are concatenated.</dd>
	</list></t>	</dl></li></ul>

	<t>The Originator SRGB TLV contains the SRGB of the node originating	<t>The Originator SRGB TLV contains the SRGB of the node originating
	the prefix to which the BGP Prefix-SID is attached. The Originator	the prefix to which the BGP Prefix-SID is attached. The Originator

	SRGB TLV MUST NOT be changed during the propagation of the BGP	SRGB TLV <bcp14>MUST NOT</bcp14> be changed during the propagation of th
	update. It is used to build segment routing policies	e BGP
	when different SRGBs are used in the fabric, for example (<xref	update. It is used to build SR policies
	target="I-D.ietf-spring-segment-routing-msdc"/>).</t>	when different SRGBs are used in the fabric, for example, <xref target="
		RFC8670" format="default"/>.</t>
	<t>Examples of how the receiving routers concatenate the	<t>Examples of how the receiving routers concatenate the
	ranges and build their neighbor's Segment Routing Global Block (SRGB)	ranges and build their neighbor's Segment Routing Global Block (SRGB)

	are included in <xref target="I-D.ietf-spring-segment-routing-mpls"/>) .</t>	are included in <xref target="RFC8660" format="default"/>.</t>
	<t>The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute	<t>The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute

	attached to IPv4/IPv6 Labeled Unicast prefixes (<xref	attached to IPv4/IPv6 Labeled Unicast prefixes (<xref target="RFC8277" f
	target="RFC8277"/>). It MUST be ignored when received for other	ormat="default"/>). It <bcp14>MUST</bcp14> be ignored when received for other
	BGP AFI/SAFI combinations. Since the Label-Index TLV is required	BGP AFI/SAFI combinations. Since the Label-Index TLV is required
	for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be	for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be

	ignored if it is not specified consistent with <xref	ignored if it is not specified in a manner consistent with <xref target=
	target="ERRORHANDLING"/>.</t>	"ERRORHANDLING" format="default"/>.</t>
	<t>If a BGP speaker receives a node’s SRGB as an attribute of the BGP-LS	<t>If a BGP speaker receives a node's SRGB as an attribute of the BGP-LS
	Node NLRI and the BGP speaker also receives the same node’s SRGB	Node NLRI and the BGP speaker also receives the same node's SRGB
	in a BGP Prefix-SID attribute, then the received values should be the	in a BGP Prefix-SID attribute, then the received values should be the
	same. If the values are different, the values advertised in the BGP-LS	same. If the values are different, the values advertised in the BGP-LS

	NLRI SHOULD be preferred and an error should be logged.</t>	NLRI <bcp14>SHOULD</bcp14> be preferred, and an error should be logged.
	</section>	</t>
		</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Receiving BGP Prefix-SID Attribute">	<name>Receiving BGP Prefix-SID Attribute</name>
	<t>A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP)	<t>A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP)

	neighbor residing outside the boundaries of the SR domain MUST	neighbor residing outside the boundaries of the SR domain <bcp14>MUST</bcp 14>
	discard the attribute unless it is configured to accept the attribute	discard the attribute unless it is configured to accept the attribute

	from the EBGP neighbor. A BGP speaker SHOULD log an error for further	from the EBGP neighbor. A BGP speaker <bcp14>SHOULD</bcp14> log an error f or further
	analysis when discarding an attribute.</t>	analysis when discarding an attribute.</t>

		<section anchor="RECMPLSLABEL" numbered="true" toc="default">
	<section anchor="RECMPLSLABEL" title="MPLS Dataplane: Labeled Unicast">	<name>MPLS Data Plane: Labeled Unicast</name>
	<t>A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 Un	<t>A BGP session supporting the Multiprotocol BGP Labeled IPv4 or IPv6 U
	icast (<xref	nicast (<xref target="RFC8277" format="default"/>) AFI/SAFI is required.</t>
	target="RFC8277"/>) AFI/SAFI is required.</t>	<t>When the BGP Prefix-SID attribute is attached to a BGP Labeled IPv4
		or IPv6
	<t>When the BGP Prefix-SID attribute is attached to a BGP labeled IPv4 o	Unicast <xref target="RFC8277" format="default"/> AFI/SAFI, it <bcp14>
	r IPv6	MUST</bcp14> contain the Label-Index TLV
	Unicast <xref target="RFC8277"/> AFI/SAFI, it MUST contain the Label-I	and <bcp14>MAY</bcp14> contain the Originator SRGB TLV. A BGP Prefix-
	ndex TLV	SID attribute received
	and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute r	without a Label-Index TLV <bcp14>MUST</bcp14> be considered to be "inv
	eceived	alid" by the
	without a Label-Index TLV MUST be considered as "invalid" by the
	receiving speaker.</t>	receiving speaker.</t>


	<t>The label index provides guidance to the receiving BGP speaker as to	<t>The label index provides guidance to the receiving BGP speaker as to

	the incoming label that SHOULD be allocated to the prefix.</t>	the incoming label that <bcp14>SHOULD</bcp14> be allocated to the pref
		ix.</t>
	<t>A BGP speaker may be locally configured with an SRGB=[SRGB_Start,	<t>A BGP speaker may be locally configured with an SRGB=[SRGB_Start,
	SRGB_End]. The preferred method for deriving the SRGB is a matter of	SRGB_End]. The preferred method for deriving the SRGB is a matter of
	local node configuration.</t>	local node configuration.</t>

		<t>The mechanisms through which a given label-index value is assigned
	<t>The mechanisms through which a given label index value is assigned
	to a given prefix are outside the scope of this document.</t>	to a given prefix are outside the scope of this document.</t>


	<t>Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the	<t>Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the
	derived label. A BGP Prefix-SID attribute is designated "conflicting" fo r	derived label. A BGP Prefix-SID attribute is designated "conflicting" fo r
	a speaker M if the derived label value L lies outside the SRGB	a speaker M if the derived label value L lies outside the SRGB

	configured on M. Otherwise the Label-Index TLV is designated	configured on M. Otherwise, the Label-Index TLV is designated
	"acceptable" to speaker M.</t>	"acceptable" to speaker M.</t>


	<t>If multiple different prefixes are received with the same label	<t>If multiple different prefixes are received with the same label

	index, all of the different prefixes MUST have	index, all of the different prefixes <bcp14>MUST</bcp14> have
	their BGP Prefix-SID attribute considered as “conflicting”.</t>	their BGP Prefix-SID attribute considered to be "conflicting".</t>

	<t>If multiple valid paths for the same prefix are received from	<t>If multiple valid paths for the same prefix are received from

	multiple BGP speakers or, in the case of <xref target="RFC7911"/>,	multiple BGP speakers or, in the case of <xref target="RFC7911" format ="default"/>,
	from the same BGP speaker, and the BGP Prefix-SID attributes do	from the same BGP speaker, and the BGP Prefix-SID attributes do
	not contain the same label index, then the label index from	not contain the same label index, then the label index from

	the best path BGP Prefix-SID attribute SHOULD be chosen with	the best path BGP Prefix-SID attribute <bcp14>SHOULD</bcp14> be chosen
	a notable exception being when <xref target="RFC5004"/>	with
		a notable exception being when <xref target="RFC5004" format="default"
		/>
	is being used to dampen route changes.</t>	is being used to dampen route changes.</t>


	<t>When a BGP speaker receives a path from a neighbor with an	<t>When a BGP speaker receives a path from a neighbor with an
	"acceptable" BGP Prefix-SID attribute and that path is selected as	"acceptable" BGP Prefix-SID attribute and that path is selected as

	the best path, it SHOULD program the derived label	the best path, it <bcp14>SHOULD</bcp14> program the derived label
	as the label for the prefix in its local MPLS dataplane.</t>	as the label for the prefix in its local MPLS data plane.</t>

	<t>When a BGP speaker receives a path from a neighbor with an	<t>When a BGP speaker receives a path from a neighbor with an

	"invalid" or "conflicting" BGP Prefix-SID attribute or when a	"invalid" or "conflicting" BGP Prefix-SID attribute, or when a
	BGP speaker receives a path from a neighbor with a BGP Prefix-SID	BGP speaker receives a path from a neighbor with a BGP Prefix-SID
	attribute but is unable to process it (e.g., local policy disables	attribute but is unable to process it (e.g., local policy disables

	the functionality), it MUST ignore the	the functionality), it <bcp14>MUST</bcp14> ignore the
	BGP Prefix-SID attribute. For the purposes of label allocation, a	BGP Prefix-SID attribute. For the purposes of label allocation, a

	BGP speaker MUST assign a local (also called dynamic) label (non-SRGB)	BGP speaker <bcp14>MUST</bcp14> assign a local (also called dynamic) lab el (non-SRGB)
	for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled	for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled

	Unicast (<xref target="RFC8277"/>) operation.</t>	Unicast (<xref target="RFC8277" format="default"/>) operation.</t>
		<t>In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker <
	<t>In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker M	bcp14>MUST</bcp14>
	UST	follow the error-handling rules specified in <xref target="ERRORHANDLING
	follow the error handling rules specified in <xref target="ERRORHANDLING	" format="default"/>.
	"/>.	A BGP speaker <bcp14>SHOULD</bcp14> log an error for further analysis. I
	A BGP speaker SHOULD log an error for further analysis. In the case of a	n the case of a
	"conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat i	"conflicting" BGP Prefix-SID attribute, a BGP speaker <bcp14>SHOULD NOT<
	t	/bcp14> treat it
	as error and SHOULD propagate the attribute unchanged. A BGP Speaker SHO	as an error and <bcp14>SHOULD</bcp14> propagate the attribute unchanged.
	ULD	A BGP speaker <bcp14>SHOULD</bcp14>
	log a warning for further analysis, i.e., in the case the conflict is	log a warning for further analysis, i.e., in the case the conflict is

	not due to a label index transition.</t>	not due to a label-index transition.</t>

	<t>When a BGP Prefix-SID attribute changes and transitions from	<t>When a BGP Prefix-SID attribute changes and transitions from
	"conflicting" to "acceptable", the BGP Prefix-SID attributes for othe r	"conflicting" to "acceptable", the BGP Prefix-SID attributes for othe r

	prefixes may also transition to "acceptable" as well. Implementations	prefixes may also transition to "acceptable" as well. Implementations
	SHOULD	<bcp14>SHOULD</bcp14>
	assure all impacted prefixes revert to using the label indices	ensure all impacted prefixes revert to using the label indices
	corresponding to these newly "acceptable" BGP Prefix-SID attributes.< /t>	corresponding to these newly "acceptable" BGP Prefix-SID attributes.< /t>


	<t>The outgoing label is always programmed as per classic	<t>The outgoing label is always programmed as per classic

	Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref target="RFC8277"/>)	Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref target="RFC8277" form at="default"/>)
	operation. Specifically, a BGP speaker receiving a prefix with a BGP Pre fix-SID	operation. Specifically, a BGP speaker receiving a prefix with a BGP Pre fix-SID
	attribute and a label NLRI field of Implicit NULL	attribute and a label NLRI field of Implicit NULL

	<xref target="RFC3032"/> from a neighbor MUST	<xref target="RFC3032" format="default"/> from a neighbor <bcp14>MUST</b
	adhere to standard behavior and program its MPLS dataplane to pop the	cp14>
		adhere to standard behavior and program its MPLS data plane to pop the
	top label when forwarding traffic to the prefix. The label NLRI	top label when forwarding traffic to the prefix. The label NLRI

	defines the outbound label that MUST be used by the receiving node.</t>	defines the outbound label that <bcp14>MUST</bcp14> be used by the recei ving node.</t>
	</section>	</section>

	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Advertising BGP Prefix-SID Attribute">	<name>Advertising BGP Prefix-SID Attribute</name>
	<t>The BGP Prefix-SID attribute MAY be attached to BGP IPv4/IPv6 Label Uni	<t>The BGP Prefix-SID attribute <bcp14>MAY</bcp14> be attached to BGP IPv4
	cast prefixes	/IPv6 Labeled Unicast prefixes
	<xref target="RFC8277"/>. In order to prevent distribution of the BGP	<xref target="RFC8277" format="default"/>. In order to prevent distributio
		n of the BGP
	Prefix-SID attribute beyond its intended scope of applicability,	Prefix-SID attribute beyond its intended scope of applicability,

	attribute filtering SHOULD be deployed to remove the BGP	attribute filtering <bcp14>SHOULD</bcp14> be deployed to remove the BGP
	Prefix-SID attribute at the administrative boundary of the	Prefix-SID attribute at the administrative boundary of the

	segment routing domain.</t>	SR domain.</t>
		<t>A BGP speaker that advertises a path received from one of its
	<t>A BGP speaker that advertises a path received from one of its	neighbors <bcp14>SHOULD</bcp14> advertise the BGP Prefix-SID received wi
	neighbors SHOULD advertise the BGP Prefix-SID received with the path	th the path
	without modification, as long as the BGP Prefix-SID was acceptable.	without modification as long as the BGP Prefix-SID was acceptable.
	If the path did not come with a BGP Prefix-SID attribute, the	If the path did not come with a BGP Prefix-SID attribute, the

	speaker MAY attach a BGP Prefix-SID to the path if configured to do so.	speaker <bcp14>MAY</bcp14> attach a BGP Prefix-SID to the path if config ured to do so.
	The content of the TLVs present in the BGP Prefix-SID is determined by t he	The content of the TLVs present in the BGP Prefix-SID is determined by t he
	configuration.</t>	configuration.</t>

		<section anchor="ADVMPLSLABEL" numbered="true" toc="default">
	<section anchor="ADVMPLSLABEL" title="MPLS Dataplane: Labeled Unicast">	<name>MPLS Data Plane: Labeled Unicast</name>
	<t>A BGP speaker that originates a prefix attaches the BGP Prefix-SID	<t>A BGP speaker that originates a prefix attaches the BGP Prefix-SID
	attribute when it advertises the prefix to its neighbors via	attribute when it advertises the prefix to its neighbors via

	Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref	Multiprotocol BGP IPv4/IPv6 Labeled Unicast (<xref target="RFC8277" form
	target="RFC8277"/>). The value of the label index in the Label-Index	at="default"/>). The value of the label index in the Label-Index
	TLV is determined by configuration.</t>	TLV is determined by configuration.</t>

		<t>A BGP speaker that originates a BGP Prefix-SID attribute <bcp14>MAY</
	<t>A BGP speaker that originates a BGP Prefix-SID attribute MAY optional	bcp14> optionally
	ly
	announce the Originator SRGB TLV along with the mandatory Label-Index TL V.	announce the Originator SRGB TLV along with the mandatory Label-Index TL V.
	The content of the Originator SRGB TLV is determined by	The content of the Originator SRGB TLV is determined by
	configuration.</t>	configuration.</t>

		<t>Since the label-index value must be unique within an SR domain, by
	<t>Since the label index value must be unique within an SR domain, by	default an implementation <bcp14>SHOULD NOT</bcp14> advertise the BGP Pr
	default an implementation SHOULD NOT advertise the BGP Prefix-SID	efix-SID
	attribute outside an Autonomous System unless it is explicitly	attribute outside an AS unless it is explicitly
	configured to do so.</t>	configured to do so.</t>

		<t>In all cases, the Label field of the advertised NLRI (<xref target="R
	<t>In all cases, the label field of the advertised NLRI (<xref	FC8277" format="default"/> <xref target="RFC4364" format="default"/>) <bcp14>MUS
	target="RFC8277"/>, <xref target="RFC4364"/>) MUST be set to the	T</bcp14> be set to the
	local/incoming label programmed in the MPLS dataplane for the given	local/incoming label programmed in the MPLS data plane for the given
	advertised prefix. If the prefix is associated with one of the BGP	advertised prefix. If the prefix is associated with one of the BGP
	speaker's interfaces, this is the usual MPLS label (such as the	speaker's interfaces, this is the usual MPLS label (such as the
	Implicit or Explicit NULL label	Implicit or Explicit NULL label

	<xref target="RFC3032"/>).</t>	<xref target="RFC3032" format="default"/>).</t>
	</section>	</section>
	</section>	</section>

		<section anchor="ERRORHANDLING" numbered="true" toc="default">
		<name>Error Handling of BGP Prefix-SID Attribute</name>


	<section anchor="ERRORHANDLING"	<t>When a BGP speaker receives a BGP UPDATE message containing a
	title="Error Handling of BGP Prefix-SID Attribute">	malformed or invalid BGP Prefix-SID attribute attached to an
	<t>When a BGP Speaker receives a BGP Update message containing a	IPv4/IPv6 Labeled Unicast prefix (<xref target="RFC8277" format="default"/
	malformed or invalid BGP Prefix-SID attribute attached to a	>), it <bcp14>MUST</bcp14>
	IPv4/IPv6 Labeled Unicast prefix <xref target="RFC8277"/>, it MUST	ignore the received BGP Prefix-SID attribute and not advertise it to
	ignore the received BGP Prefix-SID attributes and not advertise it to
	other BGP peers. In this context, a malformed BGP Prefix-SID attribute	other BGP peers. In this context, a malformed BGP Prefix-SID attribute
	is one that cannot be parsed due to not meeting the minimum attribute	is one that cannot be parsed due to not meeting the minimum attribute

	length requirement, contains a TLV length that doesn't conform to the	length requirement, containing a TLV length that doesn't conform to the
	length constraints for the TLV, or a contains TLV length that would	length constraints for the TLV, or containing a TLV length that would
	extend beyond the end of the attribute (as defined by the attribute	extend beyond the end of the attribute (as defined by the attribute
	length).	length).
	This is equivalent to the "Attribute discard"	This is equivalent to the "Attribute discard"

	action specified in <xref target="RFC7606"/>. When discarding an	action specified in <xref target="RFC7606" format="default"/>. When discar
	attribute, a BGP speaker SHOULD log an error for further analysis.</t>	ding an
		attribute, a BGP speaker <bcp14>SHOULD</bcp14> log an error for further an
	<t>As per with <xref target="RFC7606"/>, if the BGP	alysis.</t>
		<t>As per <xref target="RFC7606" format="default"/>, if the BGP
	Prefix-SID attribute appears more than once in an UPDATE	Prefix-SID attribute appears more than once in an UPDATE

	message, then all the occurrences of the attribute other than the	message, all the occurrences of the attribute other than the
	first one SHALL be discarded and the UPDATE message will continue	first one <bcp14>SHALL</bcp14> be discarded and the UPDATE message will
		continue
	to be processed.	to be processed.

	Similarly, if a recognized TLV appears more than once in an BGP	Similarly, if a recognized TLV appears more than once in a BGP
	Prefix-SID attribute while the specification only allows for a single	Prefix-SID attribute while the specification only allows for a single
	occurrence, then all the occurrences of the TLV other than the	occurrence, then all the occurrences of the TLV other than the

	first one SHALL be discarded and the Prefix-SID attribute will continue	first one <bcp14>SHALL</bcp14> be discarded and the Prefix-SID attribut e will continue
	to be processed.</t>	to be processed.</t>

		<t>For future extensibility, unknown TLVs <bcp14>MUST</bcp14> be ignored a
	<t>For future extensibility, unknown TLVs MUST be ignored and	nd
	propagated unmodified.</t>	propagated unmodified.</t>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>This document defines a BGP path attribute known as the BGP	<t>This document defines a BGP path attribute known as the BGP

	Prefix-SID attribute. This document requests IANA to assign an	Prefix-SID attribute. IANA has assigned
	attribute code type (suggested value: 40) to the BGP Prefix-SID	attribute code type 40 to the BGP Prefix-SID
	attribute from the BGP Path Attributes registry.</t>	attribute from the "BGP Path Attributes" registry.</t>

	<t>IANA temporarily assigned the following: <list>
	<t>40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires
	2018-09-30) [draft-ietf-idr-bgp-prefix-sid]</t>
	</list></t>

	<t>This document defines two TLVs for the BGP Prefix-SID attribute. These	<t>This document defines two TLVs for the BGP Prefix-SID attribute. These

	TLVs need to be registered with IANA. We request IANA to create a	TLVs have been registered with IANA. IANA has created a
	registry for BGP Prefix-SID Attribute TLVs as follows:</t>	registry for BGP Prefix-SID Attribute TLVs as follows:</t>

		<t>Under the "Border Gateway Protocol (BGP) Parameters" registry, the new
		registry titled "BGP
		Prefix-SID TLV Types" has been created and points to this
		document as the reference.</t>
		<t>Registration Procedure(s):</t>
		<ul empty="true" spacing="compact">
		<li>Values 1-254, Expert Review as defined in
		<xref target="RFC8126" format="default"/></li> <li>Values
		0 and 255, Reserved</li></ul>


	<t>Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP	<table anchor="IANA1" align="left">
	Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid	<name>BGP Prefix-SID TLV Types</name>
	Registration Procedure(s): Values 1-254 - Expert Review as defined in	<thead>
	<xref target="RFC8126"/>, Value	<tr>
	0 and 255 reserved</t>	<th>Value</th>
		<th>Type</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Reserved</td>
		<td>This document</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Label-Index</td>
		<td>This document</td>
		</tr>
		<tr>
		<td>2</td>
		<td>Deprecated</td>
		<td>This document</td>
		</tr>
		<tr>
		<td>3</td>
		<td>Originator SRGB</td>
		<td>This document</td>
		</tr>
		<tr>
		<td>4-254</td>
		<td>Unassigned</td>
		<td></td>
		</tr>
		<tr>
		<td>255</td>
		<td>Reserved</td>
		<td>This document</td>
		</tr>
		</tbody>
		</table>


	<figure align="center">	<t>The value 2 previously corresponded to the IPv6 SID TLV, which was spec
	<artwork align="left">Value Type Reference	ified
	0 Reserved this document	in previous versions of this document. It was removed, and use of
	1 Label-Index this document	the BGP Prefix-SID for Segment Routing over the IPv6 data plane
	2 Deprecated this document	<xref target="RFC8402" format="default"/> has been deferred to
	3 Originator SRGB this document
	4-254 Unassigned
	255 Reserved this document</artwork>
	</figure>
	<t>The value 2 previously corresponded to the IPv6 SID TLV which was speci
	fied
	in previous versions of this document. It was removed and usage of
	the BGP Prefix-SID for Segment Routing over the IPv6 dataplane
	<xref target="I-D.ietf-spring-segment-routing"/> has been deferred to
	future specifications.</t>	future specifications.</t>

		<t>IANA has also created the "BGP Prefix-SID Label-Index TLV Flags"
	<t>This document also requests creation of the "BGP Prefix-SID Label-Index
	TLV Flags"
	registry under the "Border Gateway Protocol (BGP) Parameters" registry ,	registry under the "Border Gateway Protocol (BGP) Parameters" registry ,

	Reference: draft-ietf-idr-bgp-prefix-sid. Initially, this 16-bit flags	with a reference to this document. Initially, this 16-bit flags registr
	registry will be	y is
	empty. The registration policy for flag bits will Expert Review <xref t	empty. The registration policy for flag bits is Expert Review <xref tar
	arget="RFC8126"/>	get="RFC8126" format="default"/>,
	consistent with the BGP Prefix-SID TLV Types registry.</t>	consistent with the "BGP Prefix-SID TLV Types" registry.</t>
	<t>Finally, this document requests creation of the "BGP Prefix-SID Origina	<t>Finally, IANA has created the "BGP Prefix-SID Originator SRGB TLV Flags
	tor SRGB TLV Flags"	"
	registry under the "Border Gateway Protocol (BGP) Parameters" registry ,	registry under the "Border Gateway Protocol (BGP) Parameters" registry ,

	Reference: draft-ietf-idr-bgp-prefix-sid. Initially, this 16-bit flags	with a reference to this document. Initially, this 16-bit flags registr
	registry will be	y is
	empty. The registration policy for flag bits will Expert Review <xref t	empty. The registration policy for flag bits is Expert Review <xref tar
	arget="RFC8126"/>	get="RFC8126" format="default"/>
	consistent with the BGP Prefix-SID TLV Types registry.</t>	consistent with the BGP Prefix-SID TLV Types registry.</t>

		<t>The designated experts must be good and faithful stewards of the above
	<t>The designated experts must be good and faithful stewards of the above	registries,
	registries,	ensuring that each request is legitimate and corresponds to a viable use
	assuring that each request is legitimate and corresponds to a viable use	case. Given
	case. Given
	the limited number of bits in the flags registries and the applicability to a single TLV,	the limited number of bits in the flags registries and the applicability to a single TLV,

	additional scrutiny should be afforded to flag bit allocation requests. In general, no	additional scrutiny should be afforded to requests for flag-bit allocati on. In general, no
	single use case should require more than one flag bit and, should the us e case	single use case should require more than one flag bit and, should the us e case
	require more, alternate encodings using new TLVs should be considered.</ t>	require more, alternate encodings using new TLVs should be considered.</ t>


	</section>	</section>

		<section anchor="MANAGE" numbered="true" toc="default">
	<section anchor="MANAGE" title="Manageability Considerations">	<name>Manageability Considerations</name>
	<t>This document defines a BGP attribute to address use	<t>This document defines a BGP attribute to address use
	cases such as the one described in	cases such as the one described in

	<xref target="I-D.ietf-spring-segment-routing-msdc"/>.	<xref target="RFC8670" format="default"/>.
	It is assumed that advertisement of the BGP Prefix-SID attribute is	It is assumed that advertisement of the BGP Prefix-SID attribute is

	controlled by the operator in order to:<list style="symbols">	controlled by the operator in order to:</t>
	<t>Prevent undesired origination/advertisement of the BGP Prefix-SID	<ul spacing="normal">
	attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be	<li>Prevent undesired origination/advertisement of the BGP Prefix-SID
		attribute. By default, a BGP Prefix-SID attribute <bcp14>SHOULD NOT</b
		cp14> be
	attached to a prefix and advertised. Hence, BGP Prefix-SID	attached to a prefix and advertised. Hence, BGP Prefix-SID

	advertisement SHOULD require explicit enablement.</t>	Advertisement <bcp14>SHOULD</bcp14> require explicit enablement.</li>
		<li>Prevent any undesired propagation of the BGP Prefix-SID
	<t>Prevent any undesired propagation of the BGP Prefix-SID
	attribute. By default, the BGP Prefix-SID is not advertised outside	attribute. By default, the BGP Prefix-SID is not advertised outside

	the boundary of a single SR/administrative domain which may include	the boundary of a single SR/administrative domain that may include
	one or more ASes. The propagation to other ASes MUST be	one or more ASes. The propagation to other ASes <bcp14>MUST</bcp14> be
	explicitly configured.</t>	explicitly configured.</li>
	</list></t>	</ul>
		<t>The deployment model described in <xref target="RFC8670" format="defaul
	<t>The deployment model described in <xref	t"/> assumes multiple
	target="I-D.ietf-spring-segment-routing-msdc"/> assumes multiple	ASes under a common administrative domain. For this
	Autonomous Systems (ASes) under a common administrative domain. For this	use case, the BGP Prefix-SID Advertisement is applicable to the inter-AS
	use case, the BGP Prefix-SID advertisement is applicable to the inter-AS
	context, i.e., EBGP, while it is confined to a single	context, i.e., EBGP, while it is confined to a single
	administrative domain.</t>	administrative domain.</t>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>This document introduces a BGP attribute (BGP Prefix-SID) which	<t>This document introduces a BGP attribute (BGP Prefix-SID), which
	inherits the security considerations expressed in: <xref	inherits the security considerations expressed in: <xref target="RFC4271"
	target="RFC4271"/>, <xref target="RFC8277"/>, and	format="default"/>, <xref target="RFC8277" format="default"/>, and
	<xref target="I-D.ietf-spring-segment-routing"/>.</t>	<xref target="RFC8402" format="default"/>.</t>
	<t>When advertised using BGPsec as described in <xref target="RFC8205"/>,	<t>When advertised using BGPsec as described in <xref target="RFC8205" for
		mat="default"/>,
	the BGP Prefix-SID attribute doesn't impose any unique	the BGP Prefix-SID attribute doesn't impose any unique
	security considerations. It should be noted that the BGP Prefix-SID	security considerations. It should be noted that the BGP Prefix-SID
	attribute is not protected by the BGPsec signatures.</t>	attribute is not protected by the BGPsec signatures.</t>


	<t>It should be noted that,	<t>It should be noted that,

	as described in <xref target="MANAGE"/>, this document refers	as described in <xref target="MANAGE" format="default"/>, this document re fers
	to a deployment model where all nodes are under the single administrative domain.	to a deployment model where all nodes are under the single administrative domain.
	In this context, we assume that the operator doesn't want to leak	In this context, we assume that the operator doesn't want to leak
	any information related to internal prefixes and topology outside of the	any information related to internal prefixes and topology outside of the
	administrative domain.	administrative domain.
	The internal information includes the BGP Prefix-SID. In order	The internal information includes the BGP Prefix-SID. In order
	to prevent such leaking, the common BGP mechanisms (filters) are	to prevent such leaking, the common BGP mechanisms (filters) are
	applied at the boundary of the SR/administrative domain.	applied at the boundary of the SR/administrative domain.

	Local BGP attribute filtering policies	Local BGP-attribute-filtering policies
	and mechanisms are not standardized and, consequently, beyond the	and mechanisms are not standardized and, consequently, are beyond the
	scope of this document.</t>	scope of this document.</t>
	<t>To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service	<t>To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
	(DDoS) attack due to excessive BGP updates with an invalid or conflicting	(DDoS) attack due to excessive BGP updates with an invalid or conflicting

	BGP Prefix-SID attribute, error log message rate-limiting as well as suppr	BGP Prefix-SID attribute, error log message rate limiting as well as suppr
	ession of	ession of
	duplicate error log messages SHOULD be deployed.</t>	duplicate error log messages <bcp14>SHOULD</bcp14> be deployed.</t>
	<t>Since BGP-LS is the preferred method for advertising SRGB information,	<t>Since BGP-LS is the preferred method for advertising SRGB information,

	the BGP speaker SHOULD log an error if a BGP Prefix-SID attribute	the BGP speaker <bcp14>SHOULD</bcp14> log an error if a BGP Prefix-SID attribute
	is received with SRGB information different from that received as an at tribute of	is received with SRGB information different from that received as an at tribute of
	the same node's BGP-LS Node NLRI.</t>	the same node's BGP-LS Node NLRI.</t>
	</section>	</section>

		</middle>
		<back>
		<displayreference target="I-D.ietf-idr-bgpls-segment-routing-epe"
		to="BGPLS-SR-EPE"/>
		<displayreference target="I-D.ietf-idr-bgp-ls-segment-routing-ext"
		to="BGPLS-SR-EXT"/>


	<section anchor="Contributors" title="Contributors">	<displayreference target="I-D.ietf-6man-segment-routing-header"
	<figure>	to="IPv6-SRH" />
	<artwork>Keyur Patel	<references>
	Arrcus, Inc.	<name>References</name>
	US	<references>
		<name>Normative References</name>


	Email: Keyur@arrcus.com</artwork>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	</figure>	ence.RFC.2119.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4271.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4364.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4760.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7606.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7911.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8126.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8174.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8205.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8277.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8402.xml"/>
		<!-- draft-ietf-spring-segment-routing-mpls-22: Companion Document -->


	<figure>	<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660
	<artwork>Saikat Ray	">
	Unaffiliated	<front>
	US	<title>Segment Routing with the MPLS Data Plane</title>
		<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'
		role="editor">
		<organization/>
		</author>
		<author initials='C' surname='Filsfils' fullname='Clarence' role="editor">
		<organization/>
		</author>
		<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
		<organization/>
		</author>
		<author initials="B" surname="Decraene" fullname="Bruno Decraene">
		<organization/>
		</author>
		<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
		<organization/>
		</author>
		<author initials='R' surname='Shakir' fullname='Rob Shakir'>
		<organization/>
		</author>
		<date month='December' year='2019'/>
		</front>
		<seriesInfo name="RFC" value="8660"/>
		<seriesInfo name="DOI" value="10.17487/RFC8660"/>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3032.xml"/>


	Email: raysaikat@gmail.com</artwork>	<!-- I-D.ietf-spring-segment-routing-msdc: Companion Document -->
	</figure>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
	</section>	I-D.ietf-6man-segment-routing-header.xml"/>


	<section anchor="Acknowledgements" title="Acknowledgements">	<reference anchor='RFC8670' target='https://www.rfc-editor.org/info/rfc8670'>
		<front>
		<title>BGP Prefix Segment in Large-Scale Data Centers</title>

		<author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role="edito
		r">
		<organization />
		</author>
		<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
		<organization />
		</author>
		<author initials='G' surname='Dawra' fullname='Gaurav Dawra'>
		<organization />
		</author>
		<author initials='E' surname='Aries' fullname='Ebben Aries'>
		<organization />
		</author>
		<author initials='P' surname='Lapukhov' fullname='Petr Lapukhov'>
		<organization />
		</author>
		<date month='December' year='2019' />
		</front>
		<seriesInfo name='RFC' value='8670' />
		<seriesInfo name='DOI' value='10.17487/RFC8670'/>
		</reference>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I
		-D.ietf-idr-bgpls-segment-routing-epe.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I
		-D.ietf-idr-bgp-ls-segment-routing-ext.xml"/>

		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5004.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7752.xml"/>
		</references>
		</references>
		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
	<t>The authors would like to thank Satya Mohanty for his contribution	<t>The authors would like to thank Satya Mohanty for his contribution
	to this document.</t>	to this document.</t>
	<t>The authors would like to thank Alvaro Retana for substantive	<t>The authors would like to thank Alvaro Retana for substantive
	comments as part of the Routing AD review.</t>	comments as part of the Routing AD review.</t>
	<t>The authors would like to thank Bruno Decraene for substantive	<t>The authors would like to thank Bruno Decraene for substantive
	comments and suggested text as part of the Routing Directorate	comments and suggested text as part of the Routing Directorate
	review.</t>	review.</t>
	<t>The authors would like to thank Shyam Sethuram for comments and	<t>The authors would like to thank Shyam Sethuram for comments and
	discussion of TLV processing and validation.</t>	discussion of TLV processing and validation.</t>
	<t>The authors would like to thank Robert Raszuk for comments and	<t>The authors would like to thank Robert Raszuk for comments and

	suggestions regarding the MPLS data plane behavior.</t>	suggestions regarding the MPLS data-plane behavior.</t>
	<t>The authors would like to thank Krishna Deevi,	<t>The authors would like to thank Krishna Deevi,
	Juan Alcaide, Howard Yang, and Jakob Heitz for discussions	Juan Alcaide, Howard Yang, and Jakob Heitz for discussions
	on conflicting BGP Prefix-SID label indices and BGP add paths.</t>	on conflicting BGP Prefix-SID label indices and BGP add paths.</t>
	<t>The authors would like to thank Peter Yee, Tony Przygienda,	<t>The authors would like to thank Peter Yee, Tony Przygienda,

	Mirja Kühlewind, Alexey Melnikov, Eric Rescorla, Suresh	Mirja Kuhlewind, Alexey Melnikov, Eric Rescorla, Suresh
	Krishnan, Warren Kumari, Ben Campbell Sue Hares, and Martin	Krishnan, Warren Kumari, Ben Campbell Sue Hares, and Martin
	Vigoureux for IDR Working Group last call, IETF Last Call,	Vigoureux for IDR Working Group last call, IETF Last Call,
	directorate, and IESG reviews.</t>	directorate, and IESG reviews.</t>
	</section>	</section>

	</middle>	<section anchor="Contributors" numbered="false" toc="default">
		<name>Contributors</name>
	<back>	<artwork name="" type="" align="left" alt=""><![CDATA[Keyur Patel
	<references title="Normative References">	Arrcus, Inc.
	<?rfc include="reference.RFC.2119"?>	United States of America

	<?rfc include="reference.RFC.4271"?>

	<?rfc include="reference.RFC.4364"?>

	<?rfc include="reference.RFC.4760"?>

	<?rfc include="reference.RFC.7606"?>

	<?rfc include="reference.RFC.7911"?>

	<?rfc include="reference.RFC.8126"?>

	<?rfc include="reference.RFC.8174"?>

	<?rfc include="reference.RFC.8205"?>

	<?rfc include="reference.RFC.8277"?>

	<?rfc include="reference.I-D.ietf-spring-segment-routing.xml"?>

	<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls.xml"?>
	</references>

	<references title="Informative References">
	<?rfc include="reference.RFC.3032"?>

	<?rfc include="reference.I-D.ietf-spring-segment-routing-msdc.xml"?>

	<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?>

	<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>

	<?rfc include="reference.I-D.ietf-6man-segment-routing-header.xml"?>


	<?rfc include="reference.RFC.5004"?>	Email: Keyur@arrcus.com]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[Saikat Ray
		Unaffiliated
		United States of America


	<?rfc include="reference.RFC.7752"?>	Email: raysaikat@gmail.com]]></artwork>
	</references>	</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 165 change blocks.
	474 lines changed or deleted	535 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/