< draft-ietf-pce-association-policy-06.txt		draft-ietf-pce-association-policy-07.txt >
	PCE Working Group S. Litkowski		PCE Working Group S. Litkowski
	Internet-Draft Orange		Internet-Draft S. Sivabalan
	Intended status: Standards Track S. Sivabalan		Intended status: Standards Track Cisco Systems, Inc.
	Expires: February 7, 2020 Cisco Systems, Inc.		Expires: May 2, 2020 J. Tantsura
	J. Tantsura
	Apstra, Inc.		Apstra, Inc.
	J. Hardwick		J. Hardwick
	Metaswitch Networks		Metaswitch Networks
	M. Negi		M. Negi
	Huawei Technologies		Huawei Technologies
	August 6, 2019		October 30, 2019
	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-06		draft-ietf-pce-association-policy-07
	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 40 ¶		skipping to change at page 1, line 39 ¶
	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 February 7, 2020.		This Internet-Draft will expire on May 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 29 ¶
	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 . . . . . . . . . . . . . . . . 10		9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11
	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 4, line 11 ¶		skipping to change at page 4, line 9 ¶
	[I-D.ietf-pce-association-group], the ASSOCIATION object could		[I-D.ietf-pce-association-group], the ASSOCIATION object could
	include other optional TLVs based on the association types, that		include other optional TLVs based on the association 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.
	PCC: Path Computation Client. Any client application requesting a		PCC: Path Computation Client. Any client application requesting a
	path computation to be performed by a Path Computation Element.		path computation to be performed by a Path Computation Element.
	PCE: Path Computation Element. An entity (component, application,		PCE: Path Computation Element. An entity (component, application,
	or network node) that is capable of computing a network path or		or network node) that is capable of computing a network path or
	route based on a network graph and applying computational		route based on a network graph and applying computational
	constraints.		constraints.
	PCEP: Path Computation Element Communication Protocol.		PCEP: Path Computation Element Communication Protocol.
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	[I-D.ietf-pce-association-group] to associate a set of LSPs with a		[I-D.ietf-pce-association-group] to associate a set of LSPs with a
	policy, without the need to know the details of such a policy, which		policy, without the need to know the details of such a policy, which
	simplifies network operations, avoids frequent software upgrades, as		simplifies network operations, avoids frequent software upgrades, as
	well as provides an ability to introduce new policy faster.		well as provides an ability to 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 |		| PAG X PCReq/PCRpt |
	V {Monitor LSP} {PAG Y} V		V {Monitor LSP} {PAG Y} V
	+-----+ ----------------> +-----+		+-----+ ----------------> +-----+
	_ _ _ _ _ _| PCE | | | PCE |		_ _ _ _ _ _| PCE | | | PCE |
	| +-----+ | ----------> +-----+		| +-----+ | ----------> +-----+
	| PCInitiate | | PCReq		| PCInitiate | | PCReq/PCRpt
	|{PAG X} | | {PAG Y}		|{PAG X} | | {PAG Y}
	| | |		| | |
	| .-----. | | .-----.		| .-----. | | .-----.
	| ( ) | +----+ ( )		| ( ) | +----+ ( )
	| .--( )--. | |PCC1|--.--( )--.		| .--( )--. | |PCC1|--.--( )--.
	V ( ) | +----+ ( )		V ( ) | +----+ ( )
	+---+ ( ) | ( )		+---+ ( ) | ( )
	|PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network )		|PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network )
	+---+ ( ) |PCC2|------( )		+---+ ( ) |PCC2|------( )
	PAG X ( ) +----+ ( )		PAG X ( ) +----+ ( )
	{Monitor LSP} '--( )--' '--( )--'		{Monitor '--( )--' '--( )--'
	( ) ( )		LSP} ( ) ( )
	'-----' '-----'		'-----' '-----'
	Case 1: Policy requested by PCE Case 2: Policy requested by		Case 1: Policy requested by PCE Case 2: Policy requested by
	and enforced by PCC PCC and enforced by		and enforced by PCC PCC and enforced by
	PCE		PCE
	Figure 1: Sample use-cases for carrying policies over PCEP session		Figure 1: Sample use-cases for carrying policies over PCEP session
	3.1. Policy based Constraints		3.1. Policy based Constraints
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	4. Overview		4. Overview
	As per [I-D.ietf-pce-association-group], LSPs are associated with		As per [I-D.ietf-pce-association-group], LSPs are associated with
	other LSPs with which they interact by adding them to a common		other LSPs with which they interact by adding them to a common
	association group. Grouping can also be used to define association		association group. Grouping can also be used to define association
	between LSPs and policies associated to them. One new Association		between LSPs and policies associated to them. One new Association
	type is defined in this document, based on the generic Association		type is defined in this document, based on the generic Association
	object -		object -
	o Association type = TBD1 ("Policy Association Type") for Policy		o Association type = TBD1 ("Policy Association Type (PAT)" ) for
	Association Group (PAG).		Policy Association Group (PAG).
	[I-D.ietf-pce-association-group] specify the mechanism for the		[I-D.ietf-pce-association-group] specify the mechanism for the
	capability advertisement of the Association types supported by a PCEP		capability advertisement of the Association types supported by a PCEP
	speaker by defining a ASSOC-Type-List TLV to be carried within an		speaker by defining a ASSOC-Type-List TLV to be carried within an
	OPEN object. This capability exchange for the association type		OPEN object. This capability exchange for the association type
	described in this document (i.e. Policy Association Type) MUST be		described in this document (i.e. PAT) MUST be done before using the
	done before using the policy association. Thus the PCEP speaker MUST		policy association. Thus the PCEP speaker MUST include the PAT
	include the Policy Association type (TBD1) in the ASSOC-Type-List TLV		(TBD1) in the ASSOC-Type-List TLV before using the PAG in the PCEP
	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
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 42 ¶
	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].
	5.1. Policy Parameters TLV		5.1. Policy Parameters TLV
	The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in		The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in
	ASSOCIATION object (with "Policy Association type") to carry opaque		ASSOCIATION object (for PAT) to carry opaque information needed to
	information needed to apply the policy at the PCEP peer. In some		apply the policy at the PCEP peer. In some cases to apply a PCE
	cases to apply a PCE policy successfully, it is required to also		policy successfully, it is required to also associate some policy
	associate some policy parameters that needs to be evaluated, to		parameters that needs to be evaluated, to successfully apply the said
	successfully apply the said policy. This TLV is used to carry those		policy. This TLV is used to carry those policy parameters. The TLV
	policy parameters. The TLV could include one or more policy related		could include one or more policy related parameter. The encoding
	parameter. The encoding format and the order MUST be known to the		format and the order MUST be known to the PCEP peers, this could be
	PCEP peers, this could be done during the configuration of the policy		done during the configuration of the policy (and its association
	(and its association parameters) for the PAG. The TLV format is as		parameters) for the PAG. The TLV format is as per the format of the
	per the format of the PCEP TLVs, as defined in [RFC5440], and shown		PCEP TLVs, as defined in [RFC5440], and shown in Figure 2. Only one
	in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and only		POLICY-PARAMETERS-TLV can be carried and only the first occurrence is
	the first occurrence is processed and any others MUST be ignored.		processed and any others MUST be ignored.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=TBD2 | Length |		| Type=TBD2 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Policy Parameters //		// Policy Parameters //
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	[RFC8231] and [I-D.ietf-pce-association-group] in itself.		[RFC8231] and [I-D.ietf-pce-association-group] 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 [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
	[I-D.ietf-pce-association-group]. IANA is requested to make the		[I-D.ietf-pce-association-group]. IANA is requested to make the
	following allocation.		following allocation.
	Value Name Reference		Value Name Reference
	TBD1 Policy Association type [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
	following allocation.		following allocation.
	Value Description Reference		Value Description Reference
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	9.1. Control of Function and Policy		9.1. Control of Function and Policy
	An operator MUST be allowed to configure the policy associations at		An operator MUST be allowed to configure the policy associations at
	PCEP peers and associate it with the LSPs. They MAY also allow		PCEP peers and associate it with the LSPs. They MAY also allow
	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
	The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In		[RFC7420] describes the PCEP MIB, there are no new MIB Objects for
	future, this YANG module should be extended or augmented to provide		this document.
	the following additional information relating to POlicy Association
	groups.		The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This
			module supports associations as defined in
			[I-D.ietf-pce-association-group] and thus support the Policy
			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 the current		configured. Further implementation SHOULD allow to view associations
	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].		listed in [RFC5440], [RFC8231], and [RFC8281].
	9.4. Verify Correct Operations		9.4. Verify Correct Operations
	Mechanisms defined in this document do not imply any new operation		Mechanisms defined in this document do not imply any new operation
	verification requirements in addition to those already listed in		verification requirements in addition to those already listed in
	[RFC5440].		[RFC5440], [RFC8231], and [RFC8281].
	9.5. Requirements on Other Protocols		9.5. Requirements on Other Protocols
	Mechanisms defined in this document do not imply any new requirements		Mechanisms defined in this document do not imply any new requirements
	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].
	10. Acknowledgments		10. Acknowledgments
	A special thanks to author of [I-D.ietf-pce-association-group], this		A special thanks to author of [I-D.ietf-pce-association-group], this
	document borrow some of the text from it.		document borrow some of the text from it.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 25 ¶
	[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,
	DOI 10.17487/RFC5394, December 2008,		DOI 10.17487/RFC5394, December 2008,
	<https://www.rfc-editor.org/info/rfc5394>.		<https://www.rfc-editor.org/info/rfc5394>.
			[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
			Hardwick, "Path Computation Element Communication Protocol
			(PCEP) Management Information Base (MIB) Module",
			RFC 7420, DOI 10.17487/RFC7420, December 2014,
			<https://www.rfc-editor.org/info/rfc7420>.
	[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific		[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
	Constraints in the Path Computation Element Communication		Constraints in the Path Computation Element Communication
	Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,		Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
	<https://www.rfc-editor.org/info/rfc7470>.		<https://www.rfc-editor.org/info/rfc7470>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	skipping to change at page 14, line 40 ¶		skipping to change at page 14, line 40 ¶
	Xian Zhang		Xian Zhang
	Huawei Technologies		Huawei Technologies
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129		Shenzhen 518129
	P.R.China		P.R.China
	EMail: zhang.xian@huawei.com		EMail: zhang.xian@huawei.com
	Udayasree Palle		Udayasree Palle
	Huawei Technologies
	Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066
	India
	EMail: udayasreereddy@gmail.com		EMail: udayasreereddy@gmail.com
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski
	Orange
	EMail: stephane.litkowski@orange.com		Stephane Litkowski
			Cisco Systems, Inc.
			EMail: slitkows.ietf@gmail.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive		2000 Innovation Drive
	Kanata, Ontario K2K 3E8		Kanata, Ontario K2K 3E8
	Canada		Canada
	EMail: msiva@cisco.com		EMail: msiva@cisco.com
	Jeff Tantsura		Jeff Tantsura
	Apstra, Inc.		Apstra, Inc.
End of changes. 24 change blocks.
	51 lines changed or deleted		58 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/