Diff: rfc9353.original

	rfc9353.original	rfc9353.txt


	PCE working group D. Lopez	Internet Engineering Task Force (IETF) D. Lopez
	Internet-Draft Telefonica I+D	Request for Comments: 9353 Telefonica I+D
	Updates: 5088, 5089, 8231, 8306 (if approved) Q. Wu	Updates: 5088, 5089, 8231, 8306 Q. Wu
	Intended status: Standards Track D. Dhody	Category: Standards Track D. Dhody
	Expires: 14 April 2023 Q. Ma	ISSN: 2070-1721 Q. Ma
	Huawei	Huawei
	D. King	D. King
	Old Dog Consulting	Old Dog Consulting

	11 October 2022	January 2023


	IGP extension for PCEP security capability support in PCE discovery	IGP Extension for Path Computation Element Communication Protocol (PCEP)
	draft-ietf-lsr-pce-discovery-security-support-13	Security Capability Support in PCE Discovery (PCED)

	Abstract	Abstract

	When a Path Computation Element (PCE) is a Label Switching Router	When a Path Computation Element (PCE) is a Label Switching Router

	(LSR) participating in the Interior Gateway Protocol (IGP), or even a	(LSR) or a server participating in the Interior Gateway Protocol
	server participating in the IGP, its presence and path computation	(IGP), its presence and path computation capabilities can be
	capabilities can be advertised using IGP flooding. The IGP	advertised using IGP flooding. The IGP extensions for PCE Discovery
	extensions for PCE discovery (RFC 5088 and RFC 5089) define a method	(PCED) (RFCs 5088 and 5089) define a method to advertise path
	to advertise path computation capabilities using IGP flooding for	computation capabilities using IGP flooding for OSPF and IS-IS,
	OSPF and IS-IS respectively. However these specifications lack a	respectively. However, these specifications lack a method to
	method to advertise PCE Communication Protocol (PCEP) security (e.g.,	advertise Path Computation Element Communication Protocol (PCEP)
	Transport Layer Security (TLS), TCP Authentication Option (TCP-AO))	security (e.g., Transport Layer Security (TLS) and TCP Authentication
	support capability.	Option (TCP-AO)) support capability.

	This document defines capability flag bits for the PCE-CAP-FLAGS sub-	This document defines capability flag bits for the PCE-CAP-FLAGS sub-
	TLV that can be announced as an attribute in the IGP advertisement to	TLV that can be announced as an attribute in the IGP advertisement to
	distribute PCEP security support information. In addition, this	distribute PCEP security support information. In addition, this

	document updates RFC 5088 and RFC 5089 to allow advertisement of a	document updates RFCs 5088 and 5089 to allow advertisement of a Key
	Key ID or Key Chain Name Sub-TLV to support TCP-AO security	ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.
	capability. Further, this document updates RFC 8231 and RFC 8306.	This document also updates RFCs 8231 and 8306.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.


	Internet-Drafts are working documents of the Internet Engineering	This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute	(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-	received public review and has been approved for publication by the
	Drafts is at https://datatracker.ietf.org/drafts/current/.	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	Internet-Drafts are draft documents valid for a maximum of six months	Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any	and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference	https://www.rfc-editor.org/info/rfc9353.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 14 April 2023.

	Copyright Notice	Copyright Notice


	Copyright (c) 2022 IETF Trust and the persons identified as the	Copyright (c) 2023 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
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	2. Conventions used in this document . . . . . . . . . . . . . . 4	2. Conventions Used in This Document
	3. IGP extension for PCEP security capability support . . . . . 4	3. IGP Extension for PCEP Security Capability Support
	3.1. Use of PCEP security capability support for PCE	3.1. Use of PCEP Security Capability Support for PCED
	discovery . . . . . . . . . . . . . . . . . . . . . . . . 4	3.2. KEY-ID Sub-TLV
	3.2. KEY-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 5	3.2.1. IS-IS
	3.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . 5	3.2.2. OSPF
	3.2.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . 5	3.3. KEY-CHAIN-NAME Sub-TLV
	3.3. KEY-CHAIN-NAME Sub-TLV . . . . . . . . . . . . . . . . . 6	3.3.1. IS-IS
	3.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . 6	3.3.2. OSPF
	3.3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . 7	4. Updates to RFCs
	4. Update to RFCs . . . . . . . . . . . . . . . . . . . . . . . 7	5. Backward Compatibility Considerations
	5. Backward Compatibility Considerations . . . . . . . . . . . . 8	6. Management Considerations
	6. Management Considerations . . . . . . . . . . . . . . . . . . 8	6.1. Control of Policy and Functions
	6.1. Control of Policy and Functions . . . . . . . . . . . . . 8	6.2. Information and Data Model
	6.2. Information and Data Model . . . . . . . . . . . . . . . 8	6.3. Liveness Detection and Monitoring
	6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9	6.4. Verification of Correct Operations
	6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9	6.5. Requirements on Other Protocols and Functional Components
	6.5. Requirements on Other Protocols and Functional	6.6. Impact on Network Operations
	Components . . . . . . . . . . . . . . . . . . . . . . . 9	7. Security Considerations
	6.6. Impact on Network Operations . . . . . . . . . . . . . . 9	8. IANA Considerations
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9	8.1. PCE Capability Flags
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10	8.2. PCED Sub-TLV Type Indicators
	8.1. PCE Capability Flags . . . . . . . . . . . . . . . . . . 10	9. References
	8.2. PCED sub-TLV Type Indicators . . . . . . . . . . . . . . 10	9.1. Normative References
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11	9.2. Informative References
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	Acknowledgments
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11	Authors' Addresses
	10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14

	1. Introduction	1. Introduction


	As described in [RFC5440], Path Computation Element Communication	As described in [RFC5440], privacy and integrity are important issues
	Protocol (PCEP) communication privacy and integrity are important	for communication using the Path Computation Element Communication
	issues, as an attacker that intercepts a PCEP message could obtain	Protocol (PCEP); an attacker that intercepts a PCEP message could
	sensitive information related to computed paths and resources.	obtain sensitive information related to computed paths and resources.
	Authentication and integrity checks allow the receiver of a PCEP	Authentication and integrity checks allow the receiver of a PCEP
	message to know that the message genuinely comes from the node that	message to know that the message genuinely comes from the node that

	purports to have sent it and to know whether the message has been	purports to have sent it and whether the message has been modified.
	modified.


	Among the possible solutions mentioned in that document, Transport	Among the possible solutions mentioned in [RFC5440], Transport Layer
	Layer Security (TLS) [RFC8446] provides support for peer	Security (TLS) [RFC8446] provides support for peer authentication,
	authentication, and message encryption and integrity while TCP	message encryption, and integrity while TCP-AO) [RFC5925] and
	Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms	Cryptographic Algorithms for TCP-AO [RFC5926] offer significantly
	for TCP-AO [RFC5926] offer significantly improved security for	improved security for applications using TCP. As specified in
	applications using TCP. As specified in section 4 of [RFC8253], in	Section 4 of [RFC8253], the PCC needs to know whether the PCE server
	order for a Path Computation Client (PCC) to establish a connection	supports TLS or TCP-AO as a secure transport in order for a Path
	with a PCE server using TLS or TCP-AO, the PCC needs to know whether	Computation Client (PCC) to establish a connection with a PCE server
	PCE server supports TLS or TCP-AO as a secure transport.	using TLS or TCP-AO.

	[RFC5088] and [RFC5089] define a method to advertise path computation	[RFC5088] and [RFC5089] define a method to advertise path computation

	capabilities using IGP flooding for OSPF and IS-IS respectively.	capabilities using IGP flooding for OSPF and IS-IS, respectively.
	However, these specifications lack a method to advertise PCEP	However, these specifications lack a method to advertise PCEP

	security (e.g., TLS) support capability.	security (e.g., TLS and TCP-AO) support capability.

	This document defines capability flag bits for the PCE-CAP-FLAGS sub-	This document defines capability flag bits for the PCE-CAP-FLAGS sub-
	TLV that can be announced as attributes in the IGP advertisement to	TLV that can be announced as attributes in the IGP advertisement to
	distribute PCEP security support information. In addition, this	distribute PCEP security support information. In addition, this
	document updates [RFC5088] and [RFC5089] to allow advertisement of a	document updates [RFC5088] and [RFC5089] to allow advertisement of a

	Key ID or Key Chain Name Sub-TLV to support TCP-AO security	KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security
	capability.	capability.


	As per [RFC5088], the IANA created a top-level OSPF registry, the	IANA created a top-level registry titled "Path Computation Element
	"Path Computation Element (PCE) Capability Flags" registry. This	(PCE) Capability Flags" per [RFC5088]. This document updates
	document updates [RFC5088] and moves the registry to "Interior	[RFC5088] and moves it to follow the heading of the "Interior Gateway
	Gateway Protocol (IGP) Parameters". [RFC5089] states that the IS-IS	Protocol (IGP) Parameters" registry. [RFC5089] states that the IS-IS
	uses the same registry as OSPF. This document updates [RFC5089] to	PCE-CAP-FLAGS sub-TLV uses the same registry as OSPF. This document
	refer to the new IGP registry. Further, this document updates	updates [RFC5089] to refer to the new IGP registry. Further, this
	[RFC8231] where it references the registry location as "Open Shortest	document updates [RFC8231] where it references the registry location
	Path First (OSPF) Parameters" registry to "Interior Gateway Protocol	as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry to
	(IGP) Parameters" registry. This document updates [RFC8306] where it	the "Interior Gateway Protocol (IGP) Parameters" registry. This
	uses the term "OSPF PCE Capability Flag" and request assignment from	document also updates [RFC8306] by changing the term "OSPF PCE
	OSPF Parameters registry with "PCE Capability Flag" and the IGP	Capability Flag" to read as "Path Computation Element (PCE)
	Parameters registry.	Capability Flags" and to note the corresponding registry now exists
		in the "Interior Gateway Protocol (IGP) Parameters" registry.


	Note that [RFC5557] uses the term "OSPF registry" instead of the "IGP	\| Note that [RFC5557] uses the term "OSPF registry" instead of
	registry" whereas [RFC8623] and [RFC9168] uses the term "OSPF	\| the "IGP registry", whereas [RFC8623] and [RFC9168] use the
	Parameters" instead of "IGP Parameters".	\| term "OSPF Parameters" instead of "IGP Parameters".


	Note that the PCEP Open message exchange is another way to discover	\| Note that the PCEP Open message exchange is another way to
	PCE capabilities information, but in this instance, the TCP security	\| discover PCE capabilities information; however, in this
	related key parameters need to be known before the PCEP session is	\| instance, the TCP-security-related key parameters need to be
	established and the PCEP Open messages are exchanged. Thus, the use	\| known before the PCEP session is established and the PCEP Open
	of the PCE discovery and capabilities advertisement of the IGP needs	\| messages are exchanged. Thus, the IGP advertisement and
	to be leveraged.	\| flooding mechanisms need to be leveraged for PCE discovery and
		\| capabilities advertisement.


	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

	"OPTIONAL" in this document are to be interpreted as described in BCP	"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.


	3. IGP extension for PCEP security capability support	3. IGP Extension for PCEP Security Capability Support

	[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF	[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF
	Router Information Link State Advertisement (LSA) as defined in	Router Information Link State Advertisement (LSA) as defined in

	[RFC7770] to facilitate PCE discovery using OSPF. This document	[RFC7770] to facilitate PCED using OSPF. This document defines two
	defines two capability flag bits in the OSPF PCE Capability Flags to	capability flag bits in the OSPF PCE Capability Flags to indicate
	indicate TCP Authentication Option (TCP-AO) support	TCP-AO support [RFC5925] [RFC5926] and PCEP over TLS support
	[RFC5925][RFC5926] and PCEP over TLS support [RFC8253] respectively.	[RFC8253], respectively.


	Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE	Similarly, [RFC5089] defines the PCED sub-TLV for use in PCED using
	discovery using IS-IS. This document will use the same flag for the	IS-IS. This document will use the same flag for the OSPF PCE
	OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP	Capability Flags sub-TLV to allow IS-IS to indicate TCP-AO support
	Authentication Option (TCP-AO) support, PCEP over TLS support	and PCEP over TLS support, respectively.
	respectively.

	The IANA assignments for shared OSPF and IS-IS Security Capability	The IANA assignments for shared OSPF and IS-IS Security Capability

	Flags are documented in Section 8.1 ("PCE Capability Flags") of this	Flags are documented in Section 8.1 of this document.
	document.


	3.1. Use of PCEP security capability support for PCE discovery	3.1. Use of PCEP Security Capability Support for PCED


	TCP-AO, PCEP over TLS support flag bits are advertised using IGP	TCP-AO and PCEP over TLS support flag bits are advertised using IGP
	flooding.	flooding.


	* PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO	* PCE supports TCP-AO: IGP advertisement SHOULD include a TCP-AO
	support flag bit.	support flag bit.

	* PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS	* PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS
	support flag bit.	support flag bit.

	If the PCE supports multiple security mechanisms, it SHOULD include	If the PCE supports multiple security mechanisms, it SHOULD include
	all corresponding flag bits in its IGP advertisement.	all corresponding flag bits in its IGP advertisement.

	A client's configuration MAY indicate that support for a given	A client's configuration MAY indicate that support for a given
	security capability is required. If a client is configured to	security capability is required. If a client is configured to

	skipping to change at page 5, line 21 ¶	skipping to change at line 205 ¶
	that the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given	that the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given
	server is set before it opens a connection to that server.	server is set before it opens a connection to that server.
	Similarly, if the client is configured to require that its PCE server	Similarly, if the client is configured to require that its PCE server
	supports TLS, the client MUST verify that the PCEP over TLS support	supports TLS, the client MUST verify that the PCEP over TLS support
	flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set	flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set
	before it opens a connection to that server.	before it opens a connection to that server.

	3.2. KEY-ID Sub-TLV	3.2. KEY-ID Sub-TLV

	The KEY-ID sub-TLV specifies an identifier that can be used by the	The KEY-ID sub-TLV specifies an identifier that can be used by the

	PCC to identify the TCP-AO key [RFC5925] (referred to as KeyID).	PCC to identify the TCP-AO key (referred to as "KeyID" in [RFC5925]).

	3.2.1. IS-IS	3.2.1. IS-IS

	The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within	The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within

	the IS-IS Router CAPABILITY TLV when the capability flag bit of PCE-	the IS-IS Router CAPABILITY TLV when the capability flag bit of the
	CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP Authentication	PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO support.
	Option (TCP-AO) support.

	The KEY-ID sub-TLV has the following format:	The KEY-ID sub-TLV has the following format:


	Type: 6	Type: 6


	Length: 1	Length: 1


	KeyID: The one octet Key ID as per [RFC5925] to uniquely identify	KeyID: The one-octet KeyID as per [RFC5925] to uniquely identify the
	the Master Key Tuple (MKT).	Master Key Tuple (MKT).

	3.2.2. OSPF	3.2.2. OSPF

	Similarly, this sub-TLV MAY be present in the PCED TLV carried within	Similarly, this sub-TLV MAY be present in the PCED TLV carried within

	OSPF Router Information LSA when the capability flag bit of PCE-CAP-	the OSPF Router Information LSA when the capability flag bit of the
	FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.	PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.


	The format of KEY-ID sub-TLV is as follows:	The format of the KEY-ID sub-TLV is as follows:

	1 2 3	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type = 6 \| Length \|	\| Type = 6 \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| KeyID \| Reserved \|	\| KeyID \| Reserved \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Type: 6	Type: 6


	Length: 4	Length: 4


	KeyID: The one octet Key ID as per [RFC5925] to uniquely identify	KeyID: The one octet KeyID as per [RFC5925] to uniquely identify the
	the Master Key Tuple (MKT).	MKT.


	Reserved: MUST be set to zero while sending and ignored on	Reserved: MUST be set to zero while sending and ignored on receipt.
	receipt.

	3.3. KEY-CHAIN-NAME Sub-TLV	3.3. KEY-CHAIN-NAME Sub-TLV


	The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used	The KEY-CHAIN-NAME sub-TLV specifies a key chain name that can be
	by the PCC to identify the keychain. The keychain name could be	used by the PCC to identify the key chain. The key chain name could
	manually configured via CLI or installed in the YANG datastore (see	be manually configured via command-line interface (CLI) or installed
	[RFC8177]) at the PCC.	in the YANG datastore (see [RFC8177]) at the PCC.

	3.3.1. IS-IS	3.3.1. IS-IS

	The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried	The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried
	within the IS-IS Router CAPABILITY TLV when the capability flag bit	within the IS-IS Router CAPABILITY TLV when the capability flag bit

	of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP	of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO
	Authentication Option (TCP-AO) support.	support.

	The KEY-CHAIN-NAME sub-TLV has the following format:	The KEY-CHAIN-NAME sub-TLV has the following format:


	Type: 7	Type: 7


	Length: Variable, encodes the length of the value field.	Length: Variable, encodes the length of the value field.


	Key Name: The Key Chain Name contains a string of 1 to 255 octets	Key Chain Name: The Key Chain Name contains a string of 1 to 255
	to be used to identify the key chain. It MUST be encoded using	octets to be used to identify the key chain. It MUST be encoded
	UTF-8. A receiving entity MUST NOT interpret invalid UTF-8	using UTF-8. A receiving entity MUST NOT interpret invalid UTF-8
	sequences and ignore them. This field is not NULL terminated.	sequences and ignore them. This field is not NULL terminated.
	UTF-8 "Shortest Form" encoding is REQUIRED to guard against the	UTF-8 "Shortest Form" encoding is REQUIRED to guard against the
	technical issues outlined in [UTR36].	technical issues outlined in [UTR36].

	3.3.2. OSPF	3.3.2. OSPF

	Similarly, this sub-TLV MAY be present in the PCED TLV carried within	Similarly, this sub-TLV MAY be present in the PCED TLV carried within

	the OSPF Router Information LSA when the capability flag bit of PCE-	the OSPF Router Information LSA when the capability flag bit of the
	CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support. The	PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support. The
	sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned.	sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned.

	The format of KEY-CHAIN-NAME sub-TLV is as follows:	The format of KEY-CHAIN-NAME sub-TLV is as follows:

	1 2 3	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type = 7 \| Length \|	\| Type = 7 \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	// Key Chain Name //	// Key Chain Name //
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Type: 7	Type: 7


	Length: Variable, padding is not included in the Length field	Length: Variable, padding is not included in the Length field.


	Key Name: The Key Chain Name contains a string of 1 to 255 octets	Key Chain Name: The Key Chain Name contains a string of 1 to 255
	to be used to identify the key chain. It MUST be encoded using	octets to be used to identify the key chain. It MUST be encoded
	UTF-8. A receiving entity MUST NOT interpret invalid UTF-8	using UTF-8. A receiving entity MUST NOT interpret invalid UTF-8
	sequences and ignore them. This field is not NULL terminated.	sequences and ignore them. This field is not NULL terminated.
	UTF-8 "Shortest Form" encoding is REQUIRED to guard against the	UTF-8 "Shortest Form" encoding is REQUIRED to guard against the
	technical issues outlined in [UTR36]. The sub-TLV MUST be zero-	technical issues outlined in [UTR36]. The sub-TLV MUST be zero-
	padded so that the sub-TLV is 4-octet aligned.	padded so that the sub-TLV is 4-octet aligned.


	4. Update to RFCs	4. Updates to RFCs

	Section 4 of [RFC5088] states that no new sub-TLVs will be added to	Section 4 of [RFC5088] states that no new sub-TLVs will be added to

	the PCED TLV, and no new PCE information will be carried in the	the PCED TLV and no new PCE information will be carried in the Router
	Router Information LSA. This document updates [RFC5088] by allowing	Information LSA. This document updates [RFC5088] by allowing the two
	the two sub-TLVs defined in this document to be carried in the PCED	sub-TLVs defined in this document to be carried in the PCED TLV
	TLV advertised in the Router Information LSA.	advertised in the Router Information LSA.

	Section 4 of [RFC5089] states that no new sub-TLVs will be added to	Section 4 of [RFC5089] states that no new sub-TLVs will be added to

	the PCED TLV, and no new PCE information will be carried in the	the PCED TLV and no new PCE information will be carried in the Router
	Router CAPABLITY TLV. This document updates [RFC5089] by allowing	CAPABILITY TLV. This document updates [RFC5089] by allowing the two
	the two sub-TLVs defined in this document to be carried in the PCED	sub-TLVs defined in this document to be carried in the PCED TLV
	TLV advertised in the Router CAPABILITY TLV.	advertised in the Router CAPABILITY TLV.

	This introduction of additional sub-TLVs should be viewed as an	This introduction of additional sub-TLVs should be viewed as an

	exception to the [RFC5088][RFC5089] policy, justified by the	exception to the policies in [RFC5088] and [RFC5089], which is
	requirement to discover the PCEP security support prior to	justified by the requirement to discover the PCEP security support
	establishing a PCEP session. The restrictions defined in	prior to establishing a PCEP session. The restrictions defined in
	[RFC5088][RFC5089] should still be considered to be in place. If in	[RFC5088] and [RFC5089] should still be considered to be in place.
	the future new advertisements are required, alternative mechanisms	If new advertisements are required in the future, alternative
	such as using [RFC6823] or [I-D.ietf-lsr-ospf-transport-instance]	mechanisms such as using [RFC6823] or [LSR-OSPF-TRANSPORT-INSTANCE]
	should be considered.	should be considered.


	The registry for the PCE Capability Flags assigned in section 8.3 of	The registry for the PCE Capability Flags assigned in Section 8.3 of
	[RFC5557], section 8.1 of [RFC8231], section 6.9 of [RFC8306],	[RFC5557], Section 8.1 of [RFC8231], Section 6.9 of [RFC8306],
	section 11.1 of [RFC8623], and section 10.5 of [RFC9168] has changed	Section 11.1 of [RFC8623], and Section 10.5 of [RFC9168] has changed
	to the IGP Parameters "Path Computation Element (PCE) Capability	to the IGP Parameters "Path Computation Element (PCE) Capability
	Flags" registry created in this document.	Flags" registry created in this document.

	5. Backward Compatibility Considerations	5. Backward Compatibility Considerations

	An LSR that does not support the IGP PCE capability bits specified in	An LSR that does not support the IGP PCE capability bits specified in
	this document silently ignores those bits.	this document silently ignores those bits.

	An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs	An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs

	specified in this document silently ignores these sub-TLVs.	specified in this document silently ignores those sub-TLVs.

	IGP extensions defined in this document do not introduce any new	IGP extensions defined in this document do not introduce any new
	interoperability issues.	interoperability issues.

	6. Management Considerations	6. Management Considerations


	Manageability considerations for PCE Discovery are addressed in	Manageability considerations for PCED are addressed in Section 4.10
	Section 4.10 of [RFC4674] and Section 9 of [RFC5088] [RFC5089].	of [RFC4674], Section 9 of [RFC5088], and Section 9 of [RFC5089].

	6.1. Control of Policy and Functions	6.1. Control of Policy and Functions

	A PCE implementation SHOULD allow the following parameters to be	A PCE implementation SHOULD allow the following parameters to be
	configured on the PCE:	configured on the PCE:

	* support for TCP-AO	* support for TCP-AO

	* the KeyID used by TCP-AO	* the KeyID used by TCP-AO

	* Key Chain Name	* Key Chain Name

	* support for TLS	* support for TLS

	6.2. Information and Data Model	6.2. Information and Data Model


	The YANG model for PCEP [I-D.ietf-pce-pcep-yang] supports PCEP	The YANG module for PCEP [PCE-PCEP-YANG] supports PCEP security
	security parameters (key, key chain, and TLS).	parameters (key, key chain, and TLS).

	6.3. Liveness Detection and Monitoring	6.3. Liveness Detection and Monitoring

	Normal operations of the IGP meet the requirements for liveness	Normal operations of the IGP meet the requirements for liveness
	detection and monitoring.	detection and monitoring.


	6.4. Verify Correct Operations	6.4. Verification of Correct Operations

	The correlation of PCEP security information advertised against	The correlation of PCEP security information advertised against
	information received can be achieved by comparing the information in	information received can be achieved by comparing the information in
	the PCED sub-TLV received by the PCC with that stored at the PCE	the PCED sub-TLV received by the PCC with that stored at the PCE
	using the PCEP YANG.	using the PCEP YANG.

	6.5. Requirements on Other Protocols and Functional Components	6.5. Requirements on Other Protocols and Functional Components

	There are no new requirements on other protocols.	There are no new requirements on other protocols.

	6.6. Impact on Network Operations	6.6. Impact on Network Operations

	Frequent changes in PCEP security information advertised in the PCED	Frequent changes in PCEP security information advertised in the PCED
	sub-TLV may have a significant impact on IGP and might destabilize	sub-TLV may have a significant impact on IGP and might destabilize
	the operation of the network by causing the PCCs to reconnect	the operation of the network by causing the PCCs to reconnect

	sessions with PCE(s). Section 4.10.4 of [RFC4674] and Section 9.6 of	sessions with PCEs. Section 4.10.4 of [RFC4674], Section 9.6 of
	[RFC5088] [RFC5089] list techniques that are applicable to this	[RFC5088], and Section 9.6 of [RFC5089] list techniques that are
	document as well.	applicable to this document as well.

	7. Security Considerations	7. Security Considerations

	Security considerations as specified by [RFC5088] and [RFC5089] are	Security considerations as specified by [RFC5088] and [RFC5089] are
	applicable to this document.	applicable to this document.


	As described in Section 10.2 of [RFC5440], an PCEP speaker MUST	As described in Section 10.2 of [RFC5440], a PCEP speaker MUST
	support TCP MD5 [RFC2385], so no capability advertisement is needed	support TCP MD5 [RFC2385], so no capability advertisement is needed
	to indicate support. However, as noted in [RFC6952], TCP MD5 has	to indicate support. However, as noted in [RFC6952], TCP MD5 has
	been obsoleted by TCP-AO [RFC5925] because of security concerns.	been obsoleted by TCP-AO [RFC5925] because of security concerns.

	However, TCP-AO is not widely implemented and so it is, therefore,	TCP-AO is not widely implemented; therefore, it is RECOMMENDED that
	RECOMMENDED (per [RFC8253] which updates [RFC5440]) that PCEP is	PCEP be secured using TLS per [RFC8253] (which updates [RFC5440]).
	secured using TLS. An implementation SHOULD offer at least one of	An implementation SHOULD offer at least one of the two security
	the two security capabilities defined in this document.	capabilities defined in this document.

	The information related to PCEP security is sensitive and due care	The information related to PCEP security is sensitive and due care
	needs to be taken by the operator. This document defines new	needs to be taken by the operator. This document defines new
	capability bits that are susceptible to a downgrade attack by setting	capability bits that are susceptible to a downgrade attack by setting

	them to zero. The content of Key ID or Key Chain Name Sub-TLV can be	them to zero. The content of the Key-ID or KEY-CHAIN-NAME sub-TLV
	altered to enable an on-path attack. Thus, before advertising the	can be altered to enable an on-path attack. Thus, before advertising
	PCEP security parameters, using the mechanism described in this	the PCEP security parameters by using the mechanism described in this
	document, the IGP MUST be known to provide authentication and	document, the IGP MUST be known to provide authentication and
	integrity for the PCED TLV using the mechanisms defined in [RFC5304],	integrity for the PCED TLV using the mechanisms defined in [RFC5304],

	[RFC5310] or [RFC5709].	[RFC5310], or [RFC5709].


	Moreover, as stated in the Security Considerations of [RFC5088] and	Moreover, as stated in the security considerations of [RFC5088] and
	[RFC5089], there are no mechanisms defined in OSPF or IS-IS to	[RFC5089], there are no mechanisms defined in OSPF or IS-IS to
	protect the confidentiality of the PCED TLV. For this reason, the	protect the confidentiality of the PCED TLV. For this reason, the

	operator must ensure that no private data is carried in the TLV, e.g.	operator must ensure that no private data is carried in the TLV. For
	that key-ids or key-chain names do not reveal sensitive information	example, the operator must ensure that KeyIDs or key chain names do
	about the network.	not reveal sensitive information about the network.

	8. IANA Considerations	8. IANA Considerations

	8.1. PCE Capability Flags	8.1. PCE Capability Flags


	IANA is requested to move the "Path Computation Element (PCE)	IANA has moved the "Path Computation Element (PCE) Capability Flags"
	Capability Flags" registry from the "Open Shortest Path First v2	registry from the "Open Shortest Path First v2 (OSPFv2) Parameters"
	(OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP)	grouping to the "Interior Gateway Protocol (IGP) Parameters"
	Parameters" grouping.	grouping.


	IANA is requested to make the following additional assignments from	IANA has made the following additional assignments from the "Path
	the "Path Computation Element (PCE) Capability Flags" registry.	Computation Element (PCE) Capability Flags" registry:


	Bit Capability Description Reference	+=====+========================+===========+
	xx TCP-AO Support [This.I.D]	\| Bit \| Capability Description \| Reference \|
	xx PCEP over TLS support [This.I.D]	+=====+========================+===========+
		\| 17 \| TCP-AO Support \| RFC 9353 \|
		+-----+------------------------+-----------+
		\| 18 \| PCEP over TLS support \| RFC 9353 \|
		+-----+------------------------+-----------+


	The grouping is located at: https://www.iana.org/assignments/igp-	Table 1: Path Computation Element (PCE)
	parameters/igp-parameters.xhtml.	Capability Flags Registrations


	8.2. PCED sub-TLV Type Indicators	The grouping is located at: <https://www.iana.org/assignments/igp-
		parameters/>.


	The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they	8.2. PCED Sub-TLV Type Indicators
	did not create a registry for it. This document requests IANA to
	create a new registry called "PCED sub-TLV type indicators" under the	The PCED sub-TLVs are defined in [RFC5088] and [RFC5089], but a
	"Interior Gateway Protocol (IGP) Parameters" grouping. The	corresponding IANA registry was not created. IANA has created a new
		registry called "PCE Discovery (PCED) Sub-TLV Type Indicators" under
		the "Interior Gateway Protocol (IGP) Parameters" registry. The
	registration policy for this registry is "Standards Action"	registration policy for this registry is "Standards Action"
	[RFC8126]. Values in this registry come from the range 0-65535.	[RFC8126]. Values in this registry come from the range 0-65535.


	This registry should be populated with:	This registry is initially populated as follows:


	Value Description Reference	+=======+=================+====================+
	0 Reserved [This.I.D][RFC5088]	\| Value \| Description \| Reference \|
	1 PCE-ADDRESS [This.I.D][RFC5088]	+=======+=================+====================+
	2 PATH-SCOPE [This.I.D][RFC5088]	\| 0 \| Reserved \| RFC 9353, RFC 5088 \|
	3 PCE-DOMAIN [This.I.D][RFC5088]	+-------+-----------------+--------------------+
	4 NEIG-PCE-DOMAIN [This.I.D][RFC5088]	\| 1 \| PCE-ADDRESS \| RFC 9353, RFC 5088 \|
	5 PCE-CAP-FLAGS [This.I.D][RFC5088]	+-------+-----------------+--------------------+
	6 KEY-ID [This.I.D]	\| 2 \| PATH-SCOPE \| RFC 9353, RFC 5088 \|
	7 KEY-CHAIN-NAME [This.I.D]	+-------+-----------------+--------------------+
		\| 3 \| PCE-DOMAIN \| RFC 9353, RFC 5088 \|
		+-------+-----------------+--------------------+
		\| 4 \| NEIG-PCE-DOMAIN \| RFC 9353, RFC 5088 \|
		+-------+-----------------+--------------------+
		\| 5 \| PCE-CAP-FLAGS \| RFC 9353, RFC 5088 \|
		+-------+-----------------+--------------------+
		\| 6 \| KEY-ID \| RFC 9353 \|
		+-------+-----------------+--------------------+
		\| 7 \| KEY-CHAIN-NAME \| RFC 9353 \|
		+-------+-----------------+--------------------+

		Table 2: Initial Contents of the PCED Sub-
		TLV Type Indicators Registry

	This registry is used by both the OSPF PCED TLV and the IS-IS PCED	This registry is used by both the OSPF PCED TLV and the IS-IS PCED
	sub-TLV.	sub-TLV.


	This grouping is located at: https://www.iana.org/assignments/igp-	This grouping is located at: <https://www.iana.org/assignments/igp-
	parameters/igp-parameters.xhtml.	parameters/>.

	9. Acknowledgments

	The authors of this document would also like to thank Acee Lindem,
	Julien Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch, Aijun Wang,
	Adrian Farrel for the review and comments.

	The authors would also like to special thank Michale Wang for his
	major contributions to the initial version.

	Thanks to John Scudder for providing an excellent AD review. Thanks
	to Carlos Pignataro, Yaron Sheffer, Ron Bonica, and Will (Shucheng)
	LIU for directorate reviews.

	Thanks to Lars Eggert, Robert Wilton, Roman Danyliw, Eric Vyncke,
	Paul Wouters, Murray Kucherawy, and Warren Kumari for IESG reviews.


	10. References	9. References


	10.1. Normative References	9.1. Normative References


	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs
	Requirement Levels", BCP 14, RFC 2119,	to Indicate 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>.


	[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.	[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., Zhang,
	Zhang, "OSPF Protocol Extensions for Path Computation	R., and RFC Publisher, "OSPF Protocol Extensions for Path
	Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,	Computation Element (PCE) Discovery", RFC 5088,
	January 2008, <https://www.rfc-editor.org/info/rfc5088>.	DOI 10.17487/RFC5088, January 2008,
		<https://www.rfc-editor.org/info/rfc5088>.
	[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
	Zhang, "IS-IS Protocol Extensions for Path Computation
	Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
	January 2008, <https://www.rfc-editor.org/info/rfc5089>.

	[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
	Computation Element Communication Protocol (PCEP)
	Requirements and Protocol Extensions in Support of Global
	Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
	July 2009, <https://www.rfc-editor.org/info/rfc5557>.

	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.

	[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
	"PCEPS: Usage of TLS to Provide a Secure Transport for the
	Path Computation Element Communication Protocol (PCEP)",
	RFC 8253, DOI 10.17487/RFC8253, October 2017,
	<https://www.rfc-editor.org/info/rfc8253>.

	[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
	Zhang, "YANG Data Model for Key Chains", RFC 8177,
	DOI 10.17487/RFC8177, June 2017,
	<https://www.rfc-editor.org/info/rfc8177>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.


	[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and	[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., Zhang,
	S. Shaffer, "Extensions to OSPF for Advertising Optional	R., and RFC Publisher, "IS-IS Protocol Extensions for Path
	Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,	Computation Element (PCE) Discovery", RFC 5089,
	February 2016, <https://www.rfc-editor.org/info/rfc7770>.	DOI 10.17487/RFC5089, January 2008,
		<https://www.rfc-editor.org/info/rfc5089>.


	[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic	[RFC5304] Li, T., Atkinson, R., and RFC Publisher, "IS-IS
	Authentication", RFC 5304, DOI 10.17487/RFC5304, October	Cryptographic Authentication", RFC 5304,
	2008, <https://www.rfc-editor.org/info/rfc5304>.	DOI 10.17487/RFC5304, October 2008,
		<https://www.rfc-editor.org/info/rfc5304>.

	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,

	and M. Fanto, "IS-IS Generic Cryptographic	Fanto, M., and RFC Publisher, "IS-IS Generic Cryptographic
	Authentication", RFC 5310, DOI 10.17487/RFC5310, February	Authentication", RFC 5310, DOI 10.17487/RFC5310, February
	2009, <https://www.rfc-editor.org/info/rfc5310>.	2009, <https://www.rfc-editor.org/info/rfc5310>.


		[RFC5557] Lee, Y., Le Roux, JL., King, D., Oki, E., and RFC
		Publisher, "Path Computation Element Communication
		Protocol (PCEP) Requirements and Protocol Extensions in
		Support of Global Concurrent Optimization", RFC 5557,
		DOI 10.17487/RFC5557, July 2009,
		<https://www.rfc-editor.org/info/rfc5557>.

	[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,	[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,

	Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic	Li, T., Atkinson, R., and RFC Publisher, "OSPFv2 HMAC-SHA
	Authentication", RFC 5709, DOI 10.17487/RFC5709, October	Cryptographic Authentication", RFC 5709,
	2009, <https://www.rfc-editor.org/info/rfc5709>.	DOI 10.17487/RFC5709, October 2009,
		<https://www.rfc-editor.org/info/rfc5709>.


	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for	[RFC5925] Touch, J., Mankin, A., Bonica, R., and RFC Publisher, "The
	Writing an IANA Considerations Section in RFCs", BCP 26,	TCP Authentication Option", RFC 5925,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,	DOI 10.17487/RFC5925, June 2010,
		<https://www.rfc-editor.org/info/rfc5925>.

		[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R.,
		Shaffer, S., and RFC Publisher, "Extensions to OSPF for
		Advertising Optional Router Capabilities", RFC 7770,
		DOI 10.17487/RFC7770, February 2016,
		<https://www.rfc-editor.org/info/rfc7770>.

		[RFC8126] Cotton, M., Leiba, B., Narten, T., and RFC Publisher,
		"Guidelines for Writing an IANA Considerations Section in
		RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.	<https://www.rfc-editor.org/info/rfc8126>.


	[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path	[RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs
	Computation Element Communication Protocol (PCEP)	Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174,
	Extensions for Stateful PCE", RFC 8231,	DOI 10.17487/RFC8174, May 2017,
		<https://www.rfc-editor.org/info/rfc8174>.

		[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., Zhang, J.,
		and RFC Publisher, "YANG Data Model for Key Chains",
		RFC 8177, DOI 10.17487/RFC8177, June 2017,
		<https://www.rfc-editor.org/info/rfc8177>.

		[RFC8231] Crabbe, E., Minei, I., Medved, J., Varga, R., and RFC
		Publisher, "Path Computation Element Communication
		Protocol (PCEP) Extensions for Stateful PCE", RFC 8231,
	DOI 10.17487/RFC8231, September 2017,	DOI 10.17487/RFC8231, September 2017,
	<https://www.rfc-editor.org/info/rfc8231>.	<https://www.rfc-editor.org/info/rfc8231>.


	[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,	[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., and
	"Extensions to the Path Computation Element Communication	RFC Publisher, "PCEPS: Usage of TLS to Provide a Secure
	Protocol (PCEP) for Point-to-Multipoint Traffic	Transport for the Path Computation Element Communication
	Engineering Label Switched Paths", RFC 8306,	Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October
		2017, <https://www.rfc-editor.org/info/rfc8253>.

		[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., King, D., and RFC
		Publisher, "Extensions to the Path Computation Element
		Communication Protocol (PCEP) for Point-to-Multipoint
		Traffic Engineering Label Switched Paths", RFC 8306,
	DOI 10.17487/RFC8306, November 2017,	DOI 10.17487/RFC8306, November 2017,
	<https://www.rfc-editor.org/info/rfc8306>.	<https://www.rfc-editor.org/info/rfc8306>.


	[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful	[RFC8623] Palle, U., Dhody, D., Tanaka, Y., Beeram, V., and RFC
	Path Computation Element (PCE) Protocol Extensions for	Publisher, "Stateful Path Computation Element (PCE)
	Usage with Point-to-Multipoint TE Label Switched Paths	Protocol Extensions for Usage with Point-to-Multipoint TE
	(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,	Label Switched Paths (LSPs)", RFC 8623,
		DOI 10.17487/RFC8623, June 2019,
	<https://www.rfc-editor.org/info/rfc8623>.	<https://www.rfc-editor.org/info/rfc8623>.


	[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation	[RFC9168] Dhody, D., Farrel, A., Li, Z., and RFC Publisher, "Path
	Element Communication Protocol (PCEP) Extension for Flow	Computation Element Communication Protocol (PCEP)
	Specification", RFC 9168, DOI 10.17487/RFC9168, January	Extension for Flow Specification", RFC 9168,
	2022, <https://www.rfc-editor.org/info/rfc9168>.	DOI 10.17487/RFC9168, January 2022,
		<https://www.rfc-editor.org/info/rfc9168>.


	10.2. Informative References	9.2. Informative References


	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5	[LSR-OSPF-TRANSPORT-INSTANCE]
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August	Lindem, A., Qu, Y., Roy, A., and S. Mirtorabi, "OSPF-GT
	1998, <https://www.rfc-editor.org/info/rfc2385>.	(Generalized Transport)", Work in Progress, Internet-
		Draft, draft-ietf-lsr-ospf-transport-instance-04, 3
		January 2023, <https://datatracker.ietf.org/doc/html/
		draft-ietf-lsr-ospf-transport-instance-04>.


	[RFC4674] Le Roux, J.L., Ed., "Requirements for Path Computation	[PCE-PCEP-YANG]
	Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,	Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
	October 2006, <https://www.rfc-editor.org/info/rfc4674>.	"A YANG Data Model for Path Computation Element
		Communications Protocol (PCEP)", Work in Progress,
		Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October
		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
		pce-pcep-yang-20>.


	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation	[RFC2385] Heffernan, A. and RFC Publisher, "Protection of BGP
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,	Sessions via the TCP MD5 Signature Option", RFC 2385,
	DOI 10.17487/RFC5440, March 2009,	DOI 10.17487/RFC2385, August 1998,
		<https://www.rfc-editor.org/info/rfc2385>.

		[RFC4674] Le Roux, J.L., Ed. and RFC Publisher, "Requirements for
		Path Computation Element (PCE) Discovery", RFC 4674,
		DOI 10.17487/RFC4674, October 2006,
		<https://www.rfc-editor.org/info/rfc4674>.

		[RFC5440] Vasseur, JP., Ed., Le Roux, JL., Ed., and RFC Publisher,
		"Path Computation Element (PCE) Communication Protocol
		(PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009,
	<https://www.rfc-editor.org/info/rfc5440>.	<https://www.rfc-editor.org/info/rfc5440>.


	[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms	[RFC5926] Lebovitz, G., Rescorla, E., and RFC Publisher,
	for the TCP Authentication Option (TCP-AO)", RFC 5926,	"Cryptographic Algorithms for the TCP Authentication
	DOI 10.17487/RFC5926, June 2010,	Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June
	<https://www.rfc-editor.org/info/rfc5926>.	2010, <https://www.rfc-editor.org/info/rfc5926>.


	[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising	[RFC6823] Ginsberg, L., Previdi, S., Shand, M., and RFC Publisher,
	Generic Information in IS-IS", RFC 6823,	"Advertising Generic Information in IS-IS", RFC 6823,
	DOI 10.17487/RFC6823, December 2012,	DOI 10.17487/RFC6823, December 2012,
	<https://www.rfc-editor.org/info/rfc6823>.	<https://www.rfc-editor.org/info/rfc6823>.


	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of	[RFC6952] Jethanandani, M., Patel, K., Zheng, L., and RFC Publisher,
	BGP, LDP, PCEP, and MSDP Issues According to the Keying	"Analysis of BGP, LDP, PCEP, and MSDP Issues According to
	and Authentication for Routing Protocols (KARP) Design	the Keying and Authentication for Routing Protocols (KARP)
	Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,	Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
	<https://www.rfc-editor.org/info/rfc6952>.	<https://www.rfc-editor.org/info/rfc6952>.


	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol	[RFC8446] Rescorla, E. and RFC Publisher, "The Transport Layer
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,	Security (TLS) Protocol Version 1.3", RFC 8446,
		DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.	<https://www.rfc-editor.org/info/rfc8446>.


	[I-D.ietf-pce-pcep-yang]	[UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security
	Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,	Considerations", Unicode Technical Report #36, August
	"A YANG Data Model for Path Computation Element	2010, <https://www.unicode.org/unicode/reports/tr36/>.
	Communications Protocol (PCEP)", Work in Progress,
	Internet-Draft, draft-ietf-pce-pcep-yang-19, 11 July 2022,
	<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-yang-
	19.txt>.


	[I-D.ietf-lsr-ospf-transport-instance]	Acknowledgments
	Lindem, A., Qu, Y., Roy, A., and S. Mirtorabi, "OSPF-GT
	(Generalized Transport)", Work in Progress, Internet-
	Draft, draft-ietf-lsr-ospf-transport-instance-03, 9 July
	2022, <https://www.ietf.org/archive/id/draft-ietf-lsr-
	ospf-transport-instance-03.txt>.


	[UTR36] Davis, M., "Unicode Technical Report #36, Character	The authors of this document would like to thank Acee Lindem, Julien
	Encoding Model",	Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch, Aijun Wang, and
	UTR17 https://www.unicode.org/unicode/reports/tr36/,	Adrian Farrel for the review and comments.
	February 2005.
		The authors would also like to give special thanks to Michale Wang
		for his major contributions to the initial draft version.

		Thanks to John Scudder for providing an excellent AD review. Thanks
		to Carlos Pignataro, Yaron Sheffer, Ron Bonica, and Will (Shucheng)
		LIU for directorate reviews.

		Thanks to Lars Eggert, Robert Wilton, Roman Danyliw, Éric Vyncke,
		Paul Wouters, Murray Kucherawy, and Warren Kumari for IESG reviews.

	Authors' Addresses	Authors' Addresses

	Diego R. Lopez	Diego R. Lopez
	Telefonica I+D	Telefonica I+D
	Spain	Spain
	Email: diego.r.lopez@telefonica.com	Email: diego.r.lopez@telefonica.com

	Qin Wu	Qin Wu
	Huawei Technologies	Huawei Technologies

	101 Software Avenue, Yuhua District	Yuhua District
		101 Software Avenue
	Nanjing	Nanjing
	Jiangsu, 210012	Jiangsu, 210012
	China	China
	Email: bill.wu@huawei.com	Email: bill.wu@huawei.com

	Dhruv Dhody	Dhruv Dhody
	Huawei Technologies	Huawei Technologies
	Divyashree Techno Park, Whitefield	Divyashree Techno Park, Whitefield
	Bangalore 560037	Bangalore 560037
	Karnataka	Karnataka

	skipping to change at page 15, line 4 ¶	skipping to change at line 688 ¶
	China	China
	Email: bill.wu@huawei.com	Email: bill.wu@huawei.com

	Dhruv Dhody	Dhruv Dhody
	Huawei Technologies	Huawei Technologies
	Divyashree Techno Park, Whitefield	Divyashree Techno Park, Whitefield
	Bangalore 560037	Bangalore 560037
	Karnataka	Karnataka
	India	India
	Email: dhruv.ietf@gmail.com	Email: dhruv.ietf@gmail.com


	Qiufang Ma	Qiufang Ma

	Huawei	Huawei Technologies
	101 Software Avenue, Yuhua District	Yuhua District
		101 Software Avenue
	Nanjing	Nanjing
	Jiangsu, 210012	Jiangsu, 210012
	China	China
	Email: maqiufang1@huawei.com	Email: maqiufang1@huawei.com

	Daniel King	Daniel King
	Old Dog Consulting	Old Dog Consulting
	United Kingdom	United Kingdom
	Email: daniel@olddog.co.uk	Email: daniel@olddog.co.uk

End of changes. 102 change blocks.
	354 lines changed or deleted	383 lines changed or added
This html diff was produced by rfcdiff 1.48.