rfc9757v1.txt		rfc9757.txt
	Internet Engineering Task Force (IETF) A. Wang		Internet Engineering Task Force (IETF) A. Wang
	Request for Comments: 9757 China Telecom		Request for Comments: 9757 China Telecom
	Category: Experimental B. Khasanov		Category: Experimental B. Khasanov
	ISSN: 2070-1721 MTS Web Services (MWS)		ISSN: 2070-1721 MTS Web Services (MWS)
	S. Fang		S. Fang
	R. Tan
	Huawei Technologies		Huawei Technologies
	C. Zhu		C. Zhu
	ZTE Corporation		ZTE Corporation
	February 2025		March 2025
	Path Computation Element Communication Protocol (PCEP) Extensions for		Path Computation Element Communication Protocol (PCEP) Extensions for
	Native IP Networks		Native IP Networks
	Abstract		Abstract
	This document introduces extensions to the Path Computation Element		This document introduces extensions to the Path Computation Element
	Communication Protocol (PCEP) to support path computation in native		Communication Protocol (PCEP) to support path computation in Native
	IP networks through a PCE-based central control mechanism known as		IP networks through a PCE-based central control mechanism known as
	Centralized Control Dynamic Routing (CCDR). These extensions empower		Centralized Control Dynamic Routing (CCDR). These extensions empower
	a PCE to calculate and manage paths specifically for native IP		a PCE to calculate and manage paths specifically for Native IP
	networks, expand PCEP's capabilities beyond its traditional use in		networks, thereby expanding PCEP's capabilities beyond its past use
	MPLS and GMPLS networks. By implementing these extensions, IP		in MPLS and GMPLS networks. By implementing these extensions, IP
	network resources can be utilized more efficiently, facilitating the		network resources can be utilized more efficiently, facilitating the
	deployment of traffic engineering in native IP environments.		deployment of traffic engineering in Native IP environments.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for examination, experimental implementation, and		published for examination, experimental implementation, and
	evaluation.		evaluation.
	This document defines an Experimental Protocol for the Internet		This document defines an Experimental Protocol for the Internet
	community. This document is a product of the Internet Engineering		community. This document is a product of the Internet Engineering
	Task Force (IETF). It represents the consensus of the IETF		Task Force (IETF). It represents the consensus of the IETF
	skipping to change at line 119 ¶		skipping to change at line 118 ¶
	Acknowledgements		Acknowledgements
	Contributors		Contributors
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-		Generally, Multiprotocol Label Switching Traffic Engineering (MPLS-
	TE) requires the corresponding network devices to support the		TE) requires the corresponding network devices to support the
	Resource ReSerVation Protocol (RSVP) [RFC3209] and the Label		Resource ReSerVation Protocol (RSVP) [RFC3209] and the Label
	Distribution Protocol (LDP) [RFC5036] to ensure End-to-End (E2E)		Distribution Protocol (LDP) [RFC5036] to ensure End-to-End (E2E)
	traffic performance. But in native IP network scenarios described in		traffic performance. But in Native IP network scenarios described in
	[RFC8735], there will be no such signaling protocol to synchronize		[RFC8735], there will be no such signaling protocol to synchronize
	the actions among different network devices. It is feasible to use		the actions among different network devices. It is feasible to use
	the central control mode described in [RFC8283] to correlate the		the central control mode described in [RFC8283] to correlate the
	forwarding behavior among different network devices. [RFC8821]		forwarding behavior among different network devices. [RFC8821]
	describes the architecture and solution philosophy for the E2E		describes the architecture and solution philosophy for the E2E
	traffic assurance in the Native IP network via multiple Border		traffic assurance in the Native IP network via a solution based on
	Gateway Protocol (BGP) sessions-based solution. It requires only the		multiple Border Gateway Protocol (BGP) sessions. It requires only
	PCE to send the instructions to the Path Computation Clients (PCCs)		the PCE to send the instructions to the Path Computation Clients
	to build multiple BGP sessions, distribute different prefixes on the		(PCCs) to build multiple BGP sessions, distribute different prefixes
	established BGP sessions, and assign the different paths to the BGP		on the established BGP sessions, and assign the different paths to
	next hops.		the BGP next hops.
	This document describes the corresponding Path Computation Element		This document describes the corresponding Path Computation Element
	Communication Protocol (PCEP) extensions to transfer the key		Communication Protocol (PCEP) extensions to transfer the key
	information about the BGP peer, peer prefix advertisement, and		information about the BGP peer, peer prefix advertisement, and
	explicit peer route on on-path routers.		explicit peer route on on-path routers.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at line 199 ¶		skipping to change at line 198 ¶
	PST: Path Setup Type (defined in [RFC8408])		PST: Path Setup Type (defined in [RFC8408])
	SRP: Stateful PCE Request Parameter (defined in [RFC8231])		SRP: Stateful PCE Request Parameter (defined in [RFC8231])
	RR: Route Reflector		RR: Route Reflector
	4. Capability Advertisement		4. Capability Advertisement
	4.1. Open Message		4.1. Open Message
	During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)		During the PCEP Initialization Phase, PCEP speakers (PCE or PCC)
	advertise their support of Native IP extensions.		advertise their support of Native IP extensions.
	This document defines a new Path Setup Type (PST) [RFC8408] for		This document defines a new Path Setup Type (PST) [RFC8408] for
	Native-IP, as follows:		Native IP, as follows:
	* PST = 4: Path is a Native IP TE path as per [RFC8821].		* PST = 4: Path is a Native IP TE path as per [RFC8821].
	A PCEP speaker MUST indicate its support of the function described in		A PCEP speaker MUST indicate its support of the function described in
	this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN		this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
	object with this new PST included in the PST list.		object with this new PST included in the PST list.
	[RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange		[RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange
	information about their PCECC capability. A new flag is defined in		information about the PCEP speakers' PCECC capability. A new flag is
	the PCECC-CAPABILITY sub-TLV for Native IP:		defined in the PCECC-CAPABILITY sub-TLV for Native IP:
	N (NATIVE-IP-TE-CAPABILITY - 1 bit - 30): When set to 1 by a PCEP		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		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		in a Native IP network, as specified in this document. Both the PCC
	and PCE MUST set this flag to support this extension.		and PCE MUST set this flag to support this extension.
	If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with		If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
	the newly defined PST, but without the N bit set in PCECC-CAPABILITY		the newly defined PST, but without the N bit set in PCECC-CAPABILITY
	sub-TLV, it MUST:		sub-TLV, it MUST:
	* send a PCErr message with Error-Type=10 (Reception of an invalid		* send a PCErr message with Error-Type=10 (Reception of an invalid
	object) and Error-Value=39 (PCECC NATIVE-IP-TE-CAPABILITY bit is		object) and Error-value=39 (PCECC NATIVE-IP-TE-CAPABILITY bit is
	not set) and		not set) and
	* terminate the PCEP session.		* terminate the PCEP session.
	If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with		If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
	the newly defined PST, but without the PCECC-CAPABILITY sub-TLV, it		the newly defined PST, but without the PCECC-CAPABILITY sub-TLV, it
	MUST:		MUST:
	* send a PCErr message with Error-Type=10 (Reception of an invalid		* send a PCErr message with Error-Type=10 (Reception of an invalid
	object) and Error-Value=33 (Missing PCECC Capability sub-TLV) and		object) and Error-value=33 (Missing PCECC Capability sub-TLV) and
	* terminate the PCEP session.		* terminate the PCEP session.
	If one or both speakers (PCE and PCC) have not indicated the support		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 be		for Native IP, the PCEP extensions for the Native IP MUST NOT be
	used. If a Native-IP operation is attempted when both speakers have		used. If a Native IP operation is attempted when both speakers have
	not agreed on the OPEN messages, the receiver of the message MUST:		not agreed on the OPEN messages, the receiver of the message MUST:
	* send a PCErr message with Error-Type=19 (Invalid Operation) and		* send a PCErr message with Error-Type=19 (Invalid Operation) and
	Error-value=29 (Attempted Native-IP operations when the capability		Error-value=29 (Attempted Native IP operations when the capability
	was not advertised) and		was not advertised) and
	* terminate the PCEP session.		* terminate the PCEP session.
	5. PCEP Messages		5. PCEP Messages
	The PCECC Native IP TE solution uses the existing PCE Label Switched		The PCECC Native IP TE solution uses the existing PCE Label Switched
	Path (LSP) Initiate Request message (PCInitiate) [RFC8281], and PCE		Path (LSP) Initiate Request message (PCInitiate) [RFC8281] and PCE
	Report message (PCRpt) [RFC8231] to accomplish the multiple BGP		Report message (PCRpt) [RFC8231] to establish multiple BGP sessions,
	sessions establishment, E2E Native-IP TE path deployment, and route		deploy the E2E Native IP TE path, and advertise route prefixes among
	prefixes advertisement among different BGP sessions. A new PST for		different BGP sessions. A new PST for Native IP is used to indicate
	Native-IP is used to indicate the path setup based on TE in Native IP		the path setup based on TE in Native IP networks.
	networks.
	The extended PCInitiate message described in [RFC9050] is used to		The extended PCInitiate message described in [RFC9050] is used to
	download or remove the Central Controller Instructions (CCI).		download or remove the Central Controller Instructions (CCI).
	[RFC9050] specifies an object called CCI for the encoding of the		[RFC9050] specifies an object called CCI for the encoding of the
	central controller's instructions. This document specifies a new CCI		central controller's instructions. This document specifies a new CCI
	Object-Type for Native IP. The PCEP messages are extended in this		Object-Type for Native IP. The PCEP messages are extended in this
	document to handle the PCECC operations for Native IP. Three new		document to handle the PCECC operations for Native IP. Three new
	PCEP Objects (BGP Peer Info (BPI), Explicit Peer Route (EPR), and		PCEP objects (BGP Peer Info (BPI), Explicit Peer Route (EPR), and
	Peer Prefix Advertisement (PPA)) are defined in this document. Refer		Peer Prefix Advertisement (PPA)) are defined in this document. Refer
	to Section 7 for detailed object definitions. All PCEP procedures		to Section 7 for detailed object definitions. All PCEP procedures
	specified in [RFC9050] continue to apply unless specified otherwise.		specified in [RFC9050] continue to apply unless specified otherwise.
	5.1. The PCInitiate Message		5.1. The PCInitiate Message
	The PCInitiate Message defined in [RFC8281] and extended in [RFC9050]		The PCInitiate message defined in [RFC8281] and extended in [RFC9050]
	is further extended to support Native-IP CCI.		is further extended to support Native IP CCI.
	The format of the extended PCInitiate message is as follows:		The format of the extended PCInitiate message is as follows:
	<PCInitiate Message> ::= <Common Header>		<PCInitiate Message> ::= <Common Header>
	<PCE-initiated-lsp-list>		<PCE-initiated-lsp-list>
	Where:		Where:
	<Common Header> is defined in RFC 5440		<Common Header> is defined in RFC 5440
	skipping to change at line 316 ¶		skipping to change at line 314 ¶
	* The LSP and SRP objects are defined in [RFC8231].		* The LSP and SRP objects are defined in [RFC8231].
	When the PCInitiate message is used for Native IP instructions, i.e.,		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 be		when the CCI Object-Type is 2, the SRP, LSP, and CCI objects MUST be
	present. Error handling for missing SRP, LSP, or CCI objects MUST be		present. Error handling for missing SRP, LSP, or CCI objects MUST be
	performed as specified in [RFC9050]. Additionally, exactly one		performed as specified in [RFC9050]. Additionally, exactly one
	object among the BPI, EPR, or PPA objects MUST be present. The PCEP-		object among the BPI, EPR, or PPA objects MUST be present. The PCEP-
	specific LSP identifier (PLSP-ID) and Symbolic Path Name TLVs are set		specific LSP identifier (PLSP-ID) and Symbolic Path Name TLVs are set
	as per the existing rules in [RFC8231], [RFC8281], and [RFC9050].		as per the existing rules in [RFC8231], [RFC8281], and [RFC9050].
	The Symbolic Path Name is used by the PCE/PCC to uniquely identify		The Symbolic Path Name is used by the PCE/PCC to uniquely identify
	the E2E native IP TE path. The related Native-IP instructions with		the E2E Native IP TE path. The related Native IP instructions with
	BPI, EPR, or PPA objects are identified by the same Symbolic Path		BPI, EPR, or PPA objects are identified by the same Symbolic Path
	Name.		Name.
	If none of the BPI, EPR, or PPA objects are present, the receiving		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 MUST send a PCErr message with Error-Type=6 (Mandatory Object
	missing) and Error-value=19 (Native IP object missing). If there is		missing) and Error-value=19 (Native IP object missing). If there is
	more than one instance of BPI, EPR, or PPA object present, the		more than one BPI, EPR, or PPA object present, the receiving PCC MUST
	receiving PCC MUST send a PCErr message with Error-type=19 (Invalid		send a PCErr message with Error-Type=19 (Invalid Operation) and
	Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can		Error-value=22 (Only one BPI, EPR, or PPA object can be included in
	be included in this message).		this message).
	When the PCInitiate message is not used for Native IP instructions,		When the PCInitiate message is not used for Native IP instructions,
	i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and		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		PPA objects SHOULD NOT be present. If present, they MUST be ignored
	by the receiver.		by the receiver.
	To clean up the existing Native IP instructions, the SRP object MUST		To clean up the existing Native IP instructions, the SRP object MUST
	set the R (remove) bit.		set the R (remove) bit.
	5.2. The PCRpt Message		5.2. The PCRpt Message
	The PCRpt message is used to acknowledge the Native-IP instructions		The PCRpt message is used to acknowledge the Native IP instructions
	received from the central controller (PCE) as well as during the		received from the central controller (PCE) as well as during the
	State Synchronization phase.		State Synchronization phase.
	The format of the PCRpt message is as follows:		The format of the PCRpt message is as follows:
	<PCRpt Message> ::= <Common Header>		<PCRpt Message> ::= <Common Header>
	<state-report-list>		<state-report-list>
	Where:		Where:
	skipping to change at line 373 ¶		skipping to change at line 371 ¶
	[<BPI>|<EPR>|<PPA>]		[<BPI>|<EPR>|<PPA>]
	[<cci-list>]		[<cci-list>]
	Where:		Where:
	* <path> is as per [RFC8231].		* <path> is as per [RFC8231].
	* The LSP and SRP objects are also defined in [RFC8231].		* The LSP and SRP objects are also defined in [RFC8231].
	The error handling for missing CCI objects is as per [RFC9050].		The error handling for missing CCI objects is as per [RFC9050].
	Furthermore, one, and only one, object among BPI, EPR or PPA object		Furthermore, one and only one BPI, EPR, or PPA object MUST be
	MUST be present.		present.
	If none of the BPI, EPR, or PPA objects are present, the receiving		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 MUST send a PCErr message with Error-Type=6 (Mandatory Object
	missing) and Error-value=19 (Native IP object missing). If there are		missing) and Error-value=19 (Native IP object missing). If there is
	more than one instance of BPI, EPR or PPA objects present, the		more than one BPI, EPR, or PPA object present, the receiving PCE MUST
	receiving PCE MUST send a PCErr message with Error-type=19 (Invalid		send a PCErr message with Error-Type=19 (Invalid Operation) and
	Operation) and Error-value=22 (Only one BPI, EPR, or PPA object can		Error-value=22 (Only one BPI, EPR, or PPA object can be included in
	be included in this message).		this message).
	When the PCInitiate message is not used for Native IP instructions,		When the PCInitiate message is not used for Native IP instructions,
	i.e., when the CCI Object-Type is not equal to 2, the BPI, EPR, and		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		PPA objects SHOULD NOT be present. If present, they MUST be ignored
	by the receiver.		by the receiver.
	6. PCECC Native IP TE Procedures		6. PCECC Native IP TE Procedures
	The detailed procedures for the TE in the native IP environment are		The detailed procedures for the TE in the Native IP environment are
	described in the following sections.		described in the following sections.
	6.1. BGP Session Establishment Procedures		6.1. BGP Session Establishment Procedures
	The PCInitiate and PCRpt message pair is used to exchange the		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 the		messages are exchanged between a PCE and each BGP peer (acting as the
	PCC), which needs to establish a BGP session. After the BGP peer		PCC), which needs to establish a BGP session. After the BGP peer
	session has been initiated via this pair of PCEP messages, the BGP		session has been initiated via this pair of PCEP messages, the BGP
	session establishes and operates in a normal fashion. The BGP peers		session establishes and operates in a normal fashion. The BGP peers
	skipping to change at line 422 ¶		skipping to change at line 420 ¶
	is sent to the BGP routers R1, R3, and R7, which need to establish a		is sent to the BGP routers R1, R3, and R7, which need to establish a
	BGP session.		BGP session.
	PCInitiate message creates an autoconfiguration function for these		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.		Address.
	When the PCC receives the BPI and CCI objects (with the R bit set to		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 SHOULD try to
	establish the BGP session with the indicated Peer as per the AS and		establish the BGP session with the indicated Peer as per the AS and
	Local/Peer IP address.		Local/Peer IP Address.
	During the establishment procedure, the PCC MUST report the status of		During the establishment procedure, the PCC MUST report the status of
	the BGP session to the PCE via the PCRpt message, with the status		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.		corresponding SRP and CCI objects included.
	When the PCC receives this message with the R bit set to 1 in the SRP		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		object in the PCInitiate message, the PCC MUST 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.		BPI object.
	skipping to change at line 494 ¶		skipping to change at line 492 ¶
	| | 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		Figure 2: Message Information and Procedures
	The Local/Peer IP address MUST be dedicated to the usage of the		The Local/Peer IP Address MUST be dedicated to the usage of the
	native IP TE solution and MUST NOT be used by other BGP sessions that		Native IP TE solution and MUST NOT be used by other BGP sessions that
	are established manually or in other ways. If the Local IP Address		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		or 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		BGP sessions, the PCC MUST report such an error situation via a PCErr
	message with:		message with:
	* Error-type=33 (Native IP TE failure) and Error-value=1 (Local IP		* Error-Type=33 (Native IP TE failure) and Error-value=1 (Local IP
	is in use) or		is in use) or
	* Error-type=33 (Native IP TE failure) and Error-value=2 (Remote IP		* Error-Type=33 (Native IP TE failure) and Error-value=2 (Remote IP
	is in use).		is in use).
	The detailed Error-Types and Error-Values are defined in Section 8.		The detailed Error-Types and Error-values are defined in Section 8.
	If the established BGP session is broken, the PCC MUST report such		If the established BGP session is broken, the PCC MUST report such
	information via a 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		within the BPI object SHOULD indicate the reason that leads to the
	BGP session being down. In the future, when the BGP session is up		BGP 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		again, the PCC MUST report that as well via the PCRpt message with
	the status field set to "BGP Session Established".		the status field set to "BGP Session Established".
	6.2. Explicit Route Establishment Procedures		6.2. Explicit Route Establishment Procedures
	The explicit route establishment procedures can be used by a PCE to		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		pair. Such explicit routes operate the same as static routes
	skipping to change at line 661 ¶		skipping to change at line 659 ¶
	the EPR object MUST be sent to the PCCs in the reverse order of the		the EPR object MUST be sent to the PCCs in the reverse order of the
	E2E path. To remove the explicit peer route, the EPR object MUST be		E2E path. To remove the explicit peer route, the EPR object MUST be
	sent to the PCCs in the same order as the E2E path.		sent to the PCCs in the same order as the E2E path.
	To accomplish ECMP effects, the PCE can send multiple EPR/CCI objects		To accomplish ECMP effects, the PCE can send multiple EPR/CCI objects
	to the same node, with the same route priority and peer address value		to the same node, with the same route priority and peer address value
	but a different next-hop address.		but a different next-hop address.
	The PCC MUST verify that the next-hop address is reachable. In case		The PCC MUST verify that the next-hop address is reachable. In case
	of failure, the PCC MUST send the corresponding error via a PCErr		of failure, the PCC MUST 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) and Error-value=3 (Explicit Peer Route Error).		failure) and Error-value=3 (Explicit Peer Route Error).
	When the peer info is not the same as the peer info that is indicated		When the peer info is not the same as the peer info that is indicated
	in the BPI object in the PCC for the same path that is identified by		in the BPI object in the PCC for the same path that is identified by
	Symbolic Path Name TLV, a PCErr message MUST be reported, with the		Symbolic Path Name TLV, a PCErr message MUST be reported, with the
	error information Error-type=33 (Native IP TE failure) and Error-		error information Error-Type=33 (Native IP TE failure) and Error-
	value=4 (EPR/BPI Peer Info mismatch). Note that the same error can		value=4 (EPR/BPI Peer Info mismatch). Note that the same error can
	be used in case no BPI is received at the PCC.		be used in case no BPI is received at the PCC.
	If the PCE needs to update the path, it MUST first instruct the new		If the PCE needs to update the path, it MUST first instruct the new
	CCI with the updated EPR corresponding to the new next hop to use and		CCI with the updated EPR corresponding to the new next hop to use and
	then instruct the removal of the older CCI.		then instruct the removal of the older CCI.
	6.3. BGP Prefix Advertisement Procedures		6.3. BGP Prefix Advertisement Procedures
	The detailed procedures for BGP prefix advertisement are shown below,		The detailed procedures for BGP prefix advertisement are shown below,
	skipping to change at line 748 ¶		skipping to change at line 746 ¶
	| PPA Object(Peer IP=R1_A, Prefix=7_A) |		| PPA Object(Peer IP=R1_A, Prefix=7_A) |
	|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|		|----PCRpt,CC-ID=Z,Symbolic Path Name=Class A-------->|
	| PPA Object(Peer IP=R1_A, Prefix=7_A) |		| PPA Object(Peer IP=R1_A, Prefix=7_A) |
	| |		| |
	Figure 8: Message Information and Procedures		Figure 8: Message Information and Procedures
	The AFI/SAFI for the corresponding BGP session SHOULD match the Peer		The AFI/SAFI for the corresponding BGP session SHOULD match the Peer
	Prefix Advertisement Object-Type, i.e., AFI/SAFI SHOULD be 1/1 for		Prefix Advertisement Object-Type, i.e., AFI/SAFI SHOULD be 1/1 for
	the IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an		the IPv4 prefix and 2/1 for the IPv6 prefix. In case of mismatch, an
	error, i.e., Error-type=33 (Native IP TE failure) and Error-value=5		error, i.e., Error-Type=33 (Native IP TE failure) and Error-value=5
	(BPI/PPA Address Family mismatch), MUST be reported via the PCErr		(BPI/PPA Address Family mismatch), MUST be reported via the PCErr
	message.		message.
	When the peer info is not the same as the peer info that is indicated		When the peer info is not the same as the peer info that is indicated
	in the BPI object in the PCC for the same path that is identified by		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 (Native IP TE		Symbolic Path Name TLV, an error, i.e., Error-Type=33 (Native IP TE
	failure) and Error-value=6 (PPA/BPI Peer Info mismatch), MUST be		failure) and Error-value=6 (PPA/BPI Peer Info mismatch), MUST 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.		in case no BPI is received at the PCC.
	6.4. Selection of the Raw Mode and Tunnel Mode Forwarding Strategy		6.4. Selection of the Raw Mode and Tunnel Mode Forwarding Strategy
	Normally, when the above procedures are finished, the user traffic		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. If traffic is
	from different attached points to the same destination coming into		coming into the network from different attached points but to the
	the network, they could share the priority path, which may not be the		same destination, they could share the priority path, which may not
	initial desire. For example, as illustrated in Figure 1, the initial		be the initial desire. For example, as illustrated in Figure 1, the
	aim is to ensure that traffic enters the network via R1 and exits the		initial aim is to ensure that traffic enters the network via R1 and
	network at R7 via R5-R6-R7. If some traffic enters the network via		exits the network at R7 via R5-R6-R7. If some traffic enters the
	the R2 router, passes through R5, and exits at R7, they may share the		network via the R2 router, passes through R5, and exits at R7, they
	priority path among R5-R6-R7, which may not be the desired effect.		may share the priority path among R5-R6-R7, which may not be the
			desired effect.
	The above normal traffic forwarding behavior is clarified as a Raw		The above normal traffic forwarding behavior is clarified as a Raw
	mode forwarding strategy. Such a mode can only achieve 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 MUST tunnel the user traffic 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 Section 6.1. Such		also between the BGP peer established via Section 6.1. Such
	forwarding behavior is called the Tunnel mode forwarding strategy.		forwarding behavior is called the Tunnel mode forwarding strategy.
	For simplicity, the IPinIP tunnel type [RFC2003] is used between the		For simplicity, the IP-in-IP tunnel type [RFC2003] is used between
	BGP peers by default.		the BGP peers by default.
	The selection of Raw mode and Tunnel mode forwarding strategies are		The selection of Raw mode and Tunnel mode forwarding strategies are
	controlled via the T bit in the BPI Object, which is defined in		controlled via the T bit in the BPI object, which is defined in
	Section 7.2		Section 7.2
	6.5. Cleanup		6.5. Cleanup
	To remove the Native-IP state from the PCC, the PCE MUST send		To remove the Native IP state from the PCC, the PCE MUST send
	explicit CCI cleanup instructions for PPA, EPR, and BPI objects,		explicit CCI cleanup instructions for PPA, EPR, and BPI objects,
	respectively, with the R flag set in the SRP object. If the PCC		respectively, with the R bit 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 MUST generate a PCErr message with
	Error-Type=19 (Invalid Operation) and Error-value=30 (Unknown Native-		Error-Type=19 (Invalid Operation) and Error-value=30 (Unknown Native
	IP Info) and MUST include the SRP object to specify the error is for		IP Info) and MUST include the SRP object to specify the error is for
	the corresponding cleanup (via a PCInitiate message).		the corresponding cleanup (via a PCInitiate message).
	6.6. Other Procedures		6.6. Other Procedures
	The handling of the state synchronization, redundant PCEs,		The handling of the State Synchronization, redundant PCEs,
	redelegation, and cleanup is the same as other CCIs as specified in		redelegation, and cleanup is the same as other CCIs as specified in
	[RFC9050].		[RFC9050].
	7. New PCEP Objects		7. New PCEP Objects
	One new CCI Object type and three new PCEP objects are defined in		One new CCI Object-Type and three new PCEP objects are defined in
	this document. All new PCEP objects are as per [RFC5440].		this document. All new PCEP objects are as per [RFC5440].
	7.1. CCI Object		7.1. CCI Object
	The Central Control Instructions (CCI) Object (defined in [RFC9050])		The Central Control Instructions (CCI) Object (defined in [RFC9050])
	is used by the PCE to specify the forwarding instructions. This		is used by the PCE to specify the forwarding instructions. This
	document defines another object type for Native-IP procedures.		document defines another Object-Type for Native IP procedures.
	The CCI Object-Type is 2 for Native-IP, as follows:		The CCI Object-Type is 2 for Native IP, as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CC-ID |		| CC-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |		| Reserved | Flags |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| |		| |
	// Optional TLVs //		// Optional TLVs //
	skipping to change at line 837 ¶		skipping to change at line 836 ¶
	Figure 9: CCI Object for Native IP		Figure 9: CCI Object for Native IP
	The CC-ID field is as described in [RFC9050]. The following fields		The CC-ID field is as described in [RFC9050]. The following fields
	are defined for CCI Object-Type 2.		are defined for CCI Object-Type 2.
	Reserved: 2 bytes. Set to zero while sending and ignored on		Reserved: 2 bytes. Set to zero while sending and ignored on
	receipt.		receipt.
	Flags: 2 bytes. Used to carry any additional information about the		Flags: 2 bytes. Used to carry any additional information about the
	Native-IP CCI. Currently, no flag bits are defined. Unassigned		Native IP CCI. Currently, no flag bits are defined. Unassigned
	flags are set to zero while sending and ignored on receipt.		flags are set to zero while sending and ignored on receipt.
	Optional TLVs may be included within the CCI object body. The		Optional TLVs may be included within the CCI object body. The
	Symbolic Path Name TLV [RFC8231] MUST be included in the CCI Object-		Symbolic Path Name TLV [RFC8231] MUST be included in the CCI Object-
	Type 2 to identify the E2E TE path in the Native IP environment.		Type 2 to identify the E2E TE path in the Native IP environment.
	7.2. BGP Peer Info Object		7.2. BGP Peer Info Object
	The BGP Peer Info (BPI) object is used to specify the information		The BGP Peer Info (BPI) object is used to specify the information
	about the peer with which the PCC wants to establish the BGP session.		about the peer with which the PCC wants to establish the BGP session.
	This object is included and sent to the source and destination router		This object is included and sent to the source and destination router
	of the E2E path in case there is no Route Reflection (RR) involved.		of the E2E path in case there is no Route Reflection (RR) involved.
	If the RR is used between the source and destination routers, then		If the RR is used between the source and destination routers, then
	such information is sent to the source router, RR, and destination		such information is sent to the source router, RR, and destination
	router, respectively.		router, respectively.
	By default, the Local/Peer IP address MUST be a unicast address and		By default, the Local/Peer IP Address MUST be a unicast address and
	dedicated to the usage of the native IP TE solution and MUST NOT be		dedicated to the usage of the Native IP TE solution and MUST NOT 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.		configuration mechanisms.
	The BGP Peer Info Object-Class is 46.		The BGP Peer Info Object-Class is 46.
	The BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6.		The BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6.
	The format of the BGP Peer Info object body for IPv4 (Object-Type=1)		The format of the BGP Peer Info object body for IPv4 (Object-Type=1)
	is as follows:		is as follows:
	skipping to change at line 943 ¶		skipping to change at line 942 ¶
	1: ASes do not match, BGP Session Failure		1: ASes do not match, BGP Session Failure
	2: Peer IP can't be reached, BGP Session Failure		2: Peer IP can't be reached, BGP Session Failure
	3-255: Reserved		3-255: Reserved
	Flag: 1 byte.		Flag: 1 byte.
	Currently, only bit 7 (T bit) is defined. When the T bit is set,		Currently, only bit 7 (T bit) is defined. When the T bit is set,
	the traffic SHOULD be sent in the IPinIP tunnel (the tunnel source		the traffic SHOULD be sent in the IP-in-IP tunnel (the tunnel
	is the Local IP Address, and the tunnel destination is the Peer IP		source is the Local IP Address, and the tunnel destination is the
	Address). When the T bit is cleared, the traffic is sent via its		Peer IP Address). When the T bit is cleared, the traffic is sent
	original source and destination address. The Tunnel mode (i.e.,		via its original source and destination address. The Tunnel mode
	the T bit is set) is used when the operator wants to ensure only		(i.e., the T bit is set) is used when the operator wants to ensure
	the traffic from the specified (entry, exit) pair, and the Raw		only the traffic from the specified (entry, exit) pair, and the
	mode (i.e., the T bit is clear) is used when the operator wants to		Raw mode (i.e., the T bit is clear) is used when the operator
	ensure traffic from any entry to the specified destination.		wants to ensure traffic from any entry to the specified
	Unassigned flags are set to zero while sending and ignored on		destination. Unassigned flags are set to zero while sending and
	receipt.		ignored on receipt.
	Local IP Address(4/16 bytes): Unicast IP address of the local		Local IP Address(4/16 bytes): Unicast IP address of the local
	router, used to peer with another end router. When the Object-		router, used to peer with another end router. When the Object-
	Type is 1, the length is 4 bytes; when the Object-Type is 2, the		Type is 1, the length is 4 bytes; when the Object-Type is 2, the
	length is 16 bytes.		length is 16 bytes.
	Peer IP Address(4/16 bytes): Unicast IP address of the peer router,		Peer IP Address(4/16 bytes): Unicast IP address of the peer router,
	used to peer with the local router. When the Object-Type is 1,		used to peer with the local router. When the Object-Type is 1,
	the length is 4 bytes; when the Object-Type is 2, the length is 16		the length is 4 bytes; when the Object-Type is 2, the length is 16
	bytes.		bytes.
	skipping to change at line 978 ¶		skipping to change at line 977 ¶
	When the PCC receives a BPI object, with Object-Type=1, it SHOULD try		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.		to establish a BGP session with the peer in AFI/SAFI=1/1.
	When the PCC receives a BPI object, with Object-Type=2, it SHOULD try		When the PCC receives a BPI object, with Object-Type=2, it SHOULD try
	to establish a BGP session with the peer in AFI/SAFI=2/1.		to establish a BGP session with the peer in AFI/SAFI=2/1.
	7.3. Explicit Peer Route Object		7.3. Explicit Peer Route Object
	The Explicit Peer Route (EPR) object is defined to specify the		The Explicit Peer Route (EPR) object is defined to specify the
	explicit peer route to the corresponding peer address on each device		explicit 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		that is on the E2E Native IP TE path. This Object ought to be sent
	to all the devices on the path that are calculated by the PCE.		to all the devices on the path that are calculated by the PCE.
	Although the object is named "Explicit Peer Route", it can be seen		Although the object is named "Explicit Peer Route", it can be seen
	that the routes it installs are simply host routes. The use of this		that the routes it installs are simply host routes. The use of this
	object to install host routes for any purpose other than reaching the		object to install host routes for any purpose other than reaching the
	corresponding peer address on each device that is on the E2E Native-		corresponding peer address on each device that is on the E2E Native
	IP TE path is outside the scope of this specification.		IP TE path is outside the scope of this specification.
	By default, the path established by this object MUST have higher		By default, the path established by this object MUST have higher
	priority than the other paths calculated by the dynamic IGP protocol		priority than the other paths calculated by the dynamic IGP protocol
	and MUST have lower priority than the static route configured by		and MUST have lower priority than the static route configured by
	manual, NETCONF, or any other static means.		manual, NETCONF, or any other static means.
	The Explicit Peer Route Object-Class is 47.		The Explicit Peer Route Object-Class is 47.
	The Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6.		The Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6.
	skipping to change at line 1142 ¶		skipping to change at line 1141 ¶
	Reserved: 3 bytes. Ought to be set to zero while sending and		Reserved: 3 bytes. Ought to be set to zero while sending and
	ignored on receipt.		ignored on receipt.
	Prefix Len: 1 byte. Identifies the length of the prefix.		Prefix Len: 1 byte. Identifies the length of the prefix.
	Optional TLVs: TLVs that are associated with this object; can be		Optional TLVs: TLVs that are associated with this object; can be
	used to convey other necessary information for prefix		used to convey other necessary information for prefix
	advertisement. No TLVs are currently defined.		advertisement. No TLVs are currently defined.
	For IPv4:		For IPv4:
	Peer IPv4 Address: 4 bytes. Identifies the peer IPv4 address		Peer IPv4 Address: 4 bytes. Identifies the Peer IPv4 Address
	that the associated prefixes will be sent to.		that the associated prefixes will be sent to.
	IPv4 Prefix: 4 bytes. Identifies the prefix that will be sent to		IPv4 Prefix: 4 bytes. Identifies the prefix that will be sent to
	the peer identified by the Peer IPv4 Address.		the peer identified by the Peer IPv4 Address.
	For IPv6:		For IPv6:
	Peer IPv6 Address: 16 bytes. Identifies the peer IPv6 address		Peer IPv6 Address: 16 bytes. Identifies the Peer IPv6 Address
	that the associated prefixes will be sent to.		that the associated prefixes will be sent to.
	IPv6 Prefix: Identifies the prefix that will be sent to the peer		IPv6 Prefix: Identifies the prefix that will be sent to the peer
	identified by the Peer IPv6 Address.		identified by the Peer IPv6 Address.
	If in the future a requirement is identified to advertise IPv4		If in the future a requirement is identified to advertise IPv4
	prefixes towards an IPv6 peering address or IPv6 prefixes towards an		prefixes towards an IPv6 peering address or IPv6 prefixes towards an
	IPv4 peering address, then a new Peer Prefix Advertisement Object-		IPv4 peering address, then a new Peer Prefix Advertisement Object-
	Type can be defined for these purposes.		Type can be defined for these purposes.
	8. New Error-Type and Error-Values Defined		8. New Error-Type and Error-Values Defined
	A PCEP-ERROR object is used to report a PCEP error and is		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		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		An additional Error-Type and several Error-values are defined to
	represent the errors related to the newly defined objects that are		represent the errors related to the newly defined objects that are
	related to Native IP TE procedures.		related to Native IP TE procedures. See Table 4 for the newly
			defined Error-Type and Error-values.
	+============+=================+===============================+
	| Error-Type | Meaning | Error-value |
	+============+=================+===============================+
	| 6 | Mandatory | 19: Native IP object missing |
	| | Object missing | |
	+------------+-----------------+-------------------------------+
	| 10 | Reception of an | 39: PCECC NATIVE-IP-TE- |
	| | invalid object | CAPABILITY bit is not set |
	+------------+-----------------+-------------------------------+
	| 19 | Invalid | 22: Only one BPI, EPR, or PPA |
	| | Operation | object can be included in |
	| | | this message |
	| | +-------------------------------+
	| | | 29: Attempted Native-IP |
	| | | operations when the |
	| | | capability was not advertised |
	| | +-------------------------------+
	| | | 30: Unknown Native-IP Info |
	+------------+-----------------+-------------------------------+
	| 33 | Native IP TE | 1: Local IP is in use |
	| | failure | |
	| | +-------------------------------+
	| | | 2: Remote IP is in use |
	| | +-------------------------------+
	| | | 3: Explicit Peer Route Error |
	| | +-------------------------------+
	| | | 4: EPR/BPI Peer Info mismatch |
	| | +-------------------------------+
	| | | 5: BPI/PPA Address Family |
	| | | mismatch |
	| | +-------------------------------+
	| | | 6: PPA/BPI Peer Info mismatch |
	+------------+-----------------+-------------------------------+
	Table 1: Newly Defined Error-Type and Error-Values
	9. BGP Considerations		9. BGP Considerations
	This document defines procedures and objects to create the BGP		This document defines procedures and objects to create the BGP
	sessions and to advertise the associated prefixes dynamically. Only		sessions and to advertise the associated prefixes dynamically. Only
	the key information, for example, peer IP addresses, and Peer AS		the key information, for example, Peer IP Addresses, and Peer AS
	numbers are exchanged via the PCEP protocol. Other parameters that		numbers are exchanged via the PCEP. Other parameters that are needed
	are needed for the BGP session setup SHOULD be derived from their		for the BGP session setup SHOULD be derived from their default
	default values.		values.
	When the PCE sends out the PCInitiate message with the BPI object		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		SHOULD report the BGP session status. For instance, the PCC could
	respond with "BGP Session Establishment In Progress" initially and,		respond with "BGP Session Establishment In Progress" initially and,
	on session establishment, send another PCRpt message with the state		on session establishment, send another PCRpt message with the state
	updated to "BGP Session Established". If there is any error during		updated to "BGP Session Established". If there is any error during
	the BGP session establishment, the PCC SHOULD indicate the reason		the BGP session establishment, the PCC SHOULD indicate the reason
	with the appropriate status value set in the BPI object.		with the appropriate status value set in the BPI object.
	Upon receiving such key information, the BGP module on the PCC SHOULD		Upon receiving such key information, the BGP module on the PCC SHOULD
	try to accomplish the task appointed by the PCEP protocol and report		try to accomplish the task appointed by the PCEP and report the
	the successful status to the PCEP modules after the session is set		successful status to the PCEP modules after the session is set up.
	up.
	There is no influence on the current implementation of the BGP Finite		There is no influence on the current implementation of the BGP Finite
	State Machine (FSM). 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 accordingly.		status of the BGP session and acts upon such information accordingly.
	The error-handling procedures related to incorrect BGP parameters are		The error-handling procedures related to incorrect BGP parameters are
	specified in Sections 6.1, 6.2, and 6.3.		specified in Sections 6.1, 6.2, and 6.3.
	10. Deployment Considerations		10. Deployment Considerations
	The information transferred in this document is mainly used for the		The information transferred in this document is mainly used for the
	BGP session setup, explicit route deployment, and 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 need 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.		out of the scope of this document.
	The communication of PCE and PCC described in this document MUST		The communication of PCE and PCC described in this document MUST
	follow the state synchronization procedures described in [RFC8232],		follow the State Synchronization procedures described in [RFC8232],
	i.e., treat the three newly defined objects (BPI, EPR, and PPA)		i.e., treat the three newly defined objects (BPI, EPR, and PPA)
	associated with the same symbolic path name as the attribute of the		associated with the same Symbolic Path Name as the attribute of the
	same path in the LSP State Database (LSP-DB).		same path in the LSP Database (LSP-DB).
	When the PCE detects that one or some of the PCCs are out of its		When the PCE detects that one or some of the PCCs are out of its
	control, it MUST recompute and redeploy the traffic engineering path		control, it MUST recompute and redeploy the traffic engineering path
	for native IP on the currently active PCCs. The PCE MUST ensure the		for Native IP on the currently active PCCs. The PCE MUST ensure the
	avoidance of the possible transient loop in such node failure when it		avoidance of the possible transient loop in such node failure when it
	deploys the explicit peer route on the PCCs.		deploys the explicit peer route on the PCCs.
	In case of a PCE failure, a new PCE can gain control over the central		In case of a PCE failure, a new PCE can gain control over the Central
	controller instructions as described in [RFC9050].		Controller Instructions as described in [RFC9050].
	As per the PCEP procedures in [RFC8281], the State Timeout Interval		As per the PCEP procedures in [RFC8281], the State Timeout Interval
	timer is used to ensure that a PCE failure does not result in		timer is used to ensure that a PCE failure does not result in
	automatic and immediate disruption for the services. Similarly, as		automatic and immediate disruption for the services. Similarly, as
	per [RFC9050], the central controller instructions are not removed		per [RFC9050], the Central Controller Instructions are not removed
	immediately upon PCE failure. Instead, they could be redelegated to		immediately upon PCE failure. Instead, they could be redelegated to
	the new PCE before the expiration of this timer or be cleaned up on		the new PCE before the expiration of this timer or be cleaned up on
	the expiration of this timer. This allows for network cleanup		the expiration of this timer. This allows for network cleanup
	without manual intervention. The PCC supports the removal of CCI as		without manual intervention. The PCC supports the removal of CCI as
	one of the behaviors applied on the expiration of the State Timeout		one of the behaviors applied on the expiration of the State Timeout
	Interval timer.		Interval timer.
	11. Manageability Considerations		11. Manageability Considerations
	11.1. Control of Function and Policy		11.1. Control of Function and Policy
	A PCE or PCC implementation SHOULD allow the PCECC Native-IP		A PCE or PCC implementation SHOULD allow the PCECC Native IP
	capability to be enabled/disabled as part of the global		capability to be enabled/disabled as part of the global
	configuration.		configuration.
	11.2. Information and Data Models		11.2. Information and Data Models
	[RFC7420] describes the PCEP MIB; this MIB could be extended to get		[RFC7420] describes the PCEP MIB; this MIB could be extended to get
	the PCECC Native-IP capability status. The PCEP YANG module		the PCECC Native IP capability status. The PCEP YANG module
	[YANG-PCEP] could be extended to enable/disable the PCECC Native-IP		[YANG-PCEP] could be extended to enable/disable the PCECC Native IP
	capability.		capability.
	11.3. Liveness Detection and Monitoring		11.3. Liveness Detection and Monitoring
	Mechanisms defined in this document do not imply any new liveness		Mechanisms defined in this document do not imply any new liveness
	detection and monitoring requirements in addition to those already		detection and monitoring requirements beyond those already listed in
	listed in [RFC5440]. The operator relies on existing IP liveness		[RFC5440]. The operator relies on existing IP liveness detection and
	detection and monitoring.		monitoring.
	11.4. Verify Correct Operations		11.4. Verify Correct Operations
	Verification of the mechanisms defined in this document can be built		Verification of the mechanisms defined in this document can be built
	on those already listed in [RFC5440], [RFC8231], and [RFC9050].		on those already listed in [RFC5440], [RFC8231], and [RFC9050].
	Further, the operator needs to be able to verify the status of BGP		Further, the operator needs to be able to verify the status of BGP
	sessions and prefix advertisements.		sessions and prefix advertisements.
	11.5. Requirements on Other Protocols		11.5. Requirements on Other Protocols
	Mechanisms defined in this document require the interaction with BGP.		Mechanisms defined in this document require the interaction with BGP.
	Section 9 describes in detail the considerations regarding the BGP.		Section 9 describes in detail the considerations regarding the BGP.
	During the BGP session establishment, the Local/Peer IP address MUST		During the BGP session establishment, the Local/Peer IP Address MUST
	be dedicated to the usage of the native IP TE solution and MUST NOT		be dedicated to the usage of the Native IP TE solution and MUST NOT
	be used by other BGP sessions that are established manually or in		be used by other BGP sessions that are established manually or in
	other ways.		other ways.
	11.6. Impact on Network Operations		11.6. Impact on Network Operations
	[RFC8821] describes the various deployment considerations in CCDR		[RFC8821] describes the various deployment considerations in CCDR
	architecture and their impact on network operations.		architecture and their impact on network operations.
	12. Security Considerations		12. Security Considerations
	In this setup, the BGP sessions, prefix advertisement, and explicit		In this setup, the BGP sessions, prefix advertisement, and explicit
	peer route establishment are all controlled by the PCE. See		peer route establishment are all controlled by the PCE. See
	[RFC4271] for classical BGP implementation security considerations		[RFC4271] for classical BGP implementation security considerations
	and [RFC4272] for classical BGP vulnerabilities analysis. Security		and [RFC4272] for classical BGP vulnerabilities analysis. Security
	considerations in [RFC5440] for the basic PCEP protocol, [RFC8231]		considerations in [RFC5440] for the basic PCEP, [RFC8231] for PCEP
	for PCEP extension for stateful PCE, and [RFC8281] for PCE-Initiated		extension for stateful PCE, and [RFC8281] for PCE-initiated LSP setup
	LSP setup SHOULD be considered. To prevent a bogus PCE from sending		SHOULD be considered. To prevent a bogus PCE from sending harmful
	harmful messages to the network nodes, the network devices SHOULD		messages to the network nodes, the network devices SHOULD
	authenticate the PCE and ensure a secure communication channel		authenticate the PCE and ensure a secure communication channel
	between them. Thus, the mechanisms described in [RFC8253] for the		between them. Thus, the mechanisms described in [RFC8253] for the
	usage of TLS for PCEP and [RFC9050] for protection against malicious		usage of TLS for PCEP and [RFC9050] for protection against malicious
	PCEs SHOULD be used.		PCEs SHOULD be used.
	If the suitable default values discussed in Section 9 aren't enough		If the default values discussed in Section 9 aren't enough and
	and securing the BGP transport is required (for example, the TCP		securing the BGP transport is required (for example, by using TCP
	Authentication Option (TCP-AO) [RFC5925]), it can be provided through		Authentication Option (TCP-AO) [RFC5925]), a suitable value can be
	the addition of optional TLVs to the BGP Peer Info object that		provided through the addition of optional TLVs to the BGP Peer Info
	conveys the necessary additional information (for example, a key		object that conveys the necessary additional information (for
	chain [RFC8177] name).		example, a key chain [RFC8177] name).
	13. IANA Considerations		13. IANA Considerations
	13.1. PCEP Path Setup Types		13.1. PCEP Path Setup Types
	[RFC8408] created the "PCEP Path Setup Types" registry within the		[RFC8408] created the "PCEP Path Setup Types" registry within the
	"Path Computation Element Protocol (PCEP) Numbers" registry group.		"Path Computation Element Protocol (PCEP) Numbers" registry group.
	IANA has allocated a new code point within this registry, as follows:		IANA has allocated a new codepoint within this registry, as follows:
	+=======+===================+===========+		+=======+===================+===========+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=======+===================+===========+		+=======+===================+===========+
	| 4 | Native IP TE Path | RFC 9757 |		| 4 | Native IP TE Path | RFC 9757 |
	+-------+-------------------+-----------+		+-------+-------------------+-----------+
	Table 2: PCEP Path Setup Types Registry		Table 1: PCEP Path Setup Types Registry
	13.2. PCECC-CAPABILITY Sub-TLV Flag Field		13.2. PCECC-CAPABILITY Sub-TLV Flag Field
	[RFC9050] created the "PCECC-CAPABILITY sub-TLV" registry within the		[RFC9050] created the "PCECC-CAPABILITY sub-TLV" registry within the
	"Path Computation Element Protocol (PCEP) Numbers" registry group to		"Path Computation Element Protocol (PCEP) Numbers" registry group to
	manage the value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field.		manage the value of the PCECC-CAPABILITY sub-TLV's 32-bit Flag field.
	IANA has allocated a new bit position within this registry, as		IANA has allocated a new bit position within this registry, as
	follows:		follows:
	+=====+===========+===========+		+=====+===========+===========+
	| Bit | Name | Reference |		| Bit | Name | Reference |
	+=====+===========+===========+		+=====+===========+===========+
	| 30 | NATIVE IP | RFC 9757 |		| 30 | Native IP | RFC 9757 |
	+-----+-----------+-----------+		+-----+-----------+-----------+
	Table 3: PCECC-CAPABILITY		Table 2: PCECC-CAPABILITY
	Sub-TLV Registry		Sub-TLV Registry
	13.3. PCEP Objects		13.3. PCEP Objects
	IANA has allocated new code points in the "PCEP Objects" registry, as		IANA has allocated new codepoints in the "PCEP Objects" registry, as
	follows:		follows:
	+==============+===================+=============+===========+		+==============+===================+=============+===========+
	| Object-Class | Name | Object-Type | Reference |		| Object-Class | Name | Object-Type | Reference |
	| Value | | | |		| Value | | | |
	+==============+===================+=============+===========+		+==============+===================+=============+===========+
	| 44 | CCI Object-Type | 2: Native | RFC 9757 |		| 44 | CCI Object-Type | 2: Native | RFC 9757 |
	| | | IP | |		| | | IP | |
	+--------------+-------------------+-------------+-----------+		+--------------+-------------------+-------------+-----------+
	| 46 | BGP Peer Info | 0: Reserved | RFC 9757 |		| 46 | BGP Peer Info | 0: Reserved | RFC 9757 |
	| | Object-Type | | |		| | Object-Type | | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 1: IPv4 | |		| | | 1: IPv4 | RFC 9757 |
	| | | address | |		| | | address | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 2: IPv6 | |		| | | 2: IPv6 | RFC 9757 |
	| | | address | |		| | | address | |
	+--------------+-------------------+-------------+-----------+		+--------------+-------------------+-------------+-----------+
	| 47 | Explicit Peer | 0: Reserved | RFC 9757 |		| 47 | Explicit Peer | 0: Reserved | RFC 9757 |
	| | Route Object-Type | | |		| | Route Object-Type | | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 1: IPv4 | |		| | | 1: IPv4 | RFC 9757 |
	| | | address | |		| | | address | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 2: IPv6 | |		| | | 2: IPv6 | RFC 9757 |
	| | | address | |		| | | address | |
	+--------------+-------------------+-------------+-----------+		+--------------+-------------------+-------------+-----------+
	| 48 | Peer Prefix | 0: Reserved | RFC 9757 |		| 48 | Peer Prefix | 0: Reserved | RFC 9757 |
	| | Advertisement | | |		| | Advertisement | | |
	| | Object-Type | | |		| | Object-Type | | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 1: IPv4 | |		| | | 1: IPv4 | RFC 9757 |
	| | | address | |		| | | address | |
	| | +-------------+-----------+		| | +-------------+-----------+
	| | | 2: IPv6 | |		| | | 2: IPv6 | RFC 9757 |
	| | | address | |		| | | address | |
	+--------------+-------------------+-------------+-----------+		+--------------+-------------------+-------------+-----------+
	Table 4: PCEP Objects Registry		Table 3: PCEP Objects Registry
	13.4. PCEP-Error Objects		13.4. PCEP-Error Objects
	IANA has allocated a new Error-Type and several Error-values in the		IANA has allocated a new Error-Type and several Error-values in the
	"PCEP-ERROR Object Error Types and Values" registry within the "Path		"PCEP-ERROR Object Error Types and Values" registry within the "Path
	Computation Element Protocol (PCEP) Numbers" registry group, as		Computation Element Protocol (PCEP) Numbers" registry group, as
	follows:		follows:
	+============+=================+===============================+		+============+==============+==========================+===========+
	| Error-Type | Meaning | Error-value |		| Error-Type | Meaning | Error-value | Reference |
	+============+=================+===============================+		+============+==============+==========================+===========+
	| 6 | Mandatory | 19: Native IP object missing |		| 6 | Mandatory | 19: Native IP object | RFC 9757 |
	| | Object missing | |		| | Object | missing | |
	+------------+-----------------+-------------------------------+		| | missing | | |
	| 10 | Reception of an | 39: PCECC NATIVE-IP-TE- |		+------------+--------------+--------------------------+-----------+
	| | invalid object | CAPABILITY bit is not set |		| 10 | Reception of | 39: PCECC NATIVE-IP-TE- | RFC 9757 |
	+------------+-----------------+-------------------------------+		| | an invalid | CAPABILITY bit is not | |
	| 19 | Invalid | 22: Only one BPI, EPR, or PPA |		| | object | set | |
	| | Operation | object can be included in |		+------------+--------------+--------------------------+-----------+
	| | | this message |		| 19 | Invalid | 22: Only one BPI, EPR, | RFC 9757 |
	| | +-------------------------------+		| | Operation | or PPA object can be | |
	| | | 29: Attempted Native-IP |		| | | included in this message | |
	| | | operations when the |		| | +--------------------------+-----------+
	| | | capability was not advertised |		| | | 29: Attempted Native IP | RFC 9757 |
	| | +-------------------------------+		| | | operations when the | |
	| | | 30: Unknown Native-IP Info |		| | | capability was not | |
	+------------+-----------------+-------------------------------+		| | | advertised | |
	| 33 | Native IP TE | 0: Unassigned |		| | +--------------------------+-----------+
	| | failure | |		| | | 30: Unknown Native IP | RFC 9757 |
	| | +-------------------------------+		| | | Info | |
	| | | 1: Local IP is in use |		+------------+--------------+--------------------------+-----------+
	| | +-------------------------------+		| 33 | Native IP TE | 0: Unassigned | RFC 9757 |
	| | | 2: Remote IP is in use |		| | failure | | |
	| | +-------------------------------+		| | +--------------------------+-----------+
	| | | 3: Explicit Peer Route Error |		| | | 1: Local IP is in use | RFC9757 |
	| | +-------------------------------+		| | +--------------------------+-----------+
	| | | 4: EPR/BPI Peer Info mismatch |		| | | 2: Remote IP is in use | RFC 9757 |
	| | +-------------------------------+		| | +--------------------------+-----------+
	| | | 5: BPI/PPA Address Family |		| | | 3: Explicit Peer Route | RFC 9757 |
	| | | mismatch |		| | | Error | |
	| | +-------------------------------+		| | +--------------------------+-----------+
	| | | 6: PPA/BPI Peer Info mismatch |		| | | 4: EPR/BPI Peer Info | RFC 9757 |
	+------------+-----------------+-------------------------------+		| | | mismatch | |
			| | +--------------------------+-----------+
			| | | 5: BPI/PPA Address | RFC 9757 |
			| | | Family mismatch | |
			| | +--------------------------+-----------+
			| | | 6: PPA/BPI Peer Info | RFC 9757 |
			| | | mismatch | |
			+------------+--------------+--------------------------+-----------+
	Table 5: PCEP-ERROR Object Error Types and Values Registry		Table 4: PCEP-ERROR Object Error Types and Values Registry
	The reference for each new Error-Type/Error-value should be set to		The reference for each new Error-Type/Error-value should be set to
	this document.		this document.
	13.5. CCI Object Flag Field		13.5. CCI Object Flag Field
	IANA has created the "CCI Object Flag Field for Native-IP" registry		IANA has created the "CCI Object Flag Field for Native IP" registry
	to manage the 16-bit Flag field of the new CCI Object. New values		to manage the 16-bit Flag field of the new CCI object. New values
	are to be assigned by IETF Review [RFC8126]. Each bit should be		are to be assigned by IETF Review [RFC8126]. Each bit should be
	tracked with the following qualities:		tracked with the following qualities:
	* bit number (counting from bit 0 as the most significant bit and		* bit number (counting from bit 0 as the most significant bit and
	bit 15 as the least significant bit)		bit 15 as the least significant bit)
	* capability description		* capability description
	* defining RFC		* defining RFC
	skipping to change at line 1496 ¶		skipping to change at line 1466 ¶
	+-------+---------------------------------------+-----------+		+-------+---------------------------------------+-----------+
	| 1 | BGP Session Established | RFC 9757 |		| 1 | BGP Session Established | RFC 9757 |
	+-------+---------------------------------------+-----------+		+-------+---------------------------------------+-----------+
	| 2 | BGP Session Establishment In Progress | RFC 9757 |		| 2 | BGP Session Establishment In Progress | RFC 9757 |
	+-------+---------------------------------------+-----------+		+-------+---------------------------------------+-----------+
	| 3 | BGP Session Down | RFC 9757 |		| 3 | BGP Session Down | RFC 9757 |
	+-------+---------------------------------------+-----------+		+-------+---------------------------------------+-----------+
	| 4-255 | Unassigned | RFC 9757 |		| 4-255 | Unassigned | RFC 9757 |
	+-------+---------------------------------------+-----------+		+-------+---------------------------------------+-----------+
	Table 6: BPI Object Status Code Field Registry		Table 5: BPI Object Status Code Field Registry
	13.7. BPI Object Error Codes		13.7. BPI Object Error Codes
	IANA has created the "BPI Object Error Code Field" registry within		IANA has created the "BPI Object Error Code Field" registry within
	the "Path Computation Element Protocol (PCEP) Numbers" registry		the "Path Computation Element Protocol (PCEP) Numbers" registry
	group. New values are assigned by IETF Review [RFC8126]. Each value		group. New values are assigned by IETF Review [RFC8126]. Each value
	should be tracked with the following qualities: value, meaning, and		should be tracked with the following qualities: value, meaning, and
	defining RFC. The following values are defined in this document:		defining RFC. The following values are defined in this document:
	+=======+=========================================+===========+		+=======+=========================================+===========+
	skipping to change at line 1519 ¶		skipping to change at line 1489 ¶
	| 0 | Reserved | RFC 9757 |		| 0 | Reserved | RFC 9757 |
	+-------+-----------------------------------------+-----------+		+-------+-----------------------------------------+-----------+
	| 1 | ASes do not match - BGP Session Failure | RFC 9757 |		| 1 | ASes do not match - BGP Session Failure | RFC 9757 |
	+-------+-----------------------------------------+-----------+		+-------+-----------------------------------------+-----------+
	| 2 | Peer IP can't be reached - BGP Session | RFC 9757 |		| 2 | Peer IP can't be reached - BGP Session | RFC 9757 |
	| | Failure | |		| | Failure | |
	+-------+-----------------------------------------+-----------+		+-------+-----------------------------------------+-----------+
	| 3-255 | Unassigned | RFC 9757 |		| 3-255 | Unassigned | RFC 9757 |
	+-------+-----------------------------------------+-----------+		+-------+-----------------------------------------+-----------+
	Table 7: BPI Object Error Code Field Registry		Table 6: BPI Object Error Code Field Registry
	13.8. BPI Object Flag Field		13.8. BPI Object Flag Field
	IANA has created the "BPI Object Flag Field" registry within the		IANA has created the "BPI Object Flag Field" registry within the
	"Path Computation Element Protocol (PCEP) Numbers" registry group.		"Path Computation Element Protocol (PCEP) Numbers" registry group.
	New values are to be assigned by IETF Review [RFC8126]. Each bit		New values are to be assigned by IETF Review [RFC8126]. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	* bit number (counting from bit 0 as the most significant bit)		* bit number (counting from bit 0 as the most significant bit)
	* capability description		* capability description
	* defining RFC		* defining RFC
	The following values are defined in this document:		The following values are defined in this document:
	+=====+===============+===========+		+=====+==================+===========+
	| Bit | Meaning | Reference |		| Bit | Meaning | Reference |
	+=====+===============+===========+		+=====+==================+===========+
	| 0-6 | Unassigned |		| 0-6 | Unassigned |
	+-----+---------------+-----------+		+-----+------------------+-----------+
	| 7 | T (IPnIP) bit | RFC 9757 |		| 7 | T (IP-in-IP) bit | RFC 9757 |
	+-----+---------------+-----------+		+-----+------------------+-----------+
	Table 8: BPI Object Flag Field		Table 7: BPI Object Flag Field
	Registry		Registry
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,		[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
	DOI 10.17487/RFC2003, October 1996,		DOI 10.17487/RFC2003, October 1996,
	<https://www.rfc-editor.org/info/rfc2003>.		<https://www.rfc-editor.org/info/rfc2003>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at line 1645 ¶		skipping to change at line 1615 ¶
	<https://www.rfc-editor.org/info/rfc3209>.		<https://www.rfc-editor.org/info/rfc3209>.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, DOI 10.17487/RFC4272, January 2006,		RFC 4272, DOI 10.17487/RFC4272, January 2006,
	<https://www.rfc-editor.org/info/rfc4272>.		<https://www.rfc-editor.org/info/rfc4272>.
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
	October 2007, <https://www.rfc-editor.org/info/rfc5036>.		October 2007, <https://www.rfc-editor.org/info/rfc5036>.
	[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>.
	[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.		[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
	Zhang, "YANG Data Model for Key Chains", RFC 8177,		Zhang, "YANG Data Model for Key Chains", RFC 8177,
	DOI 10.17487/RFC8177, June 2017,		DOI 10.17487/RFC8177, June 2017,
	<https://www.rfc-editor.org/info/rfc8177>.		<https://www.rfc-editor.org/info/rfc8177>.
	[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An		[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
	Architecture for Use of PCE and the PCE Communication		Architecture for Use of PCE and the PCE Communication
	Protocol (PCEP) in a Network with Central Control",		Protocol (PCEP) in a Network with Central Control",
	RFC 8283, DOI 10.17487/RFC8283, December 2017,		RFC 8283, DOI 10.17487/RFC8283, December 2017,
	<https://www.rfc-editor.org/info/rfc8283>.		<https://www.rfc-editor.org/info/rfc8283>.
	skipping to change at line 1686 ¶		skipping to change at line 1651 ¶
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-		2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
	pce-pcep-yang-30>.		pce-pcep-yang-30>.
	Acknowledgements		Acknowledgements
	Thanks to Mike Koldychev, Susan Hares, Siva Sivabalan, and Adam		Thanks to Mike Koldychev, Susan Hares, Siva Sivabalan, and Adam
	Simpson for their valuable suggestions and comments.		Simpson for their valuable suggestions and comments.
	Contributors		Contributors
	Dhruv Dhody has contributed to this document.		Ren Tan and Dhruv Dhody have contributed to this document.
	Authors' Addresses		Authors' Addresses
	Aijun Wang		Aijun Wang
	China Telecom		China Telecom
	Beiqijia Town, Changping District		Beiqijia Town, Changping District
	Beijing		Beijing
	102209		102209
	China		China
	Email: wangaijun@tsinghua.org.cn		Email: wangaijun@tsinghua.org.cn
	skipping to change at line 1713 ¶		skipping to change at line 1678 ¶
	Russian Federation		Russian Federation
	Email: bhassanov@yahoo.com		Email: bhassanov@yahoo.com
	Sheng Fang		Sheng Fang
	Huawei Technologies		Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing		Beijing
	China		China
	Email: fsheng@huawei.com		Email: fsheng@huawei.com
	Ren Tan
	Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.
	Beijing
	China
	Email: tanren@huawei.com
	Chun Zhu		Chun Zhu
	ZTE Corporation		ZTE Corporation
	50 Software Avenue, Yuhua District		50 Software Avenue, Yuhua District
	Nanjing		Nanjing
	Jiangsu, 210012		Jiangsu, 210012
	China		China
	Email: zhu.chun1@zte.com.cn		Email: zhu.chun1@zte.com.cn
End of changes. 87 change blocks.
	238 lines changed or deleted		196 lines changed or added
This html diff was produced by rfcdiff 1.48.