< draft-ietf-pce-segment-routing-ipv6-10.txt		draft-ietf-pce-segment-routing-ipv6-11.txt >
	PCE Working Group C. Li		PCE Working Group C. Li
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track M. Negi		Intended status: Standards Track M. Negi
	Expires: June 2, 2022 RtBrick Inc		Expires: 15 July 2022 RtBrick Inc
	S. Sivabalan		S. Sivabalan
	Ciena Corporation		Ciena Corporation
	M. Koldychev		M. Koldychev
	Cisco Systems, Inc.		Cisco Systems, Inc.
	P. Kaladharan		P. Kaladharan
	RtBrick Inc		RtBrick Inc
	Y. Zhu		Y. Zhu
	China Telecom		China Telecom
	November 29, 2021		11 January 2022
	PCEP Extensions for Segment Routing leveraging the IPv6 data plane		PCEP Extensions for Segment Routing leveraging the IPv6 data plane
	draft-ietf-pce-segment-routing-ipv6-10		draft-ietf-pce-segment-routing-ipv6-11
	Abstract		Abstract
	The Source Packet Routing in Networking (SPRING) architecture		The Source Packet Routing in Networking (SPRING) architecture
	describes how Segment Routing (SR) can be used to steer packets		describes how Segment Routing (SR) can be used to steer packets
	through an IPv6 or MPLS network using the source routing paradigm.		through an IPv6 or MPLS network using the source routing paradigm.
	SR enables any head-end node to select any path without relying on a		SR enables any head-end node to select any path without relying on a
	hop-by-hop signaling technique (e.g., LDP or RSVP-TE).		hop-by-hop signaling technique (e.g., LDP or RSVP-TE).
	It depends only on "segments" that are advertised by Link- State		It depends only on "segments" that are advertised by Link- State
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 2, 2022.		This Internet-Draft will expire on 15 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5		3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5
	3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6		3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6
	3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 7		3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 7
	4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7		4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7		4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
	4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7		4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7
	4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9		4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9
	4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 9		4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 9
	4.3.1.1. SID Structure . . . . . . . . . . . . . . . . . . 11		4.3.1.1. SID Structure . . . . . . . . . . . . . . . . . . 11
	4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 13		4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 13
			5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 14		5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 14
	5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15		5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15
	5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15		5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15
	5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16		5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16
	5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17		5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Manageability Considerations . . . . . . . . . . . . . . . . 17		7. Manageability Considerations . . . . . . . . . . . . . . . . 17
	7.1. Control of Function and Policy . . . . . . . . . . . . . 17		7.1. Control of Function and Policy . . . . . . . . . . . . . 17
	7.2. Information and Data Models . . . . . . . . . . . . . . . 17		7.2. Information and Data Models . . . . . . . . . . . . . . . 17
	7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17		7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	of the packet. Upon completion of a segment, a pointer in the new		of the packet. Upon completion of a segment, a pointer in the new
	routing header is incremented and indicates the next segment.		routing header is incremented and indicates the next segment.
	Segment Routing use cases are described in [RFC7855] and [RFC8354].		Segment Routing use cases are described in [RFC7855] and [RFC8354].
	Segment Routing protocol extensions are defined in [RFC8667], and		Segment Routing protocol extensions are defined in [RFC8667], and
	[RFC8666].		[RFC8666].
	As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or		As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or
	simply "SID" are often used as a shorter reference for "SRv6		simply "SID" are often used as a shorter reference for "SRv6
	Segment". Further details are in an illustration provided in		Segment". Further details are in an illustration provided in
	[I-D.ietf-spring-srv6-network-programming].		[RFC8986].
	The SR architecture can be applied to the MPLS forwarding plane		The SR architecture can be applied to the MPLS forwarding plane
	without any change, in which case an SR path corresponds to an MPLS		without any change, in which case an SR path corresponds to an MPLS
	Label Switching Path (LSP). The SR is applied to IPV6 forwarding		Label Switching Path (LSP). The SR is applied to IPV6 forwarding
	plane using SRH. A SR path can be derived from an IGP Shortest Path		plane using SRH. A SR path can be derived from an IGP Shortest Path
	Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may		Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may
	be chosen by a suitable network planning tool, or a PCE and		be chosen by a suitable network planning tool, or a PCE and
	provisioned on the ingress node.		provisioned on the ingress node.
	[RFC5440] describes Path Computation Element communication Protocol		[RFC5440] describes Path Computation Element communication Protocol
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO		This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO
	and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable		and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable
	PCEP speakers MUST be able to generate and/or process this.		PCEP speakers MUST be able to generate and/or process this.
	When a PCEP session between a PCC and a PCE is established, both PCEP		When a PCEP session between a PCC and a PCE is established, both PCEP
	speakers exchange their capabilities to indicate their ability to		speakers exchange their capabilities to indicate their ability to
	support SRv6 specific functionality.		support SRv6 specific functionality.
	In summary, this document:		In summary, this document:
	o Defines a new PCEP capability for SRv6.		* Defines a new PCEP capability for SRv6.
	o Defines a new subobject SRv6-ERO in ERO.		* Defines a new subobject SRv6-ERO in ERO.
	o Defines a new subobject SRv6-RRO in RRO.		* Defines a new subobject SRv6-RRO in RRO.
	o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV		* Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
	and the PATH-SETUP-TYPE-CAPABILITY TLV.		and the PATH-SETUP-TYPE-CAPABILITY TLV.
	3.1. Operation Overview		3.1. Operation Overview
	In SR networks, an ingress node of an SR path appends all outgoing		In SR networks, an ingress node of an SR path appends all outgoing
	packets with an SR header consisting of a list of SIDs (IPv6 Prefix		packets with an SR header consisting of a list of SIDs (IPv6 Prefix
	in case of SRv6). The header has all necessary information to guide		in case of SRv6). The header has all necessary information to guide
	the packets from the ingress node to the egress node of the path, and		the packets from the ingress node to the egress node of the path, and
	hence there is no need for any signaling protocol.		hence there is no need for any signaling protocol.
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	4. Object Formats		4. Object Formats
	4.1. The OPEN Object		4.1. The OPEN Object
	4.1.1. The SRv6 PCE Capability sub-TLV		4.1.1. The SRv6 PCE Capability sub-TLV
	This document defines a new Path Setup Type (PST) [RFC8408] for SRv6,		This document defines a new Path Setup Type (PST) [RFC8408] for SRv6,
	as follows:		as follows:
	o PST = TBD2: Path is setup using SRv6.		* PST = TBD2: Path is setup using SRv6.
	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.
	This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP		This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP
	speakers use this sub-TLV to exchange information about their SRv6		speakers use this sub-TLV to exchange information about their SRv6
	capability. If a PCEP speaker includes PST=TBD2 in the PST List of		capability. If a PCEP speaker includes PST=TBD2 in the PST List of
	the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the		the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the
	SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY		SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |N|X|		| Reserved | Flags |N|X|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSD-Type | MSD-Value | MSD-Type | MSD-Value |		| MSD-Type | MSD-Value | MSD-Type | MSD-Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// ... //		// ... //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSD-Type | MSD-Value | Padding |		| MSD-Type | MSD-Value | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: SRv6-PCE-CAPABILITY sub-TLV format		Figure 1: SRv6-PCE-CAPABILITY sub-TLV format
	The code point for the TLV type (TBD1) is to be defined by IANA. The		The code point for the TLV type (TBD1) is to be defined by IANA. The
	TLV length is variable.		TLV length is variable.
	The value comprises of -		The value comprises of -
	Reserved: 2 octet, this field MUST be set to 0 on transmission,		Reserved: 2 octet, this field MUST be set to 0 on transmission,
	and ignored on receipt.		and ignored on receipt.
	Flags: 2 octet, two bits are currently assigned in this document.		Flags: 2 octet, two bits are currently assigned in this document.
	N bit: A PCC sets this flag bit to 1 to indicate that it is		- N bit: A PCC sets this flag bit to 1 to indicate that it is
	capable of resolving a Node or Adjacency Identifier (NAI) to a		capable of resolving a Node or Adjacency Identifier (NAI) to a
	SRv6-SID.		SRv6-SID.
	X bit: A PCC sets this bit to 1 to indicate that it does not		- X bit: A PCC sets this bit to 1 to indicate that it does not
	impose any limit on MSD (irrespective of the MSD-Type).		impose any limit on MSD (irrespective of the MSD-Type).
	Unassigned bits MUST be set to 0 and ignored on receipt.		- Unassigned bits MUST be set to 0 and ignored on receipt.
	A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as		A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as
	per the IGP MSD Type registry created by [RFC8491] and populated		per the IGP MSD Type registry created by [RFC8491] and populated
	with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions];		with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions];
	MSD-Value (1 octet) is as per [RFC8491].		MSD-Value (1 octet) is as per [RFC8491].
	This sub-TLV format is compliant with the PCEP TLV format defined in		This sub-TLV format is compliant with the PCEP TLV format defined in
	[RFC5440]. That is, the sub-TLV is composed of 2 octets for the		[RFC5440]. That is, the sub-TLV is composed of 2 octets for the
	type, 2 octets specifying the length, and a Value field. The Type		type, 2 octets specifying the length, and a Value field. The Type
	field when set to TBD1 identifies the SRv6-PCE-CAPABILITY sub-TLV and		field when set to TBD1 identifies the SRv6-PCE-CAPABILITY sub-TLV and
	skipping to change at page 10, line 45 ¶		skipping to change at page 11, line 5 ¶
	(global IPv6 address, interface ID) tuples. It is used to		(global IPv6 address, interface ID) tuples. It is used to
	identify the IPv6 Adjacency and used with the SRv6 Adj-SID.		identify the IPv6 Adjacency and used with the SRv6 Adj-SID.
	SR-MPLS specific NT types are not valid in SRv6-ERO.		SR-MPLS specific NT types are not valid in SRv6-ERO.
	Flags: Used to carry additional information pertaining to the		Flags: Used to carry additional information pertaining to the
	SRv6-SID. This document defines the following flag bits. The other		SRv6-SID. This document defines the following flag bits. The other
	bits MUST be set to zero by the sender and MUST be ignored by the		bits MUST be set to zero by the sender and MUST be ignored by the
	receiver.		receiver.
	o S: When this bit is set to 1, the SRv6-SID value in the subobject		* S: When this bit is set to 1, the SRv6-SID value in the subobject
	body is absent. In this case, the PCC is responsible for choosing		body is absent. In this case, the PCC is responsible for choosing
	the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI		the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI
	which, in this case, MUST be present in the subobject. If the S		which, in this case, MUST be present in the subobject. If the S
	bit is set to 1 then F bit MUST be set to zero.		bit is set to 1 then F bit MUST be set to zero.
	o F: When this bit is set to 1, the NAI value in the subobject body		* F: When this bit is set to 1, the NAI value in the subobject body
	is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST		is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST
	be set to zero. The S and F bits MUST NOT both be set to 1.		be set to zero. The S and F bits MUST NOT both be set to 1.
	o T: When this bit is set to 1, the SID Structure value in the		* T: When this bit is set to 1, the SID Structure value in the
	subobject body is present. The T bit MUST be set to 0 when S bit		subobject body is present. The T bit MUST be set to 0 when S bit
	is set to 1. If the T bit is set when the S bit is set, the T bit		is set to 1. If the T bit is set when the S bit is set, the T bit
	MUST be ignored. Thus, the T bit indicates the presence of an		MUST be ignored. Thus, the T bit indicates the presence of an
	optional 8-byte SID Structure when SRv6 SID is included. The SID		optional 8-byte SID Structure when SRv6 SID is included. The SID
	Structure is defined in Section 4.3.1.1.		Structure is defined in Section 4.3.1.1.
	o V: The "SID verification" bit usage is as per Section 5.1 of		* V: The "SID verification" bit usage is as per Section 5.1 of
	[I-D.ietf-spring-segment-routing-policy].		[I-D.ietf-spring-segment-routing-policy].
	Reserved: MUST be set to zero while sending and ignored on receipt.		Reserved: MUST be set to zero while sending and ignored on receipt.
	Endpoint Behavior: A 16 bit field representing the behavior		Endpoint Behavior: A 16 bit field representing the behavior
	associated with the SRv6 SIDs. This information is optional and		associated with the SRv6 SIDs. This information is optional and
	plays no role in the fields in SRH imposed on the packet. It could		plays no role in the fields in SRH imposed on the packet. It could
	be used for maintainability and diagnostic purpose. If behavior is		be used for maintainability and diagnostic purpose. If behavior is
	not known, 0 is used. The list of Endpoint behavior are defined in		not known, 0 is used. The list of Endpoint behavior are defined in
	[I-D.ietf-spring-srv6-network-programming].		[RFC8986].
	SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing		SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing
	the SRv6 segment.		the SRv6 segment.
	NAI: The NAI associated with the SRv6-SID. The NAI's format depends		NAI: The NAI associated with the SRv6-SID. The NAI's format depends
	on the value in the NT field, and is described in [RFC8664].		on the value in the NT field, and is described in [RFC8664].
	At least one of the SRv6-SID or the NAI MUST be included in the		At least one of the SRv6-SID or the NAI MUST be included in the
	SRv6-ERO subobject, and both MAY be included.		SRv6-ERO subobject, and both MAY be included.
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 13 ¶
	following figure.		following figure.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LB Length | LN Length | Fun. Length | Arg. Length |		| LB Length | LN Length | Fun. Length | Arg. Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags |		| Reserved | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: SID Structure Format		Figure 3: SID Structure Format
	where:		where:
	LB Length: 1 octet. SRv6 SID Locator Block length in bits.		LB Length: 1 octet. SRv6 SID Locator Block length in bits.
	LN Length: 1 octet. SRv6 SID Locator Node length in bits.		LN Length: 1 octet. SRv6 SID Locator Node length in bits.
	Fun. Length: 1 octet. SRv6 SID Function length in bits.		Fun. Length: 1 octet. SRv6 SID Function length in bits.
	Arg. Length: 1 octet. SRv6 SID Arguments length in bits.		Arg. Length: 1 octet. SRv6 SID Arguments length in bits.
	skipping to change at page 15, line 43 ¶		skipping to change at page 15, line 43 ¶
	5.2.1. SRv6 ERO Validation		5.2.1. SRv6 ERO Validation
	If a PCC does not support the SRv6 PCE Capability and thus cannot		If a PCC does not support the SRv6 PCE Capability and thus cannot
	recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond		recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond
	according to the rules for a malformed object per [RFC5440].		according to the rules for a malformed object per [RFC5440].
	On receiving an SRv6-ERO, a PCC MUST validate that the Length field,		On receiving an SRv6-ERO, a PCC MUST validate that the Length field,
	the S bit, the F bit, the T bit, and the NT field are consistent, as		the S bit, the F bit, the T bit, and the NT field are consistent, as
	follows.		follows.
	o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the		* If NT=0, the F bit MUST be 1, the S bit MUST be zero and the
	Length MUST be 24.		Length MUST be 24.
	o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length		* If NT=2, the F bit MUST be zero. If the S bit is 1, the Length
	MUST be 24, otherwise the Length MUST be 40.		MUST be 24, otherwise the Length MUST be 40.
	o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length		* If NT=4, the F bit MUST be zero. If the S bit is 1, the Length
	MUST be 40, otherwise the Length MUST be 56.		MUST be 40, otherwise the Length MUST be 56.
	o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length		* If NT=6, the F bit MUST be zero. If the S bit is 1, the Length
	MUST be 48, otherwise the Length MUST be 64.		MUST be 48, otherwise the Length MUST be 64.
	o NT types (1,3, and 5) are not valid for SRv6.		* NT types (1,3, and 5) are not valid for SRv6.
	o If T bit is 1, then S bit MUST be zero.		* If T bit is 1, then S bit MUST be zero.
	If a PCC finds that the NT field, Length field, S bit, F bit, and T		If a PCC finds that the NT field, Length field, S bit, F bit, and T
	bit are not consistent, it MUST consider the entire ERO invalid and		bit are not consistent, it MUST consider the entire ERO invalid and
	MUST send a PCErr message with Error-Type = 10 ("Reception of an		MUST send a PCErr message with Error-Type = 10 ("Reception of an
	invalid object") and Error-Value = 11 ("Malformed object").		invalid object") and Error-Value = 11 ("Malformed object").
	If a PCEP speaker that does not recognize the NT value received in		If a PCEP speaker that does not recognize the NT value received in
	SRv6-ERO subobject, it would behave as per [RFC8664].		SRv6-ERO subobject, it would behave as per [RFC8664].
	In case a PCEP speaker receives the SRv6-ERO subobject, when the PST		In case a PCEP speaker receives the SRv6-ERO subobject, when the PST
	is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged,		is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged,
	it MUST send a PCErr message with Error-Type = 19 ("Invalid		it MUST send a PCErr message with Error-Type = 19 ("Invalid
	Operation") and Error-Value = TBD5 ("Attempted SRv6 when the		Operation") and Error-Value = TBD9 ("Attempted SRv6 when the
	capability was not advertised").		capability was not advertised").
	If a PCC receives a list of SRv6 segments, and the number of SRv6		If a PCC receives a list of SRv6 segments, and the number of SRv6
	segments exceeds the SRv6 MSD that the PCC can impose on the packet		segments exceeds the SRv6 MSD that the PCC can impose on the packet
	(SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception		(SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception
	of an invalid object") and Error-Value = TBD ("Unsupported number of		of an invalid object") and Error-Value = TBD ("Unsupported number of
	Segment ERO subobjects") as per [RFC8664].		Segment ERO subobjects") as per [RFC8664].
	When a PCEP speaker detects that all subobjects of ERO are not of		When a PCEP speaker detects that all subobjects of ERO are not of
	type TBD3, and if it does not handle such ERO, it MUST send a PCErr		type TBD3, and if it does not handle such ERO, it MUST send a PCErr
	skipping to change at page 18, line 48 ¶		skipping to change at page 18, line 48 ¶
	According to [RFC7942], "this will allow reviewers and working groups		According to [RFC7942], "this will allow reviewers and working groups
	to assign due consideration to documents that have the benefit of		to assign due consideration to documents that have the benefit of
	running code, which may serve as evidence of valuable experimentation		running code, which may serve as evidence of valuable experimentation
	and feedback that have made the implemented protocols more mature.		and feedback that have made the implemented protocols more mature.
	It is up to the individual working groups to use this information as		It is up to the individual working groups to use this information as
	they see fit".		they see fit".
	8.1. Cisco's Commercial Delivery		8.1. Cisco's Commercial Delivery
	o Organization: Cisco Systems, Inc.		* Organization: Cisco Systems, Inc.
	o Implementation: IOS-XR PCE and PCC.		* Implementation: IOS-XR PCE and PCC.
	o Description: Implementation with experimental codepoints.		* Description: Implementation with experimental codepoints.
	o Maturity Level: Production		* Maturity Level: Production
	o Coverage: Partial		* Coverage: Partial
	o Contact: ssidor@cisco.com		* Contact: ssidor@cisco.com
	9. IANA Considerations		9. IANA Considerations
	9.1. PCEP ERO and RRO subobjects		9.1. PCEP ERO and RRO subobjects
	This document defines a new subobject type for the PCEP explicit		This document defines a new subobject type for the PCEP explicit
	route object (ERO), and a new subobject type for the PCEP record		route object (ERO), and a new subobject type for the PCEP record
	route object (RRO). The code points for subobject types of these		route object (RRO). The code points for subobject types of these
	objects is maintained in the RSVP parameters registry, under the		objects is maintained in the RSVP parameters registry, under the
	EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to		EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to
	skipping to change at page 19, line 36 ¶		skipping to change at page 19, line 38 ¶
	ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4		ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4
	9.2. New SRv6-ERO Flag Registry		9.2. New SRv6-ERO Flag Registry
	IANA is requested to create a new sub-registry, named "SRv6-ERO Flag		IANA is requested to create a new sub-registry, named "SRv6-ERO Flag
	Field", within the "Path Computation Element Protocol (PCEP) Numbers"		Field", within the "Path Computation Element Protocol (PCEP) Numbers"
	registry to manage the Flag field of the SRv6-ERO subobject. New		registry to manage the Flag field of the SRv6-ERO subobject. New
	values are to be assigned by Standards Action [RFC8126]. Each bit		values are to be assigned by Standards Action [RFC8126]. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	o Bit number (counting from bit 0 as the most significant bit)		* Bit number (counting from bit 0 as the most significant bit)
	o Capability description		* Capability description
	o Defining RFC		* Defining RFC
	The following values are defined in this document:		The following values are defined in this document:
	Bit Description Reference		Bit Description Reference
	----- ------------------ --------------		----- ------------------ --------------
	0-7 Unassigned		0-7 Unassigned
	8 SID Verification (V) This document		8 SID Verification (V) This document
	9 SID Structure is This document		9 SID Structure is This document
	present (T)		present (T)
	10 NAI is absent (F) This document		10 NAI is absent (F) This document
	skipping to change at page 20, line 35 ¶		skipping to change at page 20, line 35 ¶
	9.4. SRv6 PCE Capability Flags		9.4. SRv6 PCE Capability Flags
	IANA is requested to create a new sub-registry, named "SRv6		IANA is requested to create a new sub-registry, named "SRv6
	Capability Flag Field", within the "Path Computation Element Protocol		Capability Flag Field", within the "Path Computation Element Protocol
	(PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE-		(PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE-
	CAPABILITY sub-TLV. New values are to be assigned by Standards		CAPABILITY sub-TLV. New values are to be assigned by Standards
	Action [RFC8126]. Each bit should be tracked with the following		Action [RFC8126]. Each bit should be tracked with the following
	qualities:		qualities:
	o Bit number (counting from bit 0 as the most significant bit)		* Bit number (counting from bit 0 as the most significant bit)
	o Capability description		* Capability description
	o Defining RFC		* Defining RFC
	The following values are defined in this document:		The following values are defined in this document:
	Bit Description Reference		Bit Description Reference
	0-13 Unassigned		0-13 Unassigned
	14 Node or Adjacency This document		14 Node or Adjacency This document
	Identifier (NAI) is		Identifier (NAI) is
	supported (N)		supported (N)
	15 Unlimited Maximum SID This document		15 Unlimited Maximum SID This document
	skipping to change at page 21, line 33 ¶		skipping to change at page 21, line 33 ¶
	---------- -------		---------- -------
	10 Reception of an invalid object		10 Reception of an invalid object
	Error-value = TBD5 (Missing		Error-value = TBD5 (Missing
	PCE-SRv6-CAPABILITY sub-TLV)		PCE-SRv6-CAPABILITY sub-TLV)
	Error-value = TBD6 (Both SID and NAI are absent		Error-value = TBD6 (Both SID and NAI are absent
	in SRv6-RRO subobject)		in SRv6-RRO subobject)
	Error-value = TBD7 (RRO mixes SRv6-RRO subobjects		Error-value = TBD7 (RRO mixes SRv6-RRO subobjects
	with other subobject types)		with other subobject types)
	Error-value = TBD8 (Invalid SRv6 SID Structure)		Error-value = TBD8 (Invalid SRv6 SID Structure)
	19 Invalid Operation		19 Invalid Operation
	Error-value = TBD5 (Attempted SRv6 when the		Error-value = TBD9 (Attempted SRv6 when the
	capability was not advertised)		capability was not advertised)
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank Jeff Tentsura, Adrian Farrel, Aijun		The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun
	Wang and Khasanov Boris for valuable suggestions.		Wang and Khasanov Boris for valuable suggestions.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 23, line 16 ¶		skipping to change at page 23, line 16 ¶
	"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,		"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
	DOI 10.17487/RFC8491, November 2018,		DOI 10.17487/RFC8491, November 2018,
	<https://www.rfc-editor.org/info/rfc8491>.		<https://www.rfc-editor.org/info/rfc8491>.
	[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,		[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	and J. Hardwick, "Path Computation Element Communication		and J. Hardwick, "Path Computation Element Communication
	Protocol (PCEP) Extensions for Segment Routing", RFC 8664,		Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
	DOI 10.17487/RFC8664, December 2019,		DOI 10.17487/RFC8664, December 2019,
	<https://www.rfc-editor.org/info/rfc8664>.		<https://www.rfc-editor.org/info/rfc8664>.
			[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
			D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
			(SRv6) Network Programming", RFC 8986,
			DOI 10.17487/RFC8986, February 2021,
			<https://www.rfc-editor.org/info/rfc8986>.
	[I-D.ietf-lsr-isis-srv6-extensions]		[I-D.ietf-lsr-isis-srv6-extensions]
	Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and		Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
	Z. Hu, "IS-IS Extensions to Support Segment Routing over		Z. Hu, "IS-IS Extensions to Support Segment Routing over
	IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18		IPv6 Dataplane", Work in Progress, Internet-Draft, draft-
	(work in progress), October 2021.		ietf-lsr-isis-srv6-extensions-18, 20 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
	[I-D.ietf-spring-srv6-network-programming]		extensions-18.txt>.
	Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
	Matsushima, S., and Z. Li, "Segment Routing over IPv6
	(SRv6) Network Programming", draft-ietf-spring-srv6-
	network-programming-28 (work in progress), December 2020.
	11.2. Informative References		11.2. Informative References
	[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation		[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol Generic		Element (PCE) Communication Protocol Generic
	Requirements", RFC 4657, DOI 10.17487/RFC4657, September		Requirements", RFC 4657, DOI 10.17487/RFC4657, September
	2006, <https://www.rfc-editor.org/info/rfc4657>.		2006, <https://www.rfc-editor.org/info/rfc4657>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,		[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
	skipping to change at page 24, line 28 ¶		skipping to change at page 24, line 28 ¶
	DOI 10.17487/RFC8667, December 2019,		DOI 10.17487/RFC8667, December 2019,
	<https://www.rfc-editor.org/info/rfc8667>.		<https://www.rfc-editor.org/info/rfc8667>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
	[I-D.ietf-spring-segment-routing-policy]		[I-D.ietf-spring-segment-routing-policy]
	Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and		Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
	P. Mattes, "Segment Routing Policy Architecture", draft-		P. Mattes, "Segment Routing Policy Architecture", Work in
	ietf-spring-segment-routing-policy-14 (work in progress),		Progress, Internet-Draft, draft-ietf-spring-segment-
	October 2021.		routing-policy-14, 25 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-spring-
			segment-routing-policy-14.txt>.
	[I-D.ietf-lsr-ospfv3-srv6-extensions]		[I-D.ietf-lsr-ospfv3-srv6-extensions]
	Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,		Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
	"OSPFv3 Extensions for SRv6", draft-ietf-lsr-		"OSPFv3 Extensions for SRv6", Work in Progress, Internet-
	ospfv3-srv6-extensions-03 (work in progress), November		Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19
	2021.		November 2021, <https://www.ietf.org/archive/id/draft-
			ietf-lsr-ospfv3-srv6-extensions-03.txt>.
	[I-D.ietf-idr-bgpls-srv6-ext]		[I-D.ietf-idr-bgpls-srv6-ext]
	Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,		Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
	Bernier, D., and B. Decraene, "BGP Link State Extensions		Bernier, D., and B. Decraene, "BGP Link State Extensions
	for SRv6", draft-ietf-idr-bgpls-srv6-ext-09 (work in		for SRv6", Work in Progress, Internet-Draft, draft-ietf-
	progress), November 2021.		idr-bgpls-srv6-ext-09, 10 November 2021,
			<https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-
			srv6-ext-09.txt>.
	[I-D.ietf-pce-pcep-yang]		[I-D.ietf-pce-pcep-yang]
	Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura,		Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura,
	"A YANG Data Model for Path Computation Element		"A YANG Data Model for Path Computation Element
	Communications Protocol (PCEP)", draft-ietf-pce-pcep-		Communications Protocol (PCEP)", Work in Progress,
	yang-17 (work in progress), October 2021.		Internet-Draft, draft-ietf-pce-pcep-yang-17, 23 October
			2021, <https://www.ietf.org/archive/id/draft-ietf-pce-
			pcep-yang-17.txt>.
	Appendix A. Contributor		Appendix A. Contributor
	The following persons contributed to this document:		The following persons contributed to this document:
	Dhruv Dhody		Dhruv Dhody
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	skipping to change at page 25, line 38 ¶		skipping to change at page 25, line 41 ¶
	Beijing 100095		Beijing 100095
	China		China
	Email: pengshuping@huawei.com		Email: pengshuping@huawei.com
	Authors' Addresses		Authors' Addresses
	Cheng Li(Editor)		Cheng Li(Editor)
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing 100095		Beijing
			100095
	China		China
	EMail: c.l@huawei.com		Email: c.l@huawei.com
	Mahendra Singh Negi		Mahendra Singh Negi
	RtBrick Inc		RtBrick Inc
	Bangalore, Karnataka		Bangalore
			Karnataka
	India		India
	EMail: mahend.ietf@gmail.com		Email: mahend.ietf@gmail.com
	Siva Sivabalan		Siva Sivabalan
	Ciena Corporation		Ciena Corporation
	EMail: msiva282@gmail.com		Email: msiva282@gmail.com
	Mike Koldychev		Mike Koldychev
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Canada		Canada
	EMail: mkoldych@cisco.com		Email: mkoldych@cisco.com
	Prejeeth Kaladharan		Prejeeth Kaladharan
	RtBrick Inc		RtBrick Inc
	Bangalore, Karnataka		Bangalore
			Karnataka
	India		India
	EMail: prejeeth@rtbrick.com		Email: prejeeth@rtbrick.com
	Yongqing Zhu		Yongqing Zhu
	China Telecom		China Telecom
	109 West Zhongshan Ave, Tianhe District		109 West Zhongshan Ave, Tianhe District
	Bangalore, Guangzhou		Bangalore
			Guangzhou,
	P.R. China		P.R. China
	EMail: zhuyq8@chinatelecom.cn		Email: zhuyq8@chinatelecom.cn
End of changes. 62 change blocks.
	81 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/