Diff: rfc8664xml2.original.xml

	rfc8664xml2.original.xml	rfc8664.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<?rfc toc="yes"?>	nsus="true" docName="draft-ietf-pce-segment-routing-16" indexInclude="true" ipr=
	<?rfc tocompact="yes"?>	"trust200902" number="8664" prepTime="2019-12-04T22:27:30" scripts="Common,Latin
	<?rfc tocdepth="3"?>	" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="
	<?rfc tocindent="yes"?>	true" updates="8408" xml:lang="en">
	<?rfc symrefs="yes"?>	<link href="https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-16
	<?rfc sortrefs="yes"?>	" rel="prev"/>
	<?rfc comments="yes"?>	<link href="https://dx.doi.org/10.17487/rfc8664" rel="alternate"/>
	<?rfc inline="yes"?>	<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-pce-segment-routing-16" ipr="trust200902
	" updates="8408">
	<front>	<front>

	<title abbrev="PCEP Extensions for Segment Routing">	<title abbrev="PCEP Extensions for Segment Routing">Path Computation Element
	PCEP Extensions for Segment Routing</title>	Communication Protocol (PCEP) Extensions for Segment Routing</title>
		<seriesInfo name="RFC" value="8664" stream="IETF"/>
	<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">	<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">

	<organization>Cisco Systems, Inc.</organization>	<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>2000 Innovation Drive</street>	<street>2000 Innovation Drive</street>
	<city>Kanata</city>	<city>Kanata</city>
	<region>Ontario</region>	<region>Ontario</region>
	<code>K2K 3E8</code>	<code>K2K 3E8</code>
	<country>Canada</country>	<country>Canada</country>
	</postal>	</postal>
	<email>msiva@cisco.com</email>	<email>msiva@cisco.com</email>
	</address>	</address>

	skipping to change at line 31 ¶	skipping to change at line 22 ¶
	<postal>	<postal>
	<street>2000 Innovation Drive</street>	<street>2000 Innovation Drive</street>
	<city>Kanata</city>	<city>Kanata</city>
	<region>Ontario</region>	<region>Ontario</region>
	<code>K2K 3E8</code>	<code>K2K 3E8</code>
	<country>Canada</country>	<country>Canada</country>
	</postal>	</postal>
	<email>msiva@cisco.com</email>	<email>msiva@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">

	<organization>Cisco Systems, Inc.</organization>	<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Pegasus Parc</street>	<street>Pegasus Parc</street>
	<city>De kleetlaan 6a</city>	<city>De kleetlaan 6a</city>

	<region>DIEGEM</region>	<region>Diegem</region>
	<code>BRABANT 1831</code>	<code>Brabant 1831</code>
	<country>BELGIUM</country>	<country>Belgium</country>
	</postal>	</postal>
	<email>cfilsfil@cisco.com</email>	<email>cfilsfil@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">	<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">

	<organization>Apstra, Inc.</organization>	<organization showOnFrontPage="true">Apstra, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>333 Middlefield Rd #200</street>	<street>333 Middlefield Rd #200</street>
	<city>Menlo Park</city>	<city>Menlo Park</city>
	<region>CA</region>	<region>CA</region>
	<code>94025</code>	<code>94025</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jefftant.ietf@gmail.com</email>	<email>jefftant.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Wim Henderickx" initials="W." surname="Henderickx">	<author fullname="Wim Henderickx" initials="W." surname="Henderickx">

	<organization>Nokia</organization>	<organization showOnFrontPage="true">Nokia</organization>
	<address>	<address>
	<postal>	<postal>

	<street>Copernicuslaan 50 </street>	<street>Copernicuslaan 50</street>
	<city>Antwerp 2018</city>	<city>Antwerp 2018</city>
	<region>CA</region>	<region>CA</region>
	<code>95134</code>	<code>95134</code>

	<country>BELGIUM</country>	<country>Belgium</country>
	</postal>	</postal>

	<email>wim.henderickx@alcatel-lucent.com</email>	<email>wim.henderickx@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Jon Hardwick" initials="J." surname="Hardwick">	<author fullname="Jon Hardwick" initials="J." surname="Hardwick">

	<organization>Metaswitch Networks</organization>	<organization showOnFrontPage="true">Metaswitch Networks</organization>
	<address>	<address>
	<postal>	<postal>
	<street>100 Church Street</street>	<street>100 Church Street</street>
	<city>Enfield</city>	<city>Enfield</city>
	<region>Middlesex</region>	<region>Middlesex</region>

	<country>UK</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>jonathan.hardwick@metaswitch.com</email>	<email>jonathan.hardwick@metaswitch.com</email>
	</address>	</address>
	</author>	</author>

		<date month="12" year="2019"/>
	<date day="4" month="March" year="2019" />

	<workgroup>PCE</workgroup>	<workgroup>PCE</workgroup>

		<keyword>SR</keyword>
	<abstract>	<keyword>Traffic-Engineering</keyword>
		<keyword>PCE</keyword>
	<t>Segment Routing (SR) enables any head-end node to select any path without rel	<abstract pn="section-abstract">
	ying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only	<t pn="section-abstract-1">Segment Routing (SR) enables any head-end node
	on "segments" that are advertised by link-state Interior Gateway Protocols (IGP	to select any path without relying on a hop-by-hop signaling technique (e.g., LD
	s). A Segment Routing Path can be derived from a variety of mechanisms, includin	P or RSVP-TE). It depends only on "segments" that are advertised by link-state I
	g an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation	nterior Gateway Protocols (IGPs). An SR path can be derived from a variety of me
	Element (PCE). This document specifies extensions to the Path Computation Eleme	chanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration,
	nt Communication Protocol (PCEP) that allow a stateful PCE to compute and initia	or a Path Computation Element (PCE). This document specifies extensions to the P
	te Traffic Engineering (TE) paths, as well as a PCC to request a path subject to	ath Computation Element Communication Protocol (PCEP) that allow a stateful PCE
	certain constraints and optimization criteria in SR networks.	to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Comput
		ation Client (PCC) to request a path subject to certain constraints and optimiza
		tion criteria in SR networks.</t>
		<t pn="section-abstract-2">
		This document updates RFC 8408.
	</t>	</t>

		</abstract>
		<boilerplate>
		<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
		"exclude" pn="section-boilerplate.1">
		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
		>
		<t pn="section-boilerplate.1-1">
		This is an Internet Standards Track document.
		</t>
		<t pn="section-boilerplate.1-2">
		This document is a product of the Internet Engineering Task Force
		(IETF). It represents the consensus of the IETF community. It has
		received public review and has been approved for publication by
		the Internet Engineering Steering Group (IESG). Further
		information on Internet Standards is available in Section 2 of
		RFC 7841.
		</t>
		<t pn="section-boilerplate.1-3">
		Information about the current status of this document, any
		errata, and how to provide feedback on it may be obtained at
		<eref target="https://www.rfc-editor.org/info/rfc8664" brackets="non
		e"/>.
		</t>
		</section>
		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
		ude" pn="section-boilerplate.2">
		<name slugifiedName="name-copyright-notice">Copyright Notice</name>
		<t pn="section-boilerplate.2-1">
		Copyright (c) 2019 IETF Trust and the persons identified as the
		document authors. All rights reserved.
		</t>
		<t pn="section-boilerplate.2-2">
		This document is subject to BCP 78 and the IETF Trust's Legal
		Provisions Relating to IETF Documents
		(<eref target="https://trustee.ietf.org/license-info" brackets="none
		"/>) in effect on the date of
		publication of this document. Please review these documents
		carefully, as they describe your rights and restrictions with
		respect to this document. Code Components extracted from this
		document must include Simplified BSD License text as described in
		Section 4.e of the Trust Legal Provisions and are provided without
		warranty as described in the Simplified BSD License.
		</t>
		</section>
		</boilerplate>
		<toc>
		<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
		n="section-toc.1">
		<name slugifiedName="name-table-of-contents">Table of Contents</name>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
		c.1-1">
		<li pn="section-toc.1-1.1">
		<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
		="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
		n</xref></t>
		</li>
		<li pn="section-toc.1-1.2">
		<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
		="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-terminology">Terminology<
		/xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.2.2">
		<li pn="section-toc.1-1.2.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
		dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-requirements-
		language">Requirements Language</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.3">
		<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
		="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-overview-of-pcep-operatio
		n-">Overview of PCEP Operation in SR Networks</xref></t>
		</li>
		<li pn="section-toc.1-1.4">
		<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
		="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-object-formats">Object Fo
		rmats</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.4.2">
		<li pn="section-toc.1-1.4.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derive
		dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-the-open-obje
		ct">The OPEN Object</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.4.2.1.2">
		<li pn="section-toc.1-1.4.2.1.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.1.1"><xre
		f derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-t
		he-path-setup-type-capabil">The Path Setup Type Capability TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.1.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.2.1"><xre
		f derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-t
		he-sr-pce-capability-sub-t">The SR PCE Capability Sub-TLV</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.4.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derive
		dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-the-rp-srp-ob
		ject">The RP/SRP Object</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derive
		dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-ero">ERO</xre
		f></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.4.2.3.2">
		<li pn="section-toc.1-1.4.2.3.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.1.1"><xre
		f derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-s
		r-ero-subobject">SR-ERO Subobject</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.3.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.2.1"><xre
		f derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-n
		ai-associated-with-sid">NAI Associated with SID</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.4.2.4">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derive
		dContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-rro">RRO</xre
		f></t>
		</li>
		<li pn="section-toc.1-1.4.2.5">
		<t keepWithNext="true" pn="section-toc.1-1.4.2.5.1"><xref derive
		dContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-metric-object
		">METRIC Object</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.5">
		<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
		="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-procedures">Procedures</x
		ref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.5.2">
		<li pn="section-toc.1-1.5.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derive
		dContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-exchanging-th
		e-sr-pce-capab">Exchanging the SR PCE Capability</xref></t>
		</li>
		<li pn="section-toc.1-1.5.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derive
		dContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-ero-processin
		g">ERO Processing</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.5.2.2.2">
		<li pn="section-toc.1-1.5.2.2.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.1.1"><xre
		f derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-s
		r-ero-validation">SR-ERO Validation</xref></t>
		</li>
		<li pn="section-toc.1-1.5.2.2.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.2.1"><xre
		f derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		nterpreting-the-sr-ero">Interpreting the SR-ERO</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.5.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.5.2.3.1"><xref derive
		dContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-rro-processin
		g">RRO Processing</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.6">
		<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
		="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-management-considerations
		">Management Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.6.2">
		<li pn="section-toc.1-1.6.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
		dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-controlling-t
		he-path-setup-">Controlling the Path Setup Type</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
		dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-migrating-a-n
		etwork-to-use-">Migrating a Network to Use PCEP Segment-Routed Paths</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.6.2.3.1"><xref derive
		dContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-verification-
		of-network-ope">Verification of Network Operation</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.4">
		<t keepWithNext="true" pn="section-toc.1-1.6.2.4.1"><xref derive
		dContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-relationship-
		to-existing-ma">Relationship to Existing Management Models</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.7">
		<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
		="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-security-considerations">
		Security Considerations</xref></t>
		</li>
		<li pn="section-toc.1-1.8">
		<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
		="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
		Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.8.2">
		<li pn="section-toc.1-1.8.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derive
		dContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-pcep-ero-and-
		rro-subobjects">PCEP ERO and RRO Subobjects</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derive
		dContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-new-nai-type-
		registry">New NAI Type Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.3.1"><xref derive
		dContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-new-sr-ero-fl
		ag-registry">New SR-ERO Flag Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.4">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.4.1"><xref derive
		dContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-pcep-error-ob
		ject">PCEP-Error Object</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.5">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.5.1"><xref derive
		dContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-pcep-tlv-type
		-indicators">PCEP TLV Type Indicators</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.6">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.6.1"><xref derive
		dContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-path-setup-ty
		pe-capability-">PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.7">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.7.1"><xref derive
		dContent="8.7" format="counter" sectionFormat="of" target="section-8.7"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-new-path-setu
		p-type">New Path Setup Type</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.8">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.8.1"><xref derive
		dContent="8.8" format="counter" sectionFormat="of" target="section-8.8"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-new-metric-ty
		pe">New Metric Type</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.9">
		<t keepWithNext="true" pn="section-toc.1-1.8.2.9.1"><xref derive
		dContent="8.9" format="counter" sectionFormat="of" target="section-8.9"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-sr-pce-capabi
		lity-flags">SR PCE Capability Flags</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.9">
		<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
		="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedCon
		tent="" format="title" sectionFormat="of" target="name-references">References</x
		ref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.9.2">
		<li pn="section-toc.1-1.9.2.1">
		<t keepWithNext="true" pn="section-toc.1-1.9.2.1.1"><xref derive
		dContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
		erences">Normative References</xref></t>
		</li>
		<li pn="section-toc.1-1.9.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.9.2.2.1"><xref derive
		dContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
		eferences">Informative References</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.10">
		<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
		t="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>
		. <xref derivedContent="" format="title" sectionFormat="of" target="name-compat
		ibility-with-early-im">Compatibility with Early Implementations</xref></t>
		</li>
		<li pn="section-toc.1-1.11">
		<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
		t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
		Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
		owledgements</xref></t>
		</li>
		<li pn="section-toc.1-1.12">
		<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
		t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
		Content="" format="title" sectionFormat="of" target="name-contributors">Contribu
		tors</xref></t>
		</li>
		<li pn="section-toc.1-1.13">
		<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
		t="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derived
		Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
		hors' Addresses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
		</front>
		<middle>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
		<name slugifiedName="name-introduction">Introduction</name>
		<t pn="section-1-1">Segment Routing (SR) leverages the source-routing para
		digm. Using
		SR, a source node steers a packet through a path without relying on
		hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is
		specified as an ordered list of instructions called "segments". Each
		segment is an instruction to route the packet to a specific place in
		the network or to perform a function on the packet. A database of
		segments can be distributed through the network using a routing
		protocol (such as IS-IS or OSPF) or by any other means. Several types
		of segments are defined. A node segment uniquely identifies a specific
		node in the SR domain. Each router in the SR domain associates a node
		segment with an ECMP-aware shortest path to the node that it
		identifies. An adjacency segment represents a unidirectional
		adjacency. An adjacency segment is local to the node that advertises
		it. Both node segments and adjacency segments can be used for SR.</t>
		<t pn="section-1-2"><xref target="RFC8402" format="default" sectionFormat=
		"of" derivedContent="RFC8402"/> describes the SR architecture. The
		corresponding IS-IS and OSPF extensions are specified in <xref target="RFC8667"
		format="default" sectionFormat="of" derivedContent="RFC8667"/> and <xref target=
		"RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, respec
		tively.</t>
		<t pn="section-1-3">The SR architecture can be implemented using either an
		MPLS
		forwarding plane <xref target="RFC8660" format="default" sectionFormat="of" deri
		vedContent="RFC8660"/> or an IPv6 forwarding plane
		<xref target="I-D.ietf-6man-segment-routing-header" format="default" sectionForm
		at="of" derivedContent="IPv6-SRH"/>. The MPLS forwarding plane can be applied
		to SR without any change; in which case, an SR path corresponds to an
		MPLS Label Switching Path (LSP). This document is relevant to the MPLS
		forwarding plane only. In this document, "Node-SID" and
		"Adj-SID" denote the Node Segment Identifier and Adjacency
		Segment Identifier, respectively.</t>
		<t pn="section-1-4">An SR path can be derived from an IGP Shortest Path Tr
		ee
		(SPT). Segment Routing Traffic-Engineering (SR-TE) paths may not
		follow an IGP SPT. Such paths may be chosen by a suitable network
		planning tool and provisioned on the ingress node of the SR-TE
		path.</t>
		<t pn="section-1-5"><xref target="RFC5440" format="default" sectionFormat=
		"of" derivedContent="RFC5440"/> describes the Path Computation Element
		Communication Protocol (PCEP) for communication between a Path
		Computation Client (PCC) and a Path Computation Element (PCE) or
		between a pair of PCEs. A PCE computes paths for MPLS
		Traffic-Engineering (MPLS-TE) LSPs based on various constraints and
		optimization criteria. <xref target="RFC8231" format="default" sectionFormat="of
		" derivedContent="RFC8231"/> specifies extensions
		to PCEP that allow a stateful PCE to compute and recommend network
		paths in compliance with <xref target="RFC4657" format="default" sectionFormat="
		of" derivedContent="RFC4657"/>. It also defines objects
		and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide
		synchronization of LSP state between a PCC and a PCE or between a pair
		of PCEs, delegation of LSP control, reporting of LSP state from a PCC
		to a PCE, and control of the setup and path routing of an LSP from a
		PCE to a PCC. Stateful PCEP extensions are intended for an operational
		model in which LSPs are configured on the PCC, and control over them
		is delegated to the PCE.</t>
		<t pn="section-1-6">A mechanism to dynamically initiate LSPs on a PCC base
		d on the requests from a stateful PCE or a controller using stateful PCE is spec
		ified in <xref target="RFC8281" format="default" sectionFormat="of" derivedConte
		nt="RFC8281"/>. This mechanism is useful in Software-Defined Networking (SDN) ap
		plications, such as on-demand engineering or bandwidth calendaring <xref target=
		"RFC8413" format="default" sectionFormat="of" derivedContent="RFC8413"/>.</t>
		<t pn="section-1-7">It is possible to use a stateful PCE for computing one
		or more SR-TE paths, taking into account various constraints and objective func
		tions. Once a path is chosen, the stateful PCE can initiate an SR-TE path on a P
		CC using the PCEP extensions specified in <xref target="RFC8281" format="default
		" sectionFormat="of" derivedContent="RFC8281"/> and the SR-specific PCEP extensi
		ons specified in this document. Additionally, using procedures described in this
		document, a PCC can request an SR path from either a stateful or a stateless PC
		E.</t>
		<t pn="section-1-8">This specification relies on the procedures specified
		in <xref target="RFC8408" format="default" sectionFormat="of" derivedContent="RF
		C8408"/> to exchange the Segment Routing capability and to specify that the path
		setup type of an LSP is Segment Routing. This specification also updates <xref
		target="RFC8408" format="default" sectionFormat="of" derivedContent="RFC8408"/>
		to clarify the use of sub-TLVs in the PATH-SETUP-TYPE-CAPABILITY TLV. See <xre
		f target="pst-cap-tlv" format="default" sectionFormat="of" derivedContent="Secti
		on 4.1.1"/> for details.</t>
		<t pn="section-1-9">This specification provides a mechanism for a network
		controller (acting as a PCE) to instantiate candidate paths for an SR Policy ont
		o a head-end node (acting as a PCC) using PCEP. For more information on the SR
		Policy Architecture, see <xref target="I-D.ietf-spring-segment-routing-policy" f
		ormat="default" sectionFormat="of" derivedContent="SR-POLICY"/>.</t>
		</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
		<name slugifiedName="name-terminology">Terminology</name>
		<t pn="section-2-1">The following terminology is used in this document:


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

	</note>	<dl newline="false" spacing="normal" indent="8" pn="section-2-2">
		<dt pn="section-2-2.1">ERO:</dt>
	</front>	<dd pn="section-2-2.2"> Explicit Route Object</dd>
		<dt pn="section-2-2.3">IGP:</dt>
	<middle>	<dd pn="section-2-2.4"> Interior Gateway Protocol</dd>
		<dt pn="section-2-2.5">IS-IS:</dt>
	<section title="Introduction">	<dd pn="section-2-2.6"> Intermediate System to Intermediate System</dd>
		<dt pn="section-2-2.7">LSR:</dt>
	<t>Segment Routing (SR) leverages the source routing paradigm. Using SR, a sourc	<dd pn="section-2-2.8"> Label Switching Router</dd>
	e node steers a packet through a path without relying on hop-by-hop signaling pr	<dt pn="section-2-2.9">MSD:</dt>
	otocols such as LDP or RSVP-TE. Each path is specified as an ordered list of ins	<dd pn="section-2-2.10"> Base MPLS Imposition Maximum SID Depth, as defi
	tructions called "segments". Each segment is an instruction to route the packet	ned in <xref target="RFC8491" format="default" sectionFormat="of" derivedContent
	to a specific place in the network, or to perform a function on the packet. A	="RFC8491"/></dd>
	database of segments can be distributed through the network using a routing prot	<dt pn="section-2-2.11">NAI:</dt>
	ocol (such as IS-IS or OSPF) or by any other means. Several types of segment ar	<dd pn="section-2-2.12"> Node or Adjacency Identifier</dd>
	e defined. A node segment uniquely identifies a specific node in the SR domain.	<dt pn="section-2-2.13">OSPF:</dt>
	Each router in the SR domain associates a node segment with an ECMP-aware shorte	<dd pn="section-2-2.14"> Open Shortest Path First</dd>
	st path to the node that it identifies. An adjacency segment represents a unidir	<dt pn="section-2-2.15">PCC:</dt>
	ectional adjacency. An adjacency segment is local to the node which advertises i	<dd pn="section-2-2.16"> Path Computation Client</dd>
	t. Both node segments and adjacency segments can be used for SR.</t>	<dt pn="section-2-2.17">PCE:</dt>
		<dd pn="section-2-2.18"> Path Computation Element</dd>
	<t><xref target="RFC8402"/> describes the SR architecture. The corresponding IS	<dt pn="section-2-2.19">PCEP:</dt>
	-IS and OSPF extensions are specified in <xref target="I-D.ietf-isis-segment-rou	<dd pn="section-2-2.20"> Path Computation Element Communication Protocol
	ting-extensions"/> and <xref target="I-D.ietf-ospf-segment-routing-extensions"/>	</dd>
	, respectively.</t>	<dt pn="section-2-2.21">RRO:</dt>
		<dd pn="section-2-2.22"> Record Route Object</dd>
	<t>The SR architecture can be implemented using either an MPLS forwarding plane	<dt pn="section-2-2.23">SID:</dt>
	<xref target="I-D.ietf-spring-segment-routing-mpls"/> or an IPv6 forwarding plan	<dd pn="section-2-2.24"> Segment Identifier</dd>
	e <xref target="I-D.ietf-6man-segment-routing-header"/>. The MPLS forwarding pl	<dt pn="section-2-2.25">SR:</dt>
	ane can be applied to SR without any change, in which case an SR path correspond	<dd pn="section-2-2.26"> Segment Routing</dd>
	s to an MPLS Label Switching Path (LSP). This document is relevant to the MPLS f	<dt pn="section-2-2.27">SR-DB:</dt>
	orwarding plane only. In this document, "Node-SID" and "Adjacency-SID" denote No	<dd pn="section-2-2.28"> Segment Routing Database: the collection of SRG
	de Segment Identifier and Adjacency Segment Identifier respectively.</t>	Bs, SRLBs, and SIDs and the objects they map to, advertised by a link-state IGP<
		/dd>
	<t>A Segment Routing path (SR path) can be derived from an IGP Shortest Path Tre	<dt pn="section-2-2.29">SR-TE:</dt>
	e (SPT). SR-TE paths may not follow an IGP SPT. Such paths may be chosen by a su	<dd pn="section-2-2.30"> Segment Routing Traffic Engineering</dd>
	itable network planning tool and provisioned on the ingress node of the SR-TE pa	<dt pn="section-2-2.31">SRGB:</dt>
	th.</t>	<dd pn="section-2-2.32"> Segment Routing Global Block</dd>
		<dt pn="section-2-2.33">SRLB:</dt>
	<t> <xref target="RFC5440"/> describes the Path Computation Element Communicatio	<dd pn="section-2-2.34"> Segment Routing Local Block</dd>
	n Protocol (PCEP) for communication between a Path Computation Client (PCC) and	</dl>
	a Path Computation Element (PCE) or between a pair of PCEs. A PCE computes paths	<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1
	for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints a	">
	nd optimization criteria. <xref target="RFC8231"/> specifies extensions to PCEP	<name slugifiedName="name-requirements-language">Requirements Language</
	that allow a stateful PCE to compute and recommend network paths in compliance w	name>
	ith <xref target="RFC4657"/> and defines objects and TLVs for MPLS-TE LSPs. Stat	<t pn="section-2.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST
	eful PCEP extensions provide synchronization of LSP state between a PCC and a PC	NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL N
	E or between a pair of PCEs, delegation of LSP control, reporting of LSP state f	OT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOM
	rom a PCC to a PCE, controlling the setup and path routing of an LSP from a PCE	MENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	to a PCC. Stateful PCEP extensions are intended for an operational model in whic	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	h LSPs are configured on the PCC, and control over them is delegated to the PCE.	be interpreted as
	</t>	described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
	<t>A mechanism to dynamically initiate LSPs on a PCC based on the requests from	mat="of" derivedContent="RFC8174"/>
	a stateful PCE or a controller using stateful PCE is specified in <xref target="	when, and only when, they appear in all capitals, as shown here.
	RFC8281"/>. This mechanism is useful in Software Defined Networking (SDN) applic	</t>
	ations, such as on-demand engineering, or bandwidth calendaring <xref target="RF	</section>
	C8413"/>.</t>	</section>
		<section anchor="Operation-Overview" numbered="true" toc="include" removeInR
	<t>It is possible to use a stateful PCE for computing one or more SR-TE paths ta	FC="false" pn="section-3">
	king into account various constraints and objective functions. Once a path is ch	<name slugifiedName="name-overview-of-pcep-operation-">Overview of PCEP Op
	osen, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions	eration in SR Networks</name>
	specified in <xref target="RFC8281"/> using the SR specific PCEP extensions spe	<t pn="section-3-1">In an SR network, the ingress node of an SR path prepe
	cified in this document. Additionally, using procedures described in this docume	nds an SR header to all outgoing packets. The SR header consists of a list of S
	nt, a PCC can request an SR path from either a stateful or a stateless PCE.</t>	IDs (or MPLS labels in the context of this document). The header has all

	<t>This specification relies on the procedures specified in <xref target="RFC840
	8"/> to exchange the segment routing capability and to specify that the path set
	up type of an LSP is segment routing. This specification also updates <xref tar
	get="RFC8408"/> to clarify the use of sub-TLVs in the PATH-SETUP-TYPE-CAPABILITY
	TLV. See <xref target="pst-cap-tlv"/> for details.</t>

	<t>This specification provides a mechanism for a network controller (acting as a
	PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acti
	ng as a PCC) using PCEP. For more information on the SR Policy Architecture, se
	e <xref target="I-D.ietf-spring-segment-routing-policy"/>.</t>

	</section> <!-- Introduction -->

	<section title="Terminology">

	<t>The following terminologies are used in this document:

	<list style="hanging">
	<t hangText="ERO:"> Explicit Route Object</t>
	<t hangText="IGP:"> Interior Gateway Protocol</t>
	<t hangText="IS-IS:"> Intermediate System to Intermediate System</t>
	<t hangText="LSR:"> Label Switching Router</t>
	<t hangText="MSD:"> Base MPLS Imposition Maximum SID Depth, as defined in
	<xref target="RFC8491"/></t>
	<t hangText="NAI:"> Node or Adjacency Identifier</t>
	<t hangText="OSPF:"> Open Shortest Path First</t>
	<t hangText="PCC:"> Path Computation Client</t>
	<t hangText="PCE:"> Path Computation Element</t>
	<t hangText="PCEP:"> Path Computation Element Communication Protocol</t>
	<t hangText="RRO:"> Record Route Object</t>
	<t hangText="SID:"> Segment Identifier</t>
	<t hangText="SR:"> Segment Routing</t>
	<t hangText="SR-DB:"> Segment Routing Database: the collection of SRGBs, S
	RLBs and SIDs and the objects they map to, advertised by a link state IGP</t>
	<t hangText="SRGB:"> Segment Routing Global Block</t>
	<t hangText="SRLB:"> Segment Routing Local Block</t>
	<t hangText="SR-TE:"> Segment Routing Traffic Engineering</t>
	</list>

	</t>

	</section> <!-- Terminology -->

	<section anchor="Operation-Overview" title="Overview of PCEP Operation in SR Net
	works">

	<t>In an SR network, the ingress node of an SR path prepends an SR header to all
	outgoing packets. The SR header consists of a list of SIDs (or MPLS labels in
	the context of this document). The header has all
	necessary information so that, in combination with the information	necessary information so that, in combination with the information
	distributed by the IGP, the packets can be guided from the ingress	distributed by the IGP, the packets can be guided from the ingress
	node to the egress node of the path; hence, there is no need for	node to the egress node of the path; hence, there is no need for
	any signaling protocol.	any signaling protocol.
	</t>	</t>

		<t pn="section-3-2">
	<t>
	In PCEP messages, LSP route information is carried in the Explicit	In PCEP messages, LSP route information is carried in the Explicit
	Route Object (ERO), which consists of a sequence of subobjects.	Route Object (ERO), which consists of a sequence of subobjects.
	SR-TE paths computed by a PCE can be represented in an ERO in one	SR-TE paths computed by a PCE can be represented in an ERO in one
	of the following forms:	of the following forms:


	<list style="symbols">

	<t>An ordered set of IP addresses representing network nodes/links.</t>

	<t>An ordered set of SIDs, with or without the corresponding IP addresses.</t>

	<t>An ordered set of MPLS labels, with or without corresponding IP address.</t>

	</list>

	The PCC converts these into an MPLS label stack and next hop, as described in <x
	ref target="SR-ERO-INTERPRET"/>.

	</t>	</t>

		<ul spacing="normal" bare="false" empty="false" pn="section-3-3">
		<li pn="section-3-3.1">An ordered set of IP addresses representing netwo
		rk nodes/links.</li>
		<li pn="section-3-3.2">An ordered set of SIDs, with or without the corre
		sponding IP addresses.</li>
		<li pn="section-3-3.3">An ordered set of MPLS labels, with or without co
		rresponding IP addresses.</li>
		</ul>
		<t pn="section-3-4">


	<t>This document defines a new ERO subobject denoted by "SR-ERO subobject" capab	The PCC converts these into an MPLS label stack and next hop, as described in <x
	le of carrying a SID as well as the identity of the node/adjacency represented b	ref target="SR-ERO-INTERPRET" format="default" sectionFormat="of" derivedContent
	y the SID. SR-capable PCEP speakers should be able to generate and/or process su	="Section 5.2.2"/>.
	ch ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCE
	P Path Computation Reply (PCRep) message defined in <xref target="RFC5440"/>, th
	e PCEP LSP Initiate Request message (PCInitiate) defined in <xref target="RFC828
	1"/>, as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Repor
	t (PCRpt) messages defined in <xref target="RFC8231"/>.</t>

	<t>When a PCEP session between a PCC and a PCE is established, both PCEP speaker
	s exchange their capabilities to indicate their ability to support SR-specific f
	unctionality.</t>

	<t>A PCE can update an LSP that is initially established via RSVP-TE signaling t
	o use an SR-TE path, by sending a PCUpd to the PCC that delegated the LSP to it
	(<xref target="RFC8231"/>). A PCC can update an undelegated LSP that is initial
	ly established via RSVP-TE signaling to use an SR-TE path as follows. First, it
	requests an SR-TE Path from a PCE by sending a PCReq message. If it receives a
	suitable path, it establishes the path in the data plane, and then tears down t
	he original RSVP-TE path. If the PCE is stateful, then the PCC sends PCRpt mess
	ages indicating that the new path is set up and the old path is torn down, per <
	xref target="RFC8231"/>.</t>

	<t>Similarly, a PCE or PCC can update an LSP initially created with an SR-TE pat
	h to use RSVP-TE signaling, if necessary. This capability is useful for rolling
	back a change when a network is migrated from RSVP-TE to SR-TE technology.</t>

	<t>A PCC MAY include an RRO containing the recorded LSP in PCReq and PCRpt messa
	ges as specified in <xref target="RFC5440"/> and <xref target="RFC8231"/>, respe
	ctively. This document defines a new RRO subobject for SR networks. The methods
	used by a PCC to record the SR-TE LSP are outside the scope of this document.</t
	>

	<t>In summary, this document:

	<list style="symbols">

	<t>Defines a new ERO subobject, a new RRO subobject and new PCEP error c
	odes.</t>

	<t>Specifies how two PCEP speakers can establish a PCEP session that can
	carry information about SR-TE paths.</t>

	<t>Specifies processing rules for the ERO subobject.</t>

	<t>Defines a new path setup type to be used in the PATH-SETUP-TYPE and P
	ATH-SETUP-TYPE-CAPABILITY TLVs (<xref target="RFC8408"/>).</t>

	<t>Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV.</t
	>

	</list>

	</t>

	<t>The extensions specified in this document complement the existing PCEP specif
	ications to support SR-TE paths. As such, the PCEP messages (e.g., Path Computat
	ion Request, Path Computation Reply, Path Computation Report, Path Computation U
	pdate, Path Computation Initiate, etc.,) are formatted according to <xref target
	="RFC5440"/>, <xref target="RFC8231"/>, <xref target="RFC8281"/>, and any other
	applicable PCEP specifications.</t>

	</section> <!-- Overview of PCEP Operation in SR Networks -->

	<section anchor="object-formats" title="Object Formats">

	<section anchor="open-object-fmt" title="The OPEN Object">

	<section anchor="pst-cap-tlv" title="The Path Setup Type Capability TLV">

	<t><xref target="RFC8408"/> defines the PATH-SETUP-TYPE-CAPABILITY TLV for use i
	n the OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional list
	of sub-TLVs which are intended to convey parameters that are associated with th
	e path setup types supported by a PCEP speaker.</t>

	<t>This specification updates <xref target="RFC8408"/>, as follows. It creates
	a new registry which defines the valid type indicators of the sub-TLVs of the PA
	TH-SETUP-TYPE-CAPABILITY TLV (see <xref target="IANA-subTLV-Type-Indicators"/>).
	A PCEP speaker MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TL
	V unless it appears in this registry. If a PCEP speaker receives a sub-TLV whos
	e type indicator does not match one of those from the registry, or else is not r
	ecognised by the speaker, then the speaker MUST ignore the sub-TLV.</t>

	</section>

	<section anchor="cap-negotiation" title="The SR PCE Capability sub-TLV">


	<t>This document defines a new Path Setup Type (PST) for SR, as follows:
	<list style="symbols">
	<t>PST = 1: Path is setup using Segment Routing Traffic Engineering.</t>
	</list>
	</t>	</t>

		<t pn="section-3-5">This document defines a new ERO subobject denoted by "
		SR-ERO subobject" that is capable of carrying a SID as well as the identity of t
		he node/adjacency represented by the SID. SR-capable PCEP speakers should be abl
		e to generate and/or process such an ERO subobject.
		An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation
		Reply (PCRep) message defined in <xref target="RFC5440" format="default" sectio
		nFormat="of" derivedContent="RFC5440"/>, the Path Computation LSP Initiate Reque
		st (PCInitiate) message defined in <xref target="RFC8281" format="default" secti
		onFormat="of" derivedContent="RFC8281"/>, and the Path Computation Update Reques
		t (PCUpd) and Path Computation State Report (PCRpt) messages for LSPs defined in
		<xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8
		231"/>.</t>
		<t pn="section-3-6">When a PCEP session between a PCC and a PCE is establi
		shed, both PCEP speakers exchange their capabilities to indicate their ability t
		o support SR-specific functionality.</t>
		<t pn="section-3-7">A PCE can update an LSP that is initially established
		via RSVP-TE
		signaling to use an SR-TE path by sending a PCUpd to the PCC that
		delegated the LSP to it <xref target="RFC8231" format="default" sectionFormat="o
		f" derivedContent="RFC8231"/>. A PCC can update an
		undelegated LSP that is initially established via RSVP-TE signaling to
		use an SR-TE path as follows. First, it requests an SR-TE path from a
		PCE by sending a Path Computation Request (PCReq) message. If it
		receives a suitable path, it establishes the path in the data plane
		and then tears down the original RSVP-TE path. If the PCE is
		stateful, then the PCC sends PCRpt messages indicating that the new
		path is set up and the old path is torn down, per <xref target="RFC8231" format=
		"default" sectionFormat="of" derivedContent="RFC8231"/>.</t>
		<t pn="section-3-8">Similarly, a PCE or PCC can update an LSP initially cr
		eated with an SR-TE path to use RSVP-TE signaling, if necessary. This capability
		is useful for rolling back a change when a network is migrated from RSVP-TE to
		SR-TE technology.</t>
		<t pn="section-3-9">A PCC <bcp14>MAY</bcp14> include a Record Route Object
		(RRO) containing the recorded LSP in PCReq and PCRpt messages as specified in <
		xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC544
		0"/> and <xref target="RFC8231" format="default" sectionFormat="of" derivedConte
		nt="RFC8231"/>, respectively. This document defines a new RRO subobject for SR n
		etworks. The methods used by a PCC to record the SR-TE LSP are outside the scope
		of this document.</t>
		<t pn="section-3-10">In summary, this document:


	<t>A PCEP speaker SHOULD indicate its support of the function described in this	</t>
	document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with thi	<ul spacing="normal" bare="false" empty="false" pn="section-3-11">
	s new PST included in the PST list.</t>	<li pn="section-3-11.1">Defines a new ERO subobject, a new RRO subobject
		, and new PCEP error codes.</li>
	<t>This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP speakers use	<li pn="section-3-11.2">Specifies how two PCEP speakers can establish a
	this sub-TLV to exchange information about their SR capability. If a PCEP speake	PCEP session that can carry information about SR-TE paths.</li>
	r includes PST=1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it M	<li pn="section-3-11.3">Specifies processing rules for the ERO subobject
	UST also include the SR-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABI	.</li>
	LITY TLV.</t>	<li pn="section-3-11.4">Defines a new path setup type to be used in the
		PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs <xref target="RFC8408" forma
	<t>The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following figure:	t="default" sectionFormat="of" derivedContent="RFC8408"/>.</li>
	</t>	<li pn="section-3-11.5">Defines a new sub-TLV for the PATH-SETUP-TYPE-CA
		PABILITY TLV.</li>
	<figure anchor="Capability-TLV-Fmt" title="SR-PCE-CAPABILITY sub-TLV format">	</ul>
	<artwork align="center"><![CDATA[	<t pn="section-3-12">The extensions specified in this document complement
	0 1 2 3	the existing
	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	PCEP specifications to support SR-TE paths. As such, the PCEP messages
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	(e.g., PCReq, PCRep, PCRpt, PCUpd, PCInitiate, etc.) are formatted
	\| Type=TBD11 \| Length=4 \|	according to <xref target="RFC5440" format="default" sectionFormat="of" derivedC
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	ontent="RFC5440"/>, <xref target="RFC8231" format="default" sectionFormat="of" d
	\| Reserved \| Flags \|N\|X\| MSD \|	erivedContent="RFC8231"/>, <xref target="RFC8281" format="default" sectionFormat
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	="of" derivedContent="RFC8281"/>, and any other applicable PCEP specifications.<
		/t>
	]]></artwork>	</section>
		<section anchor="object-formats" numbered="true" toc="include" removeInRFC="
		false" pn="section-4">
		<name slugifiedName="name-object-formats">Object Formats</name>
		<section anchor="open-object-fmt" numbered="true" toc="include" removeInRF
		C="false" pn="section-4.1">
		<name slugifiedName="name-the-open-object">The OPEN Object</name>
		<section anchor="pst-cap-tlv" numbered="true" toc="include" removeInRFC=
		"false" pn="section-4.1.1">
		<name slugifiedName="name-the-path-setup-type-capabil">The Path Setup
		Type Capability TLV</name>
		<t pn="section-4.1.1-1"><xref target="RFC8408" format="default" sectio
		nFormat="of" derivedContent="RFC8408"/> defines the PATH-SETUP-TYPE-CAPABILITY T
		LV
		for use in the OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV
		contains an optional list of sub-TLVs, which are intended to convey
		parameters that are associated with the path setup types supported by
		a PCEP speaker.</t>
		<t pn="section-4.1.1-2">This specification updates <xref target="RFC84
		08" format="default" sectionFormat="of" derivedContent="RFC8408"/> as follows.
		It
		creates a new registry that defines the valid type indicators of the
		sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV (see <xref target="IANA-subTLV-Ty
		pe-Indicators" format="default" sectionFormat="of" derivedContent="Section 8.6"/
		>). A PCEP speaker <bcp14>MUST NOT</bcp14>
		include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV unless it
		appears in this registry. If a PCEP speaker receives a sub-TLV whose
		type indicator does not match one of those from the registry or is not
		recognized by the speaker, then the speaker <bcp14>MUST</bcp14> ignore the
		sub-TLV.</t>
		</section>
		<section anchor="cap-negotiation" numbered="true" toc="include" removeIn
		RFC="false" pn="section-4.1.2">
		<name slugifiedName="name-the-sr-pce-capability-sub-t">The SR PCE Capa
		bility Sub-TLV</name>
		<t pn="section-4.1.2-1">This document defines a new Path Setup Type (P
		ST) for SR, as follows:
		</t>
		<ul spacing="normal" empty="true" bare="false" pn="section-4.1.2-2">
		<li pn="section-4.1.2-2.1">
		<dl newline="false" spacing="normal" pn="section-4.1.2-2.1.1">
		<dt pn="section-4.1.2-2.1.1.1">PST = 1:</dt>
		<dd pn="section-4.1.2-2.1.1.2">Traffic-engineering path is set u
		p using Segment Routing.</dd>
		</dl>
		</li>
		</ul>
		<t pn="section-4.1.2-3">A PCEP speaker <bcp14>SHOULD</bcp14> indicate
		its support of the function described in this document by sending a PATH-SETUP-T
		YPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list
		.</t>
		<t pn="section-4.1.2-4">This document also defines the SR-PCE-CAPABILI
		TY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their
		SR capability. If a PCEP speaker includes PST=1 in the PST list of the PATH-SETU
		P-TYPE-CAPABILITY TLV, then it <bcp14>MUST</bcp14> also include the SR-PCE-CAPAB
		ILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV.</t>
		<t pn="section-4.1.2-5">The format of the SR-PCE-CAPABILITY sub-TLV is
		shown in the following figure:</t>
		<figure anchor="Capability-TLV-Fmt" align="left" suppress-title="false
		" pn="figure-1">
		<name slugifiedName="name-sr-pce-capability-sub-tlv-f">SR-PCE-CAPABI
		LITY Sub-TLV Format</name>
		<artwork align="center" name="" type="" alt="" pn="section-4.1.2-6.1
		">
		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Type=26 \| Length=4 \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Reserved \| Flags \|N\|X\| MSD \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
	</figure>	</figure>

		<t pn="section-4.1.2-7">The codepoint for the TLV type is 26. The TLV
	<t>The code point for the TLV type is TBD11. The TLV length is 4 octets.</t>	length is 4 octets.</t>
		<t pn="section-4.1.2-8">The 32-bit value is formatted as follows.
	<t>The 32-bit value is formatted as follows.	</t>
	<list style="hanging">	<dl newline="false" spacing="normal" pn="section-4.1.2-9">
	<t hangText="Reserved:"> MUST be set to zero by the sender and MUST be ignor	<dt pn="section-4.1.2-9.1">Reserved:</dt>
	ed by the receiver.</t>	<dd pn="section-4.1.2-9.2">
	<t hangText="Flags:"> This document defines the following flag bits. The ot	<bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</
	her bits	bcp14> be ignored by the receiver.</dd>
	MUST be set to zero by the sender and MUST be ignored by the receiver.	<dt pn="section-4.1.2-9.3">Flags:</dt>
	<list style="symbols">	<dd pn="section-4.1.2-9.4">
	<t>N: A PCC sets this flag bit to 1 to indicate that it is capable of re	<t pn="section-4.1.2-9.4.1"> This document defines the following f
	solving a Node or Adjacency Identifier (NAI) to a SID.</t>	lag bits. The other bits
	<t>X: A PCC sets this flag bit to 1 to indicate that it does not impose	<bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> b
	any limit on the MSD.</t>	e ignored by the receiver.
	</list>	</t>
	</t>	<ul spacing="normal" empty="true" bare="false" pn="section-4.1.2-9
	<t hangText="Maximum SID Depth (MSD):"> specifies the maximum number of SIDs	.4.2">
	(MPLS label stack depth in the context of this document) that a PCC is capable	<li pn="section-4.1.2-9.4.2.1">
	of imposing on a packet. <xref target="SR-CAP-PROCESS"/> explains the relations	<dl indent="5" newline="false" spacing="normal" pn="section-4.
	hip between this field and the X flag.</t>	1.2-9.4.2.1.1">
	</list>	<dt pn="section-4.1.2-9.4.2.1.1.1">N:</dt>
	</t>	<dd pn="section-4.1.2-9.4.2.1.1.2">A PCC sets this flag bit
		to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier
	</section>	(NAI) to a SID.</dd>
		<dt pn="section-4.1.2-9.4.2.1.1.3">X:</dt>
	</section>	<dd pn="section-4.1.2-9.4.2.1.1.4">A PCC sets this flag bit
		to 1 to indicate that it does not impose any limit on the MSD.</dd>
	<section anchor="rp-object-fmt" title="The RP/SRP Object">	</dl>
		</li>
	<t>To set up an SR-TE LSP using SR, the RP (Request Parameters) or SRP (Stateful	</ul>
	PCE Request Parameters) object MUST include the PATH-SETUP-TYPE TLV, specified	</dd>
	in <xref target="RFC8408"/>, with the PST set to 1 (path setup using SR-TE).</t>	<dt pn="section-4.1.2-9.5">Maximum SID Depth (MSD):</dt>
		<dd pn="section-4.1.2-9.6"> specifies the maximum number of SIDs (MP
	<t>The LSP-IDENTIFIERS TLV MAY be present for the above PST type.</t>	LS label stack depth in the context of this document) that a PCC is capable of i
		mposing on a packet. <xref target="SR-CAP-PROCESS" format="default" sectionForm
	</section>	at="of" derivedContent="Section 5.1"/> explains the relationship between this fi
		eld and the X-Flag.</dd>
	<section anchor="SR-ERO" title="ERO">	</dl>
		</section>
	<t>An SR-TE path consists of one or more SIDs where each SID MAY be associated w	</section>
	ith the identifier that represents the node or adjacency corresponding to the SI	<section anchor="rp-object-fmt" numbered="true" toc="include" removeInRFC=
	D. This identifier is referred to as the 'Node or Adjacency Identifier' (NAI). A	"false" pn="section-4.2">
	s described later, a NAI can be represented in various formats (e.g., IPv4 addre	<name slugifiedName="name-the-rp-srp-object">The RP/SRP Object</name>
	ss, IPv6 address, etc). Furthermore, a NAI is used for troubleshooting purposes	<t pn="section-4.2-1">To set up an SR-TE LSP using SR, the Request Param
	and, if necessary, to derive SID value as described below.</t>	eter (RP) or Stateful PCE Request Parameter (SRP) object <bcp14>MUST</bcp14> inc
		lude the PATH-SETUP-TYPE TLV, specified in <xref target="RFC8408" format="defaul
	<t>The ERO specified in <xref target="RFC5440"/> is used to carry SR-TE path inf	t" sectionFormat="of" derivedContent="RFC8408"/>, with the PST set to 1 (and pat
	ormation. In order to carry SID and/or NAI, this document defines a new ERO subo	h setup using SR-TE).</t>
	bject referred to as "SR-ERO subobject" whose format is specified in the followi	<t pn="section-4.2-2">The LSP-IDENTIFIERS TLV <bcp14>MAY</bcp14> be pres
	ng section. An ERO carrying an SR-TE path consists of one or more ERO subobjects	ent for the above PST type.</t>
	, and MUST carry only SR-ERO subobjects. Note that an SR-ERO subobject does not	</section>
	need to have both SID and NAI. However, at least one of them MUST be present.</t	<section anchor="SR-ERO" numbered="true" toc="include" removeInRFC="false"
	>	pn="section-4.3">
		<name slugifiedName="name-ero">ERO</name>
	<t>When building the MPLS label stack from ERO, a PCC MUST assume that SR-ERO su	<t pn="section-4.3-1">An SR-TE path consists of one or more SIDs where e
	bobjects are organized as a last-in-first-out stack. The first subobject relati	ach SID <bcp14>MAY</bcp14> be associated with the identifier that represents the
	ve to the beginning of ERO contains the information about the topmost label. The	node or adjacency corresponding to the SID. This identifier is referred to as t
	last subobject contains information about the bottommost label.</t>	he NAI. As described later, an NAI can be represented in various formats (e.g.,
		IPv4 address, IPv6 address, etc). Furthermore, an NAI is used for troubleshootin
	<section anchor="SR-ERO-SUB" title="SR-ERO Subobject">	g purposes and, if necessary, to derive a SID value as described below.</t>
		<t pn="section-4.3-2">The ERO specified in <xref target="RFC5440" format
	<t>An SR-ERO subobject is formatted as shown in the following diagram.</t>	="default" sectionFormat="of" derivedContent="RFC5440"/> is used to carry SR-TE
		path information. In order to carry a SID and/or NAI, this document defines a ne
	<figure anchor="SR-ERO-SUBOBJECT" title="SR-ERO subobject format">	w ERO subobject referred to as the "SR-ERO subobject", whose format is specified
	<artwork><![CDATA[	in the following section. An ERO carrying an SR-TE path consists of one or more
		ERO subobjects, and it <bcp14>MUST</bcp14> carry only SR-ERO subobjects. Note t
		hat an SR-ERO subobject does not need to have both the SID and NAI. However, at
		least one of them <bcp14>MUST</bcp14> be present.</t>
		<t pn="section-4.3-3">When building the MPLS label stack from ERO, a PCC
		<bcp14>MUST</bcp14> assume that SR-ERO subobjects are organized as a last-in-fi
		rst-out stack. The first subobject relative to the beginning of ERO contains th
		e information about the topmost label. The last subobject contains information a
		bout the bottommost label.</t>
		<section anchor="SR-ERO-SUB" numbered="true" toc="include" removeInRFC="
		false" pn="section-4.3.1">
		<name slugifiedName="name-sr-ero-subobject">SR-ERO Subobject</name>
		<t pn="section-4.3.1-1">An SR-ERO subobject is formatted as shown in t
		he following diagram.</t>
		<figure anchor="SR-ERO-SUBOBJECT" align="left" suppress-title="false"
		pn="figure-2">
		<name slugifiedName="name-sr-ero-subobject-format">SR-ERO Subobject
		Format</name>
		<artwork name="" type="" align="left" alt="" pn="section-4.3.1-2.1">
	0 1 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|L\| Type=36 \| Length \| NT \| Flags \|F\|S\|C\|M\|	\|L\| Type=36 \| Length \| NT \| Flags \|F\|S\|C\|M\|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (optional) \|	\| SID (optional) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// NAI (variable, optional) //	// NAI (variable, optional) //

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
	]]></artwork>
	</figure>	</figure>

		<t pn="section-4.3.1-3">The fields in the SR-ERO subobject are as foll ows:


	<t>The fields in the SR-ERO Subobject are as follows:

	<list style="hanging">

	<t hangText="The 'L' Flag:"> Indicates whether the subobject represents a loose-
	hop in the LSP <xref target="RFC3209"/>. If this flag is set to zero, a PCC MUST
	NOT overwrite the SID value present in the SR-ERO subobject. Otherwise, a PCC M
	AY expand or replace one or more SID values in the received SR-ERO based on its
	local policy.</t>

	<t hangText="Type:"> Set to 36. </t>

	<t hangText="Length:"> Contains the total length of the subobject in octets. The
	Length MUST be at least 8, and MUST be a multiple of 4. An SR-ERO subobject MUS
	T contain at least one of a SID or an NAI. The flags described below indicate wh
	ether the SID or NAI fields are absent.</t>

	<t hangText="NAI Type (NT):"> Indicates the type and format of the NAI contained
	in the object body, if any is present. If the F bit is set to zero (see below)
	then the NT field has no meaning and MUST be ignored by the receiver. This docu
	ment describes the following NT values:</t>
	<t><list style="hanging">
	<t hangText="NT=0">The NAI is absent.</t>
	<t hangText="NT=1">The NAI is an IPv4 node ID.</t>
	<t hangText="NT=2">The NAI is an IPv6 node ID.</t>
	<t hangText="NT=3">The NAI is an IPv4 adjacency.</t>
	<t hangText="NT=4">The NAI is an IPv6 adjacency with global IPv6 addresses.</t>
	<t hangText="NT=5">The NAI is an unnumbered adjacency with IPv4 node IDs.</t>
	<t hangText="NT=6">The NAI is an IPv6 adjacency with link-local IPv6 addresses.<
	/t>
	</list>
	</t>

	<t hangText="Flags:"> Used to carry additional information pertaining to the SID
	. This document defines the following flag bits. The other bits MUST be set to z
	ero by the sender and MUST be ignored by the receiver.

	<list style="symbols">

	<t>M: If this bit is set to 1, the SID value represents an MPLS label stack entr
	y as specified in <xref target="RFC3032"/>. Otherwise, the SID value is an admin
	istratively configured value which represents an index into an MPLS label space
	(either SRGB or SRLB) per <xref target="RFC8402"/>.</t>

	<t>C: If the M bit and the C bit are both set to 1, then the TC, S, and TTL fiel
	ds in the MPLS label stack entry are specified by the PCE. However, a PCC MAY ch
	oose to override these values according its local policy and MPLS forwarding rul
	es. If the M bit is set to 1 but the C bit is set to zero, then the TC, S, and T
	TL fields MUST be ignored by the PCC. The PCC MUST set these fields according to
	its local policy and MPLS forwarding rules. If the M bit is set to zero then th
	e C bit MUST be set to zero.</t>

	<t>S: When this bit is set to 1, the SID value in the subobject body is absent.
	In this case, the PCC is responsible for choosing the SID value, e.g., by lookin
	g up in the SR-DB using the NAI which, in this case, MUST be present in the subo
	bject. If the S bit is set to 1 then the M and C bits MUST be set to zero.</t>

	<t>F: When this bit is set to 1, the NAI value in the subobject body is absent.
	The F bit MUST be set to 1 if NT=0, and otherwise MUST be set to zero. The S a
	nd F bits MUST NOT both be set to 1.</t>

	</list>
	</t>	</t>

		<dl newline="false" spacing="normal" pn="section-4.3.1-4">
		<dt pn="section-4.3.1-4.1">The L-Flag:</dt>
		<dd pn="section-4.3.1-4.2"> Indicates whether the subobject represen
		ts a loose hop in the LSP <xref target="RFC3209" format="default" sectionFormat=
		"of" derivedContent="RFC3209"/>. If this flag is set to zero, a PCC <bcp14>MUST
		NOT</bcp14> overwrite the SID value present in the SR-ERO subobject. Otherwise,
		a PCC <bcp14>MAY</bcp14> expand or replace one or more SID values in the receive
		d SR-ERO based on its local policy.</dd>
		<dt pn="section-4.3.1-4.3">Type:</dt>
		<dd pn="section-4.3.1-4.4"> Set to 36. </dd>
		<dt pn="section-4.3.1-4.5">Length:</dt>
		<dd pn="section-4.3.1-4.6"> Contains the total length of the subobje
		ct in octets. The Length <bcp14>MUST</bcp14> be at least 8 and <bcp14>MUST</bcp1
		4> be a multiple of 4. An SR-ERO subobject <bcp14>MUST</bcp14> contain at least
		one SID or NAI. The flags described below indicate whether the SID or NAI fields
		are absent.</dd>
		<dt pn="section-4.3.1-4.7">NAI Type (NT):</dt>
		<dd pn="section-4.3.1-4.8">
		<t pn="section-4.3.1-4.8.1">Indicates the type and format of the N
		AI contained in
		the object body, if any is present. If the F bit is set to
		zero (see below), then the NT field has no meaning and
		<bcp14>MUST</bcp14> be ignored by the receiver. This
		document describes the following NT values:</t>
		<dl newline="false" spacing="normal" pn="section-4.3.1-4.8.2">
		<dt pn="section-4.3.1-4.8.2.1">NT=0</dt>
		<dd pn="section-4.3.1-4.8.2.2">The NAI is absent.</dd>
		<dt pn="section-4.3.1-4.8.2.3">NT=1</dt>
		<dd pn="section-4.3.1-4.8.2.4">The NAI is an IPv4 node ID.</dd>
		<dt pn="section-4.3.1-4.8.2.5">NT=2</dt>
		<dd pn="section-4.3.1-4.8.2.6">The NAI is an IPv6 node ID.</dd>
		<dt pn="section-4.3.1-4.8.2.7">NT=3</dt>
		<dd pn="section-4.3.1-4.8.2.8">The NAI is an IPv4 adjacency.</dd
		>
		<dt pn="section-4.3.1-4.8.2.9">NT=4</dt>
		<dd pn="section-4.3.1-4.8.2.10">The NAI is an IPv6 adjacency wit
		h global IPv6
		addresses.</dd>
		<dt pn="section-4.3.1-4.8.2.11">NT=5</dt>
		<dd pn="section-4.3.1-4.8.2.12">The NAI is an unnumbered adjacen
		cy with IPv4 node
		IDs.</dd>
		<dt pn="section-4.3.1-4.8.2.13">NT=6</dt>
		<dd pn="section-4.3.1-4.8.2.14">The NAI is an IPv6 adjacency wit
		h link-local IPv6
		addresses.</dd>
		</dl>
		</dd>
		<dt pn="section-4.3.1-4.9">Flags:</dt>
		<dd pn="section-4.3.1-4.10">
		<t pn="section-4.3.1-4.10.1"> Used to carry additional information
		pertaining to the SID. This document defines the following flag bits. The other
		bits <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> b
		e ignored by the receiver.


	<t hangText="SID:"> The Segment Identifier. Depending on the M bit, it contains
	either:
	<list style="symbols">
	<t>A 4 octet index defining the offset into an MPLS label space per <xref ta
	rget="RFC8402"/>.</t>
	<t>A 4 octet MPLS Label Stack Entry, where the 20 most significant bits enco
	de the label value per <xref target="RFC3032"/>.</t>
	</list>
	</t>	</t>

		<dl newline="false" spacing="normal" indent="5" pn="section-4.3.1-
	<t hangText="NAI:"> The NAI associated with the SID. The NAI's format depends on	4.10.2">
	the value in the NT field, and is described in the following section.</t>	<dt pn="section-4.3.1-4.10.2.1">M:</dt>
		<dd pn="section-4.3.1-4.10.2.2">If this bit is set to 1, the SID
	</list>	value represents an MPLS label stack entry as specified in <xref target="RFC303
	At least one of the SID and the NAI MUST be included in the SR-ERO subobject, an	2" format="default" sectionFormat="of" derivedContent="RFC3032"/>. Otherwise, th
	d both MAY be included.	e SID value is an administratively configured value that represents an index int
		o an MPLS label space (either SRGB or SRLB) per <xref target="RFC8402" format="d
		efault" sectionFormat="of" derivedContent="RFC8402"/>.</dd>
		<dt pn="section-4.3.1-4.10.2.3">C:</dt>
		<dd pn="section-4.3.1-4.10.2.4">If the M bit and the C bit are b
		oth set to 1, then the TC, S, and TTL fields in the MPLS label stack entry are s
		pecified by the PCE. However, a PCC <bcp14>MAY</bcp14> choose to override these
		values according to its local policy and MPLS forwarding rules. If the M bit is
		set to 1 but the C bit is set to zero, then the TC, S, and TTL fields <bcp14>MUS
		T</bcp14> be ignored by the PCC. The PCC <bcp14>MUST</bcp14> set these fields ac
		cording to its local policy and MPLS forwarding rules. If the M bit is set to ze
		ro, then the C bit <bcp14>MUST</bcp14> be set to zero.</dd>
		<dt pn="section-4.3.1-4.10.2.5">S:</dt>
		<dd pn="section-4.3.1-4.10.2.6">When this bit is set to 1, the S
		ID value in the subobject body is absent. In this case, the PCC is responsible f
		or choosing the SID value, e.g., by looking it up in the SR-DB using the NAI tha
		t, in this case, <bcp14>MUST</bcp14> be present in the subobject. If the S bit i
		s set to 1, then the M and C bits <bcp14>MUST</bcp14> be set to zero.</dd>
		<dt pn="section-4.3.1-4.10.2.7">F:</dt>
		<dd pn="section-4.3.1-4.10.2.8">When this bit is set to 1, the N
		AI value in the subobject body is absent. The F bit <bcp14>MUST</bcp14> be set
		to 1 if NT=0; otherwise, it <bcp14>MUST</bcp14> be set to zero. The S and F bit
		s <bcp14>MUST NOT</bcp14> both be set to 1.</dd>
		</dl>
		</dd>
		<dt pn="section-4.3.1-4.11">SID:</dt>
		<dd pn="section-4.3.1-4.12">
		<t pn="section-4.3.1-4.12.1"> The Segment Identifier. Depending on
		the M bit, it contains either:
		</t>
		<ul spacing="normal" bare="false" empty="false" pn="section-4.3.1-
		4.12.2">
		<li pn="section-4.3.1-4.12.2.1">A 4-octet index defining the off
		set into an MPLS label space per <xref target="RFC8402" format="default" section
		Format="of" derivedContent="RFC8402"/> or</li>
		<li pn="section-4.3.1-4.12.2.2">A 4-octet MPLS label stack entry
		, where the 20 most significant bits encode the label value per <xref target="RF
		C3032" format="default" sectionFormat="of" derivedContent="RFC3032"/>.</li>
		</ul>
		</dd>
		<dt pn="section-4.3.1-4.13">NAI:</dt>
		<dd pn="section-4.3.1-4.14"> The NAI associated with the SID. The NA
		I's format depends on the value in the NT field and is described in the followin
		g section.</dd>
		</dl>
		<t pn="section-4.3.1-5">
		At least one SID and NAI <bcp14>MUST</bcp14> be included in the SR-ERO subobject
		, and both <bcp14>MAY</bcp14> be included.
	</t>	</t>

	</section>	</section>
		<section anchor="SR-ERO-NODAL-32" numbered="true" toc="include" removeIn
	<section anchor="SR-ERO-NODAL-32" title="NAI Associated with SID">	RFC="false" pn="section-4.3.2">
		<name slugifiedName="name-nai-associated-with-sid">NAI Associated with
	<t>This document defines the following NAIs:	SID</name>
		<t pn="section-4.3.2-1">This document defines the following NAIs:
	<list style="hanging">

	<t hangText="'IPv4 Node ID'">is specified as an IPv4 address. In this case, the
	NT value is 1 and the NAI field length is 4 octets.</t>

	<t hangText="'IPv6 Node ID'">is specified as an IPv6 address. In this case, the
	NT value is 2 and the NAI field length is 16 octets.</t>

	<t hangText="'IPv4 Adjacency'">is specified as a pair of IPv4 addresses. In this
	case, the NT value is 3 and the NAI field length is 8 octets. The format of th
	e NAI is shown in the following figure:

	<figure anchor="ADJ-SID-ERO-SUBOBJECT-32" title="NAI for IPv4 adjace
	ncy">
	<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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Local IPv4 address \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Remote IPv4 address \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>
	</figure>

	</t>

	<t hangText="'IPv6 Global Adjacency'">is specified as a pair of global IPv6 addr
	esses. It is used to describe an IPv6 adjacency for a link that uses global IPv
	6 addresses. Each global IPv6 address is configured on a specific router interf
	ace, so together they identify an adjacency between a pair of routers. In this
	case, the NT value is 4 and the NAI field length is 32 octets. The format of the
	NAI is shown in the following figure:


	<figure anchor="ADJ-SID-ERO-SUBOBJECT-128" title="NAI for IPv6 globa
	l adjacency">
	<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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Local IPv6 address (16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Remote IPv6 address (16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>
	</figure>
	</t>	</t>

		<dl newline="false" spacing="normal" pn="section-4.3.2-2">
		<dt pn="section-4.3.2-2.1">IPv4 Node ID:</dt>
		<dd pn="section-4.3.2-2.2">Specified as an IPv4 address. In this cas
		e, the NT value is 1, and the NAI field length is 4 octets.</dd>
		<dt pn="section-4.3.2-2.3">IPv6 Node ID:</dt>
		<dd pn="section-4.3.2-2.4">Specified as an IPv6 address. In this cas
		e, the NT value is 2, and the NAI field length is 16 octets.</dd>
		<dt pn="section-4.3.2-2.5">IPv4 Adjacency:</dt>
		<dd pn="section-4.3.2-2.6">
		<t pn="section-4.3.2-2.6.1">Specified as a pair of IPv4 addresses.
		In this case, the NT value is 3, and the NAI field length is 8 octets. The for
		mat of the NAI is shown in the following figure:


	<t hangText="'Unnumbered Adjacency with IPv4 NodeIDs'">is specified as a pair of	</t>
	(node ID, interface ID) tuples. In this case, the NT value is 5 and the NAI fie	<figure anchor="ADJ-SID-ERO-SUBOBJECT-32" align="left" suppress-ti
	ld length is 16 octets. The format of the NAI is shown in the following figure:	tle="false" pn="figure-3">
	<figure anchor="ADJ-SID-ERO-UNNUM-32" title="NAI for Unnumbered adja	<name slugifiedName="name-nai-for-ipv4-adjacency">NAI for IPv4 A
	cency with IPv4 Node IDs">	djacency</name>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt="" pn="section-4.3.2-2
	0 1 2 3	.6.2.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	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
	\| Local Node-ID \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| Local IPv4 address \|
	\| Local Interface ID \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| Remote IPv4 address \|
	\| Remote Node-ID \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	</figure>
	\| Remote Interface ID \|	</dd>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dt pn="section-4.3.2-2.7">IPv6 Global Adjacency:</dt>
	]]></artwork>	<dd pn="section-4.3.2-2.8">
	</figure>	<t pn="section-4.3.2-2.8.1">Specified as a pair of global IPv6 add
	</t>	resses. It is used to describe an IPv6 adjacency for a link that uses global IP
		v6 addresses. Each global IPv6 address is configured on a specific router inter
		face, so together they identify an adjacency between a pair of routers. In this
		case, the NT value is 4, and the NAI field length is 32 octets. The format of t
		he NAI is shown in the following figure:


	<t hangText="'IPv6 Link-Local Adjacency'">is specified as a pair of (global IPv6	</t>
	address, interface ID) tuples. It is used to describe an IPv6 adjacency for a	<figure anchor="ADJ-SID-ERO-SUBOBJECT-128" align="left" suppress-t
	link that uses only link local IPv6 addresses. Each global IPv6 address is confi	itle="false" pn="figure-4">
	gured on a specific router, so together they identify a pair of adjacent routers	<name slugifiedName="name-nai-for-ipv6-global-adjacen">NAI for I
	. The interface IDs identify the link that the adjacency is formed over. In this	Pv6 Global Adjacency</name>
	case, the NT value is 6 and the NAI field length is 40 octets. The format of th	<artwork name="" type="" align="left" alt="" pn="section-4.3.2-2
	e NAI is shown in the following figure:	.8.2.1">
		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		// Local IPv6 address (16 octets) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		// Remote IPv6 address (16 octets) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
		</figure>
		</dd>
		<dt pn="section-4.3.2-2.9">Unnumbered Adjacency with IPv4 NodeIDs:</
		dt>
		<dd pn="section-4.3.2-2.10">
		<t pn="section-4.3.2-2.10.1">Specified as a
		pair of (node ID, interface ID) tuples. In this case, the NT value is
		5, and the NAI field length is 16 octets. The format of the NAI is
		shown in the following figure:


	<figure anchor="ADJ-SID-ERO-LINKLOCAL-40" title="NAI for IPv6 link-l	</t>
	ocal adjacency">	<figure anchor="ADJ-SID-ERO-UNNUM-32" align="left" suppress-title=
	<artwork><![CDATA[	"false" pn="figure-5">
	0 1 2 3	<name slugifiedName="name-nai-for-unnumbered-adjacenc">NAI for U
	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	nnumbered Adjacency with IPv4 Node IDs</name>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<artwork name="" type="" align="left" alt="" pn="section-4.3.2-2
	// Local IPv6 address (16 octets) //	.10.2.1">
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	0 1 2 3
	\| Local Interface ID \|	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Remote IPv6 address (16 octets) //	\| Local Node ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Remote Interface ID \|	\| Local Interface ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	\| Remote Node ID \|
	</figure>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	</t>	\| Remote Interface ID \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
		</figure>
		</dd>
		<dt pn="section-4.3.2-2.11">IPv6 Link-Local Adjacency:</dt>
		<dd pn="section-4.3.2-2.12">
		<t pn="section-4.3.2-2.12.1">Specified as a pair of (global IPv6 a
		ddress, interface ID) tuples. It is used to describe an IPv6 adjacency for a li
		nk that uses only link-local IPv6 addresses. Each global IPv6 address is configu
		red on a specific router, so together they identify a pair of adjacent routers.
		The interface IDs identify the link that the adjacency is formed over. In this c
		ase, the NT value is 6, and the NAI field length is 40 octets. The format of the
		NAI is shown in the following figure:


	</list>	</t>
	</t>	<figure anchor="ADJ-SID-ERO-LINKLOCAL-40" align="left" suppress-ti
		tle="false" pn="figure-6">
		<name slugifiedName="name-nai-for-ipv6-link-local-adj">NAI for I
		Pv6 Link-Local Adjacency</name>
		<artwork name="" type="" align="left" alt="" pn="section-4.3.2-2
		.12.2.1">
		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		// Local IPv6 address (16 octets) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Local Interface ID \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		// Remote IPv6 address (16 octets) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Remote Interface ID \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
		</figure>
		</dd>
		</dl>
	</section>	</section>

		</section>
		<section anchor="SR-RRO" numbered="true" toc="include" removeInRFC="false"
		pn="section-4.4">
		<name slugifiedName="name-rro">RRO</name>
		<t pn="section-4.4-1">A PCC reports an SR-TE LSP to a PCE by sending a P
		CRpt message, per <xref target="RFC8231" format="default" sectionFormat="of" der
		ivedContent="RFC8231"/>. The RRO on this message represents the SID list that w
		as applied by the PCC, that is, the actual path taken by the LSP. The procedure
		s of <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="
		RFC8231"/> with respect to the RRO apply equally to this specification without c
		hange.</t>
		<t pn="section-4.4-2">An RRO contains one or more subobjects called "SR-
		RRO subobjects", whose format is shown below:</t>
		<figure anchor="SR-RRO-SUBOBJECT" align="left" suppress-title="false" pn
		="figure-7">
		<name slugifiedName="name-sr-rro-subobject-format">SR-RRO Subobject Fo
		rmat</name>
		<artwork name="" type="" align="left" alt="" pn="section-4.4-3.1">
		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Type=36 \| Length \| NT \| Flags \|F\|S\|C\|M\|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		// NAI (variable) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
		</figure>
		<t pn="section-4.4-4">The format of the SR-RRO subobject is the same as
		that of the SR-ERO subobject, but without the L-Flag.</t>
		<t pn="section-4.4-5">A PCC <bcp14>MUST</bcp14> order the SR-RRO subobje
		cts such that the first subobject relative to the beginning of the RRO identifie
		s the first segment visited by the SR-TE LSP, and the last subobject identifies
		the final segment of the SR-TE LSP, that is, its endpoint.</t>
		</section>
		<section anchor="SR-METRIC" numbered="true" toc="include" removeInRFC="fal
		se" pn="section-4.5">
		<name slugifiedName="name-metric-object">METRIC Object</name>
		<t pn="section-4.5-1">A PCC <bcp14>MAY</bcp14> request that PCE optimize
		s an individual path computation request to minimize the SID depth of the comput
		ed path by using the METRIC object defined in <xref target="RFC5440" format="def
		ault" sectionFormat="of" derivedContent="RFC5440"/>. This document defines a ne
		w type for the METRIC object to be used for this purpose, as follows:


	</section>	</t>
		<ul spacing="normal" empty="true" bare="false" pn="section-4.5-2">
	<section anchor="SR-RRO" title="RRO">	<li pn="section-4.5-2.1">
		<dl newline="false" spacing="normal" pn="section-4.5-2.1.1">
	<t>A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per <xref tar	<dt pn="section-4.5-2.1.1.1">T = 11:</dt>
	get="RFC8231"/>. The RRO on this message represents the SID list that was appli	<dd pn="section-4.5-2.1.1.2">Maximum SID Depth of the requested pa
	ed by the PCC, that is, the actual path taken by the LSP. The procedures of <xr	th.</dd>
	ef target="RFC8231"/> with respect to the RRO apply equally to this specificatio	</dl>
	n without change.</t>	</li>
		</ul>
	<t>An RRO contains one or more subobjects called "SR-RRO subobjects" whose forma	<t pn="section-4.5-3">If the PCC includes a METRIC object of this type o
	t is shown below:</t>	n a path computation request, then the PCE minimizes the SID depth of the comput
		ed path. If the B (bound) bit is set to 1 in the METRIC object, then the PCE <b
	<figure anchor="SR-RRO-SUBOBJECT" title="SR-RRO Subobject format">	cp14>MUST NOT</bcp14> return a path whose SID depth exceeds the given metric val
	<artwork><![CDATA[	ue. If the PCC did not set the X-Flag in its SR-PCE-CAPABILITY TLV, then it <bc
	0 1 2 3	p14>MUST</bcp14> set the B bit to 1. If the PCC set the X-Flag in its SR-PCE-CA
	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	PABILITY TLV, then it <bcp14>MAY</bcp14> set the B bit to 1 or zero.</t>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<t pn="section-4.5-4">If a PCEP session is established with a non-zero d
	\| Type=36 \| Length \| NT \| Flags \|F\|S\|C\|M\|	efault MSD value, then the
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	PCC <bcp14>MUST NOT</bcp14> send an MSD METRIC object with an MSD greater tha
	\| SID \|	n
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	the session's default MSD. If the PCE receives a path computation request
	// NAI (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>

	</figure>

	<t>The format of the SR-RRO subobject is the same as that of the SR-ERO subobjec
	t, but without the L flag.</t>

	<t>A PCC MUST order the SR-RRO subobjects such that the first subobject relative
	to the beginning of the RRO identifies the first segment visited by the SR-TE L
	SP, and the last subobject identifies the final segment of the SR-TE LSP, that i
	s, its endpoint.</t>

	</section> <!-- SR-RRO -->

	<section anchor="SR-METRIC" title="METRIC Object">

	<t>A PCC MAY request that PCE optimizes an individual path computation request t
	o minimize the SID depth of the computed path by using the METRIC object defined
	in <xref target="RFC5440"/>. This document defines a new type for the METRIC o
	bject to be used for this purpose, as follows:

	<list style="symbols">
	<t>T = 11: Maximum SID Depth of the requested path.</t>
	</list>
	</t>

	<t>If the PCC includes a METRIC object of this type on a path computation reques
	t, then the PCE minimizes the SID depth of the computed path. If the B (bound)
	bit is set to to 1 in the METRIC object, then the PCE MUST NOT return a path who
	se SID depth exceeds the given metric-value. If the PCC did not set the X flag
	in its SR-PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set t
	he X flag in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 1 or zero.<
	/t>

	<t>If a PCEP session is established with a non-zero default MSD value, then the
	PCC MUST NOT send an MSD METRIC object with an MSD greater than
	the session's default MSD. If the PCE receives a path computation request
	with an MSD METRIC object on such a session that is greater than the session' s	with an MSD METRIC object on such a session that is greater than the session' s

	default MSD, then it MUST consider the request invalid and send	default MSD, then it <bcp14>MUST</bcp14> consider the request invalid and sen
	a PCErr with Error-Type = 10 ("Reception of an invalid object") and	d
	Error-Value 9 ("MSD exceeds the default for the PCEP session").	a PCEP Error (PCErr) with Error-Type = 10 ("Reception of an invalid object")
		and
		Error-value = 9 ("MSD exceeds the default for the PCEP session").
	</t>	</t>

		</section>
		</section>
		<section anchor="procedures" numbered="true" toc="include" removeInRFC="fals
		e" pn="section-5">
		<name slugifiedName="name-procedures">Procedures</name>
		<section anchor="SR-CAP-PROCESS" numbered="true" toc="include" removeInRFC
		="false" pn="section-5.1">
		<name slugifiedName="name-exchanging-the-sr-pce-capab">Exchanging the SR
		PCE Capability</name>
		<t pn="section-5.1-1">A PCC indicates that it is capable of supporting t
		he head-end functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV i
		n the Open message that it sends to a PCE. A PCE indicates that it is capable of
		computing SR-TE paths by including the SR-PCE-CAPABILITY sub-TLV in the Open me
		ssage that it sends to a PCC.</t>
		<t pn="section-5.1-2">If a PCEP speaker receives a PATH-SETUP-TYPE-CAPAB
		ILITY TLV with a PST list containing PST=1, and supports that path setup type, t
		hen it checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that sub-TL
		V is absent, then the PCEP speaker <bcp14>MUST</bcp14> send a PCErr message with
		Error-Type = 10 ("Reception of an invalid object") and Error-value = 12 ("Missi
		ng PCE-SR-CAPABILITY sub-TLV") and <bcp14>MUST</bcp14> then close the PCEP sessi
		on. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a SR-PCE-C
		APABILITY sub-TLV, but the PST list does not contain PST=1, then the PCEP speake
		r <bcp14>MUST</bcp14> ignore the SR-PCE-CAPABILITY sub-TLV.</t>
		<t pn="section-5.1-3">If a PCC sets the N-Flag to 1, then the PCE <bcp14
		>MAY</bcp14> send an SR-ERO subobject containing an NAI and no SID (see <xref ta
		rget="SR-ERO-PROCESS" format="default" sectionFormat="of" derivedContent="Sectio
		n 5.2"/>). Otherwise, the PCE <bcp14>MUST NOT</bcp14> send an SR-ERO subobject
		containing an NAI and no SID.</t>
		<t pn="section-5.1-4">The number of SIDs that can be imposed on a packet
		depends on the PCC's data-plane capability. If a PCC sets the X-Flag to 1, then
		the MSD is not used and <bcp14>MUST</bcp14> be set to zero. If a PCE receives a
		n SR-PCE-CAPABILITY sub-TLV with the X-Flag set to 1, then it <bcp14>MUST</bcp14
		> ignore the MSD field and assume that the sender can impose a SID stack of any
		depth. If a PCC sets the X-Flag to zero, then it sets the MSD field to the maxi
		mum number of SIDs that it can impose on a packet. In this case, the PCC <bcp14
		>MUST</bcp14> set the MSD to a number greater than zero. If a PCE receives an S
		R-PCE-CAPABILITY sub-TLV with the X-Flag and MSD both set to zero, then it <bcp1
		4>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception of an inval
		id object") and Error-value = 21 ("Maximum SID depth must be non-zero") and <bcp
		14>MUST</bcp14> then close the PCEP session.</t>
		<t pn="section-5.1-5">Note that the MSD value exchanged via the SR-PCE-C
		APABILITY sub-TLV indicates the SID/label imposition limit for the PCC node. It
		is anticipated that, in many deployments, the PCCs will have network interfaces
		that are homogeneous with respect to MSD (that is, each interface has the same
		MSD). In such cases, having a per-node MSD on the PCEP session is sufficient; t
		he PCE <bcp14>SHOULD</bcp14> interpret this to mean that all network interfaces
		on the PCC have the given MSD. However, the PCE <bcp14>MAY</bcp14> also learn a
		per-node MSD and a per-interface MSD from the routing protocols, as specified i
		n <xref target="RFC8491" format="default" sectionFormat="of" derivedContent="RFC
		8491"/>, <xref target="RFC8476" format="default" sectionFormat="of" derivedConte
		nt="RFC8476"/>, and <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd" form
		at="default" sectionFormat="of" derivedContent="MSD-BGP"/>. If the PCE learns t
		he per-node MSD of a PCC from a routing protocol, then it <bcp14>MUST</bcp14> i
		gnore the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the per-no
		de MSD learned from the routing protocol instead. If the PCE learns the MSD of
		a network interface on a PCC from a routing protocol, then it <bcp14>MUST</bcp1
		4> use the per-interface MSD instead of the MSD value in the SR-PCE-CAPABILITY s
		ub-TLV when it computes a path that uses that interface.</t>
		<t pn="section-5.1-6">Once an SR-capable PCEP session is established wit
		h a non-zero MSD value, the corresponding PCE <bcp14>MUST NOT</bcp14> send SR-TE
		paths with a number of SIDs exceeding that MSD value. If a PCC needs to modify
		the MSD value, it <bcp14>MUST</bcp14> close the PCEP session and re-establish it
		with the new MSD value. If a PCEP session is established with a non-zero MSD va
		lue, and the PCC receives an SR-TE path containing more SIDs than specified in t
		he MSD value, the PCC <bcp14>MUST</bcp14> send a PCErr message with Error-Type =
		10 ("Reception of an invalid object") and Error-value = 3 ("Unsupported number
		of SR-ERO subobjects"). If a PCEP session is established with an MSD value of ze
		ro, then the PCC <bcp14>MAY</bcp14> specify an MSD for each path computation req
		uest that it sends to the PCE, by including a "maximum SID depth" METRIC object
		on the request, as defined in <xref target="SR-METRIC" format="default" sectionF
		ormat="of" derivedContent="Section 4.5"/>.</t>
		<t pn="section-5.1-7">The N-Flag, X-Flag, and MSD value inside the SR-PC
		E-CAPABILITY sub-TLV are meaningful only in the Open message sent from a PCC to
		a PCE. As such, a PCE <bcp14>MUST</bcp14> set the N-Flag to zero, X-Flag to 1, a
		nd MSD value to zero in an outbound message to a PCC. Similarly, a PCC <bcp14>MU
		ST</bcp14> ignore any MSD value received from a PCE. If a PCE receives multiple
		SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-T
		LV received.</t>
		</section>
		<section anchor="SR-ERO-PROCESS" numbered="true" toc="include" removeInRFC
		="false" pn="section-5.2">
		<name slugifiedName="name-ero-processing">ERO Processing</name>
		<section anchor="SR-ERO-VALIDATION" numbered="true" toc="include" remove
		InRFC="false" pn="section-5.2.1">
		<name slugifiedName="name-sr-ero-validation">SR-ERO Validation</name>
		<t pn="section-5.2.1-1">If a PCC does not support the SR PCE Capabilit
		y and thus cannot recognize the SR-ERO or SR-RRO subobjects, it will respond acc
		ording to the rules for a malformed object per <xref target="RFC5440" format="de
		fault" sectionFormat="of" derivedContent="RFC5440"/>.</t>
		<t pn="section-5.2.1-2">On receiving an SR-ERO, a PCC <bcp14>MUST</bcp
		14> validate that the Length field, S bit, F bit, and NT field are consistent, a
		s follows.


	</section> <!-- SR-METRIC -->	</t>
		<ul spacing="normal" bare="false" empty="false" pn="section-5.2.1-3">
	</section> <!-- object-formats -->	<li pn="section-5.2.1-3.1">If NT=0, the F bit <bcp14>MUST</bcp14> be
		1, the S bit <bcp14>MUST</bcp14> be zero, and the Length <bcp14>MUST</bcp14> be
	<section anchor="procedures" title="Procedures">	8.</li>
		<li pn="section-5.2.1-3.2">If NT=1, the F bit <bcp14>MUST</bcp14> be
	<section anchor="SR-CAP-PROCESS" title="Exchanging the SR PCE Capability">	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 8; otherwise, the L
		ength <bcp14>MUST</bcp14> be 12.</li>
	<t>A PCC indicates that it is capable of supporting the head-end functions for S	<li pn="section-5.2.1-3.3">If NT=2, the F bit <bcp14>MUST</bcp14> be
	R-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in the Open message that it	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 20; otherwise, the
	sends to a PCE. A PCE indicates that it is capable of computing SR-TE paths by i	Length <bcp14>MUST</bcp14> be 24.</li>
	ncluding the SR-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PC	<li pn="section-5.2.1-3.4">If NT=3, the F bit <bcp14>MUST</bcp14> be
	C.</t>	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 12; otherwise, the
		Length <bcp14>MUST</bcp14> be 16.</li>
	<t>If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list c	<li pn="section-5.2.1-3.5">If NT=4, the F bit <bcp14>MUST</bcp14> be
	ontaining PST=1, and supports that path setup type, then it checks for the prese	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 36; otherwise, the
	nce of the SR-PCE-CAPABILITY sub-TLV. If that sub-TLV is absent, then the PCEP	Length <bcp14>MUST</bcp14> be 40.</li>
	speaker MUST send a PCErr message with Error-Type 10 (Reception of an invalid ob	<li pn="section-5.2.1-3.6">If NT=5, the F bit <bcp14>MUST</bcp14> be
	ject) and Error-Value TBD1 (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then clo	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 20; otherwise, the
	se the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TL	Length <bcp14>MUST</bcp14> be 24.</li>
	V with a SR-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=1, the	<li pn="section-5.2.1-3.7">If NT=6, the F bit <bcp14>MUST</bcp14> be
	n the PCEP speaker MUST ignore the SR-PCE-CAPABILITY sub-TLV.</t>	zero. If the S bit is 1, the Length <bcp14>MUST</bcp14> be 44; otherwise, the
		Length <bcp14>MUST</bcp14> be 48.</li>
	<t>If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO subobject cont	</ul>
	aining NAI and no SID (see <xref target="SR-ERO-PROCESS"/>). Otherwise, the PCE	<t pn="section-5.2.1-4">If a PCC finds that the NT field, Length field
	MUST NOT send an SR-ERO subobject containing NAI and no SID.</t>	, S bit, and F bit are not consistent, it <bcp14>MUST</bcp14> consider the entir
		e ERO invalid and <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10
	<t>The number of SIDs that can be imposed on a packet depends on the PCC's data	("Reception of an invalid object") and Error-value = 11 ("Malformed object").</t
	plane's capability. If a PCC sets the X flag to 1 then the MSD is not used and M	>
	UST be set to zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X fl	<t pn="section-5.2.1-5">If a PCC does not recognize or support the val
	ag set to 1 then it MUST ignore the MSD field and assumes that the sender can im	ue in the NT field,
	pose a SID stack of any depth. If a PCC sets the X flag to zero, then it sets t	it <bcp14>MUST</bcp14> consider the entire ERO invalid and
	he MSD field to the maximum number of SIDs that it can impose on a packet. In t	<bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10
	his case, the PCC MUST set the MSD to a number greater than zero. If a PCE rece	("Reception of an invalid object") and Error-value = 13
	ives an SR-PCE-CAPABILITY sub-TLV with the X flag and MSD both set to zero then	("Unsupported NAI Type in the SR-ERO/SR-RRO subobject").</t>
	it MUST send a PCErr message with Error-Type 10 (Reception of an invalid object)	<t pn="section-5.2.1-6">If a PCC receives an SR-ERO subobject in which
	and Error-Value TBD10 (Maximum SID depth must be nonzero) and MUST then close t	the S and F bits are both set to 1 (that is, both the SID and NAI are absent),
	he PCEP session.</t>	it <bcp14>MUST</bcp14> consider the entire ERO invalid and send a PCErr message
		with Error-Type = 10 ("Reception of an invalid object") and Error-value = 6 ("Bo
	<t>Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV indicates	th SID and NAI are absent in the SR-ERO subobject").</t>
	the SID/label imposition limit for the PCC node. It is anticipated that, in ma	<t pn="section-5.2.1-7">If a PCC receives an SR-ERO subobject in which
	ny deployments, the PCCs will have network interfaces that are homogeneous with	the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent
	respect to MSD (that is, each interface has the same MSD). In such cases, havin	and the NAI is present), but the PCC does not support NAI resolution, it <bcp14>
	g a per-node MSD on the PCEP session is sufficient; the PCE SHOULD interpret thi	MUST</bcp14> consider the entire ERO invalid and send a PCErr message with Error
	s to mean that all network interfaces on the PCC have the given MSD. However, t	-Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter")
	he PCE MAY also learn a per-node MSD and a per-interface MSD from the routing pr	.</t>
	otocols, as specified in: <xref target="RFC8491"/>; <xref target="RFC8476"/>;	<t pn="section-5.2.1-8">If a PCC receives an SR-ERO subobject in which
	<xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/>. If the PCE learns the	the S bit is set to 1 and either (or both) the M bit or the C bit is set to 1,
	per-node MSD of a PCC from a routing protocol, then it MUST ignore the per-nod	it <bcp14>MUST</bcp14> consider the entire ERO invalid and send a PCErr message
	e MSD value in the SR-PCE-CAPABILITY sub-TLV and use the per-node MSD learned fr	with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("M
	om the routing protocol instead. If the PCE learns the MSD of a network interfa	alformed object").</t>
	ce on a PCC from a routing protocol, then it MUST use the per-interface MSD ins	<t pn="section-5.2.1-9">If a PCC receives an SR-ERO subobject in which
	tead of the MSD value in the SR-PCE-CAPABILITY sub-TLV when it computes a path t	the S bit is set to zero and the M bit is set to 1, then the subobject contains
	hat uses that interface.</t>	an MPLS label. The PCC <bcp14>MAY</bcp14> choose not to accept a label provide
		d by the PCE, based on its local policy. The PCC <bcp14>MUST NOT</bcp14> accept
	<t>Once an SR-capable PCEP session is established with a non-zero MSD value, the	MPLS label value 3 (Implicit NULL), but it <bcp14>MAY</bcp14> accept other spec
	corresponding PCE MUST NOT send SR-TE paths with a number of SIDs exceeding tha	ial-purpose MPLS label values. If the PCC decides not to accept an MPLS label v
	t MSD value. If a PCC needs to modify the MSD value, it MUST close the PCEP sess	alue, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Recepti
	ion and re-establish it with the new MSD value. If a PCEP session is established	on of an invalid object") and Error-value = 2 ("Bad label value").</t>
	with a non-zero MSD value, and the PCC receives an SR-TE path containing more S	<t pn="section-5.2.1-10">If both the M and C bits of an SR-ERO subobje
	IDs than specified in the MSD value, the PCC MUST send a PCErr message with Erro	ct are set to 1, and if a PCC finds an erroneous setting in one or more of the T
	r-Type 10 (Reception of an invalid object) and Error-Value 3 (Unsupported number	C, S, and TTL fields, it <bcp14>MAY</bcp14> overwrite those fields with values c
	of Segment ERO subobjects). If a PCEP session is established with an MSD value	hosen according to its own policy. If the PCC does not overwrite them, it <bcp14
	of zero, then the PCC MAY specify an MSD for each path computation request that	>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception of an invali
	it sends to the PCE, by including a "maximum SID depth" metric object on the req	d object") and Error-value = 4 ("Bad label format").</t>
	uest, as defined in <xref target="SR-METRIC"/>.</t>	<t pn="section-5.2.1-11">If the M bit of an SR-ERO subobject is set to
		zero but the C bit is set to 1, then the PCC <bcp14>MUST</bcp14> consider the e
	<t>The N flag, X flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV are mea	ntire ERO invalid and <bcp14>MUST</bcp14> send a PCErr message with Error-Type =
	ningful only in the Open message sent from a PCC to a PCE. As such, a PCE MUST s	10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object")
	et the N flag to zero, the X flag to 1 and MSD value to zero in an outbound mess	.</t>
	age to a PCC. Similarly, a PCC MUST ignore any MSD value received from a PCE. If	<t pn="section-5.2.1-12">If a PCC receives an SR-ERO subobject in whic
	a PCE receives multiple SR-PCE-CAPABILITY sub-TLVs in an Open message, it proce	h the S bit is set to zero and the M bit is set to zero, then the subobject cont
	sses only the first sub-TLV received.</t>	ains a SID index value. If the SID is an Adj-SID, then the L-Flag <bcp14>MUST N
		OT</bcp14> be set. If the L-Flag is set for an Adj-SID, then the PCC <bcp14>MUS
	</section>	T</bcp14> send a PCErr message with Error-Type = 10 ("Reception of an invalid ob
		ject") and Error-value = 11 ("Malformed object").</t>
	<section anchor="SR-ERO-PROCESS" title="ERO Processing">	<t pn="section-5.2.1-13">If a PCC detects that the subobjects of an ER
		O are a mixture of SR-ERO subobjects and subobjects of other types, then it <bcp
	<section anchor="SR-ERO-VALIDATION" title="SR-ERO Validation">	14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception of an inva
		lid object") and Error-value = 5 ("ERO mixes SR-ERO subobjects with other subobj
	<t>If a PCC does not support the SR PCE Capability and thus cannot recognize	ect types").</t>
	the SR-ERO or SR-RRO subobjects, it will respond according to the rules for a m	<t pn="section-5.2.1-14">The SR-ERO subobjects can be classified accor
	alformed object per <xref target="RFC5440"/>.</t>	ding to whether they contain a SID representing an MPLS label value or an index
		value, or no SID. If a PCC detects that the SR-ERO subobjects are a mixture of
	<t>On receiving an SR-ERO, a PCC MUST validate that the Length field, the S	more than one of these types, then it <bcp14>MUST</bcp14> send a PCErr message w
	bit, the F bit and the NT field are consistent, as follows.	ith Error-Type = 10 ("Reception of an invalid object") and Error-value = 20 ("In
		consistent SIDs in SR-ERO/SR-RRO subobjects").</t>
	<list style="symbols">	<t pn="section-5.2.1-15">If an ERO specifies a new SR-TE path for an e
	<t>If NT=0, the F bit MUST be 1, the S bit MUST be zero and the Length MUST	xisting LSP and the PCC determines that the ERO contains SR-ERO subobjects that
	be 8.</t>	are not valid, then the PCC <bcp14>MUST NOT</bcp14> update the LSP.</t>
	<t>If NT=1, the F bit MUST be zero. If the S bit is 1, the Length MUST be 8	</section>
	, otherwise the Length MUST be 12.</t>	<section anchor="SR-ERO-INTERPRET" numbered="true" toc="include" removeI
	<t>If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 2	nRFC="false" pn="section-5.2.2">
	0, otherwise the Length MUST be 24.</t>	<name slugifiedName="name-interpreting-the-sr-ero">Interpreting the SR
	<t>If NT=3, the F bit MUST be zero. If the S bit is 1, the Length MUST be 1	-ERO</name>
	2, otherwise the Length MUST be 16.</t>	<t pn="section-5.2.2-1">
	<t>If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 3
	6, otherwise the Length MUST be 40.</t>
	<t>If NT=5, the F bit MUST be zero. If the S bit is 1, the Length MUST be 2
	0, otherwise the Length MUST be 24.</t>
	<t>If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 4
	4, otherwise the Length MUST be 48.</t>
	</list></t>

	<t>If a PCC finds that the NT field, Length field, S bit and F bit are not c
	onsistent, it MUST consider the entire ERO invalid and MUST send a PCErr message
	with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("
	Malformed object").</t>

	<t>If a PCC does not recognise or support the value in the NT field, it MUST
	consider the entire ERO invalid and MUST send a PCErr message with Error-Type =
	10 ("Reception of an invalid object") and Error-Value = TBD2 ("Unsupported NAI
	Type in Segment ERO subobject").</t>

	<t>If a PCC receives an SR-ERO subobject in which the S and F bits are both
	set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire
	ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an inv
	alid object") and Error-Value = 6 ("Both SID and NAI are absent in SR-ERO subobj
	ect").</t>

	<t>If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and
	the F bit is set to zero (that is, the SID is absent and the NAI is present), bu
	t the PCC does not support NAI resolution, it MUST consider the entire ERO inval
	id and send a PCErr message with Error-Type = 4 ("Not supported object") and Err
	or-Value = 4 ("Unsupported parameter").</t>

	<t>If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and
	either or both of the M or C bits is set to 1, it MUST consider the entire ERO i
	nvalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid o
	bject") and Error-Value = 11 ("Malformed object").</t>

	<t>If a PCC receives an SR-ERO subobject in which the S bit is set to zero a
	nd the M bit is set to 1, then the subobject contains an MPLS label. The PCC MA
	Y choose not to accept a label provided by the PCE, based on it local policy. T
	he PCC MUST NOT accept MPLS label value 3 (Implicit NULL), but it MAY accept oth
	er special purpose MPLS label values. If the PCC decides not to accept an MPLS
	label value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an
	invalid object") and Error Value = 2 ("Bad label value").</t>

	<t>If both M and C bits of an SR-ERO subobject are set to 1, and if a PCC fi
	nds erroneous setting in one or more of TC, S, and TTL fields, it MAY overwrite
	those fields with values chosen according to its own policy. If the PCC does not
	overwrite them, it MUST send a PCErr message with Error-Type = 10 ("Reception o
	f an invalid object") and Error-Value = 4 ("Bad label format").</t>

	<t>If the M bit of an SR-ERO subobject is set to zero but the C bit is set t
	o 1, then the PCC MUST consider the entire ERO invalid and MUST send a PCErr mes
	sage with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 1
	1 ("Malformed object").</t>

	<t>If a PCC receives an SR-ERO subobject in which the S bit is set to zero a
	nd the M bit is set to zero, then the subobject contains a SID index value. If
	the SID is an Adjacency-SID then the L flag MUST NOT be set. If the L flag is s
	et for an Adjacency-SID then the PCC MUST send a PCErr message with Error-Type =
	10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object")
	.</t>

	<t>If a PCC detects that the subobjects of an ERO are a mixture of SR-ERO su
	bobjects and subobjects of other types, then it MUST send a PCErr message with E
	rror-Type = 10 ("Reception of an invalid object") and Error-Value = 5 ("ERO mixe
	s SR-ERO subobjects with other subobject types").</t>

	<t>The SR-ERO subobjects can be classified according to whether they contain
	a SID representing an MPLS label value, a SID representing an index value, or n
	o SID. If a PCC detects that the SR-ERO subobjects are a mixture of more than o
	ne of these types, then it MUST send a PCErr message with Error-Type = 10 ("Rece
	ption of an invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ER
	O / SR-RRO subobjects").</t>

	<t>If an ERO specifies a new SR-TE path for an existing LSP and the PCC dete
	rmines that the ERO contains SR-ERO subobjects that are not valid, then the PCC
	MUST NOT update the LSP.</t>

	</section>

	<section anchor="SR-ERO-INTERPRET" title="Interpreting the SR-ERO">

	<t>
	The SR-ERO contains a sequence of subobjects. Each SR-ERO subobject in	The SR-ERO contains a sequence of subobjects. Each SR-ERO subobject in
	the sequence identifies a segment that the traffic will be directed	the sequence identifies a segment that the traffic will be directed
	to, in the order given. That is, the first subobject identifies the	to, in the order given. That is, the first subobject identifies the
	first segment the traffic will be directed to, the second	first segment the traffic will be directed to, the second
	subobject represents the second segment, and so on.	subobject represents the second segment, and so on.

	</t>	</t>
	<t>	<t pn="section-5.2.2-2">
	The PCC interprets the SR-ERO by converting it to an MPLS label stack plu s a	The PCC interprets the SR-ERO by converting it to an MPLS label stack plu s a

	next hop. The PCC sends packets along the segment routed path by prepend ing	next hop. The PCC sends packets along the segment-routed path by prepend ing
	the MPLS label stack onto the packets and sending the resulting, modified	the MPLS label stack onto the packets and sending the resulting, modified
	packet to the next hop.	packet to the next hop.

	</t>	</t>
	<t>	<t pn="section-5.2.2-3">
	The PCC uses a different procedure to do this conversion, depending on th e	The PCC uses a different procedure to do this conversion, depending on th e
	information that the PCE has provided in the subobjects.	information that the PCE has provided in the subobjects.


	<list style="symbols">	</t>
	<t>	<ul spacing="normal" bare="false" empty="false" pn="section-5.2.2-4">
		<li pn="section-5.2.2-4.1">
	If the subobjects contain SID index values, then the PCC converts them into the	If the subobjects contain SID index values, then the PCC converts them into the
	corresponding MPLS labels by following the procedure defined in	corresponding MPLS labels by following the procedure defined in

	<xref target="I-D.ietf-spring-segment-routing-mpls"/>.	<xref target="RFC8660" format="default" sectionFormat="of" derivedCont
	</t>	ent="RFC8660"/>.
	<t>	</li>
	If the subobjects contain NAI only, the PCC first converts	<li pn="section-5.2.2-4.2">
		If the subobjects contain NAIs only, the PCC first converts
	each NAI into a SID index value and then proceeds as above.	each NAI into a SID index value and then proceeds as above.

	To convert an NAI to a SID index, the PCC looks for a fully-specified	To convert an NAI to a SID index, the PCC looks for a fully specified
	prefix or adjacency matching the fields in the NAI. If the PCC finds	prefix or adjacency matching the fields in the NAI. If the PCC finds
	a matching prefix/adjacency, and the matching prefix/adjacency has a S ID associated	a matching prefix/adjacency, and the matching prefix/adjacency has a S ID associated
	with it, then the PCC uses that SID. If the PCC cannot find a	with it, then the PCC uses that SID. If the PCC cannot find a
	matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated	matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated

	with it, the PCC behaves as specified in <xref target="SR-ERO-INTERPRE	with it, the PCC behaves as specified in <xref target="SR-ERO-INTERPRE
	T-ERROR"/>.	T-ERROR" format="default" sectionFormat="of" derivedContent="Section 5.2.2.1"/>.
	</t>	</li>
	<t>	<li pn="section-5.2.2-4.3">
	If the subobjects contain MPLS labels, then the PCC looks up the offse t of the first subobject's label	If the subobjects contain MPLS labels, then the PCC looks up the offse t of the first subobject's label
	in its SRGB or SRLB. This gives the first SID. The PCC pushes the la bels in any	in its SRGB or SRLB. This gives the first SID. The PCC pushes the la bels in any
	remaining subobjects onto the packet (with the final subobject specify ing the	remaining subobjects onto the packet (with the final subobject specify ing the
	bottom-of-stack label).	bottom-of-stack label).

	</t>	</li>
	</list>	</ul>
		<t pn="section-5.2.2-5">
	For all cases above, after the PCC has imposed the label stack on the pack et, it sends the packet to the segment identified by the first SID.	For all cases above, after the PCC has imposed the label stack on the pack et, it sends the packet to the segment identified by the first SID.

	</t>	</t>
		<section anchor="SR-ERO-INTERPRET-ERROR" numbered="true" toc="exclude"
	<section anchor="SR-ERO-INTERPRET-ERROR" title="Handling Errors During SR-ER	removeInRFC="false" pn="section-5.2.2.1">
	O Conversion">	<name slugifiedName="name-handling-errors-during-sr-e">Handling Erro
		rs During SR-ERO Conversion</name>
	<t>There are several errors that can occur during the process of converting	<t pn="section-5.2.2.1-1">There are several errors that can occur du
	an SR-ERO sequence to an MPLS label stack and a next hop. The PCC deals with th	ring the process of converting an SR-ERO sequence to an MPLS label stack and a n
	em as follows.	ext hop. The PCC deals with them as follows.
	<list style="symbols">	</t>
	<t>If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr m	<ul spacing="normal" bare="false" empty="false" pn="section-5.2.2.1-
	essage with Error-Type = 10 ("Reception of an invalid object") and Error-Value =	2">
	TBD3 ("Unknown SID").</t>	<li pn="section-5.2.2.1-2.1">If the PCC cannot find a SID index in
	<t>If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr messag	the SR-DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("R
	e with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD4	eception of an invalid object") and Error-value = 14 ("Unknown SID").</li>
	("NAI cannot be resolved to a SID").</t>	<li pn="section-5.2.2.1-2.2">If the PCC cannot find an NAI in the
	<t>If the PCC needs to convert a SID into an MPLS label value but cannot f	SR-DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Recept
	ind the corresponding router's SRGB in the SR-DB, it MUST send a PCErr message w	ion of an invalid object") and Error-value = 15 ("NAI cannot be resolved to a SI
	ith Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD5 ("	D").</li>
	Could not find SRGB").</t>	<li pn="section-5.2.2.1-2.3">If the PCC needs to convert a SID int
	<t>If the PCC finds that a router's SRGB is not large enough for a SID ind	o an MPLS label value but cannot find the corresponding router's SRGB in the SR-
	ex value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an in	DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception
	valid object") and Error-Value = TBD6 ("SID index exceeds SRGB size").</t>	of an invalid object") and Error-value = 16 ("Could not find SRGB").</li>
	<t>If the PCC needs to convert a SID into an MPLS label value but cannot f	<li pn="section-5.2.2.1-2.4">If the PCC finds that a router's SRGB
	ind the corresponding router's SRLB in the SR-DB, it MUST send a PCErr message w	is not large enough for a SID index value, it <bcp14>MUST</bcp14> send a PCErr
	ith Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD7 ("	message with Error-Type = 10 ("Reception of an invalid object") and Error-value
	Could not find SRLB").</t>	= 17 ("SID index exceeds SRGB size").</li>
	<t>If the PCC finds that a router's SRLB is not large enough for a SID ind	<li pn="section-5.2.2.1-2.5">If the PCC needs to convert a SID int
	ex value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an in	o an MPLS label value but cannot find the corresponding router's SRLB in the SR-
	valid object") and Error-Value = TBD8 ("SID index exceeds SRLB size").</t>	DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception
	<t>If the number of labels in the computed label stack exceeds the maximum	of an invalid object") and Error-value = 18 ("Could not find SRLB").</li>
	number of SIDs that the PCC can impose on the packet, it MUST send a PCErr mess	<li pn="section-5.2.2.1-2.6">If the PCC finds that a router's SRLB
	age with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 3	is not large enough for a SID index value, it <bcp14>MUST</bcp14> send a PCErr
	("Unsupported number of Segment ERO subobjects").</t>	message with Error-Type = 10 ("Reception of an invalid object") and Error-value
	</list></t>	= 19 ("SID index exceeds SRLB size").</li>
	<t>If an ERO specifies a new SR-TE path for an existing LSP and the PCC enco	<li pn="section-5.2.2.1-2.7">If the number of labels in the comput
	unters an error while processing the ERO, then the PCC MUST NOT update the LSP.<	ed label stack exceeds the maximum number of SIDs that the PCC can impose on the
	/t>	packet, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Rece
	</section>	ption of an invalid object") and Error-value = 3 ("Unsupported number of SR-ERO
		subobjects").</li>
	</section>	</ul>
	</section>	<t pn="section-5.2.2.1-3">If an ERO specifies a new SR-TE path for a
		n existing LSP and the PCC encounters an error while processing the ERO, then th
	<section anchor="SR-RRO-PROCESS" title="RRO Processing">	e PCC <bcp14>MUST NOT</bcp14> update the LSP.</t>
		</section>
	<t>The syntax checking rules that apply to the SR-RRO subobject are identical to	</section>
	those of the SR-ERO subobject, except as noted below.</t>	</section>
		<section anchor="SR-RRO-PROCESS" numbered="true" toc="include" removeInRFC
	<t>If a PCEP speaker receives an SR-RRO subobject in which both SID and NAI are	="false" pn="section-5.3">
	absent, it MUST consider the entire RRO invalid and send a PCErr message with Er	<name slugifiedName="name-rro-processing">RRO Processing</name>
	ror-Type = 10 ("Reception of an invalid object") and Error-Value = 7 ("Both SID	<t pn="section-5.3-1">The syntax-checking rules that apply to the SR-RRO
	and NAI are absent in SR-RRO subobject").</t>	subobject are identical to those of the SR-ERO subobject, except as noted below
		.</t>
	<t>If a PCE detects that the subobjects of an RRO are a mixture of SR-RRO subobj	<t pn="section-5.3-2">If a PCEP speaker receives an SR-RRO subobject in
	ects and subobjects of other types, then it MUST send a PCErr message with Error	which both SID and NAI are absent, it <bcp14>MUST</bcp14> consider the entire RR
	-Type = 10 ("Reception of an invalid object") and Error-Value = 10 ("RRO mixes S	O invalid and send a PCErr message with Error-Type = 10 ("Reception of an invali
	R-RRO subobjects with other subobject types").</t>	d object") and Error-value = 7 ("Both SID and NAI are absent in the SR-RRO subob
		ject").</t>
	<t>The SR-RRO subobjects can be classified according to whether they contain a S	<t pn="section-5.3-3">If a PCE detects that the subobjects of an RRO are
	ID representing an MPLS label value or a SID representing an index value, or no	a mixture of SR-RRO subobjects and subobjects of other types, then it <bcp14>MU
	SID. If a PCE detects that the SR-RRO subobjects are a mixture of more than one	ST</bcp14> send a PCErr message with Error-Type = 10 ("Reception of an invalid o
	of these types, then it MUST send a PCErr message with Error-Type = 10 ("Recept	bject") and Error-value = 10 ("RRO mixes SR-RRO subobjects with other subobject
	ion of an invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO	types").</t>
	/ SR-RRO subobjects").</t>	<t pn="section-5.3-4">The SR-RRO subobjects can be classified according
		to whether they contain a SID representing an MPLS label value or an index value
	</section>	, or no SID. If a PCE detects that the SR-RRO subobjects are a mixture of more
		than one of these types, then it <bcp14>MUST</bcp14> send a PCErr message with E
	</section> <!-- Procedures -->	rror-Type = 10 ("Reception of an invalid object") and Error-value = 20 ("Inconsi
		stent SIDs in SR-ERO / SR-RRO subobjects").</t>
	<section anchor="Management" title="Management Considerations">	</section>
		</section>
	<t>This document adds a new path setup type to PCEP to allow LSPs	<section anchor="Management" numbered="true" toc="include" removeInRFC="fals
	to be set up using segment routing techniques. This path setup	e" pn="section-6">
		<name slugifiedName="name-management-considerations">Management Considerat
		ions</name>
		<t pn="section-6-1">This document adds a new path setup type to PCEP to al
		low LSPs
		to be set up using Segment Routing techniques. This path setup
	type may be used with PCEP alongside other path setup types,	type may be used with PCEP alongside other path setup types,
	such as RSVP-TE, or it may be used exclusively.</t>	such as RSVP-TE, or it may be used exclusively.</t>

		<section anchor="control" numbered="true" toc="include" removeInRFC="false
	<section anchor="control" title="Controlling the Path Setup Type">	" pn="section-6.1">
		<name slugifiedName="name-controlling-the-path-setup-">Controlling the P
	<t>The following factors control which path setup type is used for	ath Setup Type</name>
		<t pn="section-6.1-1">The following factors control which path setup typ
		e is used for
	a given LSP.	a given LSP.


	<list style="symbols">	</t>
	<t> The available path setup types are constrained to those that	<ul spacing="normal" bare="false" empty="false" pn="section-6.1-2">
		<li pn="section-6.1-2.1"> The available path setup types are constrai
		ned to those that
	are supported by, or enabled on, the PCEP speakers. The	are supported by, or enabled on, the PCEP speakers. The
	PATH-SETUP-TYPE-CAPABILITY TLV indicates which path setup types	PATH-SETUP-TYPE-CAPABILITY TLV indicates which path setup types

	a PCEP speaker supports. To use segment routing as a path setup type,	a PCEP speaker supports. To use Segment Routing as a path setup type,
	it is a prerequisite that the PCC and PCE both include PST=1 in the	it is a prerequisite that the PCC and PCE both include PST=1 in the

	list of supported path setup types in this TLV, and also include the	list of supported path setup types in this TLV and also include the
	SR-PCE-CAPABILITY sub-TLV.</t>	SR-PCE-CAPABILITY sub-TLV.</li>
		<li pn="section-6.1-2.2"> When a PCE initiates an LSP, it proposes wh
	<t> When a PCE initiates an LSP, it proposes which path setup type	ich path setup type
	to use by including it in the	to use by including it in the
	PATH-SETUP-TYPE TLV in the SRP object of the PCInitiate message.	PATH-SETUP-TYPE TLV in the SRP object of the PCInitiate message.
	The PCE chooses the path setup type based on the capabilities of the	The PCE chooses the path setup type based on the capabilities of the

	network nodes on the path and on its local policy. The PCC MAY choose	network nodes on the path and on its local policy. The PCC <bcp14>MAY</bcp14
	to accept the proposed path setup type, or to reject the PCInitiate	> choose
	request, based on its local policy.</t>	to accept the proposed path setup type or to reject the PCInitiate
		request, based on its local policy.</li>
	<t> When a PCC requests a path for an LSP, it can nominate a preferred	<li pn="section-6.1-2.3"> When a PCC requests a path for an LSP, it c
		an nominate a preferred
	path setup type by including it in the PATH-SETUP-TYPE TLV in the	path setup type by including it in the PATH-SETUP-TYPE TLV in the

	RP object of the PCReq message. The PCE MAY choose to reply	RP object of the PCReq message. The PCE <bcp14>MAY</bcp14> choose to reply
	with a path of the requested type, or to reply with a path of a	with a path of the requested type, reply with a path of a
	different type, or to reject the request, based on the capabilities of the	different type, or reject the request, based on the capabilities of the
	network nodes on the path and on its local policy.</t>	network nodes on the path and on its local policy.</li>
	</list>	</ul>
	</t>	<t pn="section-6.1-3">The operator can influence the path setup type as
		follows.
	<t>The operator can influence the path setup type as follows.

	<list style="symbols">

	<t> Implementations MUST allow the operator to enable and disable
	the segment routing path setup type on a PCEP-speaking device.
	Implementations MAY also allow the operator to enable and disable the RSVP-TE
	path setup type.</t>

	<t> PCE implementations MUST allow the operator to specify that an LSP
	should be instantiated using segment routing or RSVP-TE as the proposed path
	setup type. </t>

	<t> PCE implementations MAY allow the operator to configure a
	preference for the PCE to propose paths using segment routing or RSVP-TE in
	the absence of a specified path setup type.</t>

	<t> PCC implementations MUST allow the operator to specify that a path
	requested for an LSP nominates segment routing or RSVP-TE as the
	path setup type.</t>

	<t> PCC implementations MAY allow the operator to configure a preference
	for the PCC to nominate segment routing or RSVP-TE as the path
	setup type if none is specified for an LSP.</t>


	<t> PCC implementations SHOULD allow the operator to configure a PCC to
	refuse to set up an LSP using an undesired path setup type.</t>
	</list>
	</t>	</t>

	</section>	<ul spacing="normal" bare="false" empty="false" pn="section-6.1-4">
		<li pn="section-6.1-4.1"> Implementations <bcp14>MUST</bcp14> allow t
	<section anchor="migrating" title="Migrating a Network to Use PCEP Segment Route	he operator to enable and disable
	d Paths">	the Segment Routing path setup type on a PCEP-speaking device.
		Implementations <bcp14>MAY</bcp14> also allow the operator to enable and disa
	<t>	ble the RSVP-TE
		path setup type.</li>
		<li pn="section-6.1-4.2"> PCE implementations <bcp14>MUST</bcp14> all
		ow the operator to specify that an LSP
		should be instantiated using Segment Routing or RSVP-TE as the proposed path
		setup type. </li>
		<li pn="section-6.1-4.3"> PCE implementations <bcp14>MAY</bcp14> allo
		w the operator to configure a
		preference for the PCE to propose paths using Segment Routing or RSVP-TE in
		the absence of a specified path setup type.</li>
		<li pn="section-6.1-4.4"> PCC implementations <bcp14>MUST</bcp14> all
		ow the operator to specify that a path
		requested for an LSP nominates Segment Routing or RSVP-TE as the
		path setup type.</li>
		<li pn="section-6.1-4.5"> PCC implementations <bcp14>MAY</bcp14> allo
		w the operator to configure a preference
		for the PCC to nominate Segment Routing or RSVP-TE as the path
		setup type if none is specified for an LSP.</li>
		<li pn="section-6.1-4.6"> PCC implementations <bcp14>SHOULD</bcp14> a
		llow the operator to configure a PCC to
		refuse to set up an LSP using an undesired path setup type.</li>
		</ul>
		</section>
		<section anchor="migrating" numbered="true" toc="include" removeInRFC="fal
		se" pn="section-6.2">
		<name slugifiedName="name-migrating-a-network-to-use-">Migrating a Netwo
		rk to Use PCEP Segment-Routed Paths</name>
		<t pn="section-6.2-1">
	This section discusses the steps that the operator takes when migrating a	This section discusses the steps that the operator takes when migrating a

	network to enable PCEP to set up paths using segment routing as the path	network to enable PCEP to set up paths using Segment Routing as the path
	setup type.	setup type.


	<list style="symbols">

	<t> The operator enables the segment routing PST on the PCE servers.</t>

	<t> The operator enables the segment routing PST on the PCCs.</t>

	<t> The operator resets each PCEP session. The PCEP sessions come
	back up with segment routing enabled.</t>

	<t> If the operator detects a problem, they can roll the network back
	to its initial state by disabling the segment routing PST on the
	PCEP speakers and resetting the PCEP sessions.</t>

	</list>
	</t>	</t>

	<t>Note that the data plane is unaffected if a PCEP session is reset. Any	<ul spacing="normal" bare="false" empty="false" pn="section-6.2-2">
		<li pn="section-6.2-2.1"> The operator enables the Segment Routing PS
		T on the PCE servers.</li>
		<li pn="section-6.2-2.2"> The operator enables the Segment Routing PS
		T on the PCCs.</li>
		<li pn="section-6.2-2.3"> The operator resets each PCEP session. The
		PCEP sessions come
		back up with Segment Routing enabled.</li>
		<li pn="section-6.2-2.4"> If the operator detects a problem, they can
		roll the network back
		to its initial state by disabling the Segment Routing PST on the
		PCEP speakers and resetting the PCEP sessions.</li>
		</ul>
		<t pn="section-6.2-3">Note that the data plane is unaffected if a PCEP s
		ession is reset. Any
	LSPs that were set up before the session reset will remain in place and	LSPs that were set up before the session reset will remain in place and
	will still be present after the session comes back up.</t>	will still be present after the session comes back up.</t>

		<t pn="section-6.2-4">An implementation <bcp14>SHOULD</bcp14> allow the
	<t>An implementation SHOULD allow the operator to manually trigger a PCEP	operator to manually trigger a PCEP
	session to be reset.</t>	session to be reset.</t>

		<t pn="section-6.2-5">An implementation <bcp14>MAY</bcp14> automatically
	<t>An implementation MAY automatically reset a PCEP session when	reset a PCEP session when
	an operator reconfigures the PCEP speaker's capabilities. However, note that	an operator reconfigures the PCEP speaker's capabilities. However, note that
	if the capabilities at both ends of the PCEP session are not reconfigured	if the capabilities at both ends of the PCEP session are not reconfigured
	simultaneously, then the session could be reset twice, which could lead to	simultaneously, then the session could be reset twice, which could lead to

	unnecessary network traffic. Therefore, such implementations SHOULD allow	unnecessary network traffic. Therefore, such implementations <bcp14>SHOULD</bcp
	the operator to override this behaviour and wait instead for a manual reset.</t>	14> allow
		the operator to override this behavior and wait instead for a manual reset.</t>
	<t>Once segment routing is enabled on a PCEP session, it can be used as the	<t pn="section-6.2-6">Once Segment Routing is enabled on a PCEP session,
		it can be used as the
	path setup type for future LSPs.</t>	path setup type for future LSPs.</t>

		<t pn="section-6.2-7">User traffic is not automatically migrated from ex
	<t>User traffic is not automatically migrated from existing LSPs onto	isting LSPs onto
	segment routed LSPs just by enabling the segment routing PST in PCEP. The	segment-routed LSPs just by enabling the Segment Routing PST in PCEP. The
	migration of user traffic from existing LSPs onto segment routing LSPs is	migration of user traffic from existing LSPs onto Segment Routing LSPs is
	beyond the scope of this document.</t>	beyond the scope of this document.</t>

		</section>
		<section anchor="verification" numbered="true" toc="include" removeInRFC="
		false" pn="section-6.3">
		<name slugifiedName="name-verification-of-network-ope">Verification of N
		etwork Operation</name>
		<t pn="section-6.3-1">The operator needs the following information to ve
		rify that PCEP is
		operating correctly with respect to the Segment Routing path setup type.


	</section>	</t>
		<ul spacing="normal" bare="false" empty="false" pn="section-6.3-2">
	<section anchor="verification" title="Verification of Network Operation">	<li pn="section-6.3-2.1"> An implementation <bcp14>SHOULD</bcp14> all
		ow the operator to view whether the
	<t>The operator needs the following information to verify that PCEP is	PCEP speaker sent the Segment Routing PST capability to its peer.
	operating correctly with respect to the segment routing path setup type.	If the PCEP speaker is a PCC, then the implementation <bcp14>SHOULD</bcp14> a
		lso allow
	<list style="symbols">	the operator to view the values of the L-Flag and N-Flag that were sent and t
		he value of the MSD field
	<t> An implementation SHOULD allow the operator to view whether the	that was sent.</li>
	PCEP speaker sent the segment routing PST capability to its peer.	<li pn="section-6.3-2.2"> An implementation <bcp14>SHOULD</bcp14> all
	If the PCEP speaker is a PCC, then the implementation SHOULD also allow	ow the operator to view
	the operator to view the values of the L and N flags that were sent, and the	whether the peer sent the Segment Routing PST capability. If the peer
	value of the MSD field	is a PCC, then the implementation <bcp14>SHOULD</bcp14> also allow the operat
	that was sent.</t>	or to view
		the values of the L-Flag and N-Flag and MSD fields that the peer sent.</li>
	<t> An implementation SHOULD allow the operator to view	<li pn="section-6.3-2.3"> An implementation <bcp14>SHOULD</bcp14> all
	whether the peer sent the segment routing PST capability. If the peer	ow the operator to view
	is a PCC, then the implementation SHOULD also allow the operator to view	whether the Segment Routing PST is enabled on the PCEP session.</li>
	the values of the L and N flags and MSD fields that the peer sent.</t>	<li pn="section-6.3-2.4"> If one PCEP speaker advertises the Segment
		Routing PST capability, but the other
	<t> An implementation SHOULD allow the operator to view	does not, then the implementation <bcp14>SHOULD</bcp14> create a log to infor
	whether the segment routing PST is enabled on the PCEP session.</t>	m the
		operator of the capability mismatch.</li>
	<t> If one PCEP speaker advertises the segment routing PST capability, but the	<li pn="section-6.3-2.5"> An implementation <bcp14>SHOULD</bcp14> all
	other	ow the operator to view the PST that was
	does not, then the implementation SHOULD create a log to inform the	proposed, or requested, for an LSP and the PST that was actually used.</li>
	operator of the capability mismatch.</t>	<li pn="section-6.3-2.6"> If a PCEP speaker decides to use a differen
		t PST to the one that was
	<t> An implementation SHOULD allow the operator to view the PST that was	proposed, or requested, for an LSP, then the implementation <bcp14>SHOULD</bc
	proposed, or requested, for an LSP, and the PST that was actually used.</t>	p14>

	<t> If a PCEP speaker decides to use a different PST to the one that was
	proposed, or requested, for an LSP, then the implementation SHOULD
	create a log to inform the operator that the expected PST has not been used.	create a log to inform the operator that the expected PST has not been used.

	The log SHOULD give the reason for this choice (local policy,	The log <bcp14>SHOULD</bcp14> give the reason for this choice (local policy,
	equipment capability etc.)</t>	equipment capability, etc.).</li>
		<li pn="section-6.3-2.7"> If a PCEP speaker rejects a Segment Routing
	<t> If a PCEP speaker rejects a segment routing path, then it SHOULD create a l	path, then it <bcp14>SHOULD</bcp14> create a log
	og
	to inform the operator, giving the reason for the decision (local policy,	to inform the operator, giving the reason for the decision (local policy,

	MSD exceeded etc.)</t>	MSD exceeded, etc.).</li>
	</list>	</ul>
	</t>	</section>
	</section>	<section anchor="models" numbered="true" toc="include" removeInRFC="false"
		pn="section-6.4">
	<section anchor="models" title="Relationship to Existing Management Models">	<name slugifiedName="name-relationship-to-existing-ma">Relationship to E
		xisting Management Models</name>
	<t>The PCEP YANG module is defined in <xref target="I-D.ietf-pce-pcep-yang"/>.	<t pn="section-6.4-1">The PCEP YANG module is defined in <xref target="I
	In future, this	-D.ietf-pce-pcep-yang" format="default" sectionFormat="of" derivedContent="PCE-P
		CEP-YANG"/>. In the future, this
	YANG module should be extended or augmented to provide the following	YANG module should be extended or augmented to provide the following

	additional information relating to segment routing:	additional information relating to Segment Routing:

	<list style="symbols">

	<t> The advertised PST capabilities and MSD per PCEP session.</t>


	<t> The PST configured for, and used by, each LSP.</t>
	</list>
	</t>	</t>

	<t>The PCEP MIB <xref target="RFC7420"/> could also be updated to include this	<ul spacing="normal" bare="false" empty="false" pn="section-6.4-2">
		<li pn="section-6.4-2.1"> The advertised PST capabilities and MSD per
		PCEP session.</li>
		<li pn="section-6.4-2.2"> The PST configured for, and used by, each L
		SP.</li>
		</ul>
		<t pn="section-6.4-3">The PCEP MIB <xref target="RFC7420" format="defaul
		t" sectionFormat="of" derivedContent="RFC7420"/> could also be updated to includ
		e this
	information.</t>	information.</t>

	</section>	</section>
		</section>
	</section>	<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
		pn="section-7">
	<section anchor="Security" title="Security Considerations">	<name slugifiedName="name-security-considerations">Security Considerations
		</name>
	<t>The security considerations described in <xref target="RFC5440"/>, <xref targ	<t pn="section-7-1">The security considerations described in <xref target=
	et="RFC8231"/>, <xref target="RFC8281"/> and <xref target="RFC8408"/> are	"RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, <xref
	applicable to this specification. No additional security measure is required.</	target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>,
	t>	<xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8
		281"/>, and <xref target="RFC8408" format="default" sectionFormat="of" derivedCo
	<t>Note that this specification enables a network controller to instantiate a	ntent="RFC8408"/> are
		applicable to this specification. No additional security measures are required.
		</t>
		<t pn="section-7-2">Note that this specification enables a network control
		ler to instantiate a
	path in the network without the use of a hop-by-hop signaling protocol	path in the network without the use of a hop-by-hop signaling protocol
	(such as RSVP-TE). This creates an additional vulnerability if the security	(such as RSVP-TE). This creates an additional vulnerability if the security

	mechanisms of <xref target="RFC5440"/>, <xref target="RFC8231"/> and <xref ta	mechanisms of <xref target="RFC5440" format="default" sectionFormat="of" deri
	rget="RFC8281"/> are not	vedContent="RFC5440"/>, <xref target="RFC8231" format="default" sectionFormat="o
	used. If there is no integrity protection on the session, then an attacker c	f" derivedContent="RFC8231"/>, and <xref target="RFC8281" format="default" secti
	ould create a path which is not subjected to the	onFormat="of" derivedContent="RFC8281"/> are not
		used. If there is no integrity protection on the session, then an attacker c
		ould create a path that is not subjected to the
	further verification checks that would be performed by the signaling	further verification checks that would be performed by the signaling
	protocol.</t>	protocol.</t>

		<t pn="section-7-3">Note that this specification adds the MSD field to the
	<t>Note that this specification adds the MSD field to the OPEN message (see <xre	Open message (see <xref target="cap-negotiation" format="default" sectionFormat
	f target="cap-negotiation"/>)	="of" derivedContent="Section 4.1.2"/>),
	which discloses how many MPLS labels the sender can push onto packets that	which discloses how many MPLS labels the sender can push onto packets that

	it forwards into the network. If the security mechanisms of <xref target="RFC 8231"/> and <xref target="RFC8281"/>	it forwards into the network. If the security mechanisms of <xref target="RFC 8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> and <xref t arget="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>
	are not used with strong encryption, then an attacker could use this	are not used with strong encryption, then an attacker could use this
	new field to gain intelligence about the capabilities of the edge devices in	new field to gain intelligence about the capabilities of the edge devices in
	the network.</t>	the network.</t>

		</section>
	</section>	<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
		"section-8">
	<section anchor="IANA" title="IANA Considerations">	<name slugifiedName="name-iana-considerations">IANA Considerations</name>
		<section anchor="PCEP-Object-Codepoints" numbered="true" toc="include" rem
	<section anchor="PCEP-Object-Codepoints" title="PCEP ERO and RRO subobject	oveInRFC="false" pn="section-8.1">
	s">	<name slugifiedName="name-pcep-ero-and-rro-subobjects">PCEP ERO and RRO
		Subobjects</name>
	<t>This document defines a new subobject type for the PCEP	<t pn="section-8.1-1">This document defines a new subobject type for the
	explicit route object (ERO), and a new subobject type for the PCEP record rou	PCEP ERO
	te object (RRO). The code points for subobject types of these objects is mainta	and a new subobject type for the PCEP RRO. The codepoints for
	ined in the RSVP parameters registry, under the EXPLICIT_ROUTE and ROUTE_RECORD	subobject types of these objects are maintained in the "Resource Reservati
	objects. IANA is requested to confirm the early allocation of the following code	on Protocol (RSVP) Parameters" registry, under the EXPLICIT_ROUTE and ROUTE_RECO
	points in the RSVP Parameters registry for each of the new subobject types defi	RD
	ned in this document.</t>	objects, respectively.</t>
		<table anchor="IANA-Subobject-Type" align="center" pn="table-1">
	<texttable anchor="IANA-Subobject-Type" style="none" suppress-title="true">	<thead>
	<ttcol align="left" width='40%'>Object</ttcol>	<tr>
	<ttcol align="left" width='40%'>Subobject</ttcol>	<th align="left" colspan="1" rowspan="1">Object</th>
	<ttcol align="left" width='60%'>Subobject Type</ttcol>	<th align="left" colspan="1" rowspan="1">Subobject</th>
		<th align="left" colspan="1" rowspan="1">Subobject Type</th>
	<c>---------------------</c><c>--------------------------</c><c>--------	</tr>
	----------</c>	</thead>
		<tbody>
	<c>EXPLICIT_ROUTE</c><c>SR-ERO (PCEP-specific)</c><c>36</c>	<tr>
	<c>ROUTE_RECORD</c><c>SR-RRO (PCEP-specific)</c><c>36</c>	<td align="left" colspan="1" rowspan="1">EXPLICIT_ROUTE</td>
	</texttable>	<td align="left" colspan="1" rowspan="1">SR-ERO (PCEP specific)</t
		d>
		<td align="left" colspan="1" rowspan="1">36</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">ROUTE_RECORD</td>
		<td align="left" colspan="1" rowspan="1">SR-RRO (PCEP specific)</t
		d>
		<td align="left" colspan="1" rowspan="1">36</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="NAI-Type-Registry" numbered="true" toc="include" removeIn
	<section anchor="NAI-Type-Registry" title="New NAI Type Registry">	RFC="false" pn="section-8.2">
		<name slugifiedName="name-new-nai-type-registry">New NAI Type Registry</
	<t>IANA is requested to create a new sub-registry within the "Path Computation E	name>
	lement Protocol (PCEP) Numbers" registry called "PCEP SR-ERO NAI Types". The all	<t pn="section-8.2-1">IANA has created a new sub-registry within the "Pa
	ocation policy for this new registry should be by IETF Review. The new registry	th Computation
	should contain the following values:	Element Protocol (PCEP) Numbers" registry called "PCEP SR-ERO NAI
		Types". The allocation policy for this new registry is by IETF
		Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent
		="RFC8126"/>. The new registry contains the
		following values:
	</t>	</t>

		<table anchor="New-PCEP-SR-ERO-NAI-value" align="center" pn="table-2">
	<texttable anchor="New-PCEP-SR-ERO-NAI-value" style="none" suppress-title="true"	<thead>
	>	<tr>
	<ttcol align="left" width='40%'>Value</ttcol>	<th align="left" colspan="1" rowspan="1">Value</th>
	<ttcol align="left" width='75%'>Description </ttcol>	<th align="left" colspan="1" rowspan="1">Description </th>
	<ttcol align="left" width='55%'>Reference </ttcol>	<th align="left" colspan="1" rowspan="1">Reference </th>
	<c></c><c> </c><c></c>	</tr>
	<c>0</c><c>NAI is absent.</c><c>This document</c>	</thead>
	<c>1</c><c>NAI is an IPv4 node ID.</c><c>This document</c>	<tbody>
	<c>2</c><c>NAI is an IPv6 node ID.</c><c>This document</c>	<tr>
	<c>3</c><c>NAI is an IPv4 adjacency.</c><c>This document</c>	<td align="left" colspan="1" rowspan="1">0</td>
	<c>4</c><c>NAI is an IPv6 adjacency with global IPv6 addresses.</c><c>Th	<td align="left" colspan="1" rowspan="1">NAI is absent.</td>
	is document</c>	<td align="left" colspan="1" rowspan="1">This document</td>
	<c>5</c><c>NAI is an unnumbered adjacency with IPv4 node IDs.</c><c>This	</tr>
	document</c>	<tr>
	<c>6</c><c>NAI is an IPv6 adjacency with link-local IPv6 addresses.</c><	<td align="left" colspan="1" rowspan="1">1</td>
	c>This document</c>	<td align="left" colspan="1" rowspan="1">NAI is an IPv4 node ID.</
	</texttable>	td>
	</section>	<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
	<section anchor="IANA-SR-ERO-FLAG" title="New SR-ERO Flag Registry">	<tr>
	<t>IANA is requested to create a new sub-registry, named	<td align="left" colspan="1" rowspan="1">2</td>
		<td align="left" colspan="1" rowspan="1">NAI is an IPv6 node ID.</
		td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">NAI is an IPv4 adjacency.
		</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">4</td>
		<td align="left" colspan="1" rowspan="1">NAI is an IPv6 adjacency
		with global IPv6 addresses.</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">5</td>
		<td align="left" colspan="1" rowspan="1">NAI is an unnumbered adja
		cency with IPv4 node IDs.</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">6</td>
		<td align="left" colspan="1" rowspan="1">NAI is an IPv6 adjacency
		with link-local IPv6 addresses.</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">7-15</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="IANA-SR-ERO-FLAG" numbered="true" toc="include" removeInR
		FC="false" pn="section-8.3">
		<name slugifiedName="name-new-sr-ero-flag-registry">New SR-ERO Flag Regi
		stry</name>
		<t pn="section-8.3-1">IANA has created a new sub-registry, named
	"SR-ERO Flag Field", within the "Path Computation	"SR-ERO Flag Field", within the "Path Computation
	Element Protocol (PCEP) Numbers" registry to manage the Flag	Element Protocol (PCEP) Numbers" registry to manage the Flag
	field of the SR-ERO subobject. New values are to be assigned by Standards	field of the SR-ERO subobject. New values are to be assigned by Standards

	Action <xref target="RFC8126"/>. Each bit should be tracked with the	Action <xref target="RFC8126" format="default" sectionFormat="of" derive dContent="RFC8126"/>. Each bit should be tracked with the
	following qualities:	following qualities:

	<list style="symbols">
	<t>Bit number (counting from bit 0 as the most significant bit)</t>
	<t>Capability description</t>
	<t>Defining RFC</t>
	</list>
	</t>	</t>

		<ul spacing="normal" bare="false" empty="false" pn="section-8.3-2">
	<t>The following values are defined in this document:</t>	<li pn="section-8.3-2.1">Bit number (counting from bit 0 as the most s
		ignificant bit)</li>
	<texttable anchor="SR-ERO-Flags" style="none" suppress-title="true">	<li pn="section-8.3-2.2">Capability description</li>
	<ttcol align="center" width='15%'>Bit</ttcol>	<li pn="section-8.3-2.3">Defining RFC</li>
	<ttcol align="left" width='30%'>Description </ttcol>	</ul>
	<ttcol align="left" width='55%'>Reference </ttcol>	<t pn="section-8.3-3">The following values are defined in this document:
	<c></c><c> </c><c></c>	</t>
	<c>0-7</c><c>Unassigned</c><c></c>	<table anchor="SR-ERO-Flags" align="center" pn="table-3">
	<c>8</c><c>NAI is absent (F)</c><c>This document</c>	<thead>
	<c>9</c><c>SID is absent (S)</c><c>This document</c>	<tr>
	<c>10</c><c>SID specifies TC, S and TTL in addition to an MPLS label (	<th align="center" colspan="1" rowspan="1">Bit</th>
	C)</c><c>This document</c>	<th align="left" colspan="1" rowspan="1">Description </th>
	<c>11</c><c>SID specifies an MPLS label (M)</c><c>This document</c>	<th align="left" colspan="1" rowspan="1">Reference </th>
	</texttable>	</tr>
	</section> <!-- SR-ERO Flags -->	</thead>
		<tbody>
	<section anchor="IANA-Error-Object" title="PCEP-Error Object">	<tr>
		<td align="center" colspan="1" rowspan="1">0-7</td>
	<t>IANA is requested to confirm the early allocation of the code-points	<td align="left" colspan="1" rowspan="1">Unassigned</td>
	in the PCEP-ERROR Object Error Types and Values registry for the following new e	<td align="left" colspan="1" rowspan="1"/>
	rror-values:	</tr>
		<tr>
	<vspace blankLines="1" />	<td align="center" colspan="1" rowspan="1">8</td>
		<td align="left" colspan="1" rowspan="1">NAI is absent (F)</td>
	<?rfc subcompact="yes"?>	<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
	<list style="hanging" hangIndent="13">	<tr>
		<td align="center" colspan="1" rowspan="1">9</td>
	<t hangText="Error-Type">Meaning</t>	<td align="left" colspan="1" rowspan="1">SID is absent (S)</td>
	<t hangText="---------- -------"></t>	<td align="left" colspan="1" rowspan="1">This document</td>
	<t hangText="10">Reception of an invalid object.	</tr>
	<list style="hanging" hangIndent="37">	<tr>
	<t hangText=" Error-value = 2:">Bad label value</t>	<td align="center" colspan="1" rowspan="1">10</td>
	<t hangText=" Error-value = 3:">Unsupported number of SR-ERO subobje	<td align="left" colspan="1" rowspan="1">SID specifies TC, S, and
	cts</t>	TTL in addition to an MPLS label (C)</td>
	<t hangText=" Error-value = 4:">Bad label format</t>	<td align="left" colspan="1" rowspan="1">This document</td>
	<t hangText=" Error-value = 5:">ERO mixes SR-ERO subobjects with oth	</tr>
	er subobject types</t>	<tr>
	<t hangText=" Error-value = 6:">Both SID and NAI are absent in SR-ER	<td align="center" colspan="1" rowspan="1">11</td>
	O subobject</t>	<td align="left" colspan="1" rowspan="1">SID specifies an MPLS lab
	<t hangText=" Error-value = 7:">Both SID and NAI are absent in SR-RR	el (M)</td>
	O subobject</t>	<td align="left" colspan="1" rowspan="1">This document</td>
	<t hangText=" Error-value = 9:">MSD exceeds the default for the PCEP	</tr>
	session</t>	</tbody>
	<t hangText=" Error-value = 10:">RRO mixes SR-RRO subobjects with ot	</table>
	her subobject types</t>
	<t hangText=" Error-value = TBD1:">Missing PCE-SR-CAPABILITY sub-TLV
	</t>
	<t hangText=" Error-value = TBD2:">Unsupported NAI Type in SR-ERO su
	bobject</t>
	<t hangText=" Error-value = TBD3:">Unknown SID</t>
	<t hangText=" Error-value = TBD4:">NAI cannot be resolved to a SID</
	t>
	<t hangText=" Error-value = TBD5:">Could not find SRGB</t>
	<t hangText=" Error-value = TBD6:">SID index exceeds SRGB size</t>
	<t hangText=" Error-value = TBD7:">Could not find SRLB</t>
	<t hangText=" Error-value = TBD8:">SID index exceeds SRLB size</t>
	<t hangText=" Error-value = TBD9:">Inconsistent SIDs in SR-ERO / SR-
	RRO subobjects</t>
	<t hangText=" Error-value = TBD10:">MSD must be nonzero</t>
	</list>
	</t>
	</list>
	</t>

	<t>Note to IANA: this draft originally had an early allocation for Error
	-value=11 (Malformed object) in the above list. However, we have since moved th
	e definition of that code point to RFC8408.</t>

	<t>Note to IANA: some Error-values in the above list were defined after
	the early allocation took place, and so do not currently have a code point assig
	ned. Please assign code points from the indicated registry and replace each ins
	tance of "TBD1", "TBD2" etc. in this document with the respective code points.</
	t>

	<t>Note to IANA: some of the Error-value descriptive strings above have
	changed since the early allocation. Please refresh the registry.</t>
	</section>	</section>

		<section anchor="IANA-Error-Object" numbered="true" toc="include" removeIn
	<section anchor="IANA-TLV-Type-Indicators" title="PCEP TLV Type Indicators	RFC="false" pn="section-8.4">
	">	<name slugifiedName="name-pcep-error-object">PCEP-Error Object</name>
	<t>IANA is requested to confirm the early allocation of the following co	<t pn="section-8.4-1">IANA has allocated the following codepoints in the
	de point in the PCEP TLV Type Indicators registry. Note that this TLV type indi	"PCEP-ERROR Object Error Types and Values" registry for the following new Error
	cator is deprecated but retained in the registry to ensure compatibility with ea	-values:</t>
	rly implementations of this specification. See <xref target="Early"/> for detai	<table anchor="PCEP-Error-table" align="center" pn="table-4">
	ls.</t>	<thead>
		<tr>
	<texttable anchor="PCEP-New-TLV-CP" style="none" suppress-title="true">	<th align="left" colspan="1" rowspan="1">Error-Type</th>
	<ttcol align="left" width='65%'>Value</ttcol>	<th align="left" colspan="1" rowspan="1">Meaning</th>
	<ttcol align="left" width='40%'>Meaning </ttcol>	<th align="left" colspan="1" rowspan="1">Error-value</th>
	<ttcol align="left" width='35%'>Reference </ttcol>	</tr>
	<c>-------------------------</c><c>----------------------------</c><c>	</thead>
	--------------</c>	<tbody>
	<c>26</c><c>SR-PCE-CAPABILITY (deprecated)</c><c>This document</c>	<tr>
	</texttable>	<td align="left" colspan="1" rowspan="1">10</td>
		<td align="left" colspan="1" rowspan="1">Reception of an invalid o
		bject</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">2: Bad label value</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">3: Unsupported number of
		SR-ERO subobjects</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">4: Bad label format</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">5: ERO mixes SR-ERO subob
		jects with other subobject types</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">6: Both SID and NAI are a
		bsent in the SR-ERO subobject</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">7: Both SID and NAI are a
		bsent in the SR-RRO subobject</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">9: MSD exceeds the defaul
		t for the PCEP session</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">10: RRO mixes SR-RRO subo
		bjects with other subobject types</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">12: Missing PCE-SR-CAPABI
		LITY sub-TLV</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">13: Unsupported NAI Type
		in the SR-ERO/SR-RRO subobject</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">14: Unknown SID</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">15: NAI cannot be resolve
		d to a SID</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">16: Could not find SRGB</
		td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">17: SID index exceeds SRG
		B size</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">18: Could not find SRLB</
		td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">19: SID index exceeds SRL
		B size</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">20: Inconsistent SIDs in
		SR-ERO / SR-RRO subobjects</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">21: MSD must be non-zero<
		/td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IANA-TLV-Type-Indicators" numbered="true" toc="include" r
	<section anchor="IANA-subTLV-Type-Indicators" title="PATH-SETUP-TYPE-CAPAB	emoveInRFC="false" pn="section-8.5">
	ILITY Sub-TLV Type Indicators">	<name slugifiedName="name-pcep-tlv-type-indicators">PCEP TLV Type Indica
	<t>IANA is requested to create a new sub-registry, named	tors</name>
	"PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Pat	<t pn="section-8.5-1">IANA has allocated the following codepoint in the
	h Computation	"PCEP TLV Type Indicators" registry. Note that this TLV type indicator is depre
	Element Protocol (PCEP) Numbers" registry to manage the type indicato	cated but retained in the registry to ensure compatibility with early implementa
	r	tions of this specification. See <xref target="Early" format="default" sectionF
	space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. New values	ormat="of" derivedContent="Appendix A"/> for details.</t>
	are to be assigned by Standards Action <xref target="RFC8126"/>. The	<table anchor="PCEP-New-TLV-CP" align="center" pn="table-5">
	valid range of values in the registry is 0-65535. IANA is requested to initial	<thead>
	ize the registry with the following values. All other values in the registry sh	<tr>
	ould be marked as "Unassigned".</t>	<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Meaning </th>
	<texttable anchor="PCEP-New-subTLV-CP" style="none" suppress-title="true	<th align="left" colspan="1" rowspan="1">Reference </th>
	">	</tr>
	<ttcol align="left" width='65%'>Value</ttcol>	</thead>
	<ttcol align="left" width='40%'>Meaning </ttcol>	<tbody>
	<ttcol align="left" width='35%'>Reference </ttcol>	<tr>
	<c>-------------------------</c><c>----------------------------</c><c>	<td align="left" colspan="1" rowspan="1">26</td>
	--------------</c>	<td align="left" colspan="1" rowspan="1">SR-PCE-CAPABILITY (deprec
	<c>0</c><c>Reserved</c><c>This document</c>	ated)</td>
	<c>TBD11 (recommended 26)</c><c>SR-PCE-CAPABILITY</c><c>This document<	<td align="left" colspan="1" rowspan="1">This document</td>
	/c>	</tr>
	</texttable>	</tbody>
		</table>
	<t>Note to IANA: Please replace each instance of "TBD11" in this documen
	t with the allocated code point. We have recommended that value 26 be used for
	consistency with the deprecated value in the PCEP TLV Type Indicators registry.<
	/t>

	</section>	</section>

		<section anchor="IANA-subTLV-Type-Indicators" numbered="true" toc="include
	<section anchor="IANA-PATH-SETUP-TYPE" title="New Path Setup Type">	" removeInRFC="false" pn="section-8.6">
	<t><xref target="RFC8408"/> created a sub-registry within the "Path Comp	<name slugifiedName="name-path-setup-type-capability-">PATH-SETUP-TYPE-C
	utation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types"	APABILITY Sub-TLV Type Indicators</name>
	. IANA is requested to allocate a new code point within this registry, as follow	<t pn="section-8.6-1">IANA has created a new sub-registry, named
	s:</t>	"PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators", within
		the "Path Computation Element Protocol (PCEP) Numbers"
	<texttable anchor="PATH-SETUP-TLV-value" style="none" suppress-title="true	registry to manage the type indicator space for sub-TLVs of
	">	the PATH-SETUP-TYPE-CAPABILITY TLV. New values are to be
	<ttcol align="left" width='50%'>Value</ttcol>	assigned by Standards Action <xref target="RFC8126" format="default" sec
	<ttcol align="left" width='50%'>Description </ttcol>	tionFormat="of" derivedContent="RFC8126"/>. The
	<ttcol align="left" width='35%'>Reference </ttcol>	valid range of values in the registry is 0-65535. IANA
		has initialized the registry with the following
	<c>-------------------------</c><c>----------------------------</c><c>--	values. All other values in the registry should be marked as
	------------</c>	"Unassigned".</t>
		<table anchor="PCEP-New-subTLV-CP" align="center" pn="table-6">
	<c>1</c><c>Traffic engineering path is setup using Segment Routing.</c><	<thead>
	c>This document</c>	<tr>
	</texttable>	<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Meaning </th>
		<th align="left" colspan="1" rowspan="1">Reference </th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">Reserved</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">26</td>
		<td align="left" colspan="1" rowspan="1">SR-PCE-CAPABILITY</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IANA-PATH-SETUP-TYPE" numbered="true" toc="include" remov
	<section anchor="IANA-METRIC-TYPE" title="New Metric Type">	eInRFC="false" pn="section-8.7">
	<t>IANA is requested to confirm the early allocation of the following co	<name slugifiedName="name-new-path-setup-type">New Path Setup Type</name
	de point in the PCEP METRIC object T field registry:</t>	>
		<t pn="section-8.7-1">A sub-registry within the "Path Computation Elemen
	<texttable anchor="METRIC-type" style="none" suppress-title="true">	t Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types" was created i
	<ttcol align="left" width='50%'>Value</ttcol>	n <xref target="RFC8408" format="default" sectionFormat="of" derivedContent="RFC
	<ttcol align="left" width='50%'>Description </ttcol>	8408"/>. IANA has allocated a new codepoint within this registry, as follows:</t
	<ttcol align="left" width='35%'>Reference </ttcol>	>
	<c>-------------------------</c><c>----------------------------</c><c>--	<table anchor="PATH-SETUP-TLV-value" align="center" pn="table-7">
	------------</c>	<thead>
	<c>11</c><c>Segment-ID (SID) Depth.</c><c>This document</c>	<tr>
	</texttable>	<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description </th>
		<th align="left" colspan="1" rowspan="1">Reference </th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">Traffic-engineering path
		is set up using Segment Routing.</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IANA-METRIC-TYPE" numbered="true" toc="include" removeInR
	<section anchor="IANA-SR-PCE-CAP-FLAG" title="SR PCE Capability Flags">	FC="false" pn="section-8.8">
	<t>IANA is requested to create a new sub-registry, named	<name slugifiedName="name-new-metric-type">New Metric Type</name>
		<t pn="section-8.8-1">IANA has allocated the following codepoint in the
		PCEP "METRIC Object T Field" registry:</t>
		<table anchor="METRIC-type" align="center" pn="table-8">
		<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description </th>
		<th align="left" colspan="1" rowspan="1">Reference </th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">11</td>
		<td align="left" colspan="1" rowspan="1">Segment-ID (SID) Depth.</
		td>
		<td align="left" colspan="1" rowspan="1">This document</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="IANA-SR-PCE-CAP-FLAG" numbered="true" toc="include" remov
		eInRFC="false" pn="section-8.9">
		<name slugifiedName="name-sr-pce-capability-flags">SR PCE Capability Fla
		gs</name>
		<t pn="section-8.9-1">IANA has created a new sub-registry, named
	"SR Capability Flag Field", within the "Path Computation	"SR Capability Flag Field", within the "Path Computation
	Element Protocol (PCEP) Numbers" registry to manage the Flag	Element Protocol (PCEP) Numbers" registry to manage the Flag
	field of the SR-PCE-CAPABILITY TLV. New values are to be assigned by Standar ds	field of the SR-PCE-CAPABILITY TLV. New values are to be assigned by Standar ds

	Action <xref target="RFC8126"/>. Each bit should be tracked with the	Action <xref target="RFC8126" format="default" sectionFormat="of" derive dContent="RFC8126"/>. Each bit should be tracked with the
	following qualities:	following qualities:

	<list style="symbols">
	<t>Bit number (counting from bit 0 as the most significant bit)</t>
	<t>Capability description</t>
	<t>Defining RFC</t>
	</list>
	</t>	</t>

		<ul spacing="normal" bare="false" empty="false" pn="section-8.9-2">
	<t>The following values are defined in this document:</t>	<li pn="section-8.9-2.1">Bit number (counting from bit 0 as the most s
		ignificant bit)</li>
	<texttable anchor="SR-PCE-CAP-Flags" style="none" suppress-title="true">	<li pn="section-8.9-2.2">Capability description</li>
	<ttcol align="center" width='15%'>Bit</ttcol>	<li pn="section-8.9-2.3">Defining RFC</li>
	<ttcol align="left" width='30%'>Description </ttcol>	</ul>
	<ttcol align="left" width='55%'>Reference </ttcol>	<t pn="section-8.9-3">The following values are defined in this document:
	<c></c><c> </c><c></c>	</t>
	<c>0-5</c><c>Unassigned</c><c></c>	<table anchor="SR-PCE-CAP-Flags" align="center" pn="table-9">
	<c>6</c><c>Node or Adjacency Identifier (NAI) is supported (N)</c><c>T	<thead>
	his document</c>	<tr>
	<c>7</c><c>Unlimited Maximum SID Depth (X)</c><c>This document</c>	<th align="center" colspan="1" rowspan="1">Bit</th>
	</texttable>	<th align="left" colspan="1" rowspan="1">Description </th>
	<t>Note to IANA: The name of bit 7 has changed from "Unlimited Maximum S	<th align="left" colspan="1" rowspan="1">Reference </th>
	ID Depth (L)" to "Unlimited Maximum SID Depth (X)".</t>	</tr>
	</section> <!-- SR PCE Capability Flags -->	</thead>
	</section>	<tbody>
		<tr>
	<section anchor="Contributors" title="Contributors">	<td align="center" colspan="1" rowspan="1">0-5</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
	<?rfc subcompact="yes"?>	<td align="left" colspan="1" rowspan="1"/>
	<t>The following people contributed to this document:	</tr>
	<list style="empty">	<tr>
	<t>- Lakshmi Sharma</t>	<td align="center" colspan="1" rowspan="1">6</td>
	<t>- Jan Medved</t>	<td align="left" colspan="1" rowspan="1">Node or Adjacency Identif
	<t>- Edward Crabbe</t>	ier (NAI) is supported (N)</td>
	<t>- Robert Raszuk</t>	<td align="left" colspan="1" rowspan="1">This document</td>
	<t>- Victor Lopez</t>	</tr>
	</list>	<tr>
	</t>	<td align="center" colspan="1" rowspan="1">7</td>
	<?rfc subcompact="no"?>	<td align="left" colspan="1" rowspan="1">Unlimited Maximum SID Dep
	</section>	th (X)</td>
		<td align="left" colspan="1" rowspan="1">This document</td>
	<section anchor="Acknowledgement" title="Acknowledgements">	</tr>
		</tbody>
	<t>We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing-Wh	</table>
	er Chen and Tomas Janciga for the valuable comments.</t>	</section>

	</section>	</section>

		</middle>
	</middle>	<back>
		<displayreference target="I-D.ietf-6man-segment-routing-header" to="IPv6-SRH
	<back>	"/>
	<references title="Normative References">	<displayreference target="I-D.ietf-spring-segment-routing-policy" to="SR-POL
		ICY"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119	<displayreference target="I-D.ietf-idr-bgp-ls-segment-routing-msd" to="MSD-B
	.xml"?>	GP"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032	<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
	.xml"?>	<references pn="section-9">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440	<name slugifiedName="name-references">References</name>
	.xml"?>	<references pn="section-9.1">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174	<name slugifiedName="name-normative-references">Normative References</na
	.xml"?>	me>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	.xml"?>	119" quoteTitle="true" derivedAnchor="RFC2119">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281	<front>
	.xml"?>	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402	le>
	.xml"?>	<author initials="S." surname="Bradner" fullname="S. Bradner">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8408	<organization showOnFrontPage="true"/>
	.xml"?>	</author>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8491	<date year="1997" month="March"/>
	.xml"?>	<abstract>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	<t>In many standards track documents several words are used to sig
	t-ietf-spring-segment-routing-mpls-18.xml"?>	nify the requirements in the specification. These words are often capitalized.
		This document defines these words as they should be interpreted in IETF document
	</references>	s. This document specifies an Internet Best Current Practices for the Internet
		Community, and requests discussion and suggestions for improvements.</t>
	<references title="Informative References">	</abstract>
		</front>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.	<seriesInfo name="BCP" value="14"/>
	xml"?>	<seriesInfo name="RFC" value="2119"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	xml"?>	</reference>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7420.	<reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3
	xml"?>	032" quoteTitle="true" derivedAnchor="RFC3032">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.	<front>
	xml"?>	<title>MPLS Label Stack Encoding</title>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8413.	<author initials="E." surname="Rosen" fullname="E. Rosen">
	xml"?>	<organization showOnFrontPage="true"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8476.	</author>
	xml"?>	<author initials="D." surname="Tappan" fullname="D. Tappan">
		<organization showOnFrontPage="true"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	</author>
	t-ietf-6man-segment-routing-header-16.xml"?>	<author initials="G." surname="Fedorkow" fullname="G. Fedorkow">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	<organization showOnFrontPage="true"/>
	t-ietf-spring-segment-routing-policy-02.xml"?>	</author>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
	t-ietf-isis-segment-routing-extensions-22.xml"?>	<organization showOnFrontPage="true"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	</author>
	t-ietf-ospf-segment-routing-extensions-27.xml"?>	<author initials="D." surname="Farinacci" fullname="D. Farinacci">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	<organization showOnFrontPage="true"/>
	t-ietf-idr-bgp-ls-segment-routing-msd-02.xml"?>	</author>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draf	<author initials="T." surname="Li" fullname="T. Li">
	t-ietf-pce-pcep-yang-09.xml"?>	<organization showOnFrontPage="true"/>
		</author>
	</references>	<author initials="A." surname="Conta" fullname="A. Conta">
		<organization showOnFrontPage="true"/>
	<section anchor="Early" title="Compatibility with Early Implementations">	</author>
		<date year="2001" month="January"/>
	<t>	<abstract>
		<t>This document specifies the encoding to be used by an LSR in or
		der to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on
		LAN data links, and possibly on other data links as well. This document also sp
		ecifies rules and procedures for processing the various fields of the label stac
		k encoding. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3032"/>
		<seriesInfo name="DOI" value="10.17487/RFC3032"/>
		</reference>
		<reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5
		440" quoteTitle="true" derivedAnchor="RFC5440">
		<front>
		<title>Path Computation Element (PCE) Communication Protocol (PCEP)<
		/title>
		<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
		="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role
		="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2009" month="March"/>
		<abstract>
		<t>This document specifies the Path Computation Element (PCE) Comm
		unication Protocol (PCEP) for communications between a Path Computation Client (
		PCC) and a PCE, or between two PCEs. Such interactions include path computation
		requests and path computation replies as well as notifications of specific stat
		es related to the use of a PCE in the context of Multiprotocol Label Switching (
		MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be
		flexible and extensible so as to easily allow for the addition of further messag
		es and objects, should further requirements be expressed in the future. [STANDA
		RDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5440"/>
		<seriesInfo name="DOI" value="10.17487/RFC5440"/>
		</reference>
		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
		174" quoteTitle="true" derivedAnchor="RFC8174">
		<front>
		<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
		tle>
		<author initials="B." surname="Leiba" fullname="B. Leiba">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2017" month="May"/>
		<abstract>
		<t>RFC 2119 specifies common key words that may be used in protoco
		l specifications. This document aims to reduce the ambiguity by clarifying tha
		t only UPPERCASE usage of the key words have the defined special meanings.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="14"/>
		<seriesInfo name="RFC" value="8174"/>
		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
		</reference>
		<reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8
		231" quoteTitle="true" derivedAnchor="RFC8231">
		<front>
		<title>Path Computation Element Communication Protocol (PCEP) Extens
		ions for Stateful PCE</title>
		<author initials="E." surname="Crabbe" fullname="E. Crabbe">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="I." surname="Minei" fullname="I. Minei">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J." surname="Medved" fullname="J. Medved">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R." surname="Varga" fullname="R. Varga">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2017" month="September"/>
		<abstract>
		<t>The Path Computation Element Communication Protocol (PCEP) prov
		ides mechanisms for Path Computation Elements (PCEs) to perform path computation
		s in response to Path Computation Client (PCC) requests.</t>
		<t>Although PCEP explicitly makes no assumptions regarding the inf
		ormation available to the PCE, it also makes no provisions for PCE control of ti
		ming and sequence of path computations within and across PCEP sessions. This do
		cument describes a set of extensions to PCEP to enable stateful control of MPLS-
		TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8231"/>
		<seriesInfo name="DOI" value="10.17487/RFC8231"/>
		</reference>
		<reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8
		281" quoteTitle="true" derivedAnchor="RFC8281">
		<front>
		<title>Path Computation Element Communication Protocol (PCEP) Extens
		ions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
		<author initials="E." surname="Crabbe" fullname="E. Crabbe">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="I." surname="Minei" fullname="I. Minei">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R." surname="Varga" fullname="R. Varga">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2017" month="December"/>
		<abstract>
		<t>The Path Computation Element Communication Protocol (PCEP) prov
		ides mechanisms for Path Computation Elements (PCEs) to perform path computation
		s in response to Path Computation Client (PCC) requests.</t>
		<t>The extensions for stateful PCE provide active control of Multi
		protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP
		s) via PCEP, for a model where the PCC delegates control over one or more locall
		y configured LSPs to the PCE. This document describes the creation and deletion
		of PCE-initiated LSPs under the stateful PCE model.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8281"/>
		<seriesInfo name="DOI" value="10.17487/RFC8281"/>
		</reference>
		<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
		402" quoteTitle="true" derivedAnchor="RFC8402">
		<front>
		<title>Segment Routing Architecture</title>
		<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
		="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S." surname="Previdi" fullname="S. Previdi" role="
		editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="B." surname="Decraene" fullname="B. Decraene">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S." surname="Litkowski" fullname="S. Litkowski">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R." surname="Shakir" fullname="R. Shakir">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2018" month="July"/>
		<abstract>
		<t>Segment Routing (SR) leverages the source routing paradigm. A
		node steers a packet through an ordered list of instructions, called "segments".
		A segment can represent any instruction, topological or service based. A segm
		ent can have a semantic local to an SR node or global within an SR domain. SR p
		rovides a mechanism that allows a flow to be restricted to a specific topologica
		l path, while maintaining per-flow state only at the ingress node(s) to the SR d
		omain.</t>
		<t>SR can be directly applied to the MPLS architecture with no cha
		nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered
		list of segments is encoded as a stack of labels. The segment to process is on
		the top of the stack. Upon completion of a segment, the related label is poppe
		d from the stack.</t>
		<t>SR can be applied to the IPv6 architecture, with a new type of
		routing header. A segment is encoded as an IPv6 address. An ordered list of se
		gments is encoded as an ordered list of IPv6 addresses in the routing header. T
		he active segment is indicated by the Destination Address (DA) of the packet. T
		he next active segment is indicated by a pointer in the new routing header.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8402"/>
		<seriesInfo name="DOI" value="10.17487/RFC8402"/>
		</reference>
		<reference anchor="RFC8408" target="https://www.rfc-editor.org/info/rfc8
		408" quoteTitle="true" derivedAnchor="RFC8408">
		<front>
		<title>Conveying Path Setup Type in PCE Communication Protocol (PCEP
		) Messages</title>
		<author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J." surname="Tantsura" fullname="J. Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="I." surname="Minei" fullname="I. Minei">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R." surname="Varga" fullname="R. Varga">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J." surname="Hardwick" fullname="J. Hardwick">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2018" month="July"/>
		<abstract>
		<t>A Path Computation Element (PCE) can compute Traffic Engineerin
		g (TE) paths through a network; these paths are subject to various constraints.
		Currently, TE paths are Label Switched Paths (LSPs) that are set up using the R
		SVP-TE signaling protocol. However, other TE path setup methods are possible wi
		thin the PCE architecture. This document proposes an extension to the PCE Commu
		nication Protocol (PCEP) to allow support for different path setup methods over
		a given PCEP session.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8408"/>
		<seriesInfo name="DOI" value="10.17487/RFC8408"/>
		</reference>
		<reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8
		491" quoteTitle="true" derivedAnchor="RFC8491">
		<front>
		<title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
		<author initials="J." surname="Tantsura" fullname="J. Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="U." surname="Chunduri" fullname="U. Chunduri">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S." surname="Aldrin" fullname="S. Aldrin">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2018" month="November"/>
		<abstract>
		<t>This document defines a way for an Intermediate System to Inter
		mediate System (IS-IS) router to advertise multiple types of supported Maximum S
		ID Depths (MSDs) at node and/or link granularity. Such advertisements allow enti
		ties (e.g., centralized controllers) to determine whether a particular Segment I
		D (SID) stack can be supported in a given network. This document only defines o
		ne type of MSD: Base MPLS Imposition. However, it defines an encoding that can
		support other MSD types. This document focuses on MSD use in a network that is
		Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.
		</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8491"/>
		<seriesInfo name="DOI" value="10.17487/RFC8491"/>
		</reference>
		<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8
		660" quoteTitle="true" derivedAnchor="RFC8660">
		<front>
		<title>Segment Routing with the MPLS Data Plane</title>
		<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
		le="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		role="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Previdi" fullname="Stefano Previdi">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="B" surname="Decraene" fullname="Bruno Decraene">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
		i">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R" surname="Shakir" fullname="Rob Shakir">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="December" year="2019"/>
		</front>
		<seriesInfo name="RFC" value="8660"/>
		<seriesInfo name="DOI" value="10.17487/RFC8660"/>
		</reference>
		</references>
		<references pn="section-9.2">
		<name slugifiedName="name-informative-references">Informative References
		</name>
		<reference anchor="I-D.ietf-6man-segment-routing-header" quoteTitle="tru
		e" target="https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
		" derivedAnchor="IPv6-SRH">
		<front>
		<title>IPv6 Segment Routing Header (SRH)</title>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D" surname="Dukes" fullname="Darren Dukes">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Previdi" fullname="Stefano Previdi">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J" surname="Leddy" fullname="John Leddy">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Matsushima" fullname="Satoru Matsushim
		a">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D" surname="Voyer" fullname="Daniel Voyer">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="October" day="22" year="2019"/>
		<abstract>
		<t>Segment Routing can be applied to the IPv6 data plane using a n
		ew type of Routing Extension Header called the Segment Routing Header. This docu
		ment describes the Segment Routing Header and how it is used by Segment Routing
		capable nodes.</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-6man-segment-routi
		ng-header-26"/>
		<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
		etf-6man-segment-routing-header-26.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="I-D.ietf-idr-bgp-ls-segment-routing-msd" quoteTitle="
		true" target="https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-
		msd-09" derivedAnchor="MSD-BGP">
		<front>
		<title>Signaling MSD (Maximum SID Depth) using Border Gateway Protoc
		ol Link-State</title>
		<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="U" surname="Chunduri" fullname="Uma Chunduri">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar
		">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="G" surname="Mirsky" fullname="Gregory Mirsky">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="N" surname="Triantafillis" fullname="Nikos Trianta
		fillis">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="October" day="15" year="2019"/>
		<abstract>
		<t>This document defines a way for a Border Gateway Protocol Link-
		State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Dept
		hs (MSDs) at node and/or link granularity. Such advertisements allow entities (
		e.g., centralized controllers) to determine whether a particular Segment Identif
		ier (SID) stack can be supported in a given network.</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-segment
		-routing-msd-09"/>
		<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
		etf-idr-bgp-ls-segment-routing-msd-09.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="I-D.ietf-pce-pcep-yang" quoteTitle="true" target="htt
		ps://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13" derivedAnchor="PCE-PCEP-YA
		NG">
		<front>
		<title>A YANG Data Model for Path Computation Element Communications
		Protocol (PCEP)</title>
		<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J" surname="Hardwick" fullname="Jonathan Hardwick"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="V" surname="Beeram" fullname="Vishnu Beeram">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="October" day="31" year="2019"/>
		<abstract>
		<t>This document defines a YANG data model for the management of P
		ath Computation Element communications Protocol (PCEP) for communications betwee
		n a Path Computation Client (PCC) and a Path Computation Element (PCE), or betwe
		en two PCEs. The data model includes configuration and state data.</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-13"/
		>
		<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
		etf-pce-pcep-yang-13.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3
		209" quoteTitle="true" derivedAnchor="RFC3209">
		<front>
		<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
		<author initials="D." surname="Awduche" fullname="D. Awduche">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L." surname="Berger" fullname="L. Berger">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D." surname="Gan" fullname="D. Gan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="T." surname="Li" fullname="T. Li">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="G." surname="Swallow" fullname="G. Swallow">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2001" month="December"/>
		<abstract>
		<t>This document describes the use of RSVP (Resource Reservation P
		rotocol), including all the necessary extensions, to establish label-switched pa
		ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LS
		P is completely identified by the label applied at the ingress node of the path,
		these paths may be treated as tunnels. A key application of LSP tunnels is tra
		ffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3209"/>
		<seriesInfo name="DOI" value="10.17487/RFC3209"/>
		</reference>
		<reference anchor="RFC4657" target="https://www.rfc-editor.org/info/rfc4
		657" quoteTitle="true" derivedAnchor="RFC4657">
		<front>
		<title>Path Computation Element (PCE) Communication Protocol Generic
		Requirements</title>
		<author initials="J." surname="Ash" fullname="J. Ash" role="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J.L." surname="Le Roux" fullname="J.L. Le Roux" ro
		le="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2006" month="September"/>
		<abstract>
		<t>The PCE model is described in the "PCE Architecture" document a
		nd facilitates path computation requests from Path Computation Clients (PCCs) to
		Path Computation Elements (PCEs). This document specifies generic requirements
		for a communication protocol between PCCs and PCEs, and also between PCEs where
		cooperation between PCEs is desirable. Subsequent documents will specify appli
		cation-specific requirements for the PCE communication protocol. This memo prov
		ides information for the Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4657"/>
		<seriesInfo name="DOI" value="10.17487/RFC4657"/>
		</reference>
		<reference anchor="RFC7420" target="https://www.rfc-editor.org/info/rfc7
		420" quoteTitle="true" derivedAnchor="RFC7420">
		<front>
		<title>Path Computation Element Communication Protocol (PCEP) Manage
		ment Information Base (MIB) Module</title>
		<author initials="A." surname="Koushik" fullname="A. Koushik">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="E." surname="Stephan" fullname="E. Stephan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="Q." surname="Zhao" fullname="Q. Zhao">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D." surname="King" fullname="D. King">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J." surname="Hardwick" fullname="J. Hardwick">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2014" month="December"/>
		<abstract>
		<t>This memo defines a portion of the Management Information Base
		(MIB) for use with network management protocols in the Internet community. In pa
		rticular, it describes managed objects for modeling of the Path Computation Elem
		ent Communication Protocol (PCEP) for communications between a Path Computation
		Client (PCC) and a Path Computation Element (PCE), or between two PCEs.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7420"/>
		<seriesInfo name="DOI" value="10.17487/RFC7420"/>
		</reference>
		<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
		126" quoteTitle="true" derivedAnchor="RFC8126">
		<front>
		<title>Guidelines for Writing an IANA Considerations Section in RFCs
		</title>
		<author initials="M." surname="Cotton" fullname="M. Cotton">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="B." surname="Leiba" fullname="B. Leiba">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="T." surname="Narten" fullname="T. Narten">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2017" month="June"/>
		<abstract>
		<t>Many protocols make use of points of extensibility that use con
		stants to identify various protocol parameters. To ensure that the values in th
		ese fields do not have conflicting uses and to promote interoperability, their a
		llocations are often coordinated by a central record keeper. For IETF protocols
		, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
		<t>To make assignments in a given registry prudently, guidance des
		cribing the conditions under which new values should be assigned, as well as whe
		n and how modifications to existing values can be made, is needed. This documen
		t defines a framework for the documentation of these guidelines by specification
		authors, in order to assure that the provided guidance for the IANA Considerati
		ons is clear and addresses the various issues that are likely in the operation o
		f a registry.</t>
		<t>This is the third edition of this document; it obsoletes RFC 52
		26.</t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="26"/>
		<seriesInfo name="RFC" value="8126"/>
		<seriesInfo name="DOI" value="10.17487/RFC8126"/>
		</reference>
		<reference anchor="RFC8413" target="https://www.rfc-editor.org/info/rfc8
		413" quoteTitle="true" derivedAnchor="RFC8413">
		<front>
		<title>Framework for Scheduled Use of Resources</title>
		<author initials="Y." surname="Zhuang" fullname="Y. Zhuang">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="Q." surname="Wu" fullname="Q. Wu">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="H." surname="Chen" fullname="H. Chen">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="A." surname="Farrel" fullname="A. Farrel">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2018" month="July"/>
		<abstract>
		<t>Time-Scheduled (TS) reservation of Traffic Engineering (TE) res
		ources can be used to provide resource booking for TE Label Switched Paths so as
		to better guarantee services for customers and to improve the efficiency of net
		work resource usage at any moment in time, including network usage that is plann
		ed for the future. This document provides a framework that describes and discus
		ses the architecture for supporting scheduled reservation of TE resources. This
		document does not describe specific protocols or protocol extensions needed to
		realize this service.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8413"/>
		<seriesInfo name="DOI" value="10.17487/RFC8413"/>
		</reference>
		<reference anchor="RFC8476" target="https://www.rfc-editor.org/info/rfc8
		476" quoteTitle="true" derivedAnchor="RFC8476">
		<front>
		<title>Signaling Maximum SID Depth (MSD) Using OSPF</title>
		<author initials="J." surname="Tantsura" fullname="J. Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="U." surname="Chunduri" fullname="U. Chunduri">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S." surname="Aldrin" fullname="S. Aldrin">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="P." surname="Psenak" fullname="P. Psenak">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2018" month="December"/>
		<abstract>
		<t>This document defines a way for an Open Shortest Path First (OS
		PF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at
		node and/or link granularity. Such advertisements allow entities (e.g., centra
		lized controllers) to determine whether a particular Segment Identifier (SID) st
		ack can be supported in a given network. This document only refers to the Signa
		ling MSD as defined in RFC 8491, but it defines an encoding that can support oth
		er MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8476"/>
		<seriesInfo name="DOI" value="10.17487/RFC8476"/>
		</reference>
		<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
		665" quoteTitle="true" derivedAnchor="RFC8665">
		<front>
		<title>OSPF Extensions for Segment Routing</title>
		<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
		editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
		le="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="H" surname="Gredler" fullname="Hannes Gredler">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R" surname="Shakir" fullname="Rob Shakir">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="W" surname="Henderickx" fullname="Wim Henderickx">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="December" year="2019"/>
		</front>
		<seriesInfo name="RFC" value="8665"/>
		<seriesInfo name="DOI" value="10.17487/RFC8665"/>
		</reference>
		<reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
		667" quoteTitle="true" derivedAnchor="RFC8667">
		<front>
		<title>IS-IS Extensions for Segment Routing</title>
		<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
		le="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L" surname="Ginsberg" fullname="Les Ginsberg" role
		="editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="H" surname="Gredler" fullname="Hannes Gredler">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="B" surname="Decraene" fullname="Bruno Decraene">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="December" year="2019"/>
		</front>
		<seriesInfo name="RFC" value="8667"/>
		<seriesInfo name="DOI" value="10.17487/RFC8667"/>
		</reference>
		<reference anchor="I-D.ietf-spring-segment-routing-policy" quoteTitle="t
		rue" target="https://tools.ietf.org/html/draft-ietf-spring-segment-routing-polic
		y-05" derivedAnchor="SR-POLICY">
		<front>
		<title>Segment Routing Policy Architecture</title>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D" surname="Voyer" fullname="Daniel Voyer">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="A" surname="Bogdanov" fullname="Alex Bogdanov">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="P" surname="Mattes" fullname="Paul Mattes">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="November" day="17" year="2019"/>
		<abstract>
		<t>Segment Routing (SR) allows a headend node to steer a packet fl
		ow along any path. Intermediate per-flow states are eliminated thanks to source
		routing. The headend node steers a flow into an SR Policy. The header of a pac
		ket steered in an SR Policy is augmented with an ordered list of segments associ
		ated with that SR Policy. This document details the concepts of SR Policy and s
		teering into an SR Policy.</t>
		</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-spring-segment-rou
		ting-policy-05"/>
		<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
		etf-spring-segment-routing-policy-05.txt"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		</references>
		</references>
		<section anchor="Early" numbered="true" toc="include" removeInRFC="false" pn
		="section-appendix.a">
		<name slugifiedName="name-compatibility-with-early-im">Compatibility with
		Early Implementations</name>
		<t pn="section-appendix.a-1">
	An early implementation of this specification will send the	An early implementation of this specification will send the
	SR-CAPABILITY-TLV as a top-level TLV in the OPEN object instead	SR-CAPABILITY-TLV as a top-level TLV in the OPEN object instead
	of sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object.	of sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object.
	Implementations that wish to interoperate with such early implementations	Implementations that wish to interoperate with such early implementations
	should also send the SR-CAPABILITY-TLV as a top-level TLV in their OPEN object	should also send the SR-CAPABILITY-TLV as a top-level TLV in their OPEN object
	and should interpret receiving this top-level TLV as though the sender had sen t	and should interpret receiving this top-level TLV as though the sender had sen t
	a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP -TE and	a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP -TE and
	SR-TE PSTs are supported) with the SR-CAPABILITY-TLV as a sub-TLV.	SR-TE PSTs are supported) with the SR-CAPABILITY-TLV as a sub-TLV.
	If a PCEP speaker receives an OPEN object in which both the	If a PCEP speaker receives an OPEN object in which both the
	SR-CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level	SR-CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level
	TLVs, then it should ignore the top-level SR-CAPABILITY-TLV and process	TLVs, then it should ignore the top-level SR-CAPABILITY-TLV and process
	only the PATH-SETUP-TYPE-CAPABILITY TLV.	only the PATH-SETUP-TYPE-CAPABILITY TLV.
	</t>	</t>

		</section>
	</section>	<section anchor="Acknowledgement" numbered="false" toc="include" removeInRFC
		="false" pn="section-appendix.b">
	</back>	<name slugifiedName="name-acknowledgements">Acknowledgements</name>
		<t pn="section-appendix.b-1">We thank Ina Minei, George Swallow, Marek Zav
		odsky, Dhruv Dhody, Ing-Wher Chen, and Tomas Janciga for the valuable comments.<
		/t>
		</section>
		<section anchor="Contributors" numbered="false" toc="include" removeInRFC="f
		alse" pn="section-appendix.c">
		<name slugifiedName="name-contributors">Contributors</name>
		<t pn="section-appendix.c-1">The following people contributed to this docu
		ment:
		</t>
		<ul spacing="compact" bare="false" empty="false" pn="section-appendix.c-2"
		>
		<li pn="section-appendix.c-2.1">Lakshmi Sharma</li>
		<li pn="section-appendix.c-2.2">Jan Medved</li>
		<li pn="section-appendix.c-2.3">Edward Crabbe</li>
		<li pn="section-appendix.c-2.4">Robert Raszuk</li>
		<li pn="section-appendix.c-2.5">Victor Lopez</li>
		</ul>
		</section>
		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.d">
		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
		<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
		<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
		<address>
		<postal>
		<street>2000 Innovation Drive</street>
		<city>Kanata</city>
		<region>Ontario</region>
		<code>K2K 3E8</code>
		<country>Canada</country>
		</postal>
		<email>msiva@cisco.com</email>
		</address>
		</author>
		<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
		<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
		<address>
		<postal>
		<street>Pegasus Parc</street>
		<city>De kleetlaan 6a</city>
		<region>Diegem</region>
		<code>Brabant 1831</code>
		<country>Belgium</country>
		</postal>
		<email>cfilsfil@cisco.com</email>
		</address>
		</author>
		<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
		<organization showOnFrontPage="true">Apstra, Inc.</organization>
		<address>
		<postal>
		<street>333 Middlefield Rd #200</street>
		<city>Menlo Park</city>
		<region>CA</region>
		<code>94025</code>
		<country>United States of America</country>
		</postal>
		<email>jefftant.ietf@gmail.com</email>
		</address>
		</author>
		<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
		<organization showOnFrontPage="true">Nokia</organization>
		<address>
		<postal>
		<street>Copernicuslaan 50</street>
		<city>Antwerp 2018</city>
		<region>CA</region>
		<code>95134</code>
		<country>Belgium</country>
		</postal>
		<email>wim.henderickx@nokia.com</email>
		</address>
		</author>
		<author fullname="Jon Hardwick" initials="J." surname="Hardwick">
		<organization showOnFrontPage="true">Metaswitch Networks</organization>
		<address>
		<postal>
		<street>100 Church Street</street>
		<city>Enfield</city>
		<region>Middlesex</region>
		<country>United Kingdom</country>
		</postal>
		<email>jonathan.hardwick@metaswitch.com</email>
		</address>
		</author>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 99 change blocks.
	1371 lines changed or deleted	2801 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/