< draft-ietf-pce-association-policy-07.txt		draft-ietf-pce-association-policy-08.txt >
	PCE Working Group S. Litkowski		PCE Working Group S. Litkowski
	Internet-Draft S. Sivabalan		Internet-Draft S. Sivabalan
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: May 2, 2020 J. Tantsura		Expires: September 10, 2020 J. Tantsura
	Apstra, Inc.		Apstra, Inc.
	J. Hardwick		J. Hardwick
	Metaswitch Networks		Metaswitch Networks
	M. Negi		M. Negi
			C. Li
	Huawei Technologies		Huawei Technologies
	October 30, 2019		March 9, 2020
	Path Computation Element communication Protocol (PCEP) extension for		Path Computation Element communication Protocol (PCEP) extension for
	associating Policies and Label Switched Paths (LSPs)		associating Policies and Label Switched Paths (LSPs)
	draft-ietf-pce-association-policy-07		draft-ietf-pce-association-policy-08
	Abstract		Abstract
	This document introduces a simple mechanism to associate policies to		This document introduces a simple mechanism to associate policies to
	a group of Label Switched Paths (LSPs) via an extension to the Path		a group of Label Switched Paths (LSPs) via an extension to the Path
	Computation Element (PCE) Communication Protocol (PCEP).		Computation Element (PCE) Communication Protocol (PCEP).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 40 ¶
	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 May 2, 2020.		This Internet-Draft will expire on September 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 30 ¶
	5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7		5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8		6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Association object Type Indicators . . . . . . . . . . . 9		8.1. Association object Type Indicators . . . . . . . . . . . 9
	8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10		8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10
	9. Manageability Considerations . . . . . . . . . . . . . . . . 10		9. Manageability Considerations . . . . . . . . . . . . . . . . 10
	9.1. Control of Function and Policy . . . . . . . . . . . . . 10		9.1. Control of Function and Policy . . . . . . . . . . . . . 10
	9.2. Information and Data Models . . . . . . . . . . . . . . . 10		9.2. Information and Data Models . . . . . . . . . . . . . . . 10
	9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10		9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10
	9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11		9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10
	9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11		9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11
	9.6. Impact on Network Operations . . . . . . . . . . . . . . 11		9.6. Impact on Network Operations . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14		Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 9 ¶
	provides context for the support of PCE Policy.		provides context for the support of PCE Policy.
	PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of		PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
	extensions to PCEP to enable active control of Multiprotocol Label		extensions to PCEP to enable active control of Multiprotocol Label
	Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS)		Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS)
	tunnels. [RFC8281] describes the set-up and teardown of PCE-		tunnels. [RFC8281] describes the set-up and teardown of PCE-
	initiated LSPs under the active stateful PCE model, without the need		initiated LSPs under the active stateful PCE model, without the need
	for local configuration on the PCC, thus allowing for a dynamic		for local configuration on the PCC, thus allowing for a dynamic
	network. Currently, the LSPs can either be signalled via Resource		network. Currently, the LSPs can either be signalled via Resource
	Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment		Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment
	routed as specified in [I-D.ietf-pce-segment-routing].		routed as specified in [RFC8664].
	[I-D.ietf-pce-association-group] introduces a generic mechanism to		[RFC8697] introduces a generic mechanism to create a grouping of LSPs
	create a grouping of LSPs which can then be used to define		which can then be used to define associations between a set of LSPs
	associations between a set of LSPs and a set of attributes (such as		and a set of attributes (such as configuration parameters or
	configuration parameters or behaviours) and is equally applicable to		behaviours) and is equally applicable to stateful PCE (active and
	stateful PCE (active and passive modes) and stateless PCE.		passive modes) and stateless PCE.
	This document specifies a PCEP extension to associate one or more		This document specifies a PCEP extension to associate one or more
	LSPs with policies using the generic association mechanism.		LSPs with policies using the generic association mechanism.
	A PCEP speaker may want to influence the PCEP peer with respect to		A PCEP speaker may want to influence the PCEP peer with respect to
	path selection and other policies. This document describes a PCEP		path selection and other policies. This document describes a PCEP
	extension to associate policies by creating Policy Association Group		extension to associate policies by creating Policy Association Group
	(PAG) and encoding this association in PCEP messages. The		(PAG) and encoding this association in PCEP messages. The
	specification is applicable to both stateful and stateless PCEP		specification is applicable to both stateful and stateless PCEP
	sessions.		sessions.
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 39 ¶
	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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Terminology		2. Terminology
	The following terminology is used in this document.		The following terminology is used in this document.
	Association parameters: As described in		Association parameters: As described in [RFC8697], the combination
	[I-D.ietf-pce-association-group], the combination of the mandatory		of the mandatory fields Association type, Association ID and
	fields Association type, Association ID and Association Source in		Association Source in the ASSOCIATION object uniquely identify the
	the ASSOCIATION object uniquely identify the association group.		association group. If the optional TLVs - Global Association
	If the optional TLVs - Global Association Source or Extended		Source or Extended Association ID are included, then they are
	Association ID are included, then they are included in combination		included in combination with mandatory fields to uniquely identify
	with mandatory fields to uniquely identify the association group.		the association group.
	Association information: As described in		Association information: As described in [RFC8697], the ASSOCIATION
	[I-D.ietf-pce-association-group], the ASSOCIATION object could		object could include other optional TLVs based on the association
	include other optional TLVs based on the association types, that		types, that provides 'information' related to the association.
	provides 'information' related to the association.
	LSR: Label Switch Router.		LSR: Label Switch Router.
	MPLS: Multiprotocol Label Switching.		MPLS: Multiprotocol Label Switching.
	PAG: Policy Association Group.		PAG: Policy Association Group.
	PAT: Policy Association Type.		PAT: Policy Association Type.
	PCC: Path Computation Client. Any client application requesting a		PCC: Path Computation Client. Any client application requesting a
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	3. Motivation		3. Motivation
	Paths computed using PCE can be subjected to various policies on both		Paths computed using PCE can be subjected to various policies on both
	PCE and PCC. For example, in a centralized traffic engineering		PCE and PCC. For example, in a centralized traffic engineering
	scenario, network operators may instantiate LSPs and specifies		scenario, network operators may instantiate LSPs and specifies
	policies for traffic steering, path monitoring, etc., for some LSPs		policies for traffic steering, path monitoring, etc., for some LSPs
	via the Stateful PCE. Similarly, a PCC could request a user- or		via the Stateful PCE. Similarly, a PCC could request a user- or
	service-specific policy to be applied at the PCE, such as constraints		service-specific policy to be applied at the PCE, such as constraints
	relaxation to meet optimal QoS and resiliency.		relaxation to meet optimal QoS and resiliency.
	PCEP speaker can use the generic mechanism as per		PCEP speaker can use the generic mechanism as per [RFC8697] to
	[I-D.ietf-pce-association-group] to associate a set of LSPs with a		associate a set of LSPs with a policy, without the need to know the
	policy, without the need to know the details of such a policy, which		details of such a policy, which simplifies network operations, avoids
	simplifies network operations, avoids frequent software upgrades, as		frequent software upgrades, as well as provides an ability to
	well as provides an ability to introduce new policy faster.		introduce new policy faster.
	PAG Y		PAG Y
	{Service-Specific Policy		{Service-Specific Policy
	for constraint		for constraint
	Initiate & Monitor LSP relaxation}		Initiate & Monitor LSP relaxation}
	| |		| |
	| PAG X PCReq/PCRpt |		| PAG X PCReq/PCRpt |
	V {Monitor LSP} {PAG Y} V		V {Monitor LSP} {PAG Y} V
	+-----+ ----------------> +-----+		+-----+ ----------------> +-----+
	_ _ _ _ _ _| PCE | | | PCE |		_ _ _ _ _ _| PCE | | | PCE |
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 7 ¶
	interface to establish a service. The PCC may also apply user- or		interface to establish a service. The PCC may also apply user- or
	service-specific policies to decide how the path selection process		service-specific policies to decide how the path selection process
	should be constrained, that is, which constraints, diversities,		should be constrained, that is, which constraints, diversities,
	optimization criterion, and constraint relaxation strategies should		optimization criterion, and constraint relaxation strategies should
	be applied in order for the service LSP(s) to have a likelihood to be		be applied in order for the service LSP(s) to have a likelihood to be
	successfully established and provide necessary QoS and resilience		successfully established and provide necessary QoS and resilience
	against network failures. The user- or service-specific policies		against network failures. The user- or service-specific policies
	applied to PCC and are then passed to the PCE along with the Path		applied to PCC and are then passed to the PCE along with the Path
	computation request, in the form of constraints [RFC5394].		computation request, in the form of constraints [RFC5394].
	PCEP speaker can use the generic mechanism as per		PCEP speaker can use the generic mechanism as per [RFC8697] to
	[I-D.ietf-pce-association-group] to associate a set of LSPs with		associate a set of LSPs with policy and its resulting path
	policy and its resulting path computation constraints. This would		computation constraints. This would simplify the path computation
	simplify the path computation message exchanges in PCEP.		message exchanges in PCEP.
	4. Overview		4. Overview
	As per [I-D.ietf-pce-association-group], LSPs are associated with		As per [RFC8697], LSPs are associated with other LSPs with which they
	other LSPs with which they interact by adding them to a common		interact by adding them to a common association group. Grouping can
	association group. Grouping can also be used to define association		also be used to define association between LSPs and policies
	between LSPs and policies associated to them. One new Association		associated to them. One new Association type is defined in this
	type is defined in this document, based on the generic Association		document, based on the generic Association object -
	object -
	o Association type = TBD1 ("Policy Association Type (PAT)" ) for		o Association type = TBD1 ("Policy Association Type (PAT)" ) for
	Policy Association Group (PAG).		Policy Association Group (PAG).
	[I-D.ietf-pce-association-group] specify the mechanism for the		[RFC8697] specify the mechanism for the capability advertisement of
	capability advertisement of the Association types supported by a PCEP		the Association types supported by a PCEP speaker by defining a
	speaker by defining a ASSOC-Type-List TLV to be carried within an		ASSOC-Type-List TLV to be carried within an OPEN object. This
	OPEN object. This capability exchange for the association type		capability exchange for the association type described in this
	described in this document (i.e. PAT) MUST be done before using the		document (i.e. PAT) MUST be done before using the policy
	policy association. Thus the PCEP speaker MUST include the PAT		association. Thus the PCEP speaker MUST include the PAT (TBD1) in
	(TBD1) in the ASSOC-Type-List TLV before using the PAG in the PCEP		the ASSOC-Type-List TLV before using the PAG in the PCEP messages.
	messages.
	This Association type is operator-configured association in nature		This Association type is operator-configured association in nature
	and created by the operator manually on the PCEP peers. An LSP		and created by the operator manually on the PCEP peers. An LSP
	belonging to this association is conveyed via PCEP messages to the		belonging to this association is conveyed via PCEP messages to the
	PCEP peer. Operator-configured Association Range need not be set for		PCEP peer. Operator-configured Association Range need not be set for
	this association-type, and MUST be ignored, so that the full range of		this association-type, and MUST be ignored, so that the full range of
	association identifier can be utilized.		association identifier can be utilized.
	A PAG can have one or more LSPs and its associated policy. The		A PAG can have one or more LSPs and its associated policy. The
	association parameters including association identifier, Association		association parameters including association identifier, Association
	type (Policy), as well as the association source IP address is		type (Policy), as well as the association source IP address is
	manually configured by the operator and is used to identify the PAG		manually configured by the operator and is used to identify the PAG
	as described in [I-D.ietf-pce-association-group]. The Global		as described in [RFC8697]. The Global Association Source and
	Association Source and Extended Association ID MAY also be included.		Extended Association ID MAY also be included.
	As per the processing rules specified in section 6.4 of		As per the processing rules specified in section 6.4 of [RFC8697], if
	[I-D.ietf-pce-association-group], if a PCEP speaker does not support		a PCEP speaker does not support this Policy Association type, it
	this Policy Association type, it would return a PCErr message with		would return a PCErr message with Error-Type 26 "Association Error"
	Error-Type 26 "Association Error" and Error-Value 1 "Association type		and Error-Value 1 "Association type is not supported". Since the PAG
	is not supported". Since the PAG is opaque in nature, the PAG and		is opaque in nature, the PAG and the policy MUST be configured on the
	the policy MUST be configured on the PCEP peers as per the operator-		PCEP peers as per the operator-configured association procedures.
	configured association procedures. All further processing is as per		All further processing is as per section 6.4 of [RFC8697]. If a PCE
	section 6.4 of [I-D.ietf-pce-association-group]. If a PCE speaker		speaker receives PAG in a PCEP message, and the policy association
	receives PAG in a PCEP message, and the policy association
	information is not configured, it MUST return a PCErr message with		information is not configured, it MUST return a PCErr message with
	Error-Type 26 "Association Error" and Error- Value 4 "Association		Error-Type 26 "Association Error" and Error- Value 4 "Association
	unknown". If some of the association information		unknown". If some of the association information [RFC8697] (the TLVs
	[I-D.ietf-pce-association-group] (the TLVs defined in this document)		defined in this document) received from the peer does not match the
	received from the peer does not match the local configured values,		local configured values, the PCEP speaker MUST reject the PCEP
	the PCEP speaker MUST reject the PCEP message and send a PCErr		message and send a PCErr message with Error-Type 26 "Association
	message with Error-Type 26 "Association Error" and Error-Value 5		Error" and Error-Value 5 "Operator-configured association information
	"Operator-configured association information mismatch".		mismatch".
	Associating a particular LSP to multiple policy groups is authorized		Associating a particular LSP to multiple policy groups is authorized
	from a protocol perspective, however there is no assurance that the		from a protocol perspective, however there is no assurance that the
	PCE will be able to apply multiple policies.		PCE will be able to apply multiple policies.
	5. Policy Association Group		5. Policy Association Group
	Association groups and their memberships are defined using the		Association groups and their memberships are defined using the
	ASSOCIATION object defined in [I-D.ietf-pce-association-group]. Two		ASSOCIATION object defined in [RFC8697]. Two object types for IPv4
	object types for IPv4 and IPv6 are defined. The ASSOCIATION object		and IPv6 are defined. The ASSOCIATION object includes "Association
	includes "Association type" indicating the type of the association		type" indicating the type of the association group. This document
	group. This document add a new Association type -		add a new Association type -
	Association type = TBD1 ("Policy Association type") for PAG.		Association type = TBD1 ("Policy Association type") for PAG.
	PAG may carry optional TLVs including but not limited to -		PAG may carry optional TLVs including but not limited to -
	o POLICY-PARAMETERS-TLV: Used to communicate opaque information		o POLICY-PARAMETERS-TLV: Used to communicate opaque information
	useful to apply the policy, described in Section 5.1.		useful to apply the policy, described in Section 5.1.
	o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor		o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
	specific behavioural information, described in [RFC7470].		specific behavioural information, described in [RFC7470].
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 25 ¶
	they see fit".		they see fit".
	Currently there are no confirmed implementations, though vendors have		Currently there are no confirmed implementations, though vendors have
	shown interest in making this as part of their roadmap. More details		shown interest in making this as part of their roadmap. More details
	to be added in a later revision.		to be added in a later revision.
	7. Security Considerations		7. Security Considerations
	This document defines one new type for association, which do not add		This document defines one new type for association, which do not add
	any new security concerns beyond those discussed in [RFC5440],		any new security concerns beyond those discussed in [RFC5440],
	[RFC8231] and [I-D.ietf-pce-association-group] in itself.		[RFC8231] and [RFC8697] in itself.
	Extra care needs to be taken by the implementation with respect to		Extra care needs to be taken by the implementation with respect to
	POLICY-PARAMETERS-TLV while decoding, verifying and applying these		POLICY-PARAMETERS-TLV while decoding, verifying and applying these
	policy variables. This TLV parsing could be exploited by an		policy variables. This TLV parsing could be exploited by an
	attacker.		attacker.
	Some deployments may find policy associations and their implications		Some deployments may find policy associations and their implications
	as extra sensitive and thus securing the PCEP session using Transport		as extra sensitive and thus securing the PCEP session using Transport
	Layer Security (TLS) [RFC8253], as per the recommendations and best		Layer Security (TLS) [RFC8253], as per the recommendations and best
	current practices in BCP 195 [RFC7525], is RECOMMENDED.		current practices in BCP 195 [RFC7525], is RECOMMENDED.
	8. IANA Considerations		8. IANA Considerations
	8.1. Association object Type Indicators		8.1. Association object Type Indicators
	This document defines a new Association type. The sub-registry		This document defines a new Association type. The sub-registry
	"ASSOCIATION Type Field" of the "Path Computation Element Protocol		"ASSOCIATION Type Field" of the "Path Computation Element Protocol
	(PCEP) Numbers" registry was originally defined in		(PCEP) Numbers" registry was originally defined in [RFC8697]. IANA
	[I-D.ietf-pce-association-group]. IANA is requested to make the		is requested to make the following allocation.
	following allocation.
	Value Name Reference		Value Name Reference
	TBD1 Policy Association [This.I-D]		TBD1 Policy Association [This.I-D]
	8.2. PCEP TLV Type Indicators		8.2. PCEP TLV Type Indicators
	The following TLV Type Indicator value is requested within the "PCEP		The following TLV Type Indicator value is requested within the "PCEP
	TLV Type Indicators" subregistry of the "Path Computation Element		TLV Type Indicators" subregistry of the "Path Computation Element
	Protocol (PCEP) Numbers" registry. IANA is requested to make the		Protocol (PCEP) Numbers" registry. IANA is requested to make the
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 32 ¶
	configuration to related policy parameters, in which case the an		configuration to related policy parameters, in which case the an
	operator MUST also be allowed to set the encoding format and order to		operator MUST also be allowed to set the encoding format and order to
	parse the associated policy parameters TLV.		parse the associated policy parameters TLV.
	9.2. Information and Data Models		9.2. Information and Data Models
	[RFC7420] describes the PCEP MIB, there are no new MIB Objects for		[RFC7420] describes the PCEP MIB, there are no new MIB Objects for
	this document.		this document.
	The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This		The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This
	module supports associations as defined in		module supports associations as defined in [RFC8697] and thus support
	[I-D.ietf-pce-association-group] and thus support the Policy		the Policy Association groups.
	Association groups.
	An implementation SHOULD allow the operator to view the PAG		An implementation SHOULD allow the operator to view the PAG
	configured. Further implementation SHOULD allow to view associations		configured. Further implementation SHOULD allow to view associations
	reported by each peer, and the current set of LSPs in the PAG.		reported by each peer, and the current set of LSPs in the PAG.
	9.3. Liveness Detection and Monitoring		9.3. Liveness Detection and Monitoring
	Mechanisms defined in this document do not imply any new liveness		Mechanisms defined in this document do not imply any new liveness
	detection and monitoring requirements in addition to those already		detection and monitoring requirements in addition to those already
	listed in [RFC5440], [RFC8231], and [RFC8281].		listed in [RFC5440], [RFC8231], and [RFC8281].
	skipping to change at page 11, line 24 ¶		skipping to change at page 11, line 18 ¶
	on other protocols.		on other protocols.
	9.6. Impact on Network Operations		9.6. Impact on Network Operations
	Mechanisms defined in this document do not have any impact on network		Mechanisms defined in this document do not have any impact on network
	operations in addition to those already listed in [RFC5440],		operations in addition to those already listed in [RFC5440],
	[RFC8231], and [RFC8281].		[RFC8231], and [RFC8281].
	10. Acknowledgments		10. Acknowledgments
	A special thanks to author of [I-D.ietf-pce-association-group], this		A special thanks to author of [RFC8697], this document borrow some of
	document borrow some of the text from it.		the text from it.
	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 12, line 5 ¶		skipping to change at page 11, line 45 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path		[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
	Computation Element Communication Protocol (PCEP)		Computation Element Communication Protocol (PCEP)
	Extensions for Stateful PCE", RFC 8231,		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>.
	[I-D.ietf-pce-association-group]		[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
	Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
	Dhody, D., and Y. Tanaka, "Path Computation Element		Dhody, D., and Y. Tanaka, "Path Computation Element
	Communication Protocol (PCEP) Extensions for Establishing		Communication Protocol (PCEP) Extensions for Establishing
	Relationships Between Sets of Label Switched Paths		Relationships between Sets of Label Switched Paths
	(LSPs)", draft-ietf-pce-association-group-10 (work in		(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
	progress), August 2019.		<https://www.rfc-editor.org/info/rfc8697>.
	11.2. Informative References		11.2. Informative References
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655,		Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<https://www.rfc-editor.org/info/rfc4655>.		<https://www.rfc-editor.org/info/rfc4655>.
	[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,		[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
	"Policy-Enabled Path Computation Framework", RFC 5394,		"Policy-Enabled Path Computation Framework", RFC 5394,
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 5 ¶
	Path Computation Element Communication Protocol (PCEP)",		Path Computation Element Communication Protocol (PCEP)",
	RFC 8253, DOI 10.17487/RFC8253, October 2017,		RFC 8253, DOI 10.17487/RFC8253, October 2017,
	<https://www.rfc-editor.org/info/rfc8253>.		<https://www.rfc-editor.org/info/rfc8253>.
	[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path		[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
	Computation Element Communication Protocol (PCEP)		Computation Element Communication Protocol (PCEP)
	Extensions for PCE-Initiated LSP Setup in a Stateful PCE		Extensions for PCE-Initiated LSP Setup in a Stateful PCE
	Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,		Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
	<https://www.rfc-editor.org/info/rfc8281>.		<https://www.rfc-editor.org/info/rfc8281>.
	[I-D.ietf-pce-segment-routing]		[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,		and J. Hardwick, "Path Computation Element Communication
	and J. Hardwick, "PCEP Extensions for Segment Routing",		Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
	draft-ietf-pce-segment-routing-16 (work in progress),		DOI 10.17487/RFC8664, December 2019,
	March 2019.		<https://www.rfc-editor.org/info/rfc8664>.
	[I-D.ietf-pce-pcep-yang]		[I-D.ietf-pce-pcep-yang]
	Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A		Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
	YANG Data Model for Path Computation Element		YANG Data Model for Path Computation Element
	Communications Protocol (PCEP)", draft-ietf-pce-pcep-		Communications Protocol (PCEP)", draft-ietf-pce-pcep-
	yang-12 (work in progress), July 2019.		yang-13 (work in progress), October 2019.
	Appendix A. Contributor Addresses		Appendix A. Contributor Addresses
	Dhruv Dhody		Dhruv Dhody
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	EMail: dhruv.ietf@gmail.com		EMail: dhruv.ietf@gmail.com
	skipping to change at line 641 ¶		skipping to change at page 15, line 32 ¶
	EMail: Jonathan.Hardwick@metaswitch.com		EMail: Jonathan.Hardwick@metaswitch.com
	Mahendra Singh Negi		Mahendra Singh Negi
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	EMail: mahend.ietf@gmail.com		EMail: mahend.ietf@gmail.com
			Cheng Li
			Huawei Technologies
			Huawei Campus, No. 156 Beiqing Rd.
			Beijing 100095
			China
			EMail: chengli13@huawei.com
End of changes. 28 change blocks.
	87 lines changed or deleted		81 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/