rfc9757.original.xml		rfc9757.xml
	<?xml version='1.0' encoding='UTF-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!-- [rfced] pre-edited by ST 09/04/24 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie tf-pce-pcep-extension-native-ip-39" number="0000" consensus="true" ipr="trust200 902" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" obso letes="" updates="" xml:lang="en" tocDepth="3" version="3">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie tf-pce-pcep-extension-native-ip-40" number="9757" consensus="true" ipr="trust200 902" sortRefs="true" submissionType="IETF" symRefs="true" tocInclude="true" obso letes="" updates="" xml:lang="en" tocDepth="3" version="3">
	<front>		<front>
	<title abbrev="PCEP for Native IP">Path Computation Element Communication		<title abbrev="PCEP for Native IP">Path Computation Element Communication
	Protocol (PCEP) Extensions for Native IP Networks</title>		Protocol (PCEP) Extensions for Native IP Networks</title>
	<seriesInfo name="RFC" value="0000"/>		<seriesInfo name="RFC" value="9757"/>
	<author fullname="Aijun Wang" initials="A" surname="Wang">		<author fullname="Aijun Wang" initials="A" surname="Wang">
	<organization>China Telecom</organization>		<organization>China Telecom</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Beiqijia Town, Changping District</street>		<street>Beiqijia Town, Changping District</street>
	<city>Beijing</city>		<city>Beijing</city>
	<region>Beijing</region>
	<code>102209</code>		<code>102209</code>
	<country>China</country>		<country>China</country>
	</postal>		</postal>
	<email>wangaijun@tsinghua.org.cn</email>		<email>wangaijun@tsinghua.org.cn</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Boris Khasanov" initials="B" surname="Khasanov">		<author fullname="Boris Khasanov" initials="B" surname="Khasanov">
	<organization abbrev="">MTS Web Services (MWS)</organization>		<organization abbrev="">MTS Web Services (MWS)</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Andropova av.,18/9 115432</street>		<street>Andropova av., 18/9</street>
	<city>Moscow</city>		<city>Moscow</city>
			<code>115432</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>bhassanov@yahoo.com</email>		<email>bhassanov@yahoo.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Sheng Fang" initials="S" surname="Fang">		<author fullname="Sheng Fang" initials="S" surname="Fang">
	<organization abbrev="">Huawei Technologies</organization>		<organization abbrev="">Huawei Technologies</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Huawei Bld., No.156 Beiqing Rd.</street>		<street>Huawei Bld., No.156 Beiqing Rd.</street>
	skipping to change at line 77 ¶		skipping to change at line 74 ¶
	<postal>		<postal>
	<street>50 Software Avenue, Yuhua District</street>		<street>50 Software Avenue, Yuhua District</street>
	<city>Nanjing</city>		<city>Nanjing</city>
	<region>Jiangsu</region>		<region>Jiangsu</region>
	<code>210012</code>		<code>210012</code>
	<country>China</country>		<country>China</country>
	</postal>		</postal>
	<email>zhu.chun1@zte.com.cn</email>		<email>zhu.chun1@zte.com.cn</email>
	</address>		</address>
	</author>		</author>
	<date month="September" year="2024"/>		<date month="February" year="2025"/>
	<area>RTG</area>		<area>RTG</area>
	<workgroup>pce</workgroup>		<workgroup>pce</workgroup>
	<keyword>CCDR</keyword>		<keyword>CCDR</keyword>
	<keyword>PCECC</keyword>		<keyword>PCECC</keyword>
	<abstract>		<abstract>
	<t>This document introduces extensions to the PCE Communication Protocol		<t>This document introduces extensions to the Path Computation Element Com munication Protocol
	(PCEP) to support path computation in native IP networks through a		(PCEP) to support path computation in native IP networks through a
	PCE-based central control mechanism known as Centralized Control Dynamic		PCE-based central control mechanism known as Centralized Control Dynamic
	Routing (CCDR). These extensions empower a PCE to calculate and manage		Routing (CCDR).
			<!--[rfced] How may we clarify the latter part of this sentence?
			Original:
			These extensions empower a PCE to calculate
			and manage paths specifically for native IP networks, expand PCEP's
			capabilities beyond its traditional use in MPLS and GMPLS networks.
			Perhaps:
			These extensions empower a PCE to calculate
			and manage paths specifically for native IP networks, thereby expanding
			PCEP's capabilities beyond its traditional use in MPLS and GMPLS networks.
			-->
			These extensions empower a PCE to calculate and manage
	paths specifically for native IP networks, expand PCEP's		paths specifically for native IP networks, expand PCEP's
	capabilities beyond its traditional use in MPLS and GMPLS networks. By		capabilities beyond its traditional use in MPLS and GMPLS networks. By
	implementing these extensions, IP network resources can be utilized more		implementing these extensions, IP network resources can be utilized more
	efficiently, facilitating the deployment of traffic engineering in		efficiently, facilitating the deployment of traffic engineering in
	native IP environments.</t>		native IP environments.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	skipping to change at line 97 ¶		skipping to change at line 109 ¶
	paths specifically for native IP networks, expand PCEP's		paths specifically for native IP networks, expand PCEP's
	capabilities beyond its traditional use in MPLS and GMPLS networks. By		capabilities beyond its traditional use in MPLS and GMPLS networks. By
	implementing these extensions, IP network resources can be utilized more		implementing these extensions, IP network resources can be utilized more
	efficiently, facilitating the deployment of traffic engineering in		efficiently, facilitating the deployment of traffic engineering in
	native IP environments.</t>		native IP environments.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Generally, Multiprotocol Label Switching Traffic Engineering		<t>Generally, Multiprotocol Label Switching Traffic Engineering
	(MPLS-TE) requires the corresponding network devices to support Resource		(MPLS-TE) requires the corresponding network devices to support the Resour
	ReSerVation Protocol (RSVP)<xref target="RFC3209" format="default"/>/Label		ce
	Distribution		ReSerVation Protocol (RSVP) <xref target="RFC3209" format="default"/> and
	Protocol (LDP)<xref target="RFC5036" format="default"/> protocols to ensur		the Label Distribution
	e the		Protocol (LDP) <xref target="RFC5036" format="default"/> to ensure
	End-to-End (E2E) traffic performance. But in native IP network scenarios		End-to-End (E2E) traffic performance. But in native IP network scenarios
	described in <xref target="RFC8735" format="default"/>, there will be no s uch signaling		described in <xref target="RFC8735" format="default"/>, there will be no s uch signaling
	protocol to synchronize the actions among different network devices. It		protocol to synchronize the actions among different network devices. It
	is feasible to use the central control mode described in <xref target="RFC 8283" format="default"/> to correlate the forwarding behavior among different		is feasible to use the central control mode described in <xref target="RFC 8283" format="default"/> to correlate the forwarding behavior among different
	network devices. <xref target="RFC8821" format="default"/> describes the a		network devices.
	rchitecture and
			<!--[rfced] To avoid awkward hyphenation, may we update the text below
			as follows?
			Original:
			[RFC8821] describes the architecture and solution philosophy for the E2E
			traffic assurance in the Native IP network via multiple Border
			Gateway Protocol (BGP) sessions-based solution.
			Perhaps:
			[RFC8821] describes the architecture and solution philosophy for the E2E
			traffic assurance in the Native IP network via a solution based on
			multiple Border Gateway Protocol (BGP) sessions.
			-->
			<xref target="RFC8821" format="default"/> describes the architecture and
	solution philosophy for the E2E traffic assurance in the Native IP		solution philosophy for the E2E traffic assurance in the Native IP
	network via multiple Border Gateway Protocol (BGP) sessions-based		network via multiple Border Gateway Protocol (BGP) sessions-based
	solution. It requires only the PCE to send the instructions to the PCCs,		solution. It requires only the PCE to send the instructions to the Path Co mputation Clients (PCCs)
	to build multiple BGP sessions, distribute different prefixes on the		to build multiple BGP sessions, distribute different prefixes on the
	established BGP sessions and assign the different paths to the BGP next		established BGP sessions, and assign the different paths to the BGP next
	hops.</t>		hops.</t>
	<t>This document describes the corresponding Path Computation Element		<t>This document describes the corresponding Path Computation Element
	Communication Protocol (PCEP) extensions to transfer the key information		Communication Protocol (PCEP) extensions to transfer the key information
	about BGP peer, peer prefix advertisement, and the explicit peer route		about the BGP peer, peer prefix advertisement, and explicit peer route
	on on-path routers.</t>		on on-path routers.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Conventions used in this document</name>		<name>Conventions Used in This Document</name>
	<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"OPTIONAL" in this document are to be interpreted as described in BCP 14		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	efault"/> when, and only when,		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	they appear in all capitals, as shown here.</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Use of RBNF</name>		<name>Use of RBNF</name>
	<t>The message formats in this document are illustrated using Routing		<t>The message formats in this document are illustrated using Routing
	Backus-Naur Form (RBNF) encoding, as specified in <xref target="RFC5511" format="default"/>. The use of RBNF is illustrative only and may elide		Backus-Naur Form (RBNF) encoding, as specified in <xref target="RFC5511" format="default"/>. The use of RBNF is illustrative only and may elide
	certain important details; the normative specification of messages is		certain important details; the normative specification of messages is
	found in the prose description. If there is any divergence between the		found in the prose description. If there is any divergence between the
	RBNF and the prose, the prose is considered authoritative.</t>		RBNF and the prose, the prose is considered authoritative.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Experimental Status Consideration</name>		<name>Experimental Status Consideration</name>
	<t>The procedures outlined in this document are experimental. The		<t>The procedures outlined in this document are experimental. The
	experiment aims to explore the use of PCE (and PCEP) for end-to-end		experiment aims to explore the use of PCE (and PCEP) for E2E
	traffic assurance in Native IP networks through multiple BGP sessions.		traffic assurance in Native IP networks through multiple BGP sessions.
	Additional implementation is necessary to gain a deeper understanding		Additional implementation is necessary to gain a deeper understanding
	of the operational impact, scalability, and stability of the mechanism		of the operational impact, scalability, and stability of the mechanism
	described. Feedback from deployments will be crucial in determining		described.
			<!-- [rfced] This sentence implies that the status of this document
			could change in the future. May we update the text to state that
			a new document would be published in order to update the status?
			Original:
			Feedback from deployments will be
			crucial in determining whether this specification should advance from
			Experimental to the IETF Standards Track.
			Perhaps:
			Feedback from deployments will be
			crucial in determining whether a future document will be published to
			advance this specification from Experimental to the IETF Standards Track.
			-->
			Feedback from deployments will be crucial in determining
	whether this specification should advance from Experimental to the		whether this specification should advance from Experimental to the
	IETF Standards Track.</t>		IETF Standards Track.</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>This document uses the following terms defined in <xref target="RFC5440		<t>This document uses the following terms defined in <xref target="RFC5440
	" format="default"/>: PCC, PCE, PCEP.</t>		" format="default"/>: PCC, PCE, and PCEP.</t>
	<t>The following terminology is used in this document:</t>		<t>Additionally, the following terminology is used in this document:</t>
	<ul spacing="normal">		<dl spacing="normal" newline="false">
	<li>		<dt>BPI:</dt><dd>BGP Peer Info</dd>
	<t>BPI: BGP Peer Info</t>		<dt>CCDR:</dt><dd>Centralized Control Dynamic Routing</dd>
	</li>		<dt>CCI:</dt><dd>Central Controller Instructions (defined in <xref tar
	<li>		get="RFC9050" format="default"/>)</dd>
	<t>CCDR: Central Control Dynamic Routing</t>		<dt>E2E:</dt><dd>End-to-End</dd>
	</li>		<dt>EPR:</dt><dd>Explicit Peer Route</dd>
	<li>		<dt>Native IP network:</dt><dd>Network that forwards traffic based sol
	<t>CCI: Central Controller Instructions, defined in <xref target="RFC9		ely on
	050" format="default"/></t>		the IP address, instead of another indicator, for example, MPLS,
	</li>		etc.</dd>
	<li>		<dt>PCECC:</dt><dd>PCE as a Central Controller (defined in <xref targe
	<t>E2E: End-to-End</t>		t="RFC8283" format="default"/>)</dd>
	</li>		<dt>PPA:</dt><dd>Peer Prefix Advertisement</dd>
	<li>		<dt>PST:</dt><dd>Path Setup Type (defined in <xref target="RFC8408" fo
	<t>EPR: Explicit Peer Route</t>		rmat="default"/>)</dd>
	</li>		<dt>SRP:</dt><dd>Stateful PCE Request Parameter (defined in <xref targ
	<li>		et="RFC8231" format="default"/>)</dd>
	<t>Native IP network: Network that forwards traffic based solely on		<dt>RR:</dt><dd>Route Reflector</dd>
	the IP address, instead of other indicator, for example MPLS		</dl>
	etc.</t>
	</li>
	<li>
	<t>PCECC: PCE as a Central Controller, defined in <xref target="RFC828
	3" format="default"/></t>
	</li>
	<li>
	<t>PPA: Peer Prefix Advertisement</t>
	</li>
	<li>
	<t>PST: Path Setup Type, defined in <xref target="RFC8408" format="def
	ault"/></t>
	</li>
	<li>
	<t>SRP: Stateful PCE Request Parameters, defined in <xref target="RFC8
	231" format="default"/></t>
	</li>
	<li>
	<t>RR: Route Reflector</t>
	</li>
	</ul>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Capability Advertisement</name>		<name>Capability Advertisement</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Open Message</name>		<name>Open Message</name>
	<t>During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)		<t>During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
	advertise their support of Native IP extensions.</t>		advertise their support of Native IP extensions.</t>
	<t>This document defines a new Path Setup Type (PST) <xref target="RFC84 08" format="default"/> for Native-IP, as follows: </t>		<t>This document defines a new Path Setup Type (PST) <xref target="RFC84 08" format="default"/> for Native-IP, as follows: </t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>PST = 4: Path is a Native IP TE path as per <xref target="RFC8821"
	<t>PST = 4: Path is a Native IP TE path as per <xref target="RFC8821		format="default"/>.</li>
	" format="default"/>.</t>
	</li>
	</ul>		</ul>
	<t>A PCEP speaker MUST indicate its support of the function described		<t>A PCEP speaker <bcp14>MUST</bcp14> indicate its support of the functi on described
	in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the		in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
	OPEN object with this new PST included in the PST list.</t>		OPEN object with this new PST included in the PST list.</t>
			<!--[rfced] Does "their" refer to "PCECC-CAPABILITY sub-TLV"? If
			yes, may we update "their" to "its" for clarity?
			Original:
			[RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange
			information about their PCECC capability.
			Perhaps:
			[RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange
			information about its PCECC capability.
			-->
	<t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILIT Y sub-TLV to		<t><xref target="RFC9050" format="default"/> defined the PCECC-CAPABILIT Y sub-TLV to
	exchange information about their PCECC capability. A new flag is		exchange information about their PCECC capability. A new flag is
	defined in PCECC-CAPABILITY sub-TLV for Native IP:</t>		defined in the PCECC-CAPABILITY sub-TLV for Native IP:</t>
	<t>N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP		<t>N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP
	speaker, this flag indicates that the PCEP speaker is capable of TE in		speaker, this flag indicates that the PCEP speaker is capable of TE in
	a Native IP network, as specified in this document. Both the PCC and		a Native IP network, as specified in this document. Both the PCC and
	PCE MUST set this flag to support this extension.</t>		PCE <bcp14>MUST</bcp14> set this flag to support this extension.</t>
	<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with		<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
	the newly defined path setup type, but without the N bit set in		the newly defined PST, but without the N bit set in
	PCECC-CAPABILITY sub-TLV, it MUST:</t>		PCECC-CAPABILITY sub-TLV, it <bcp14>MUST</bcp14>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>send a PCErr message with Error-Type=10 (Reception of an		<t>send a PCErr message with Error-Type=10 (Reception of an
	invalid object) and Error-Value=39 (PCECC NATIVE-IP-TE-CAPABILITY		invalid object) and Error-Value=39 (PCECC NATIVE-IP-TE-CAPABILITY
	bit is not set).</t>		bit is not set) and</t>
	</li>		</li>
	<li>		<li>
	<t>terminate the PCEP session</t>		<t>terminate the PCEP session.</t>
	</li>		</li>
	</ul>		</ul>
	<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with		<t>If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
	the newly defined path setup type, but without the PCECC-CAPABILITY		the newly defined PST, but without the PCECC-CAPABILITY
	sub-TLV, it MUST:</t>		sub-TLV, it <bcp14>MUST</bcp14>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>send a PCErr message with Error-Type=10(Reception of an invalid		<t>send a PCErr message with Error-Type=10 (Reception of an invalid
	object) and Error-Value=33 (Missing PCECC Capability sub-TLV).</t>		object) and Error-Value=33 (Missing PCECC Capability sub-TLV) and</t
			>
	</li>		</li>
	<li>		<li>
	<t>terminate the PCEP session</t>		<t>terminate the PCEP session.</t>
	</li>		</li>
	</ul>		</ul>
	<t>If one or both speakers (PCE and PCC) have not indicated the		<t>If one or both speakers (PCE and PCC) have not indicated the
	support for Native-IP, the PCEP extensions for the Native-IP MUST NOT		support for Native-IP, the PCEP extensions for the Native-IP <bcp14>MUST NOT</bcp14>
	be used. If a Native-IP operation is attempted when both speakers have		be used. If a Native-IP operation is attempted when both speakers have
	not agreed on the OPEN messages, the receiver of the message MUST:</t>		not agreed on the OPEN messages, the receiver of the message <bcp14>MUST </bcp14>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>send a PCErr message with Error-Type=19 (Invalid Operation) and		<t>send a PCErr message with Error-Type=19 (Invalid Operation) and
	Error-value=TBD1 (Attempted Native-IP operations when the		Error-value=29 (Attempted Native-IP operations when the
	capability was not advertised) and</t>		capability was not advertised) and</t>
	</li>		</li>
	<li>		<li>
	<t>terminate the PCEP session.</t>		<t>terminate the PCEP session.</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section toc="default" numbered="true">		<section toc="default" numbered="true">
	<name>PCEP Messages</name>		<name>PCEP Messages</name>
	<t>PCECC Native IP TE solution uses the existing PCE Label Switched Path
			<!--[rfced] To improve readability, may we update this sentence as
			follows? Please review and ensure that the suggested text does not alter
			the intended meaning.
			Original:
			The PCECC Native IP TE solution uses the existing PCE Label Switched
			Path (LSP) Initiate Request message (PCInitiate) [RFC8281], and PCE
			Report message (PCRpt) [RFC8231] to accomplish the multiple BGP
			sessions establishment, E2E Native-IP TE path deployment, and route
			prefixes advertisement among different BGP sessions.
			Perhaps:
			The PCECC Native IP TE solution uses the existing PCE Label Switched
			Path (LSP) Initiate Request message (PCInitiate) [RFC8281] and PCE
			Report message (PCRpt) [RFC8231] to establish multiple BGP sessions,
			deploy the E2E Native-IP TE path, and advertise route prefixes
			among different BGP sessions.
			-->
			<t>The PCECC Native IP TE solution uses the existing PCE Label Switched Pa
			th
	(LSP) Initiate Request message (PCInitiate) <xref target="RFC8281" format= "default"/>,		(LSP) Initiate Request message (PCInitiate) <xref target="RFC8281" format= "default"/>,
	and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> t o accomplish		and PCE Report message (PCRpt) <xref target="RFC8231" format="default"/> t o accomplish
	the multiple BGP sessions establishment, E2E Native-IP TE path		the multiple BGP sessions establishment, E2E Native-IP TE path
	deployment, and route prefixes advertisement among different BGP		deployment, and route prefixes advertisement among different BGP
	sessions. A new PST for Native-IP is used to indicate the path setup		sessions. A new PST for Native-IP is used to indicate the path setup
	based on TE in Native IP networks.</t>		based on TE in Native IP networks.</t>
	<t>The extended PCInitiate message described in <xref target="RFC9050" for mat="default"/>		<t>The extended PCInitiate message described in <xref target="RFC9050" for mat="default"/>
	is used to download or remove the central controller's instructions		is used to download or remove the Central Controller Instructions
	(CCIs). <xref target="RFC9050" format="default"/> specifies an object call		(CCI). <xref target="RFC9050" format="default"/> specifies an object calle
	ed CCI for the		d CCI for the
	encoding of the central controller's instructions. This document		encoding of the central controller's instructions. This document
	specifies a new CCI Object-Type for Native IP. The PCEP messages are		specifies a new CCI Object-Type for Native IP. The PCEP messages are
	extended in this document to handle the PCECC operations for Native IP.		extended in this document to handle the PCECC operations for Native IP.
	Three new PCEP Objects (BGP Peer Info (BPI) Object, Explicit Peer Route		Three new PCEP Objects (BGP Peer Info (BPI), Explicit Peer Route
	(EPR) Object, and Peer Prefix Advertisement (PPA) Object) are defined in		(EPR), and Peer Prefix Advertisement (PPA)) are defined in
	this document. Refer to <xref target="Obj-Def-Sec" format="default"/> for detailed object		this document. Refer to <xref target="Obj-Def-Sec" format="default"/> for detailed object
	definitions. All PCEP procedures specified in <xref target="RFC9050" forma t="default"/>		definitions. All PCEP procedures specified in <xref target="RFC9050" forma t="default"/>
	continue to apply unless specified otherwise.</t>		continue to apply unless specified otherwise.</t>
	<section anchor="SEC_PCInitiate" toc="default" numbered="true">		<section anchor="SEC_PCInitiate" toc="default" numbered="true">
	<name>The PCInitiate Message</name>		<name>The PCInitiate Message</name>
	<t>The PCInitiate Message defined in <xref target="RFC8281" format="defa ult"/> and		<t>The PCInitiate Message defined in <xref target="RFC8281" format="defa ult"/> and
	extended in <xref target="RFC9050" format="default"/> is further extende d to support		extended in <xref target="RFC9050" format="default"/> is further extende d to support
	Native-IP CCI.</t>		Native-IP CCI.</t>
	<t>The format of the extended PCInitiate message is as follows:		<t>The format of the extended PCInitiate message is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<!-- [rfced] Please review the "type" attribute of each sourcecode element
			in the XML file to ensure correctness. If the current list of preferred
			values for "type"
			(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
			does not contain an applicable type, then feel free to let us know.
			Also, it is acceptable to leave the "type" attribute not set.
			-->
			<sourcecode name="" type="rbnf"><![CDATA[
	<PCInitiate Message> ::= <Common Header>		<PCInitiate Message> ::= <Common Header>
	<PCE-initiated-lsp-list>		<PCE-initiated-lsp-list>
	Where:		]]></sourcecode>
	<Common Header> is defined in [RFC5440]
			<t>Where:</t>
			<sourcecode name="" type="rbnf"><![CDATA[
			<Common Header> is defined in RFC 5440
	<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>		<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
	[<PCE-initiated-lsp-list>]		[<PCE-initiated-lsp-list>]
	<PCE-initiated-lsp-request> ::=		<PCE-initiated-lsp-request> ::=
	(<PCE-initiated-lsp-instantiation>|		(<PCE-initiated-lsp-instantiation>|
	<PCE-initiated-lsp-deletion>|		<PCE-initiated-lsp-deletion>|
	<PCE-initiated-lsp-central-control>)		<PCE-initiated-lsp-central-control>)
	<PCE-initiated-lsp-central-control> ::= <SRP>		<PCE-initiated-lsp-central-control> ::= <SRP>
	<LSP>		<LSP>
	<cci-list>		<cci-list>
	<cci-list> ::= <CCI>		<cci-list> ::= <CCI>
	[<BPI>|<EPR>|<PPA>]		[<BPI>|<EPR>|<PPA>]
	[<cci-list>]		[<cci-list>]
	]]></artwork>		]]></sourcecode>
	<t>Where: </t>		<t>Where:</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>&lt;PCE-initiated-lsp-instantiation&gt; and		<t>&lt;PCE-initiated-lsp-instantiation&gt; and
	&lt;PCE-initiated-lsp-deletion&gt; are as per [RFC8281].</t>		&lt;PCE-initiated-lsp-deletion&gt; are as per <xref target="RFC8281" />.</t>
	</li>		</li>
	<li>		<li>
	<t>The LSP and SRP objects are defined in [RFC8231].</t>		<t>The LSP and SRP objects are defined in <xref target="RFC8231"/>.< /t>
	</li>		</li>
	</ul>		</ul>
	<t>When the PCInitiate message is used for Native IP instructions,		<t>When the PCInitiate message is used for Native IP instructions,
	i.e. When the CCI Object-Type is 2, the SRP, LSP and CCI objects MUST		i.e., when the CCI Object-Type is 2, the SRP, LSP, and CCI objects <bcp1
	be present. Error handling for missing SRP, LSP or CCI objects MUST be		4>MUST</bcp14>
			be present. Error handling for missing SRP, LSP, or CCI objects <bcp14>M
			UST</bcp14> be
	performed as specified in <xref target="RFC9050" format="default"/>. Add itionally,		performed as specified in <xref target="RFC9050" format="default"/>. Add itionally,
	exactly one object among the BPI, EPR, or PPA objects MUST be present.		exactly one object among the BPI, EPR, or PPA objects <bcp14>MUST</bcp14
	The PLSP-ID and Symbolic Path Name TLVs are set as per the existing		> be present.
			The PCEP-specific LSP
			identifier (PLSP-ID) and Symbolic Path Name TLVs are set as per the existing
	rules in <xref target="RFC8231" format="default"/>, <xref target="RFC828 1" format="default"/>, and <xref target="RFC9050" format="default"/>. The Symbol ic Path Name is used by the PCE/PCC to		rules in <xref target="RFC8231" format="default"/>, <xref target="RFC828 1" format="default"/>, and <xref target="RFC9050" format="default"/>. The Symbol ic Path Name is used by the PCE/PCC to
	uniquely identify the E2E native IP TE path. The related Native-IP		uniquely identify the E2E native IP TE path. The related Native-IP
	instructions with BPI, EPR or PPA objects are identified by the same		instructions with BPI, EPR, or PPA objects are identified by the same
	Symbolic Path Name.</t>		Symbolic Path Name.</t>
	<t>If none of the BPI, EPR or PPA objects are present, the receiving		<t>If none of the BPI, EPR, or PPA objects are present, the receiving
	PCC MUST send a PCErr message with Error-type=6 (Mandatory Object		PCC <bcp14>MUST</bcp14> send a PCErr message with Error-type=6 (Mandator
	missing) and Error-value=19 (Native IP object missing). If there is		y Object
	more than one instance of BPI, EPR or PPA object present, the		missing) and Error-value=19 (Native IP object missing).
	receiving PCC MUST send a PCErr message with Error-type=19 (Invalid
	Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be		<!--[rfced] May we make the following sentences more concise by removing
			"instance of"? Please review the suggested text and let us know if this
			change alters the intended meaning.
			Original:
			If there is
			more than one instance of BPI, EPR or PPA object present, the
			receiving PCC MUST send a PCErr message with Error-type=19 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be
			included in this message).
			...
			If there are
			more than one instance of BPI, EPR or PPA objects present, the
			receiving PCE MUST send a PCErr message with Error-type=19 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be
			included in this message).
			Perhaps:
			If there is
			more than one BPI, EPR, or PPA object present, the
			receiving PCC MUST send a PCErr message with Error-type=19 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
			included in this message).
			...
			If there is
			more than one BPI, EPR, or PPA object present, the
			receiving PCE MUST send a PCErr message with Error-type=19 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
			included in this message).
			-->
			If there is
			more than one instance of BPI, EPR, or PPA object present, the
			receiving PCC <bcp14>MUST</bcp14> send a PCErr message with Error-type=1
			9 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
	included in this message).</t>		included in this message).</t>
	<t>When the PCInitiate message is not used for Native IP instructions,		<t>When the PCInitiate message is not used for Native IP instructions,
	i.e. When CCI Object-Type is not equal to 2, the BPI, EPR and PPA		i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and PPA
	objects SHOULD NOT be present. If present, they MUST be ignored by the		objects <bcp14>SHOULD NOT</bcp14> be present. If present, they <bcp14>MU
			ST</bcp14> be ignored by the
	receiver.</t>		receiver.</t>
	<t>To clean up the existing Native IP instructions, the SRP object		<t>To clean up the existing Native IP instructions, the SRP object
	MUST set the R (remove) bit.</t>		<bcp14>MUST</bcp14> set the R (remove) bit.</t>
	</section>		</section>
	<section anchor="SEC_PCRpt" toc="default" numbered="true">		<section anchor="SEC_PCRpt" toc="default" numbered="true">
	<name>The PCRpt Message</name>		<name>The PCRpt Message</name>
	<t>The PCRpt message is used to acknowledge the Native-IP instructions		<t>The PCRpt message is used to acknowledge the Native-IP instructions
	received from the central controller (PCE) as well as during the State		received from the central controller (PCE) as well as during the State
	Synchronization phase.</t>		Synchronization phase.</t>
	<t>The format of the PCRpt message is as follows: </t>		<t>The format of the PCRpt message is as follows: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<sourcecode name="" type="rbnf"><![CDATA[
	<PCRpt Message> ::= <Common Header>		<PCRpt Message> ::= <Common Header>
	<state-report-list>		<state-report-list>
	Where:		]]></sourcecode>
			<t>Where:</t>
			<sourcecode name="" type="rbnf"><![CDATA[
	<state-report-list> ::= <state-report>[<state-report-list>]		<state-report-list> ::= <state-report>[<state-report-list>]
	<state-report> ::= (<lsp-state-report>|		<state-report> ::= (<lsp-state-report>|
	<central-control-report>)		<central-control-report>)
	<lsp-state-report> ::= [<SRP>]		<lsp-state-report> ::= [<SRP>]
	<LSP>		<LSP>
	<path>		<path>
	<central-control-report> ::= [<SRP>]		<central-control-report> ::= [<SRP>]
	<LSP>		<LSP>
	<cci-list>		<cci-list>
	<cci-list> ::= <CCI>		<cci-list> ::= <CCI>
	[<BPI>|<EPR>|<PPA>]		[<BPI>|<EPR>|<PPA>]
	[<cci-list>]		[<cci-list>]
	]]></artwork>		]]></sourcecode>
	<ul empty="true" spacing="normal">
	<li>		<t>Where:</t>
	<t>Where: &lt;path&gt; is as per [RFC8231] and the LSP and SRP
	objects are also defined in [RFC8231].</t>		<ul spacing="normal">
	</li>		<li>&lt;path&gt; is as per <xref target="RFC8231"/>.</li>
	</ul>		<li>The LSP and SRP objects are also defined in <xref target="RFC82
			31"/>.</li>
			</ul>
			<!--[rfced] To avoid the repetition of "object", may we update the
			sentence below?
			Original:
			Furthermore, one, and only one, object among BPI, EPR or PPA object
			MUST be present.
			Perhaps:
			Furthermore, one and only one BPI, EPR, or PPA object MUST be present.
			-->
	<t>The error handling for missing CCI objects is as per <xref target="RF C9050" format="default"/>. Furthermore, one, and only one, object among BPI,		<t>The error handling for missing CCI objects is as per <xref target="RF C9050" format="default"/>. Furthermore, one, and only one, object among BPI,
	EPR or PPA object MUST be present.</t>		EPR or PPA object <bcp14>MUST</bcp14> be present.</t>
	<t>If none of the BPI, EPR or PPA objects are present, the receiving		<t>If none of the BPI, EPR, or PPA objects are present, the receiving
	PCE MUST send a PCErr message with Error-type=6 (Mandatory Object		PCE <bcp14>MUST</bcp14> send a PCErr message with Error-type=6 (Mandator
			y Object
	missing) and Error-value=19 (Native IP object missing). If there are		missing) and Error-value=19 (Native IP object missing). If there are
	more than one instance of BPI, EPR or PPA objects present, the		more than one instance of BPI, EPR or PPA objects present, the
	receiving PCE MUST send a PCErr message with Error-type=19 (Invalid		receiving PCE <bcp14>MUST</bcp14> send a PCErr message with Error-type=1
	Operation) and Error-value=22 (Only one BPI, EPR or PPA object can be		9 (Invalid
			Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can be
	included in this message).</t>		included in this message).</t>
	<t>When the PCInitiate message is not used for Native IP instructions,		<t>When the PCInitiate message is not used for Native IP instructions,
	i.e. When CCI Object-Type is not equal to 2, the BPI, EPR and PPA		i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and PPA
	objects SHOULD NOT be present. If present, they MUST be ignored by the		objects <bcp14>SHOULD NOT</bcp14> be present. If present, they <bcp14>MU
			ST</bcp14> be ignored by the
	receiver.</t>		receiver.</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>PCECC Native IP TE Procedures</name>		<name>PCECC Native IP TE Procedures</name>
	<t>The detailed procedures for the TE in the native IP environment are		<t>The detailed procedures for the TE in the native IP environment are
	described in the following sections.</t>		described in the following sections.</t>
	<section anchor="BGPSess" numbered="true" toc="default">		<section anchor="BGPSess" numbered="true" toc="default">
	<name>BGP Session Establishment Procedures</name>		<name>BGP Session Establishment Procedures</name>
	<t>The PCInitiate and PCRpt message pair is used to exchange the		<t>The PCInitiate and PCRpt message pair is used to exchange the
	configuration parameters for a BGP peer session. This pair of PCEP		configuration parameters for a BGP peer session. This pair of PCEP
	messages are exchanged between a PCE and each BGP peer (acting as PCC)		messages are exchanged between a PCE and each BGP peer (acting as the PC C),
	which needs to establish a BGP session. After the BGP peer session has		which needs to establish a BGP session. After the BGP peer session has
	been initiated via this pair of PCEP messages, the BGP session		been initiated via this pair of PCEP messages, the BGP session
	establishes and operates in a normal fashion. The BGP peers can be		establishes and operates in a normal fashion. The BGP peers can be
	used for External BGP (EBGP) peers or Internal BGP (IBGP) peers. For		used for External BGP (EBGP) peers or Internal BGP (IBGP) peers. For
	IBGP connection topologies, the Route Reflector (RR) is required.</t>		IBGP connection topologies, the Route Reflector (RR) is required.</t>
	<t>The PCInitiate message is sent to the BGP router and/or RR (which		<t>The PCInitiate message is sent to the BGP router and/or RR (which
	are acting as PCC).</t>		are acting as the PCC).</t>
	<t>The RR topology for a single Autonomous System (AS) is shown in		<t>The RR topology for a single Autonomous System (AS) is shown in
	Figure 1. The BGP routers R1, R3, and R7 are within a single AS. R1		<xref target="fig-1"/>. The BGP routers R1, R3, and R7 are within a sing
	and R7 are BGP RR clients, and R3 is a RR. The PCInitiate message is		le AS. R1
	sent to the BGP routers R1, R3 and R7 that need to establish a BGP		and R7 are BGP RR clients, and R3 is an RR. The PCInitiate message is
			sent to the BGP routers R1, R3, and R7, which need to establish a BGP
	session.</t>		session.</t>
	<t>PCInitiate message creates an auto-configuration function for these		<t>PCInitiate message creates an autoconfiguration function for these
	BGP peers by providing the indicated Peer AS and the Local/Peer IP		BGP peers by providing the indicated Peer AS and the Local/Peer IP
	Address.</t>		Address.</t>
	<t>When the PCC receives the BPI and CCI object (with the R bit set to		<t>When the PCC receives the BPI and CCI objects (with the R bit set to
	0 in the SRP object) in the PCInitiate message, the PCC SHOULD try to		0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SHOULD</b
	establish the BGP session with the indicated Peer as per AS and		cp14> try to
			establish the BGP session with the indicated Peer as per the AS and
	Local/Peer IP address.</t>		Local/Peer IP address.</t>
	<t>During the establishment procedure, the PCC MUST report to the PCE		<t>During the establishment procedure, the PCC <bcp14>MUST</bcp14> repor
	the status of the BGP session via the PCRpt message, with the status		t
			the status of the BGP session to the PCE via the PCRpt message, with the
			status
	field in the BPI object set to the appropriate value and the		field in the BPI object set to the appropriate value and the
	corresponding SRP and CCI objects included.</t>		corresponding SRP and CCI objects included.</t>
	<t>When the PCC receives this message with the R bit set to 1 in the		<t>When the PCC receives this message with the R bit set to 1 in the
	SRP object in the PCInitiate message, the PCC MUST clear the BGP		SRP object in the PCInitiate message, the PCC <bcp14>MUST</bcp14> clear the BGP
	configuration and tear down the BGP session that is indicated by the		configuration and tear down the BGP session that is indicated by the
	BPI object.</t>		BPI object.</t>
	<t>When the PCC clears successfully the specified BGP session		<t>When the PCC successfully clears the specified BGP session
	configuration, it MUST report the result via the PCRpt message, with		configuration, it <bcp14>MUST</bcp14> report the result via the PCRpt me
	the BPI object included, and the corresponding SRP and CCI		ssage, with
	objects.</t>		the BPI object and the corresponding SRP and CCI
	<artwork name="" type="" align="left" alt=""><![CDATA[		objects included.</t>
	+------------------+
	+-----------> PCE <----------+		<figure anchor="fig-1">
	| +--------^---------+ |		<name>BGP Session Establishment Procedures (R3 acts as the RR)</name>
	| | |		<artwork name="" type="" align="center" alt=""><![CDATA[
	| PCInitiate/PCRpt |		+------------------+
	| | |		+-----------> PCE <----------+
	| +----v--+ |		| +--------^---------+ |
	+---------------+ R3(RR)+-----------------+		| | |
	| +-------+ |		| PCInitiate/PCRpt |
	PCInitiate/PCRpt PCInitiate/PCRpt		| | |
	| |		| +----v--+ |
	+v-+ +--+ +--+ +-v+		+---------------+ R3(RR)+-----------------+
	|R1+----------+R5+----------+R6+---------+R7|		| +-------+ |
	++-+ +-++ +--+ +-++		PCInitiate/PCRpt PCInitiate/PCRpt
	| | |		| |
	| +--+ +--+ |		+v-+ +--+ +--+ +-v+
	+------------+R2+----------+R4+-----------+		|R1+----------+R5+----------+R6+---------+R7|
	+--+ +--+		++-+ +-++ +--+ +-++
	Figure 1: BGP Session Establishment Procedures(R3 act as RR)		| | |
			| +--+ +--+ |
			+------------+R2+----------+R4+-----------+
			+--+ +--+
	]]></artwork>		]]></artwork>
	<t/>		</figure>
	<t>The message peers, message type, message key parameters and
	procedures in the above figures are shown below:</t>		<t>The message peers, message types, message key parameters, and
	<artwork name="" type="" align="left" alt=""><![CDATA[		procedures in the above figure are shown below:</t>
			<figure anchor="fig-2">
			<name>Message Information and Procedures</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
	+-------+ +-------+		+-------+ +-------+
	|PCC | | PCE |		|PCC | | PCE |
	|R1 | +-------+		|R1 | +-------+
	+------| | |		+------| | |
	| PCC +-------+ |		| PCC +-------+ |
	| R3 | | (For R1/R3 BGP Session on R1) |		| R3 | | (For R1/R3 BGP Session on R1) |
	+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A-|		+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A-|
	| | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)|		| | | |BPI Object(Peer AS, Local_IP=R1_A, Peer_IP=R3_A)|
	|PCC +--------+ | |		|PCC +--------+ | |
	|R7 | | |----PCRpt,CC-ID=X(Symbolic Path Name=Class A)-->|		|R7 | | |----PCRpt,CC-ID=X(Symbolic Path Name=Class A)-->|
	skipping to change at line 475 ¶		skipping to change at line 601 ¶
	| |<--PCInitiate,CC-ID=Y2,Symbolic Path Name=Class A-----|		| |<--PCInitiate,CC-ID=Y2,Symbolic Path Name=Class A-----|
	| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |		| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |
	| |----PCRpt,CC-ID=Y2,Symbolic Path Name=Class A-------->|		| |----PCRpt,CC-ID=Y2,Symbolic Path Name=Class A-------->|
	| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |		| | BPI Object(Peer AS, Local_IP=R3_A, Peer_IP=R7_A) |
	| |		| |
	| (For R3/R7 BGP Session on R7) |		| (For R3/R7 BGP Session on R7) |
	|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A--------------|		|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A--------------|
	| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |		| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |
	|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A------------------>|		|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A------------------>|
	| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |		| BPI Object(Peer AS, Local_IP=R7_A, Peer_IP=R3_A) |
	Figure 2: Message Information and Procedures
	]]></artwork>		]]></artwork>
	<t>The Local/Peer IP address MUST be dedicated to the usage of the		</figure>
	native IP TE solution, and MUST NOT be used by other BGP sessions that		<t>The Local/Peer IP address <bcp14>MUST</bcp14> be dedicated to the usa
			ge of the
			native IP TE solution and <bcp14>MUST NOT</bcp14> be used by other BGP s
			essions that
	are established manually or in other ways. If the Local IP Address or		are established manually or in other ways. If the Local IP Address or
	Peer IP Address within the BPI object is used in other existing BGP		Peer IP Address within the BPI object is used in other existing BGP
	sessions, the PCC MUST report such an error situation via a PCErr		sessions, the PCC <bcp14>MUST</bcp14> report such an error situation via a PCErr
	message with:</t>		message with:</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Error-type=33 (Native IP TE failure) and Error-value=1 (Local		<t>Error-type=33 (Native IP TE failure) and Error-value=1 (Local
	IP is in use), or</t>		IP is in use) or</t>
	</li>		</li>
	<li>		<li>
	<t>Error-type=33 (Native IP TE failure )and Error-value=2 (Remote		<t>Error-type=33 (Native IP TE failure) and Error-value=2 (Remote
	IP is in use).</t>		IP is in use).</t>
	</li>		</li>
	<li>		</ul>
	<t>The detailed Error-Types and Error-Values are defined in <xref ta		<t>The detailed Error-Types and Error-Values are defined in <xref target
	rget="NewErrorTypeAndValue" format="default"/></t>		="NewErrorTypeAndValue" format="default"/>.</t>
	</li>
	</ul>		<t>If the established BGP session is broken, the PCC <bcp14>MUST</bcp14>
	<t>If the established BGP session is broken, the PCC MUST report such		report such
	information via PCRpt message with the status field set to "BGP		information via a PCRpt message with the status field set to "BGP
	session down" in the associated BPI Object. The error code field		session down" in the associated BPI Object. The error code field
	within the BPI object SHOULD indicate the reason that leads to the BGP		within the BPI object <bcp14>SHOULD</bcp14> indicate the reason that lea ds to the BGP
	session being down. In the future, when the BGP session is up again,		session being down. In the future, when the BGP session is up again,
	the PCC MUST report that as well via the PCRpt message with the status		the PCC <bcp14>MUST</bcp14> report that as well via the PCRpt message wi th the status
	field set to "BGP Session Established".</t>		field set to "BGP Session Established".</t>
	</section>		</section>
	<section anchor="BGPEx" numbered="true" toc="default">		<section anchor="BGPEx" numbered="true" toc="default">
	<name>Explicit Route Establishment Procedures</name>		<name>Explicit Route Establishment Procedures</name>
	<t>The explicit route establishment procedures can be used by PCE to		<t>The explicit route establishment procedures can be used by a PCE to
	install a route on the PCC, using the PCInitiate and PCRpt message		install a route on the PCC, using the PCInitiate and PCRpt message
	pair. Such explicit routes operate the same as static routes installed		pair. Such explicit routes operate the same as static routes installed
	by network management protocols (Network Configuration Protocol		by network management protocols (e.g., Network Configuration Protocol
	(NETCONF)/YANG). The procedures of such explicit route addition and		(NETCONF) / YANG). The procedures of such explicit route addition and
	removal MUST be controlled by the PCE in a specific order so that the		removal <bcp14>MUST</bcp14> be controlled by the PCE in a specific order
			so that the
	pathways are established without loops.</t>		pathways are established without loops.</t>
	<t>For the purpose of explicit route addition, the PCInitiate message		<t>For the purpose of explicit route addition, the PCInitiate message
	ought to be sent to every router on the explicit path. In the example,		ought to be sent to every router on the explicit path. In the example,
	for the explicit route from R1 to R7, the PCInitiate message is sent		for the explicit route from R1 to R7, the PCInitiate message is sent
	to R1, R2 and R4, as shown in Figure 3. For the explicit route from R7		to R1, R2, and R4, as shown in <xref target="fig-3"/>. For the explicit
	to R1, the PCInitiate message is sent to R7, R4 and R2, as shown in		route from R7
	Figure 5.</t>		to R1, the PCInitiate message is sent to R7, R4, and R2, as shown in
			<xref target="fig-5"/>.</t>
	<t>When the PCC receives the EPR and the CCI object (with the R bit		<t>When the PCC receives the EPR and the CCI object (with the R bit
	set to 0 in the SRP object) in the PCInitiate message, the PCC SHOULD		set to 0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SH OULD</bcp14>
	install the explicit route to the peer in the RIB/FIB.</t>		install the explicit route to the peer in the RIB/FIB.</t>
	<t>When the PCC installs successfully the explicit route to the peer,		<t>When the PCC successfully installs the explicit route to the peer,
	it MUST report the result via the PCRpt messages, with the EPR object		it <bcp14>MUST</bcp14> report the result via the PCRpt message, with the
			EPR object
	and the corresponding SRP and CCI objects included.</t>		and the corresponding SRP and CCI objects included.</t>
	<t>When the PCC receives the EPR and the CCI object with the R bit set		<t>When the PCC receives the EPR and the CCI object with the R bit set
	to 1 in the SRP object in the PCInitiate message, the PCC MUST remove		to 1 in the SRP object in the PCInitiate message, the PCC <bcp14>MUST</b cp14> remove
	the explicit route to the peer that is indicated by the EPR		the explicit route to the peer that is indicated by the EPR
	object.</t>		object.</t>
	<t>When the PCC has removed the explicit route that is indicated by		<t>When the PCC has removed the explicit route that is indicated by
	this object, it MUST report the result via the PCRpt message, with the		this object, it <bcp14>MUST</bcp14> report the result via the PCRpt mess
	EPR object included, and the corresponding SRP and CCI object.</t>		age, with the
	<artwork name="" type="" align="left" alt=""><![CDATA[		EPR object and the corresponding SRP and CCI objects included.</t>
	+------------------+
	+----------> PCE +		<figure anchor="fig-3">
	| +----^-----------^-+		<name>Explicit Route Establish Procedures (from R1 to R7)</name>
	| | |		<artwork name="" type="" align="center" alt=""><![CDATA[
	| | |		+------------------+
	| | +------+ |		+----------> PCE +
	+---------------|-+R3(RR)+--|-------------+		| +----^-----------^-+
	PCInitiate/PCRpt | +------+ | |		| | |
	| | | |		| | |
	+v-+ +--+ | | +--+ +--+		| | +------+ |
	|R1+------+R5+---+-----------|---+R6+----+R7|		+---------------|-+R3(RR)+--|-------------+
	++-+ +--+ | | +--+ +-++		PCInitiate/PCRpt | +------+ | |
	| PCInitiate/PCRpt PCInitiate/PCRpt |		| | | |
	| | | |		+v-+ +--+ | | +--+ +--+
	| +--v--+ +--v-+ |		|R1+------+R5+---+-----------|---+R6+----+R7|
	+------------+- R2 +-----+ R4 +-----------+		++-+ +--+ | | +--+ +-++
	+--+--+ +--+-+		| PCInitiate/PCRpt PCInitiate/PCRpt |
	Figure 3: Explicit Route Establish Procedures(From R1 to R7)		| | | |
			| +--v--+ +--v-+ |
			+------------+- R2 +-----+ R4 +-----------+
			+--+--+ +--+-+
	]]></artwork>		]]></artwork>
	<t>The message peers, message type, message key parameters and		</figure>
	procedures in the above figures are shown below:</t>		<t>The message peers, message types, message key parameters, and
	<artwork name="" type="" align="left" alt=""><![CDATA[		procedures in the above figure are shown below:</t>
			<figure anchor="fig-4">
			<name>Message Information and Procedures</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
	+-------+ +-------+		+-------+ +-------+
	|PCC | | PCE |		|PCC | | PCE |
	|R4 | +-------+		|R4 | +-------+
	+------| | |		+------| | |
	| PCC +-------+ |		| PCC +-------+ |
	| R2 | | (EPR route on R4) |		| R2 | | (EPR route on R4) |
	+------| | |<-PCInitiate,CC-ID=Z,Symbolic Path Name=Class A|		+------| | |<-PCInitiate,CC-ID=Z,Symbolic Path Name=Class A|
	| | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)|		| | | | EPR Object(Peer Address=R7_A, Next Hop=R7_A)|
	|PCC +--------+ | |		|PCC +--------+ | |
	|R1 | | |----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-->|		|R1 | | |----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-->|
	skipping to change at line 579 ¶		skipping to change at line 710 ¶
	| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |		| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |
	| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|		| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|
	| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |		| | EPR Object(Peer Address=R7_A, Next Hop=R4_A) |
	| | |		| | |
	| |		| |
	| (EPR route on R1) |		| (EPR route on R1) |
	|<--PCInitiate,CC-ID=X,Symbolic Path Name=Class A-------------|		|<--PCInitiate,CC-ID=X,Symbolic Path Name=Class A-------------|
	| EPR Object(Peer Address=R7_A, Next Hop=R2_A) |		| EPR Object(Peer Address=R7_A, Next Hop=R2_A) |
	|---PCRpt,CC-ID=X1(Symbolic Path Name=Class A)--------------->|		|---PCRpt,CC-ID=X1(Symbolic Path Name=Class A)--------------->|
	| EPR Object(Peer Address=R7_A, Next Hop=R2_A) |		| EPR Object(Peer Address=R7_A, Next Hop=R2_A) |
	Figure 4: Message Information and Procedures
	]]></artwork>		]]></artwork>
	<artwork name="" type="" align="left" alt=""><![CDATA[		</figure>
	+------------------+
	+ PCE <-----------+		<figure anchor="fig-5">
	+----^-----------^-+ |		<name>Explicit Route Establish Procedures (from R7 to R1)</name>
	| | |		<artwork name="" type="" align="center" alt=""><![CDATA[
	| | |		+------------------+
	| +------+ | |		+ PCE <-----------+
	+-----------------+R3(RR)+--|-------------+		+----^-----------^-+ |
	| | +------+ | PCInitiate/PCRpt		| | |
	| | | |		| | |
	+--+ +--+ | | +--+ +-v+		| +------+ | |
	|R1+------+R5+---+-----------|---+R6+----+R7|		+-----------------+R3(RR)+--|-------------+
	++-+ +--+ | | +--+ +-++		| | +------+ | PCInitiate/PCRpt
	| PCInitiate/PCRpt PCInitiate/PCRpt |		| | | |
	| | | |		+--+ +--+ | | +--+ +-v+
	| +--v--+ +--v-+ |		|R1+------+R5+---+-----------|---+R6+----+R7|
	+------------+- R2 +-----+ R4 +-----------+		| PCInitiate/PCRpt PCInitiate/PCRpt |
	+--+--+ +--+-+		| | | |
	Figure 5: Explicit Route Establish Procedures(From R7 to R1)		| +--v--+ +--v-+ |
			+------------+- R2 +-----+ R4 +-----------+
			+--+--+ +--+-+
	]]></artwork>		]]></artwork>
	<t>The message peers, message type, message key parameters and		</figure>
	procedures in the above figures are shown below:</t>		<t>The message peers, message types, message key parameters, and
	<artwork name="" type="" align="left" alt=""><![CDATA[		procedures in the above figure are shown below:</t>
			<figure anchor="fig-6">
			<name>Explicit Route Establish Procedures (from R7 to R1)</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
	+-------+ +-------+		+-------+ +-------+
	|PCC | | PCE |		|PCC | | PCE |
	|R2 | +-------+		|R2 | +-------+
	+------| | |		+------| | |
	| PCC +-------+ |		| PCC +-------+ |
	| R4 | | (EPR route on R2) |		| R4 | | (EPR route on R2) |
	+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|		+------| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
	| | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) |		| | | | EPR Object(Peer Address=R1_A, Next Hop=R1_A) |
	|PCC +--------+ | |		|PCC +--------+ | |
	|R7 | | |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|		|R7 | | |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
	skipping to change at line 629 ¶		skipping to change at line 765 ¶
	| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |		| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |
	| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|		| |----PCRpt,CC-ID=Y,Symbolic Path Name=Class A-------->|
	| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |		| | EPR Object(Peer Address=R1_A, Next Hop=R2_A) |
	| | |		| | |
	| |		| |
	| (EPR route on R7) |		| (EPR route on R7) |
	|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-------------|		|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-------------|
	| EPR Object(Peer Address=R1_A, Next Hop=R4_A) |		| EPR Object(Peer Address=R1_A, Next Hop=R4_A) |
	|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A----------------->|		|---PCRpt,CC-ID=Z,Symbolic Path Name=Class A----------------->|
	| EPR Object(Peer Address=R1_A, Next Hop=R4_A) |		| EPR Object(Peer Address=R1_A, Next Hop=R4_A) |
	Figure 6: Explicit Route Establish Procedures(From R7 to R1)
	]]></artwork>		]]></artwork>
			</figure>
	<t>To avoid the transient loop while deploying the explicit peer		<t>To avoid the transient loop while deploying the explicit peer
	route, the EPR object MUST be sent to the PCCs in the reverse order of		route, the EPR object <bcp14>MUST</bcp14> be sent to the PCCs in the rev
	the E2E path. To remove the explicit peer route, the EPR object MUST		erse order of
			the E2E path. To remove the explicit peer route, the EPR object <bcp14>M
			UST</bcp14>
	be sent to the PCCs in the same order as the E2E path.</t>		be sent to the PCCs in the same order as the E2E path.</t>
	<t>To accomplish ECMP effects, the PCE can send multiple EPR/CCI		<t>To accomplish ECMP effects, the PCE can send multiple EPR/CCI
	objects to the same node, with the same route priority and peer		objects to the same node, with the same route priority and peer
	address value but a different next-hop address.</t>		address value but a different next-hop address.</t>
	<t>The PCC MUST verify that the next hop address is reachable. In case		<t>The PCC <bcp14>MUST</bcp14> verify that the next-hop address is reach
	of failure, the PCC MUST send the corresponding error via PCErr		able. In case
			of failure, the PCC <bcp14>MUST</bcp14> send the corresponding error via
			a PCErr
	message, with the error information: Error-type=33 (Native IP TE		message, with the error information: Error-type=33 (Native IP TE
	failure), Error-value=3 (Explicit Peer Route Error).</t>		failure) and Error-value=3 (Explicit Peer Route Error).</t>
	<t>When the peer info is not the same as the peer info that is		<t>When the peer info is not the same as the peer info that is
	indicated in the BPI object in PCC for the same path that is		indicated in the BPI object in the PCC for the same path that is
	identified by Symbolic Path Name TLV, a PCErr message MUST be		identified by Symbolic Path Name TLV, a PCErr message <bcp14>MUST</bcp14
	reported, with the error information: Error-type=33 (Native IP TE		> be
	failure), Error-value=4, EPR/BPI Peer Info Mismatch. Note that the		reported, with the error information Error-type=33 (Native IP TE
			failure) and Error-value=4 (EPR/BPI Peer Info mismatch). Note that the
	same error can be used in case no BPI is received at the PCC.</t>		same error can be used in case no BPI is received at the PCC.</t>
	<t>If the PCE needs to update the path, it MUST first instruct the new		<t>If the PCE needs to update the path, it <bcp14>MUST</bcp14> first ins
	CCI with updated EPR corresponding to the new next hop to use and then		truct the new
			CCI with the updated EPR corresponding to the new next hop to use and th
			en
	instruct the removal of the older CCI.</t>		instruct the removal of the older CCI.</t>
	</section>		</section>
	<section anchor="BGPPrefix" numbered="true" toc="default">		<section anchor="BGPPrefix" numbered="true" toc="default">
	<name>BGP Prefix Advertisement Procedures</name>		<name>BGP Prefix Advertisement Procedures</name>
	<t>The detailed procedures for BGP prefix advertisement are shown		<t>The detailed procedures for BGP prefix advertisement are shown
	below, using the PCInitiate and PCRpt message pair.</t>		below, using the PCInitiate and PCRpt message pair.</t>
	<t>The PCInitiate message SHOULD be sent to PCC that acts as a BGP		<t>The PCInitiate message <bcp14>SHOULD</bcp14> be sent to the PCC that
	peer edge router only. In the example, it is sent to R1 and R7		acts as a BGP
			peer edge router only. In the example, it is sent to R1 and R7,
	respectively.</t>		respectively.</t>
	<t>When the PCC receives the PPA and the CCI object (with the R bit		<t>When the PCC receives the PPA and the CCI object (with the R bit
	set to 0 in the SRP object) in the PCInitiate message, the PCC SHOULD		set to 0 in the SRP object) in the PCInitiate message, the PCC <bcp14>SH OULD</bcp14>
	send the prefixes indicated in this object to the identified BGP peer		send the prefixes indicated in this object to the identified BGP peer
	via the corresponding BGP session <xref target="RFC4271" format="default "/>.</t>		via the corresponding BGP session <xref target="RFC4271" format="default "/>.</t>
	<t>When the PCC has successfully sent the prefixes to the appointed		<t>When the PCC has successfully sent the prefixes to the appointed
	BGP peer, it MUST report the result via the PCRpt messages, with the		BGP peer, it <bcp14>MUST</bcp14> report the result via the PCRpt message s, with the
	PPA object and the corresponding SRP and CCI objects included.</t>		PPA object and the corresponding SRP and CCI objects included.</t>
	<t>When the PCC receives the PPA and the CCI object with the R bit set		<t>When the PCC receives the PPA and the CCI object with the R bit set
	to 1 in the SRP object in the PCInitiate message, the PCC MUST		to 1 in the SRP object in the PCInitiate message, the PCC <bcp14>MUST</b
	withdraw the prefixes advertisement to the peer indicated by this		cp14>
			withdraw the prefix advertisement to the peer indicated by this
	object.</t>		object.</t>
	<t>When the PCC withdraws successfully the prefixes that are indicated		<t>When the PCC successfully withdraws the prefixes that are indicated
	by this object, it MUST report the result via the PCRpt message, with		by this object, it <bcp14>MUST</bcp14> report the result via the PCRpt m
	the PPA object included, and the corresponding SRP and CCI		essage, with
	objects.</t>		the PPA object and the corresponding SRP and CCI
	<artwork name="" type="" align="left" alt=""><![CDATA[		objects included.</t>
			<figure anchor="fig-7">
			<name>BGP Prefix Advertisement Procedures</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
	+------------------+		+------------------+
	+----------> PCE <-----------+		+----------> PCE <-----------+
	| +------------------+ |		| +------------------+ |
	| +--+ |		| +--+ |
	+------------------+R3+-------------------+		+------------------+R3+-------------------+
	PCInitiate/PCRpt +--+ PCInitiate/PCRpt		PCInitiate/PCRpt +--+ PCInitiate/PCRpt
	| |		| |
	+v-+ +--+ +--+ +-v+		+v-+ +--+ +--+ +-v+
	|R1+----------+R5+----------+R6+---------+R7|		|R1+----------+R5+----------+R6+---------+R7|
	++-+ +--+ +--+ +-++		++-+ +--+ +--+ +-++
	(BGP Router) (BGP Router)		(BGP Router) (BGP Router)
	| |		| |
	| |		| |
	| +--+ +--+ |		| +--+ +--+ |
	+------------+R2+----------+R4+-----------+		+------------+R2+----------+R4+-----------+
	+--+ +--+		+--+ +--+
	Figure 7: BGP Prefix Advertisement Procedures
	]]></artwork>		]]></artwork>
	<t>The message peers, message type, message key parameters and		</figure>
	procedures in the above figures are shown below:</t>		<t>The message peers, message types, message key parameters, and
	<artwork name="" type="" align="left" alt=""><![CDATA[		procedures in the above figure are shown below:</t>
	+-------+ +-------+
	|PCC | | PCE |
	|R1 | +-------+
	+------| | |
	| PCC +-------+ |
	| R7 | | (Instruct R1 to advertise Prefix 1_A to R7) |
	| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
	| | | PPA Object(Peer IP=R7_A, Prefix=1_A) |
	+--------+ | |
	| |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
	| | PPA Object(Peer IP=R7_A, Prefix=1_A) |
	| |
	| (Instruct R7 to advertise Prefix 7_A to R1 ) |
	|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-----|
	| PPA Object(Peer IP=R1_A, Prefix=7_A) |
	|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|
	| PPA Object(Peer IP=R1_A, Prefix=7_A) |
	| |
	Figure 8: Message Information and Procedures		<figure anchor="fig-8">
			<name>Message Information and Procedures</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			+-------+ +-------+
			|PCC | | PCE |
			|R1 | +-------+
			+------| | |
			| PCC +-------+ |
			| R7 | | (Instruct R1 to advertise Prefix 1_A to R7) |
			| | |<-PCInitiate,CC-ID=X,Symbolic Path Name=Class A|
			| | | PPA Object(Peer IP=R7_A, Prefix=1_A) |
			+--------+ | |
			| |----PCRpt,CC-ID=X,Symbolic Path Name=Class A-->|
			| | PPA Object(Peer IP=R7_A, Prefix=1_A) |
			| |
			| (Instruct R7 to advertise Prefix 7_A to R1 ) |
			|<--PCInitiate,CC-ID=Z,Symbolic Path Name=Class A-----|
			| PPA Object(Peer IP=R1_A, Prefix=7_A) |
			|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|
			| PPA Object(Peer IP=R1_A, Prefix=7_A) |
			| |
	]]></artwork>		]]></artwork>
	<t>The AFI/SAFI for the corresponding BGP session SHOULD match the		</figure>
	Peer Prefix Advertisement Object-Type, AFI/SAFI SHOULD be 1/1 for the		<t>The AFI/SAFI for the corresponding BGP session <bcp14>SHOULD</bcp14>
			match the
			Peer Prefix Advertisement Object-Type, i.e., AFI/SAFI <bcp14>SHOULD</bcp
			14> be 1/1 for the
	IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an		IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an
	error: Error-type=33 (Native IP TE failure), Error-value=5 (BPI/PPA		error, i.e., Error-type=33 (Native IP TE failure) and Error-value=5 (BPI
	address family mismatch) MUST be reported via PCErr message.</t>		/PPA
	<t>When the peer info is not the same as the peer info that is		Address Family mismatch), <bcp14>MUST</bcp14> be reported via the PCErr
	indicated in the BPI object in PCC for the same path that is		message.</t> <t>When the peer info is not the same as the peer info that
	identified by Symbolic Path Name TLV, an error: Error-type=33 (Native		is
	IP TE failure), Error-value=6 (PPA/BPI peer info mismatch) MUST be		indicated in the BPI object in the PCC for the same path that is
			identified by Symbolic Path Name TLV, an error, i.e., Error-type=33 (Nat
			ive
			IP TE failure) and Error-value=6 (PPA/BPI Peer Info mismatch), <bcp14>MU
			ST</bcp14> be
	reported via the PCErr message. Note that the same error can be used		reported via the PCErr message. Note that the same error can be used
	in case no BPI is received at the PCC.</t>		in case no BPI is received at the PCC.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Selection of Raw Mode and Tunnel Mode Forwarding Strategy</name>		<name>Selection of the Raw Mode and Tunnel Mode Forwarding Strategy</nam e>
	<t>Normally, when the above procedures are finished, the user traffic		<t>Normally, when the above procedures are finished, the user traffic
	will be forwarded via the appointed path, but the forwarding will be		will be forwarded via the appointed path, but the forwarding will be
	based solely on the destination of user traffic. If there is traffic		based solely on the destination of user traffic.
			<!--[rfced] How may we clarify "to the same destination"?
			Original:
			If there is traffic
			from different attached points to the same destination coming into
			the network, they could share the priority path which may not be the
			initial desire.
			Perhaps:
			If traffic is coming into the network from different attached points
			but to the same destination, they could share the priority path,
			which may not be the initial desire.
			-->
			If there is traffic
	from different attached points to the same destination coming into the		from different attached points to the same destination coming into the
	network, they could share the priority path which may not be the		network, they could share the priority path, which may not be the
	initial desire. For example, as illustrated in Figure 1, the initial		initial desire. For example, as illustrated in <xref target="fig-1"/>, t
	aim is to ensure traffic that enters the network via R1 and exits the		he initial
			aim is to ensure that traffic enters the network via R1 and exits the
	network at R7 via R5-R6-R7. If some traffic enters the network via the		network at R7 via R5-R6-R7. If some traffic enters the network via the
	R2 router, passes through R5 and exits at R7, they may share the		R2 router, passes through R5, and exits at R7, they may share the
	priority path among R5-R6-R7, which may not be the desired effect.</t>		priority path among R5-R6-R7, which may not be the desired effect.</t>
	<t>The above normal traffic forwarding behavior is clarified as a Raw		<t>The above normal traffic forwarding behavior is clarified as a Raw
	mode forwarding strategy. Such a mode can achieve only the moderate		mode forwarding strategy. Such a mode can only achieve the moderate
	traffic path control effect. To achieve the strict traffic path		traffic path control effect. To achieve the strict traffic path
	control effect, the entry point MUST tunnel the user traffic from the		control effect, the entry point <bcp14>MUST</bcp14> tunnel the user traf fic from the
	entry point of the network to the exit point of the network, which is		entry point of the network to the exit point of the network, which is
	also between the BGP peer established via <xref target="BGPSess" format= "default"/>.		also between the BGP peer established via <xref target="BGPSess" format= "default"/>.
			<!--[rfced] We don't see the term "IPinIP" in RFC 2003. Should this be
			updated as "IP in IP"? Note that other RFCs generally use "IP-in-IP"
			when referring to tunnels.
			We also see "IPnIP" in Table 8 - is this term the same as "IPinIP" or
			different? Please let us know if/how these terms may be updated for
			consistency.
			Original:
			Section 6.4
			For simplicity, the IPinIP tunnel type [RFC2003] is used between the
			BGP peers by default.
			Section 7.2
			Currently, only bit 7 (T bit) is defined. When the T bit is set,
			the traffic SHOULD be sent in the IPinIP tunnel (Tunnel source
			is Local IP Address, tunnel destination is Peer IP Address).
			Table 8
			7 | T (IPnIP) bit |
			-->
	Such forwarding behavior is called the Tunnel mode forwarding		Such forwarding behavior is called the Tunnel mode forwarding
	strategy. For simplicity, the IPinIP tunnel type <xref target="RFC2003" format="default"/> is used between the BGP peers by default.</t>		strategy. For simplicity, the IPinIP tunnel type <xref target="RFC2003" format="default"/> is used between the BGP peers by default.</t>
	<t>The selection of Raw mode and Tunnel mode forwarding strategies are		<t>The selection of Raw mode and Tunnel mode forwarding strategies are
	controlled via the "T" bit in BPI Object that is defined in <xref target ="BPI_Object" format="default"/></t>		controlled via the T bit in the BPI Object, which is defined in <xref ta rget="BPI_Object" format="default"/></t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Clean Up</name>		<name>Cleanup</name>
	<t>To remove the Native-IP state from the PCC, the PCE MUST send
	explicit CCI cleanup instructions for PPA, EPR and BPI objects		<!--[rfced] Per use elsewhere throughout the document, should "R flag"
	respectively with the R flag set in the SRP object. If the PCC		be updated to "R bit"?
			Original:
			To remove the Native-IP state from the PCC, the PCE MUST send
			explicit CCI cleanup instructions for PPA, EPR and BPI objects
			respectively with the R flag set in the SRP object.
			Perhaps:
			To remove the Native-IP state from the PCC, the PCE MUST send
			explicit CCI cleanup instructions for PPA, EPR, and BPI objects,
			respectively, with the R bit set in the SRP object.
			-->
			<t>To remove the Native-IP state from the PCC, the PCE <bcp14>MUST</bcp1
			4> send
			explicit CCI cleanup instructions for PPA, EPR, and BPI objects,
			respectively, with the R flag set in the SRP object. If the PCC
	receives a PCInitiate message but does not recognize the Native-IP		receives a PCInitiate message but does not recognize the Native-IP
	information in the CCI, the PCC MUST generate a PCErr message with		information in the CCI, the PCC <bcp14>MUST</bcp14> generate a PCErr mes
	Error-Type=19 (Invalid operation) and Error-value=TBD2 (Unknown		sage with
	Native-IP Info) and MUST include the SRP object to specify the error		Error-Type=19 (Invalid Operation) and Error-value=30 (Unknown
			Native-IP Info) and <bcp14>MUST</bcp14> include the SRP object to specif
			y the error
	is for the corresponding cleanup (via a PCInitiate message).</t>		is for the corresponding cleanup (via a PCInitiate message).</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Other Procedures</name>		<name>Other Procedures</name>
	<t>The handling of the state synchronization, redundant PCEs,		<t>The handling of the state synchronization, redundant PCEs,
	re-delegation and clean up is the same as other CCIs as specified in		redelegation, and cleanup is the same as other CCIs as specified in
	<xref target="RFC9050" format="default"/>.</t>		<xref target="RFC9050" format="default"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Obj-Def-Sec" numbered="true" toc="default">		<section anchor="Obj-Def-Sec" numbered="true" toc="default">
	<name>New PCEP Objects</name>		<name>New PCEP Objects</name>
	<t>One new CCI Object type and three new PCEP objects are defined in		<t>One new CCI Object type and three new PCEP objects are defined in
	this document. All new PCEP objects are as per <xref target="RFC5440" form at="default"/>.</t>		this document. All new PCEP objects are as per <xref target="RFC5440" form at="default"/>.</t>
	<section anchor="CCI" numbered="true" toc="default">		<section anchor="CCI" numbered="true" toc="default">
	<name>CCI Object</name>		<name>CCI Object</name>
	<t>The Central Control Instructions (CCI) Object (defined in <xref targe t="RFC9050" format="default"/>) is used by the PCE to specify the forwarding		<t>The Central Control Instructions (CCI) Object (defined in <xref targe t="RFC9050" format="default"/>) is used by the PCE to specify the forwarding
	instructions. This document defines another object type for Native-IP		instructions. This document defines another object type for Native-IP
	procedures.</t>		procedures.</t>
	<t>CCI Object-Type is 2 for Native-IP as below: </t>		<t>The CCI Object-Type is 2 for Native-IP, as follows: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-9">
			<name>CCI Object for Native IP</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CC-ID |		| CC-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |		| Reserved | Flags |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| |		| |
	// Optional TLVs //		// Optional TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			]]></artwork>
	Figure 9: CCI Object for Native IP]]></artwork>		</figure>
	<t>The field CC-ID is as described in <xref target="RFC9050" format="def		<t>The CC-ID field is as described in <xref target="RFC9050" format="def
	ault"/>. The		ault"/>. The
	following fields are defined for CCI Object-Type 2 </t>		following fields are defined for CCI Object-Type 2.</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Reserved:</dt>		<dt>Reserved:</dt>
	<dd>2 bytes, is set to zero while sending and		<dd>2 bytes. Set to zero while sending and
	ignored on receipt.</dd>		ignored on receipt.</dd>
	<dt>Flags:</dt>		<dt>Flags:</dt>
	<dd>2 bytes, is used to carry any additional		<dd>2 bytes. Used to carry any additional
	information about the Native-IP CCI. Currently, no flag bits are		information about the Native-IP CCI. Currently, no flag bits are
	defined. Unassigned flags are set to zero while sending and		defined. Unassigned flags are set to zero while sending and
	ignored on receipt.</dd>		ignored on receipt.</dd>
	</dl>		</dl>
	<t>Optional TLVs may be included within the CCI object body. The		<t>Optional TLVs may be included within the CCI object body. The
	Symbolic Path Name TLV <xref target="RFC8231" format="default"/> MUST be included in		Symbolic Path Name TLV <xref target="RFC8231" format="default"/> <bcp14> MUST</bcp14> be included in
	the CCI Object-Type 2 to identify the E2E TE path in the Native IP		the CCI Object-Type 2 to identify the E2E TE path in the Native IP
	environment.</t>		environment.</t>
	</section>		</section>
	<section anchor="BPI_Object" numbered="true" toc="default">		<section anchor="BPI_Object" numbered="true" toc="default">
	<name>BGP Peer Info Object</name>		<name>BGP Peer Info Object</name>
	<t>The BGP Peer Info object is used to specify the information about		<t>The BGP Peer Info (BPI) object is used to specify the information abo
	the peer with which the PCC want to establish the BGP session. This		ut
			the peer with which the PCC wants to establish the BGP session. This
	object is included and sent to the source and destination router of		object is included and sent to the source and destination router of
	the E2E path in case there is no Route Reflection (RR) involved. If		the E2E path in case there is no Route Reflection (RR) involved. If
	the RR is used between the source and destination routers, then such		the RR is used between the source and destination routers, then such
	information is sent to the source router, RR and destination router		information is sent to the source router, RR, and destination router,
	respectively.</t>		respectively.</t>
	<t>By default, the Local/Peer IP address MUST be a unicast address and		<t>By default, the Local/Peer IP address <bcp14>MUST</bcp14> be a unicas
	dedicated to the usage of the native IP TE solution, and MUST NOT be		t address and
			dedicated to the usage of the native IP TE solution and <bcp14>MUST NOT<
			/bcp14> be
	used by other BGP sessions that are established by manual or other		used by other BGP sessions that are established by manual or other
	configuration mechanisms.</t>		configuration mechanisms.</t>
	<t>BGP Peer Info Object-Class is 46</t>		<t>The BGP Peer Info Object-Class is 46.</t>
	<t>BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6</t>		<t>The BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6.</t>
	<t>The format of the BGP Peer Info object body for IPv4		<t>The format of the BGP Peer Info object body for IPv4
	(Object-Type=1) is as follows:</t>		(Object-Type=1) is as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-10">
			<name>BGP Peer Info Object Body Format for IPv4</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS Number |		| Peer AS Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ETTL | Status | Error Code | Flag |T|		| ETTL | Status | Error Code | Flag |T|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local IP Address |		| Local IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP Address |		| Peer IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: BGP Peer Info Object Body Format for IPv4 ]]></artwork>		]]></artwork>
	<t/>		</figure>
	<t>The format of the BGP Peer Info object body for IPv6		<t>The format of the BGP Peer Info object body for IPv6
	(Object-Type=2) is as follows:</t>		(Object-Type=2) is as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-11">
			<name>BGP Peer Info Object Body Format for IPv6</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS Number |		| Peer AS Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ETTL | Status | Error Code | Flag |T|		| ETTL | Status | Error Code | Flag |T|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Local IP Address (16 bytes) |		| Local IP Address (16 bytes) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Peer IP Address (16 bytes) |		| Peer IP Address (16 bytes) |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: BGP Peer Info Object Body Format for IPv6 ]]></artwork>		]]></artwork>
	<ul empty="true" spacing="normal">		</figure>
	<li>
	<t>Peer AS Number: 4 bytes, to indicate the AS number of Remote		<dl spacing="normal" newline="false">
	Peer. Note that if 2-byte AS numbers are in use, the low-order		<dt>Peer AS Number:</dt><dd>4 bytes. Indicates the AS number of the Remote
	bits (16 through 31) is used, and the high-order bits (0 through		Peer. Note that if 2-byte AS numbers are in use, the low-order bits (16
	15) is set to zero.</t>		through 31) are used, and the high-order bits (0 through 15) are set to
	</li>		zero.</dd>
	<li>		<dt>ETTL:</dt><dd>1 byte. EBGP Time To Live. Indicates the multi-hop count
	<t>ETTL: 1 byte, EBGP Time To Live, to indicate the multi-hop		for the EBGP session. It should be 0 and ignored when Local AS and Peer AS
	count for the EBGP session. It should be 0 and ignored when Local		are the same.</dd>
	AS and Peer AS are the same.</t>		<dt>Status:</dt><dd><t>1 byte. Indicates the BGP session status between the
	</li>		peers. Its values are defined below:</t>
	<li>		<dl spacing="normal" newline="false">
	<t>Status: 1 byte, Indicate BGP session status between the peers.		<dt>0:</dt><dd>Reserved</dd>
	Its values are defined below:</t>		<dt>1:</dt><dd>BGP Session Established</dd>
	</li>		<dt>2:</dt><dd>BGP Session Establishment In Progress</dd>
	<li>		<dt>3:</dt><dd>BGP Session Down</dd>
	<ul spacing="normal">		<dt>4-255:</dt><dd>Reserved</dd>
	<li>		</dl>
	<t>0: Reserved</t>		</dd>
	</li>		<dt>Error Code:</dt><dd><t>1 byte. Indicates the reason that the BGP session
	<li>		can't be established.</t>
	<t>1: BGP Session Established</t>		<dl spacing="normal" newline="false">
	</li>		<dt>0:</dt><dd>Unspecific</dd>
	<li>		<dt>1:</dt><dd>ASes do not match, BGP Session Failure</dd>
	<t>2: BGP Session Establishment In Progress</t>		<dt>2:</dt><dd>Peer IP can't be reached, BGP Session Failure</dd
	</li>		>
	<li>		<dt>3-255:</dt><dd>Reserved</dd>
	<t>3: BGP Session Down</t>		</dl>
	</li>		</dd>
	<li>		<dt>Flag:</dt><dd><t>1 byte.</t>
	<t>4-255: Reserved</t>		<t>Currently, only bit 7 (T bit) is defined. When the T bit is set, the
	</li>		traffic <bcp14>SHOULD</bcp14> be sent in the IPinIP tunnel (the tunnel source
	</ul>		is
	</li>		the Local IP Address, and the tunnel destination is the Peer IP Address). When
	<li>		the T bit is
	<t>Error Code: 1 byte, Indicate the reason that the BGP session		cleared, the traffic is sent via its original source and destination
	can't be established.</t>		address. The Tunnel mode (i.e., the T bit is set) is used when the operator wa
	</li>		nts to
	<li>		ensure only the traffic from the specified (entry, exit) pair, and the Raw
	<ul spacing="normal">		mode (i.e., the T bit is clear) is used when the operator wants to ensure traf
	<li>		fic from
	<t>0: Unspecific</t>		any entry to the specified destination. Unassigned flags are set to zero
	</li>		while sending and ignored on receipt.</t>
	<li>		</dd>
	<t>1: ASes do not match, BGP Session Failure</t>		<dt>Local IP Address(4/16 bytes):</dt><dd>Unicast IP address of the local
	</li>		router, used to peer with another end router. When the Object-Type is 1, the
	<li>		length is 4 bytes; when the Object-Type is 2, the length is 16 bytes.</dd>
	<t>2: Peer IP can't be reached, BGP Session Failure</t>		<dt>Peer IP Address(4/16 bytes):</dt><dd>Unicast IP address of the peer
	</li>		router, used to peer with the local router. When the Object-Type is 1, the
	<li>		length is 4 bytes; when the Object-Type is 2, the length is 16 bytes.</dd>
	<t>3-255: Reserved</t>		<dt>Optional TLVs:</dt><dd>TLVs that are associated with this object; can be
	</li>		used to convey other necessary information for dynamic BGP session
	</ul>		establishment. No TLVs are currently defined.</dd>
	</li>		</dl>
	<li>		<t>When the PCC receives a BPI object, with Object-Type=1, it <bcp14>SHO
	<t>Flag: 1 byte.</t>		ULD</bcp14>
	</li>
	<li>
	<ul spacing="normal">
	<li>
	<t>Currently, only bit 7 (T bit) is defined. When the T bit is
	set, the traffic SHOULD be sent in the IPinIP tunnel (Tunnel
	source is Local IP Address, tunnel destination is Peer IP
	Address). When the T bit is cleared, the traffic is sent via
	its original source and destination address. The Tunnel mode(T
	bit is set) is used when the operator wants to ensure only the
	traffic from the specified (entry, exit) pair, and the Raw
	mode (T bit is clear) is used when the operator wants to
	ensure traffic from any entry to the specified destination.
	Unassigned flags are set to zero while sending and ignored on
	receipt.</t>
	</li>
	</ul>
	</li>
	<li>
	<t>Local IP Address(4/16 bytes): Unicast IP address of the local
	router, used to peer with another end router. When Object-Type is
	1, the length is 4 bytes; when Object-Type is 2, the length is 16
	bytes.</t>
	</li>
	<li>
	<t>Peer IP Address(4/16 bytes): Unicast IP address of the peer
	router, used to peer with the local router. When Object-Type is 1,
	the length is 4 bytes; when Object-Type is 2, the length is 16
	bytes;</t>
	</li>
	<li>
	<t>Optional TLVs: TLVs that are associated with this object, can
	be used to convey other necessary information for dynamic BGP
	session establishment. No TLVs are currently defined.</t>
	</li>
	</ul>
	<t>When the PCC receives a BPI object, with Object-Type=1, it SHOULD
	try to establish a BGP session with the peer in AFI/SAFI=1/1.</t>		try to establish a BGP session with the peer in AFI/SAFI=1/1.</t>
	<t>When the PCC receives a BPI object with Object-Type=2, it SHOULD		<t>When the PCC receives a BPI object, with Object-Type=2, it <bcp14>SHO ULD</bcp14>
	try to establish a BGP session with the peer in AFI/SAFI=2/1.</t>		try to establish a BGP session with the peer in AFI/SAFI=2/1.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Explicit Peer Route Object</name>		<name>Explicit Peer Route Object</name>
	<t>The Explicit Peer Route object is defined to specify the explicit		<t>The Explicit Peer Route (EPR) object is defined to specify the explic it
	peer route to the corresponding peer address on each device that is on		peer route to the corresponding peer address on each device that is on
	the E2E Native-IP TE path. This Object ought to be sent to all the		the E2E Native-IP TE path. This Object ought to be sent to all the
	devices on the path that is calculated by the PCE. Although the object		devices on the path that are calculated by the PCE. Although the object
	is named as "Explicit Peer Route", it can be seen that the		is named "Explicit Peer Route", it can be seen that the
	routes it installs are simply host routes. The use of this object to		routes it installs are simply host routes. The use of this object to
	install host routes for any purpose other than reaching the		install host routes for any purpose other than reaching the
	corresponding peer address on each device that is on the E2E Native-IP		corresponding peer address on each device that is on the E2E Native-IP
	TE path is outside the scope of this specification.</t>		TE path is outside the scope of this specification.</t>
	<t>By default, the path established by this object MUST have higher		<t>By default, the path established by this object <bcp14>MUST</bcp14> h
	priority than the other paths calculated by dynamic IGP protocol, and		ave higher
	MUST have lower priority than the static route configured by manual or		priority than the other paths calculated by the dynamic IGP protocol and
	NETCONF or any other static means.</t>		<bcp14>MUST</bcp14> have lower priority than the static route configured
	<t>Explicit Peer Route Object-Class is 47.</t>		by manual,
	<t>Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6</t>		NETCONF, or any other static means.</t>
			<t>The Explicit Peer Route Object-Class is 47.</t>
			<t>The Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6.</t>
	<t>The format of the Explicit Peer Route object body for IPv4		<t>The format of the Explicit Peer Route object body for IPv4
	(Object-Type=1) is as follows:</t>		(Object-Type=1) is as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-12">
			<name>Explicit Peer Route Object Body Format for IPv4</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Route Priority | Reserved |		| Route Priority | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IPv4 Address |		| Peer IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Hop IPv4 Address to the Peer |		| Next Hop IPv4 Address to the Peer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Explicit Peer Route Object Body Format for IPv4
	]]></artwork>		]]></artwork>
	<t/>		</figure>
	<t>The format of the Explicit Peer Route object body for IPv6		<t>The format of the Explicit Peer Route object body for IPv6
	(Object-Type=2) is as follows:</t>		(Object-Type=2) is as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-13">
			<name>Explicit Peer Route Object Body Format for IPv6</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Route Priority | Reserved |		| Route Priority | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Peer IPv6 Address |		| Peer IPv6 Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Next Hop IPv6 Address to the Peer |		| Next Hop IPv6 Address to the Peer |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13: Explicit Peer Route Object Body Format for IPv6
	]]></artwork>		]]></artwork>
	<ul empty="true" spacing="normal">		</figure>
	<li>
	<t>Route Priority: 2 bytes; the priority of this explicit route.		<dl newline="false" spacing="normal">
	The higher priority SHOULD be preferred by the device. This field		<dt>Route Priority:</dt><dd>2 bytes. The priority of this explicit
	is used to indicate the preferred path at each hop.</t>		route. The higher priority <bcp14>SHOULD</bcp14> be preferred by
	</li>		the device. This field is used to indicate the preferred path at
	<li>		each hop.</dd>
	<t>Reserved: is set to zero while sending, ignored on receipt.</t>		<dt>Reserved:</dt><dd>Set to zero while sending and ignored on receipt
	</li>		.</dd>
	<li>		<dt>Peer (IPv4/IPv6) Address:</dt><dd>Peer address for the BGP
	<t>Peer (IPv4/IPv6) Address: Peer Address for the BGP session		session (4/16 bytes).</dd>
	(4/16 bytes).</t>		<dt>Next Hop (IPv4/IPv6) Address to the Peer:</dt><dd>Indicates
	</li>		the next-hop address (4/16 bytes) to the corresponding peer
	<li>		address.</dd>
	<t>Next Hop (IPv4/IPv6) Address to the Peer: To indicate the next		<dt>Optional TLVs:</dt><dd>TLVs that are associated with this
	hop address (4/16 bytes) to the corresponding peer address.</t>		object; can be used to convey other necessary information for
	</li>		explicit peer path establishment. No TLVs are currently defined.</dd>
	<li>		</dl>
	<t>Optional TLVs: TLVs that are associated with this object, can
	be used to convey other necessary information for explicit peer
	path establishment. No TLVs are currently defined.</t>
	</li>
	</ul>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Peer Prefix Advertisement Object</name>		<name>Peer Prefix Advertisement Object</name>
	<t>The Peer Prefix Advertisement object is defined to specify the IP		<t>The Peer Prefix Advertisement (PPA) object is defined to specify the IP
	prefixes that are advertised to the corresponding peer. This object		prefixes that are advertised to the corresponding peer. This object
	needs only be included and sent to the source/destination router of		only needs to be included and sent to the source/destination router of
	the E2E path.</t>		the E2E path.</t>
	<t>The prefix information included in this object MUST only be		<t>The prefix information included in this object <bcp14>MUST</bcp14> on
	advertised to the indicated peer, and SHOULD NOT be advertised to		ly be
			advertised to the indicated peer and <bcp14>SHOULD NOT</bcp14> be advert
			ised to
	other BGP peers.</t>		other BGP peers.</t>
	<t>Peer Prefix Advertisement Object-Class is 48</t>		<t>The Peer Prefix Advertisement Object-Class is 48.</t>
	<t>Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for		<t>The Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for
	IPv6</t>		IPv6.</t>
	<t>The format of the Peer Prefix Advertisement object body is as		<t>The format of the Peer Prefix Advertisement object body for IPv4 is a
			s
	follows:</t>		follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0
	1 2 3		<figure anchor="fig-14">
			<name>Peer Prefix Advertisement Object Body Format for IPv4</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IPv4 Address |		| Peer IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| No. of Prefix | Reserved |		| No. of Prefix | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Prefix #1 |		| IPv4 Prefix #1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Prefix #1 Len | Reserved |		|Prefix #1 Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| : |		| : |
	| : |		| : |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Prefix #n |		| IPv4 Prefix #n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Prefix #n Len | Reserved |		|Prefix #n Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 14: Peer Prefix Advertisement Object Body Format for IPv4]]></artwork>		]]></artwork>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0		</figure>
	1 2 3
			<!--[rfced] FYI - To match Sections 7.2 and 7.3, we have updated
			the single sentence preceding Figures 14 and 15 in Section 7.4 to
			be two sentences, one preceding each figure, respectively. Please
			review and let us know of any objections.
			Original:
			The format of the Peer Prefix Advertisement object body is as
			follows:
			Current:
			The format of the Peer Prefix Advertisement object body for IPv4
			is as follows:
			...
			The format of the Peer Prefix Advertisement object body for IPv6
			is as follows:
			-->
			<t>The format of the Peer Prefix Advertisement object body for IPv6 is a
			s
			follows:</t>
			<figure anchor="fig-15">
			<name>Peer Prefix Advertisement Object Body Format for IPv6</name>
			<artwork name="" type="" align="center" alt=""><![CDATA[
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Peer IPv6 Address |		| Peer IPv6 Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| No. of Prefix | Reserved |		| No. of Prefix | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Prefix #1 |		| IPv6 Prefix #1 |
	skipping to change at line 1105 ¶		skipping to change at line 1298 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Prefix #n |		| IPv6 Prefix #n |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Prefix #n Len | Reserved |		|Prefix #n Len | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Optional TLVs //		// Optional TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15: Peer Prefix Advertisement Object Body Format for IPv6]]></artwork>		]]></artwork>
	<ul empty="true" spacing="normal">		</figure>
	<li>
	<t>Common Fields:</t>		<dl newline="true">
	</li>		<dt>Common Fields:</dt>
	<li>		<dd>
	<ul empty="true" spacing="normal">		<dl newline="false" spacing="normal">
	<li>		<dt>No. of Prefix:</dt><dd>1 byte. Identifies the
	<t>No. of Prefix: 1 byte. Identifies the number of prefixes		number of prefixes that are advertised to the peer in the PPA
	that are advertised to the peer in the PPA object.</t>		object.</dd>
	</li>		<dt>Reserved:</dt><dd>3 bytes. Ought to be set to zero
	<li>		while sending and ignored on receipt.</dd>
	<t>Reserved: 3 bytes. Ought to be set to zero while sending		<dt>Prefix Len:</dt><dd>1 byte. Identifies the length
	and be ignored on receipt.</t>		of the prefix.</dd>
	</li>		<dt>Optional TLVs:</dt><dd>TLVs that are associated with this
	<li>		object; can be used to convey other necessary information for
	<t>Prefix Len: 1 byte. Identifies the length of the		prefix advertisement. No TLVs are currently defined.</dd>
	prefix.</t>		</dl>
	</li>		</dd>
	<li>		<dt>For IPv4:</dt>
	<t>Optional TLVs: TLVs that are associated with this object,		<dd>
	can be used to convey other necessary information for prefix		<dl newline="false" spacing="normal">
	advertisement. No TLVs are currently defined.</t>		<dt>Peer IPv4 Address:</dt><dd>4 bytes. Identifies the
	</li>		peer IPv4 address that the associated prefixes will be sent
	</ul>		to.</dd>
	</li>		<dt>IPv4 Prefix:</dt><dd>4 bytes. Identifies the prefix
	<li>		that will be sent to the peer identified by the Peer IPv4
	<t>For IPv4:</t>		Address.</dd>
	</li>		</dl>
	<li>		</dd>
	<ul empty="true" spacing="normal">		<dt>For IPv6:</dt>
	<li>		<dd>
	<t>Peer IPv4 Address: 4 bytes. Identifies the peer IPv4		<dl newline="false" spacing="normal">
	address that the associated prefixes will be sent to.</t>		<dt>Peer IPv6 Address:</dt><dd>16 bytes. Identifies the
	</li>		peer IPv6 address that the associated prefixes will be sent
	<li>		to.</dd>
	<t>IPv4 Prefix: 4 bytes. Identifies the prefix that will be		<dt>IPv6 Prefix:</dt><dd>Identifies the prefix that will be
	sent to the peer identified by Peer IPv4 Address.</t>		sent to the peer identified by the Peer IPv6 Address.</dd>
	</li>		</dl>
	</ul>		</dd>
	</li>		</dl>
	<li>		<t>If in the future a requirement is identified to advertise IPv4
	<t>For IPv6:</t>		prefixes towards an IPv6 peering address or IPv6 prefixes towards an
	<ul empty="true" spacing="normal">		IPv4 peering address, then a new Peer Prefix Advertisement
	<li>		Object-Type can be defined for these purposes.</t>
	<t>Peer IPv6 Address: 16 bytes. Identifies the peer IPv6
	address that the associated prefixes will be sent to.</t>
	</li>
	<li>
	<t>IPv6 Prefix: Identifies the prefix that will be sent to the
	peer identified by Peer IPv6 Address.</t>
	</li>
	</ul>
	<t>If in the future, a requirement is identified to
	advertise IPv4 prefixes toward an IPv6 peering address, or IPv6
	prefixes towards an IPv4 peering address, then a new Peer Prefix
	Advertisement Object-Types can be defined for these purposes.</t>
	</li>
	</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="NewErrorTypeAndValue" numbered="true" toc="default">		<section anchor="NewErrorTypeAndValue" numbered="true" toc="default">
	<name>New Error-Types and Error-Values Defined</name>		<name>New Error-Type and Error-Values Defined</name>
	<t>A PCEP-ERROR object is used to report a PCEP error and is		<t>A PCEP-ERROR object is used to report a PCEP error and is
	characterized by an Error-Type that specifies that type of error and an		characterized by an Error-Type that specifies that type of error and an
	Error-value that provides additional information about the error. An		Error-value that provides additional information about the error. An
	additional Error-Type and several Error-values are defined to represent		additional Error-Type and several Error-values are defined to represent
	the errors related to the newly defined objects that are related to		the errors related to the newly defined objects that are related to
	Native IP TE procedures.</t>		Native IP TE procedures.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ +============
	+==========+=====================================+		<!-- [rfced] Table 1: Rather than have two tables with the same
	| Error-Type | Meaning | Error-value |		information, may we point readers to Table 5 in the IANA
	+=======+===============+=====================================+		Considerations section as shown below?
	| 33 | Native IP TE failure |
	| | |		Current (Section 8):
	+-------+---------------+-------------------------------------+		An additional Error-Type and several Error-values are defined to
	| | |0:Unassigned |		represent the errors related to the newly defined objects that are
	+-------+---------------+-------------------------------------+		related to Native IP TE procedures.
	| | |1:Local IP is in use |
	+-------+---------------+-------------------------------------+		Perhaps:
	| | |2:Remote IP is in use |		An additional Error-Type and several Error-values are defined to
	+-------+---------------+-------------------------------------+		represent the errors related to the newly defined objects that are
	| | |3:Explicit Peer Route Error |		related to Native IP TE procedures. See Table 5 (Section 13.4) for
	+-------+---------------+-------------------------------------+		the newly defined Error-Type and Error-values.
	| | |4:EPR/BPI Peer Info mismatch |		-->
	+-------+---------------+-------------------------------------+
	| | |5:BPI/PPA Address Family mismatch |		<table>
	+-------+---------------+-------------------------------------+		<name>Newly Defined Error-Type and Error-Values</name>
	| | |6:PPA/BPI Peer Info mismatch |		<thead>
	+-------+---------------+-------------------------------------+		<tr>
	| 6 | Mandatory Object missing |		<th>Error-Type</th>
	| | |		<th>Meaning</th>
	+-------+---------------+-------------------------------------+		<th>Error-value</th>
	| | |19:Native IP object missing |		</tr>
	+-------+---------------+-------------------------------------+		</thead>
	| 10 | Reception of an invalid object |		<tbody>
	| | |		<tr>
	+-------+---------------+-------------------------------------+		<td>6</td>
	| | |39:PCECC NATIVE-IP-TE-CAPABILITY bit |		<td>Mandatory Object missing</td>
	| | |is not set |		<td>19: Native IP object missing</td>
	+-------+---------------+-------------------------------------+		</tr>
	| 19 | Invalid Operation |		<tr>
	| | |		<td>10</td>
	+-------+---------------+-------------------------------------+		<td>Reception of an invalid object</td>
	| | |22:Only one BPI, EPR or PPA object |		<td>39: PCECC NATIVE-IP-TE-CAPABILITY bit is not set</td>
	| | |can be included in this message |		</tr>
	+-------+---------------+-------------------------------------+		<tr>
	| | |TBD1:Attempted Native-IP operations |		<td rowspan="3">19</td>
	| | |when the capability was not |		<td rowspan="3">Invalid Operation</td>
	| | | advertised |		<td> 22: Only one BPI, EPR, or PPA object can be included in this message<
	+-------+---------------+-------------------------------------+		/td>
	| | |TBD2:Unknown Native-IP Info |		</tr>
	+-------+---------------+-------------------------------------+		<tr>
	Figure 16: Newly defined Error-Type and Error-Value		<td>29: Attempted Native-IP operations when the capability was not advertised</t
	]]></artwork>		d>
			</tr>
			<tr>
			<td>30: Unknown Native-IP Info</td>
			</tr>
			<tr>
			<td rowspan="6">33</td>
			<td rowspan="6">Native IP TE failure</td>
			<td>1: Local IP is in use</td>
			</tr>
			<tr>
			<td>2: Remote IP is in use</td>
			</tr><tr>
			<td>3: Explicit Peer Route Error</td>
			</tr><tr>
			<td>4: EPR/BPI Peer Info mismatch</td>
			</tr><tr>
			<td>5: BPI/PPA Address Family mismatch</td>
			</tr><tr>
			<td>6: PPA/BPI Peer Info mismatch</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section anchor="BGP_Considerations" numbered="true" toc="default">		<section anchor="BGP_Considerations" numbered="true" toc="default">
	<name>BGP Considerations</name>		<name>BGP Considerations</name>
	<t>This document defines the procedures and objects to create the BGP
	sessions and advertise the associated prefixes dynamically. Only the key		<t>This document defines procedures and objects to create the BGP
	information, for example, peer IP addresses, and peer AS numbers are		sessions and to advertise the associated prefixes dynamically. Only the ke
			y
			information, for example, peer IP addresses, and Peer AS numbers are
	exchanged via the PCEP protocol. Other parameters that are needed for		exchanged via the PCEP protocol. Other parameters that are needed for
	the BGP session setup SHOULD be derived from their default values.</t>		the BGP session setup <bcp14>SHOULD</bcp14> be derived from their default values.</t>
	<t>When the PCE sends out the PCInitiate message with the BPI object		<t>When the PCE sends out the PCInitiate message with the BPI object
	embedded to establish the BGP session between the PCC peers, the PCC		embedded to establish the BGP session between the PCC peers, the PCC
	SHOULD report the BGP session status. For instance, the PCC could		<bcp14>SHOULD</bcp14> report the BGP session status. For instance, the PCC
	respond with "BGP Session Establishment In Progress" initially and on		could
	session establishment send another PCRpt message with the state updated		respond with "BGP Session Establishment In Progress" initially and, on
			session establishment, send another PCRpt message with the state updated
	to "BGP Session Established". If there is any error during the BGP		to "BGP Session Established". If there is any error during the BGP
	session establishment, the PCC SHOULD indicate the reason with the		session establishment, the PCC <bcp14>SHOULD</bcp14> indicate the reason w ith the
	appropriate status value set in the BPI object.</t>		appropriate status value set in the BPI object.</t>
	<t>Upon receiving such key information, the BGP module on the PCC SHOULD		<t>Upon receiving such key information, the BGP module on the PCC <bcp14>S HOULD</bcp14>
	try to accomplish the task appointed by the PCEP protocol and report the		try to accomplish the task appointed by the PCEP protocol and report the
	successful status to the PCEP modules after the session is set up.</t>		successful status to the PCEP modules after the session is set up.</t>
	<t>There is no influence on the current implementation of BGP Finite		<t>There is no influence on the current implementation of the BGP Finite
	State Machine (FSM). The PCEP focuses only on the success and failure		State Machine (FSM). PCEP focuses only on the success and failure
	status of the BGP session and acts upon such information		status of the BGP session and acts upon such information
	accordingly.</t>		accordingly.</t>
	<t>The error-handling procedures related to incorrect BGP parameters are		<t>The error-handling procedures related to incorrect BGP parameters are
	specified in <xref target="BGPSess" format="default"/>, <xref target="BGPE x" format="default"/>, and <xref target="BGPPrefix" format="default"/>.</t>		specified in Sections <xref target="BGPSess" format="counter"/>, <xref tar get="BGPEx" format="counter"/>, and <xref target="BGPPrefix" format="counter"/>. </t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Deployment Considerations</name>		<name>Deployment Considerations</name>
	<t>The information transferred in this document is mainly used for the		<t>The information transferred in this document is mainly used for the
	BGP session setup, explicit route deployment and the prefix		BGP session setup, explicit route deployment, and prefix
	distribution. The planning, allocation and distribution of the peer		distribution. The planning, allocation, and distribution of the peer
	addresses within IGP needs to be accomplished in advance and they are		addresses within IGP need to be accomplished in advance, and they are
	out of the scope of this document.</t>		out of the scope of this document.</t>
	<t>The communication of PCE and PCC described in this document MUST
	follow the state synchronization procedures described in <xref target="RFC		<!--[rfced] To have a 1:1 matchup between the acronym and its expansion, may
	8232" format="default"/>, treat the three newly defined objects (BPI, EPR and		we update "LSP-DB" as follows, i.e., remove "State" from the expansion?
			Original:
			...treat the three newly defined objects (BPI, EPR and PPA) associated
			with the same symbolic path name as the attribute of the same path in
			the LSP-DB (LSP State Database).
			Perhaps:
			...treat the three newly defined objects (BPI, EPR, and PPA) associated
			with the same symbolic path name as the attribute of the same path in
			the LSP Database (LSP-DB).
			-->
			<t>The communication of PCE and PCC described in this document <bcp14>MUST
			</bcp14>
			follow the state synchronization procedures described in <xref target="RFC
			8232" format="default"/>, i.e., treat the three newly defined objects (BPI, EPR,
			and
	PPA) associated with the same symbolic path name as the attribute of the		PPA) associated with the same symbolic path name as the attribute of the
	same path in the LSP-DB (LSP State Database).</t>		same path in the LSP State Database (LSP-DB).</t>
	<t>When PCE detects one or some of the PCCs are out of its control, it		<t>When the PCE detects that one or some of the PCCs are out of its contro
	MUST recompute and redeploy the traffic engineering path for native IP		l, it
	on the currently active PCCs. The PCE MUST ensure the avoidance of the		<bcp14>MUST</bcp14> recompute and redeploy the traffic engineering path fo
			r native IP
			on the currently active PCCs. The PCE <bcp14>MUST</bcp14> ensure the avoid
			ance of the
	possible transient loop in such node failure when it deploys the		possible transient loop in such node failure when it deploys the
	explicit peer route on the PCCs.</t>		explicit peer route on the PCCs.</t>
	<t>In case of a PCE failure, a new PCE can gain control over the central		<t>In case of a PCE failure, a new PCE can gain control over the central
	controller instructions as described in <xref target="RFC9050" format="def ault"/>.</t>		controller instructions as described in <xref target="RFC9050" format="def ault"/>.</t>
	<t>As per the PCEP procedures in <xref target="RFC8281" format="default"/> , the State		<t>As per the PCEP procedures in <xref target="RFC8281" format="default"/> , the State
	Timeout Interval timer is used to ensure that a PCE failure does not		Timeout Interval timer is used to ensure that a PCE failure does not
	result in automatic and immediate disruption for the services.		result in automatic and immediate disruption for the services.
	Similarly, as per <xref target="RFC9050" format="default"/>, the central c ontroller		Similarly, as per <xref target="RFC9050" format="default"/>, the central c ontroller
	instructions are not removed immediately upon PCE failure. Instead, they		instructions are not removed immediately upon PCE failure. Instead, they
	could be re-delegated to the new PCE before the expiration of this		could be redelegated to the new PCE before the expiration of this
	timer, or be cleaned up on the expiration of this timer. This allows for		timer or be cleaned up on the expiration of this timer. This allows for
	network clean up without manual intervention. The PCC supports the		network cleanup without manual intervention. The PCC supports the
	removal of CCI as one of the behaviors applied on the expiration of the		removal of CCI as one of the behaviors applied on the expiration of the
	State Timeout Interval timer.</t>		State Timeout Interval timer.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Manageability Considerations</name>		<name>Manageability Considerations</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Control of Function and Policy</name>		<name>Control of Function and Policy</name>
	<t>A PCE or PCC implementation SHOULD allow the PCECC Native-IP		<t>A PCE or PCC implementation <bcp14>SHOULD</bcp14> allow the PCECC Nat ive-IP
	capability to be enabled/disabled as part of the global		capability to be enabled/disabled as part of the global
	configuration.</t>		configuration.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Information and Data Models</name>		<name>Information and Data Models</name>
	<t><xref target="RFC7420" format="default"/> describes the PCEP MIB; thi s MIB could be		<t><xref target="RFC7420" format="default"/> describes the PCEP MIB; thi s MIB could be
	extended to get the PCECC Native-IP capability status. The PCEP YANG		extended to get the PCECC Native-IP capability status. The PCEP YANG mod
	<xref target="I-D.ietf-pce-pcep-yang" format="default"/> module could be		ule
	extended to		<xref target="I-D.ietf-pce-pcep-yang" format="default"/> could be extend
			ed to
	enable/disable the PCECC Native-IP capability.</t>		enable/disable the PCECC Native-IP capability.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Liveness Detection and Monitoring</name>		<name>Liveness Detection and Monitoring</name>
			<!--[rfced] Is the intended meaning that the mechanisms in this
			document and the mechanisms listed in RFC 5440 do not imply any
			new liveness detection and monitoring? If so, may we rephrase the
			text as shown below for clarity?
			Original:
			Mechanisms defined in this document do not imply any new liveness
			detection and monitoring requirements in addition to those already
			listed in [RFC5440].
			Perhaps:
			Mechanisms defined in this document, and those already listed in
			[RFC5440], do not imply any new liveness detection and monitoring
			requirements.
			-->
	<t>Mechanisms defined in this document do not imply any new liveness		<t>Mechanisms defined in this document do not imply any new liveness
	detection and monitoring requirements in addition to those already		detection and monitoring requirements in addition to those already liste
	listed in <xref target="RFC5440" format="default"/>. The operator relies		d in <xref target="RFC5440" format="default"/>. The operator relies on existing
	on existing IP		IP
	liveness detection and monitoring.</t>		liveness detection and monitoring.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Verify Correct Operations</name>		<name>Verify Correct Operations</name>
	<t>Verification of the mechanisms defined in this document can be		<t>Verification of the mechanisms defined in this document can be
	built on those already listed in <xref target="RFC5440" format="default" />, <xref target="RFC8231" format="default"/> and <xref target="RFC9050" format= "default"/>. Further, the operator		built on those already listed in <xref target="RFC5440" format="default" />, <xref target="RFC8231" format="default"/>, and <xref target="RFC9050" format ="default"/>. Further, the operator
	needs to be able to verify the status of BGP sessions and prefix		needs to be able to verify the status of BGP sessions and prefix
	advertisements.</t>		advertisements.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Requirements on Other Protocols</name>		<name>Requirements on Other Protocols</name>
	<t>Mechanisms defined in this document require the interaction with		<t>Mechanisms defined in this document require the interaction with
	BGP. <xref target="BGP_Considerations" format="default"/> describes in d etail the		BGP. <xref target="BGP_Considerations" format="default"/> describes in d etail the
	considerations regarding the BGP. During the BGP session		considerations regarding the BGP. During the BGP session
	establishment, the Local/Peer IP address MUST be dedicated to the		establishment, the Local/Peer IP address <bcp14>MUST</bcp14> be dedicate
	usage of the native IP TE solution, and MUST NOT be used by other BGP		d to the
			usage of the native IP TE solution and <bcp14>MUST NOT</bcp14> be used b
			y other BGP
	sessions that are established manually or in other ways.</t>		sessions that are established manually or in other ways.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Impact on Network Operations</name>		<name>Impact on Network Operations</name>
	<t><xref target="RFC8821" format="default"/> describes the various deplo yment		<t><xref target="RFC8821" format="default"/> describes the various deplo yment
	considerations in CCDR architecture and their impact on network		considerations in CCDR architecture and their impact on network
	operations.</t>		operations.</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>In this setup, the BGP sessions, prefix advertisement, and explicit		<t>In this setup, the BGP sessions, prefix advertisement, and explicit
	peer route establishment are all controlled by the PCE. See <xref target="		peer route establishment are all controlled by the PCE. See <xref target="
	RFC4271" format="default"/> for security consideration of classical BGP		RFC4271" format="default"/> for classical BGP
	implementation, and <xref target="RFC4272" format="default"/> for classica		implementation security considerations and <xref target="RFC4272" format="
	l BGP		default"/> for classical BGP
	vulnerabilities analysis. Security considerations in <xref target="RFC5440		vulnerabilities analysis. Security considerations in <xref target="RFC5440
	" format="default"/>for basic PCEP protocol, <xref target="RFC8231" format="defa		" format="default"/> for the basic PCEP protocol, <xref target="RFC8231" format=
	ult"/> for		"default"/> for
	PCEP extension for stateful PCE and <xref target="RFC8281" format="default		PCEP extension for stateful PCE, and <xref target="RFC8281" format="defaul
	"/> for		t"/> for
	PCE-Initiated LSP setup SHOULD be considered. To prevent a bogus PCE		PCE-Initiated LSP setup <bcp14>SHOULD</bcp14> be considered. To prevent a
			bogus PCE
	from sending harmful messages to the network nodes, the network devices		from sending harmful messages to the network nodes, the network devices
	SHOULD authenticate the PCE and ensure a secure communication channel		<bcp14>SHOULD</bcp14> authenticate the PCE and ensure a secure communicati on channel
	between them. Thus, the mechanisms described in <xref target="RFC8253" for mat="default"/>		between them. Thus, the mechanisms described in <xref target="RFC8253" for mat="default"/>
	for the usage of TLS for PCEP and <xref target="RFC9050" format="default"/ > for		for the usage of TLS for PCEP and <xref target="RFC9050" format="default"/ > for
	protection against malicious PCEs SHOULD be used.</t>		protection against malicious PCEs <bcp14>SHOULD</bcp14> be used.</t>
	<t>If suitable default values as discussed in <xref target="BGP_Considerat
	ions" format="default"/> aren't enough and securing the BGP		<!--[rfced] Does "it" refer to a suitable default value? If so, may we
	transport is required(for example, the TCP-AO <xref target="RFC5925" forma		clarify the text as follows?
	t="default"/>,
			Original:
			If suitable default values as discussed in Section 9 aren't enough
			and securing the BGP transport is required(for example, the TCP-AO
			[RFC5925], it can be provided through the addition of optional TLVs
			to the BGP Peer Info object that conveys the necessary additional
			information (for example, a key chain [RFC8177]name).
			Perhaps:
			If the suitable default values discussed in Section 9 aren't enough
			and securing the BGP transport is required (for example, by using
			TCP-AO [RFC5925]), a suitable value can be provided through the
			addition of optional TLVs to the BGP Peer Info object that conveys
			the necessary additional information (for example, a key chain
			[RFC8177] name).
			-->
			<t>If the suitable default values discussed in <xref target="BGP_Considera
			tions" format="default"/> aren't enough and securing the BGP
			transport is required (for example, the TCP Authentication Option (TCP-AO)
			<xref target="RFC5925" format="default"/>),
	it can be provided through the addition of optional TLVs to the BGP Peer		it can be provided through the addition of optional TLVs to the BGP Peer
	Info object that conveys the necessary additional information (for		Info object that conveys the necessary additional information (for
	example, a key chain <xref target="RFC8177" format="default"/>name).</t>		example, a key chain <xref target="RFC8177" format="default"/> name).</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Path Setup Type Registry</name>		<name>PCEP Path Setup Types</name>
	<t><xref target="RFC8408" format="default"/> created a sub-registry with		<t><xref target="RFC8408" format="default"/> created the "PCEP
	in the "Path		Path Setup Types" registry within the "Path
	Computation Element Protocol (PCEP) Numbers" registry called "PCEP		Computation Element Protocol (PCEP) Numbers" registry group. IANA has
	Path Setup Types". IANA is requested to allocate a new code point		allocated a new code point
	within this sub-registry, as follows:</t>		within this registry, as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Value Description Reference		<table>
	4 Native IP TE Path This document		<name>PCEP Path Setup Types Registry</name>
	]]></artwork>		<thead>
			<tr>
			<th>Value</th>
			<th>Description</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>4</td>
			<td>Native IP TE Path</td>
			<td>RFC 9757</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>PCECC-CAPABILITY sub-TLV's Flag field</name>		<name>PCECC-CAPABILITY Sub-TLV Flag Field</name>
	<t>Editorial Note (To be removed by RFC Editor): This experimental		<t><xref target="RFC9050" format="default"/> created the "PCECC-CAPABILI
	track document is allocating a code point in the registry under the		TY sub-TLV" registry within the "Path
	standards action registry which is not allowed. <xref target="RFCYYY1" f		Computation Element Protocol (PCEP) Numbers" registry group to manage th
	ormat="default"/> updates the registration policy to		e
	IETF review allowing for this allocation. Note that an early		value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. IANA
	allocation was made when the document was being progressed in the		has allocated a new bit position within this registry, as
	standards track. At the time of publication, please remove this note
	and the reference to <xref target="RFCYYY1" format="default"/>.</t>
	<t><xref target="RFC9050" format="default"/> created a sub-registry with
	in the "Path
	Computation Element Protocol (PCEP) Numbers" registry to manage the
	value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field. IANA is
	requested to allocate a new bit position within this registry, as
	follows:</t>		follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
	Bit Name Reference		<name>PCECC-CAPABILITY Sub-TLV Registry</name>
	30 NATIVE IP This document		<thead>
	]]></artwork>		<tr>
			<th>Bit</th>
			<th>Name</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>30</td>
			<td>NATIVE IP</td>
			<td>RFC 9757</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>PCEP Object</name>		<name>PCEP Objects</name>
	<t>IANA is requested to allocate new codepoints in the "PCEP Objects"		<t>IANA has allocated new code points in the "PCEP Objects"
	sub-registry as follows:</t>		registry, as follows:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Object-Class Value Name Reference
	44 CCI Object This document
	Object-Type
	2: Native IP
	46 BGP Peer Info This document		<!-- [rfced] We have included a clarification about the IANA text
	Object-Type		below. In addition to reviewing it, please review all of the
	1: IPv4 address		IANA-related updates carefully and let us know if any further
	2: IPv6 address		updates are needed.
	47 Explicit Peer Route This document		) FYI: In Table 4, we have added "Object-Type" to each name and have added
	Object-Type		"0: Reserved" accordingly to match the "PCEP Objects" registry (see <https://www
	1: IPv4 address		.iana.org/assignments/pcep/>).
	2: IPv6 address		-->
			<table>
			<name>PCEP Objects Registry</name>
			<thead>
			<tr>
			<th>Object-Class Value</th>
			<th>Name</th>
			<th>Object-Type</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>44</td>
			<td>CCI Object-Type</td>
			<td>2: Native IP</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td rowspan="3">46</td>
			<td rowspan="3">BGP Peer Info Object-Type</td>
			<td>0: Reserved</td>
			<td>RFC 9757</td>
			</tr><tr>
			<td>1: IPv4 address</td>
			<td></td>
			</tr><tr>
			<td>2: IPv6 address</td>
			<td></td>
			</tr>
			<tr>
			<td rowspan="3">47</td>
			<td rowspan="3">Explicit Peer Route Object-Type</td>
			<td>0: Reserved</td>
			<td>RFC 9757</td>
			</tr><tr>
			<td>1: IPv4 address</td>
			<td></td>
			</tr><tr>
			<td>2: IPv6 address</td>
			<td></td>
			</tr>
			<tr>
			<td rowspan="3">48</td>
			<td rowspan="3">Peer Prefix Advertisement Object-Type</td>
			<td>0: Reserved</td>
			<td>RFC 9757</td>
			</tr><tr>
			<td>1: IPv4 address</td>
			<td></td>
			</tr><tr>
			<td>2: IPv6 address</td>
			<td></td>
			</tr>
			</tbody>
			</table>
	48 Peer Prefix Advertisement This document
	Object-Type
	1: IPv4 address
	2: IPv6 address
	]]></artwork>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>PCEP-Error Object</name>		<name>PCEP-Error Objects</name>
	<t>IANA is requested to allocate new error types and error values		<t>IANA has allocated a new Error-Type and several Error-values
	within the "PCEP-ERROR Object Error Types and Values" sub-registry of		in the "PCEP-ERROR Object Error Types and Values" registry within
	the PCEP Numbers registry for the following errors:</t>		the "Path Computation Element Protocol (PCEP) Numbers" registry group, a
	<artwork name="" type="" align="left" alt=""><![CDATA[		s follows:</t>
	Error-Type Meaning Error-value
	6 Mandatory Object missing
	19:Native IP object missing
	10 Reception of an invalid object
	39:PCECC NATIVE-IP-TE-CAPABILITY bit
	is not set
	19 Invalid Operation
	22:Only one BPI, EPR or PPA object can
	be included in this message
	TBD1:Attempted Native-IP operations
	when the capability was not advertised
	TBD2:Unknown Native-IP Info
	33 Native IP TE failure		<table>
	1:Local IP is in use		<name>PCEP-ERROR Object Error Types and Values Registry</name>
	2:Remote IP is in use		<thead>
	3:Explicit Peer Route Error		<tr>
	4:EPR/BPI Peer Info mismatch		<th>Error-Type</th>
	5:BPI/PPA Address Family mismatch		<th>Meaning</th>
	6:PPA/BPI Peer Info mismatch		<th>Error-value</th>
	]]></artwork>		</tr>
	<t>The reference for the new Error-type/value should be set to this		</thead>
			<tbody>
			<tr>
			<td>6</td>
			<td>Mandatory Object missing</td>
			<td>19: Native IP object missing</td>
			</tr>
			<tr>
			<td>10</td>
			<td>Reception of an invalid object</td>
			<td>39: PCECC NATIVE-IP-TE-CAPABILITY bit is not set</td>
			</tr>
			<tr>
			<td rowspan="3">19</td>
			<td rowspan="3">Invalid Operation</td>
			<td> 22: Only one BPI, EPR, or PPA object can be included in this message<
			/td>
			</tr>
			<tr>
			<td>29: Attempted Native-IP operations when the capability was not advertised</t
			d>
			</tr>
			<tr>
			<td>30: Unknown Native-IP Info</td>
			</tr>
			<tr>
			<td rowspan="7">33</td>
			<td rowspan="7">Native IP TE failure</td>
			<td>0: Unassigned</td>
			</tr>
			<tr>
			<td>1: Local IP is in use</td>
			</tr><tr>
			<td>2: Remote IP is in use</td>
			</tr><tr>
			<td>3: Explicit Peer Route Error</td>
			</tr><tr>
			<td>4: EPR/BPI Peer Info mismatch</td>
			</tr><tr>
			<td>5: BPI/PPA Address Family mismatch</td>
			</tr><tr>
			<td>6: PPA/BPI Peer Info mismatch</td>
			</tr>
			</tbody>
			</table>
			<t>The reference for each new Error-Type/Error-value should be set to th
			is
	document.</t>		document.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>CCI Object Flag Field</name>		<name>CCI Object Flag Field</name>
	<t>IANA is requested to create a new sub-registry to manage the		<t>IANA has created the "CCI Object Flag Field
	16-bits Flag field of the new CCI Object called "CCI Object Flag Field		for Native-IP" registry to manage the
	for Native-IP". New values are to be assigned by IETF review <xref targe		16-bit Flag field of the new CCI Object. New values are to be assigned b
	t="RFC8126" format="default"/>. Each bit should be tracked with the following		y
	qualities:</t>		IETF Review <xref target="RFC8126" format="default"/>. Each bit should
	<ul empty="true" spacing="normal">		be tracked with the following qualities:</t>
	<li>		<ul spacing="normal">
	<t>bit number (counting from bit 0 as the most significant bit,		<li>bit number (counting from bit 0 as the most significant bit
	and bit 15 as the lest significant bit)</t>		and bit 15 as the least significant bit)</li>
	</li>		<li>capability description</li>
	<li>		<li>defining RFC</li>
	<t>capability description</t>
	</li>
	<li>
	<t>defining RFC</t>
	</li>
	</ul>		</ul>
	<t>Currently, no flags are assigned.</t>		<t>Currently, no flags are assigned.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BPI Object Status Code</name>		<name>BPI Object Status Codes</name>
	<t>IANA is requested to create a new sub-registry "BPI Object Status		<t>IANA has created the "BPI Object Status
	Code Field" within the "Path Computation Element Protocol (PCEP)		Code Field" registry within the "Path Computation Element Protocol (PCEP
	Numbers". New values are assigned by IETF review <xref target="RFC8126"		)
	format="default"/>. Each value should be tracked with the following		Numbers" registry group. New values are assigned by IETF Review <xref ta
			rget="RFC8126" format="default"/>. Each value should be tracked with the followi
			ng
	qualities: value, meaning, and defining RFC. The following values are		qualities: value, meaning, and defining RFC. The following values are
	defined in this document:</t>		defined in this document:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Value Meaning Reference		<table>
	0 Reserved This document		<name>BPI Object Status Code Field Registry</name>
	1 BGP Session Established This document		<thead>
	2 BGP Session Establishment In Progress This document		<tr>
	3 BGP Session Down This document		<th>Value</th>
	4-255 Unassigned This document		<th>Meaning</th>
	]]></artwork>		<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>0</td>
			<td>Reserved</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>1</td>
			<td>BGP Session Established</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>2</td>
			<td>BGP Session Establishment In Progress</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>3</td>
			<td>BGP Session Down</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>4-255</td>
			<td>Unassigned</td>
			<td>RFC 9757</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BPI Object Error Code</name>		<name>BPI Object Error Codes</name>
	<t>IANA is requested to create a new sub-registry "BPI Object Error		<t>IANA has created the "BPI Object Error
	Code Field" within the "Path Computation Element Protocol (PCEP)		Code Field" registry within the "Path Computation Element Protocol (PCEP
	Numbers". New values are assigned by IETF review <xref target="RFC8126"		)
	format="default"/>. Each value should be tracked with the following		Numbers" registry group. New values are assigned by IETF Review <xref ta
			rget="RFC8126" format="default"/>. Each value should be tracked with the followi
			ng
	qualities: value, meaning, and defining RFC. The following values are		qualities: value, meaning, and defining RFC. The following values are
	defined in this document:</t>		defined in this document:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Value Meaning Reference		<table>
	0 Reserved This document		<name>BPI Object Error Code Field Registry</name>
	1 ASes does not match, BGP Session Failure This document		<thead>
	2 Peer IP can't be reached, BGP Session Failure This document		<tr>
	3-255 Unassigned This document		<th>Value</th>
	]]></artwork>		<th>Meaning</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>0</td>
			<td>Reserved</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>1</td>
			<td>ASes do not match - BGP Session Failure</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>2</td>
			<td>Peer IP can't be reached - BGP Session Failure</td>
			<td>RFC 9757</td>
			</tr>
			<tr>
			<td>3-255</td>
			<td>Unassigned</td>
			<td>RFC 9757</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>BPI Object Flag Field</name>		<name>BPI Object Flag Field</name>
	<t>IANA is requested to create a new sub-registry "BPI Object Flag		<t>IANA has created the "BPI Object Flag Field" registry
	Field" within the "Path Computation Element Protocol (PCEP) Numbers".		within the "Path Computation Element Protocol (PCEP) Numbers" registry g
	New values are to be assigned by IETF review <xref target="RFC8126" form		roup.
	at="default"/>.		New values are to be assigned by IETF Review <xref target="RFC8126" form
			at="default"/>.
	Each bit should be tracked with the following qualities:</t>		Each bit should be tracked with the following qualities:</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>bit number (counting from bit 0 as the most significant		<t>bit number (counting from bit 0 as the most significant
	bit)</t>		bit)</t>
	</li>		</li>
	<li>		<li>
	<t>capability description</t>		<t>capability description</t>
	</li>		</li>
	<li>		<li>
	<t>defining RFC</t>		<t>defining RFC</t>
	</li>		</li>
	</ul>		</ul>
	<t>The following values are defined in this document:</t>		<t>The following values are defined in this document:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Bit Meaning Reference		<table>
	0-6 Unassigned		<name>BPI Object Flag Field Registry</name>
	7 T (IPnIP) bit This document		<thead>
	]]></artwork>		<tr>
			<th>Bit</th>
			<th>Meaning</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>0-6</td>
			<td colspan="2">Unassigned</td>
			</tr>
			<tr>
			<td>7</td>
			<td>T (IPnIP) bit</td>
			<td>RFC 9757</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">
	<name>Contributor</name>
	<t>Dhruv Dhody has contributed to this document.</t>
	</section>
	<section numbered="true" toc="default">
	<name>Acknowledgement</name>
	<t>Thanks Mike Koldychev, Susan Hares, Siva Sivabalan and Adam Simpson
	for their valuable suggestions and comments.</t>
	</section>
	</middle>		</middle>
	<back>		<back>
	<displayreference target="I-D.ietf-pce-pcep-yang" to="YANG-PCEP"/>		<displayreference target="I-D.ietf-pce-pcep-yang" to="YANG-PCEP"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 003.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 003.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 271.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 271.xml"/>
	skipping to change at line 1537 ¶		skipping to change at line 1947 ¶
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 420.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 420.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 231.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 231.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 232.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 232.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 253.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 253.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 281.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 281.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 408.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 408.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 050.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 050.xml"/>
	<!-- [rfced] [I-D.ietf-pce-iana-update] IESG state: I-D Exists as of 09/04/24; c		<!--[rfced] *AD - Per the following note left in the document by the authors,
	ompanion document RFC YYY1-->		we have removed the normative reference [I-D.ietf-pce-iana-update]. Please
	<reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcY		review and approve of this update.
	YY1">
	<front>		Original:
	<title>Update to the IANA PCEP Registration Procedures and Allowing E		Editorial Note (To be removed by RFC Editor): This experimental track
	xperimental Error Codes</title>		document is allocating a code point in the registry under the
	<author initials="D." surname="Dhody" fullname="Dhruv Dhody">		standards action registry which is not allowed.
	<organization>Huawei</organization>		[I-D.ietf-pce-iana-update] updates the registration policy to IETF
	</author>		review allowing for this allocation. Note that an early allocation
	<author initials="A." surname="Farrel" fullname="Adrian Farrel">		was made when the document was being progressed in the standards
	<organization>Old Dog Consulting</organization>		track. At the time of publication, please remove this note and the
	</author>		reference to [I-D.ietf-pce-iana-update].
	<date month="August" day="27" year="2024"/>		-->
	</front>
	<seriesInfo name="RFC" value="YYY1"/>
	<seriesInfo name="DOI" value="10.17487/RFCYYY1"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 209.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 209.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 272.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 272.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 036.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 036.xml"/>
			<!-- [rfced] The following reference is not cited in the text. Please let
			us know where it should be cited; otherwise, it will be deleted from the
			references section.
			[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", BCP 205,
			RFC 7942, DOI 10.17487/RFC7942, July 2016,
			<https://www.rfc-editor.org/info/rfc7942>.
			-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 942.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 942.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 177.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 177.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 283.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 283.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 735.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 735.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 821.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 821.xml"/>
	<!-- [rfced] [I-D.ietf-pce-pcep-yang] IESG state: Publication requested as of 09 /04/24 -->		<!-- [I-D.ietf-pce-pcep-yang] IESG state: IESG Evaluation::Revised I-D Needed as of 1/9/25 -->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-pcep-yang.xml"/>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-pcep-yang.xml"/>
	</references>		</references>
	</references>		</references>
			<section numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Thanks to <contact fullname="Mike Koldychev"/>, <contact fullname="Susa
			n
			Hares"/>, <contact fullname="Siva Sivabalan"/>, and <contact
			fullname="Adam Simpson"/> for their valuable suggestions and
			comments.</t>
			</section>
			<section numbered="false" toc="default">
			<name>Contributors</name>
			<t><contact fullname="Dhruv Dhody"/> has contributed to this document.</t>
			</section>
			<!-- [rfced] FYI - We have added expansions for the following abbreviations
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			Path Computation Client (PCC)
			PCEP-specific LSP identifiers (PLSP-ID)
			TCP Authentication Option (TCP-AO)
			-->
			<!-- [rfced] Terminology
			a) Throughout the text, the following terminology appears to be used
			inconsistently. Please review these occurrences and let us know if/how
			they may be made consistent.
			Local/Peer IP Address vs. Local/Peer IP address
			Native IP vs. Native-IP vs. native IP vs. NATIVE IP
			[Note: These differences are also found within the
			IANA registries.]
			Peer IPv4 Address vs. peer IPv4 address
			Peer IPv6 Address vs. peer IPv6 address
			b) May we update the following terms to the form on the right in the
			running text for consistency?
			central controller instructions > Central Controller Instructions (per RFC 9050
			)
			code point > codepoint (per RFC 9050 and to match the companion document)
			Error-type > Error-Type
			Error-Value > Error-value
			Object type, object type > Object-Type
			PCE-Initiated > PCE-initiated (per RFC 8281)
			PCEP Speakers > PCEP speakers
			PCInitiate Message > PCInitiate message
			state synchronization > State Synchronization (per RFCs 8232 and 9050)
			Symbolic Path Name > symbolic path name (per RFC 8232)
			Remote Peer > remote peer (per RFC 8232)
			PCEP Object > PCEP object
			BPI Object > BPI object
			CCI Object > CCI object
			c) We note three instances of "PCEP protocol". Since this reads as
			"Path Computation Element Communication Protocol protocol" when
			expanded, may we remove "protocol" when it occurs after "PCEP"?
			d) FYI: We note "Central Control Dynamic Routing" vs. "Centralized
			Control Dynamic Routing" for the expansion of "CCDR". We have
			updated the text to reflect the latter form per use in RFCs 8735
			and 8821.
			Central Control Dynamic Routing > Centralized Control Dynamic Routing
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			For example, please consider whether the following should be updated:
			- traditional
			- native
			-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 187 change blocks.
	810 lines changed or deleted		1380 lines changed or added
This html diff was produced by rfcdiff 1.48.