< draft-ietf-pce-segment-routing-ipv6-11.txt		draft-ietf-pce-segment-routing-ipv6-12.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: 15 July 2022 RtBrick Inc		Expires: 5 September 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
	11 January 2022		4 March 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-11		draft-ietf-pce-segment-routing-ipv6-12
	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 IGPs.
	IGPs. A Segment Routed Path can be derived from a variety of		A Segment Routed Path can be derived from a variety of mechanisms,
	mechanisms, including an IGP Shortest Path Tree (SPT), explicit		including an IGP Shortest Path Tree (SPT), explicit configuration, or
	configuration, or a Path Computation Element (PCE).		a Path Computation Element (PCE).
	Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE		Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
	should be able to compute SR-Path for both MPLS and IPv6 forwarding		should be able to compute SR-Path for both MPLS and IPv6 forwarding
	plane. This document describes the extensions required for SR		plane. This document describes the extensions required for SR
	support for IPv6 data plane in Path Computation Element communication		support for IPv6 data plane in Path Computation Element communication
	Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS		Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS
	is described in RFC 8664. This document extends it to support SRv6		is described in RFC 8664. This document extends it to support SRv6
	(SR over IPv6).		(SR over IPv6).
	Requirements Language		Requirements Language
	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 15 July 2022.		This Internet-Draft will expire on 5 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3.1.2. Order of the Optional fields . . . . . . . . . . 13
			4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . . . . 16
	5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15		5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 16
	5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16		5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 17
	5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17		5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Manageability Considerations . . . . . . . . . . . . . . . . 17		7. Manageability Considerations . . . . . . . . . . . . . . . . 18
	7.1. Control of Function and Policy . . . . . . . . . . . . . 17		7.1. Control of Function and Policy . . . . . . . . . . . . . 18
	7.2. Information and Data Models . . . . . . . . . . . . . . . 17		7.2. Information and Data Models . . . . . . . . . . . . . . . 18
	7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17		7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18
	7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18		7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18
	7.5. Requirements On Other Protocols . . . . . . . . . . . . . 18		7.5. Requirements On Other Protocols . . . . . . . . . . . . . 19
	7.6. Impact On Network Operations . . . . . . . . . . . . . . 18		7.6. Impact On Network Operations . . . . . . . . . . . . . . 19
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
	8.1. Cisco's Commercial Delivery . . . . . . . . . . . . . . . 18		8.1. Cisco's Commercial Delivery . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 19		9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 20
	9.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 19		9.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 20
	9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 20		9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 21
	9.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 20		9.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 21
	9.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 21		9.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 21
	9.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 21		9.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 22
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.1. Normative References . . . . . . . . . . . . . . . . . . 21		11.1. Normative References . . . . . . . . . . . . . . . . . . 22
	11.2. Informative References . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 25		Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	As per [RFC8402], with Segment Routing (SR), a node steers a packet		As per [RFC8402], with Segment Routing (SR), a node steers a packet
	through an ordered list of instructions, called segments. A segment		through an ordered list of instructions, called segments. A segment
	can represent any instruction, topological or service-based. A		can represent any instruction, topological or service-based. A
	segment can have a semantic local to an SR node or global within an		segment can have a semantic local to an SR node or global within an
	SR domain. SR allows to enforce a flow through any path and service		SR domain. SR allows to enforce a flow through any path and service
	chain while maintaining per-flow state only at the ingress node of		chain while maintaining per-flow state only at the ingress node of
	the SR domain. Segments can be derived from different components:		the SR domain. Segments can be derived from different components:
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	set to TBD3, the suboject is a SRv6-ERO subobject representing a SRv6		set to TBD3, the suboject is a SRv6-ERO subobject representing a SRv6
	SID.		SID.
	Length: Contains the total length of the subobject in octets. The		Length: Contains the total length of the subobject in octets. The
	Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO		Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO
	subobject MUST contain at least one of a SRv6-SID or an NAI. The S		subobject MUST contain at least one of a SRv6-SID or an NAI. The S
	and F bit in the Flags field indicates whether the SRv6-SID or NAI		and F bit in the Flags field indicates whether the SRv6-SID or NAI
	fields are absent.		fields are absent.
	NAI Type (NT): Indicates the type and format of the NAI contained in		NAI Type (NT): Indicates the type and format of the NAI contained in
	the object body, if any is present. If the F bit is set to zero (see		the object body, if any is present. If the F bit is set to one (see
	below) then the NT field has no meaning and MUST be ignored by the		below) then the NT field has no meaning and MUST be ignored by the
	receiver. This document reuses NT types defined in [RFC8664]:		receiver. This document reuses NT types defined in [RFC8664]:
	If NT value is 0, the NAI MUST NOT be included.		If NT value is 0, the NAI MUST NOT be included.
	When NT value is 2, the NAI is as per the 'IPv6 Node ID' format		When NT value is 2, the NAI is as per the 'IPv6 Node ID' format
	defined in [RFC8664], which specifies an IPv6 address. This is		defined in [RFC8664], which specifies an IPv6 address. This is
	used to identify the owner of the SRv6 Identifier. This is		used to identify the owner of the SRv6 Identifier. This is
	optional, as the LOC (the locater portion) of the SRv6 SID serves		optional, as the LOC (the locater portion) of the SRv6 SID serves
	a similar purpose (when present).		a similar purpose (when present).
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	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.
	4.3.1.1. SID Structure		4.3.1.1. SID Structure
	The SID Structure is an optional part of the SR-ERO subobject, as		The SID Structure is an optional part of the SR-ERO subobject, as
	described in Section 4.3.1. It is formatted as shown in the		described in Section 4.3.1.
	following figure.
			[RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a
			locator (LOC) is encoded in the L most significant bits of the SID,
			followed by F bits of function (FUNCT) and A bits of arguments (ARG).
			A locator may be represented as B:N where B is the SRv6 SID locator
			block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is
			the identifier of the parent node instantiating the SID called
			locator node.
			It is formatted as shown in the 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
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 33 ¶
	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.
	The sum of all four sizes in the SID Structure must be lower or equal		The sum of all four sizes in the SID Structure must be lower or equal
	to 128 bits. If the sum of all four sizes advertised in the SID		to 128 bits. If the sum of all four sizes advertised in the SID
	Structure is larger than 128 bits, the corresponding SRv6 SID MUST be		Structure is larger than 128 bits, the corresponding SRv6 SID MUST be
	considered as an Error. A PCErr message with Error-Type = 10		considered invalid and a PCErr message with Error-Type = 10
	("Reception of an invalid object") and Error-Value = TBD ("Invalid		("Reception of an invalid object") and Error-Value = TBD ("Invalid
	SRv6 SID Structure").		SRv6 SID Structure") is returned.
	Reserved: MUST be set to zero while sending and ignored on receipt.		Reserved: MUST be set to zero while sending and ignored on receipt.
	Flags: Currentky no flags are defined. Unassigned bits must be set		Flags: Currently no flags are defined. Unassigned bits must be set
	to zero while sending and ignored on receipt.		to zero while sending and ignored on receipt.
	The SRv6 SID Structure TLV provides the detailed encoding information		The SRv6 SID Structure provides the detailed encoding information of
	of an SRv6 SID, which is useful in the use cases that require to know		an SRv6 SID, which is useful in the use cases that require to know
	the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID		the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID
	and its structure information, the SRv6 SID can be parsed based on		and its structure information, the SRv6 SID can be parsed based on
	the SRv6 SID Structure TLV and/or possible local policies. The		the SRv6 SID Structure and/or possible local policies. The SRv6 SID
	cunsumers of SRv6 SID structure MAY be other use cases, and the		Structure could be used by the PCE for ease of operations and
	processing and usage of SRv6 SID structure TLV are different based on		monitoring. For example, this information could be used for
	use cases. This is out of the scope of this document, and will be		validation of SRv6 SIDs being instantiated in the network and checked
	described in other documents.		for conformance to the SRv6 SID allocation scheme chosen by the
			operator as described in Section 3.2 of [RFC8986]. In the future,
			PCE could also be used for verification and the automation for
			securing the SRv6 domain by provisioning filtering rules at SR domain
			boundaries as described in Section 5 of [RFC8754]. The details of
			these potential applications are outside the scope of this document.
			4.3.1.2. Order of the Optional fields
			The optional elements in the SRv6-ERO subobject i.e. SRv6 SID, NAI
			and the SID Structure MUST be encoded in the order as depicted in
			Figure 2. The presence of each of them is indicated by the
			respective flags i.e. S flag, F flag and T flag.
			To allow for future compatibility, any optional element added to the
			SRv6-ERO subobject in future MUST specify the order of the optional
			element and request IANA to allocate a flag to indicate its presence
			from the subregistry created in Section 9.2.
	4.4. RRO		4.4. RRO
	In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO.		In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO.
	4.4.1. SRv6-RRO Subobject		4.4.1. SRv6-RRO Subobject
	A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per		A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per
	[RFC8231]. The RRO on this message represents the SID list that was		[RFC8231]. The RRO on this message represents the SID list that was
	applied by the PCC, that is, the actual path taken. The procedures		applied by the PCC, that is, the actual path taken. The procedures
	skipping to change at page 13, line 44 ¶		skipping to change at page 14, line 33 ¶
	The format of the SRv6-RRO subobject is the same as that of the		The format of the SRv6-RRO subobject is the same as that of the
	SRv6-ERO subobject, but without the L flag.		SRv6-ERO subobject, but without the L flag.
	The V flag has no meaning in the SRv6-RRO and is ignored on receipt		The V flag has no meaning in the SRv6-RRO and is ignored on receipt
	at the PCE.		at the PCE.
	Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as		Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as
	per [RFC8664].		per [RFC8664].
			The ordering of optional elements in the SRv6-RRO subobject as same
			as described in Section 4.3.1.2.
	5. Procedures		5. Procedures
	5.1. Exchanging the SRv6 Capability		5.1. Exchanging the SRv6 Capability
	A PCC indicates that it is capable of supporting the head-end		A PCC indicates that it is capable of supporting the head-end
	functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in		functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in
	the Open message that it sends to a PCE. A PCE indicates that it is		the Open message that it sends to a PCE. A PCE indicates that it is
	capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY		capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY
	sub-TLV in the Open message that it sends to a PCC.		sub-TLV in the Open message that it sends to a PCC.
	If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a		If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
	PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is		PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is
	skipping to change at page 24, line 30 ¶		skipping to change at page 25, line 20 ¶
	[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", Work in		P. Mattes, "Segment Routing Policy Architecture", Work in
	Progress, Internet-Draft, draft-ietf-spring-segment-		Progress, Internet-Draft, draft-ietf-spring-segment-
	routing-policy-14, 25 October 2021,		routing-policy-18, 17 February 2022,
	<https://www.ietf.org/archive/id/draft-ietf-spring-		<https://www.ietf.org/archive/id/draft-ietf-spring-
	segment-routing-policy-14.txt>.		segment-routing-policy-18.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", Work in Progress, Internet-		"OSPFv3 Extensions for SRv6", Work in Progress, Internet-
	Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19		Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19
	November 2021, <https://www.ietf.org/archive/id/draft-		November 2021, <https://www.ietf.org/archive/id/draft-
	ietf-lsr-ospfv3-srv6-extensions-03.txt>.		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", Work in Progress, Internet-Draft, draft-ietf-		for SRv6", Work in Progress, Internet-Draft, draft-ietf-
	idr-bgpls-srv6-ext-09, 10 November 2021,		idr-bgpls-srv6-ext-09, 10 November 2021,
	<https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-		<https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-
	srv6-ext-09.txt>.		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)", Work in Progress,		Communications Protocol (PCEP)", Work in Progress,
	Internet-Draft, draft-ietf-pce-pcep-yang-17, 23 October		Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January
	2021, <https://www.ietf.org/archive/id/draft-ietf-pce-		2022, <https://www.ietf.org/archive/id/draft-ietf-pce-
	pcep-yang-17.txt>.		pcep-yang-18.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
End of changes. 24 change blocks.
	51 lines changed or deleted		83 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/