< draft-ietf-pce-association-policy-14.txt		draft-ietf-pce-association-policy-15.txt >
	PCE Working Group S. Litkowski		PCE Working Group S. Litkowski
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track S. Sivabalan		Intended status: Standards Track S. Sivabalan
	Expires: June 11, 2021 Ciena		Expires: June 13, 2021 Ciena
	J. Tantsura		J. Tantsura
	Apstra, Inc.		Apstra, Inc.
	J. Hardwick		J. Hardwick
	Metaswitch Networks		Metaswitch Networks
	M. Negi
	RtBrick Inc
	C. Li		C. Li
	Huawei Technologies		Huawei Technologies
	December 08, 2020		December 10, 2020
	Path Computation Element (PCE) Communication Protocol (PCEP) extension		Path Computation Element (PCE) Communication Protocol (PCEP) extension
	for associating Policies and Label Switched Paths (LSPs)		for associating Policies and Label Switched Paths (LSPs)
	draft-ietf-pce-association-policy-14		draft-ietf-pce-association-policy-15
	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). The		Computation Element (PCE) Communication Protocol (PCEP). The
	extension allows a PCEP speaker to advertise to a PCEP peer that a		extension allows a PCEP speaker to advertise to a PCEP peer that a
	particular LSP belongs to a particular Policy Association Group.		particular LSP belongs to a particular Policy Association Group.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 11, 2021.		This Internet-Draft will expire on June 13, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5		3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Policy Association Group . . . . . . . . . . . . . . . . . . 7		5. Policy Association Group . . . . . . . . . . . . . . . . . . 7
	5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7		5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9		6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
	6.1. Cisco's Implementation . . . . . . . . . . . . . . . . . 9		6.1. Cisco's Implementation . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Association object Type Indicators . . . . . . . . . . . 10		8.1. Association object Type Indicators . . . . . . . . . . . 10
	8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10		8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10
	8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10		8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Manageability Considerations . . . . . . . . . . . . . . . . 11		9. Manageability Considerations . . . . . . . . . . . . . . . . 11
	9.1. Control of Function and Policy . . . . . . . . . . . . . 11		9.1. Control of Function and Policy . . . . . . . . . . . . . 11
	9.2. Information and Data Models . . . . . . . . . . . . . . . 11		9.2. Information and Data Models . . . . . . . . . . . . . . . 11
	9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11		9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11
	9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11		9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11
	9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11		9.5. Requirements on Other Protocols . . . . . . . . . . . . . 12
	9.6. Impact on Network Operations . . . . . . . . . . . . . . 11		9.6. Impact on Network Operations . . . . . . . . . . . . . . 12
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15		Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15
	Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15		Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	[RFC5440] describes the Path Computation Element Communication		[RFC5440] describes the Path Computation Element Communication
	Protocol (PCEP) which enables the communication between a Path		Protocol (PCEP) which enables the communication between a Path
	Computation Client (PCC) and a Path Control Element (PCE), or between		Computation Client (PCC) and a Path Control Element (PCE), or between
	two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides		two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides
	additional details on policy within the PCE architecture and also		additional details on policy within the PCE architecture and also
	provides context for the support of PCE Policy.		provides context for the support of PCE Policy.
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 39 ¶
	to convey traffic steering policies.		to convey traffic steering policies.
	o Maturity Level: In shipping product.		o Maturity Level: In shipping product.
	o Coverage: Partial.		o Coverage: Partial.
	o Contact: mkoldych@cisco.com		o Contact: mkoldych@cisco.com
	7. Security Considerations		7. Security Considerations
	This document defines one new type for association, which do not add		The security considerations described in [RFC8697], [RFC8231],
	any new security concerns beyond those discussed in [RFC5440],		[RFC5394], and [RFC5440] apply to the extensions described in this
	[RFC8231] and [RFC8697] in itself.		document as well. In particular, a malicious PCEP speaker could be
			spoofed and used as an attack vector by creating spurious policy
	Extra care needs to be taken by the implementation with respect to		associations as described in [RFC8697]. Further as described in
	POLICY-PARAMETERS-TLV while decoding, verifying, and applying these		[RFC8697], a spurious LSP can have policies that are inconsistent
	policy variables. This TLV parsing could be exploited by an		with those of the legitimate LSPs of the group and thus cause
	attacker.		problems in handling of the policy for the legitimate LSPs. It
			should be noted that, Policy association could provide an adversary
			with the opportunity to eavesdrop on the relationship between the
			LSPs. [RFC8697] suggest that the implementations and operators to
			use indirect values as a way to hide any sensitive business
			relationships. Thus, securing the PCEP session using Transport Layer
			Security (TLS) [RFC8253], as per the recommendations and best current
			practices in BCP 195 [RFC7525], is RECOMMENDED.
	Some deployments may find policy associations and their implications		Further, extra care needs to be taken by the implementation with
	as extra sensitive and thus securing the PCEP session using Transport		respect to POLICY-PARAMETERS-TLV while decoding, verifying, and
	Layer Security (TLS) [RFC8253], as per the recommendations and best		applying these policy variables. This TLV parsing could be exploited
	current practices in BCP 195 [RFC7525], is RECOMMENDED.		by an attacker and thus extra care must be taken while configuring
			policy association that uses POLICY-PARAMETERS-TLV and making sure
			that the data is easy to parse and verify before use.
	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 [RFC8697]. IANA		(PCEP) Numbers" registry was originally defined in [RFC8697]. IANA
	is requested to confirm the early-allocated codepoint.		is requested to confirm the early-allocated codepoint.
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, 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
			We would like to acknowledge and thank Santiago Alvarez, Zafar Ali,
			Luis Tomotaki, Victor Lopez, Rob Shakir, and Clarence Filsfils for
			working on earlier drafts with similar motivation.
	A special thanks to the authors of [RFC8697], this document borrowed		A special thanks to the authors of [RFC8697], this document borrowed
	some of the text from it. The authors would like to thank Aijun		some of the text from it. The authors would like to thank Aijun
	Wang, Peng Shuping, and Gyan Mishra for their useful comments.		Wang, Peng Shuping, and Gyan Mishra for their useful comments.
	Thanks to Hari for shepherding this document. Thanks to Deborah		Thanks to Hari for shepherding this document. Thanks to Deborah
	Brungard for being the responsible AD for this document.		Brungard for providing comments and being the responsible AD for this
			document.
	Thanks to Nic Leymann for RTGDIR review.		Thanks to Nic Leymann for RTGDIR review.
	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,
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 4 ¶
	time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact		time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact
	encoding could be the 64-bit timestamp format as defined in		encoding could be the 64-bit timestamp format as defined in
	[RFC5905].		[RFC5905].
	While the above example has a single field in the POLICY-PARAMETERS-		While the above example has a single field in the POLICY-PARAMETERS-
	TLV, it is possible to include multiple fields, but the exact order,		TLV, it is possible to include multiple fields, but the exact order,
	encoding format and meanings need to be known in advance at the PCEP		encoding format and meanings need to be known in advance at the PCEP
	peers.		peers.
	Appendix B. Contributor Addresses		Appendix B. Contributor Addresses
			Following have contributed extensively:
			Mahendra Singh Negi
			RtBrick Inc
			N-17L, 18th Cross Rd, HSR Layout
			Bangalore, Karnataka 560102
			India
			EMail: mahend.ietf@gmail.com
	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
			Following have contributed text that was incorporated:
	Qin Wu		Qin Wu
	Huawei Technologies		Huawei Technologies
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	EMail: sunseawq@huawei.com		EMail: sunseawq@huawei.com
	Xian Zhang		Xian Zhang
	Huawei Technologies		Huawei Technologies
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 36 ¶
	EMail: jefftant.ietf@gmail.com		EMail: jefftant.ietf@gmail.com
	Jonathan Hardwick		Jonathan Hardwick
	Metaswitch Networks		Metaswitch Networks
	100 Church Street		100 Church Street
	Enfield, Middlesex		Enfield, Middlesex
	UK		UK
	EMail: Jonathan.Hardwick@metaswitch.com		EMail: Jonathan.Hardwick@metaswitch.com
	Mahendra Singh Negi
	RtBrick Inc
	N-17L, 18th Cross Rd, HSR Layout
	Bangalore, Karnataka 560102
	India
	EMail: mahend.ietf@gmail.com
	Cheng Li		Cheng Li
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	EMail: c.l@huawei.com		EMail: c.l@huawei.com
End of changes. 18 change blocks.
	34 lines changed or deleted		50 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/