< draft-wu-pce-traffic-steering-sfc-08.txt		draft-wu-pce-traffic-steering-sfc-09.txt >
	PCE Working Group Q. Wu		PCE Working Group Q. Wu
	Internet-Draft D. Dhody		Internet-Draft D. Dhody
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: September 8, 2016 M. Boucadair		Expires: March 12, 2017 M. Boucadair
	C. Jacquenet		C. Jacquenet
	Orange		Orange
	J. Tantsura		J. Tantsura
	Ericsson		September 8, 2016
	March 7, 2016
	PCEP Extensions for Service Function Chaining (SFC)		PCEP Extensions for Service Function Chaining (SFC)
	draft-wu-pce-traffic-steering-sfc-08		draft-wu-pce-traffic-steering-sfc-09
	Abstract		Abstract
	This document provides an overview of the usage of Path Computation		This document provides an overview of the usage of Path Computation
	Element (PCE) to dynamically structure service function chains.		Element (PCE) to dynamically structure service function chains.
	Service Function Chaining (SFC) is a technique that is meant to		Service Function Chaining (SFC) is a technique that is meant to
	facilitate the dynamic enforcement of differentiated traffic		facilitate the dynamic enforcement of differentiated traffic
	forwarding policies within a domain. Service function chains are		forwarding policies within a domain. Service function chains are
	composed of an ordered set of elementary Service Functions (such as		composed of an ordered set of elementary Service Functions (such as
	firewalls, load balancers) that need to be invoked according to the		firewalls, load balancers) that need to be invoked according to the
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 47 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 8, 2016.		This Internet-Draft will expire on March 12, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 25 ¶		skipping to change at page 2, line 25 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4		3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4
	4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 5		4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 6
	4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6		4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6
	4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6		4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6
	4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 6		4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 7
	4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 6		4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 7
	4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6		4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 7
	5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7		5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7		5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
	5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 7		5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 8
	5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8		5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
	7. SFP Signaling and Forwarding Considerations . . . . . . . . . 9		7. SFP Instantiation Signaling and Forwarding Considerations . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Service Function Chaining (SFC) enables the creation of composite		Service Function Chaining (SFC) enables the creation of composite
	services that consist of an ordered set of Service Functions (SF)		services that consist of an ordered set of Service Functions (SF)
	that must be applied to packets and/or frames and/or flows selected		that must be applied to packets and/or frames and/or flows selected
	as a result of service-inferred traffic classification as described		as a result of service-inferred traffic classification as described
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	fashion, or by means of traffic-engineering capabilities. In the		fashion, or by means of traffic-engineering capabilities. In the
	latter case, the SFP is precomputed, i.e., an SFP is an instantiation		latter case, the SFP is precomputed, i.e., an SFP is an instantiation
	of the defined SFC as described in [RFC7665].		of the defined SFC as described in [RFC7665].
	The computation, the selection, and the establishment of a traffic-		The computation, the selection, and the establishment of a traffic-
	engineered SFP can rely upon a set of (service-specific) policies		engineered SFP can rely upon a set of (service-specific) policies
	(forwarding and routing, QoS, security, etc., or a combination		(forwarding and routing, QoS, security, etc., or a combination
	thereof). Stateful PCE with appropriate SFC-aware PCEP extensions		thereof). Stateful PCE with appropriate SFC-aware PCEP extensions
	can be used to compute traffic-engineered SFPs.		can be used to compute traffic-engineered SFPs.
	SFC Control Element		SFC Control Plane
	+------------------------+		+------------------------+
	| stateful PCE |		|PCE based Controller |
	| +-------+ +-------+ |		I2 | +-------++-------+ |
	| |Policy | | TE-DB | |		+------------- |Policy || TE-DB | |
	| +-------+ +-------+ |		| I1 | +-------++-------+ <----+
	+----------| +-------------+ |		| +----------| +-------------+ | |
	|SFP | |LSP-DB/SFP-DB| |		| |SFP | |LSP-DB/SFP-DB| | |I2
	|Instan- | +-------------+ |		| |Instan- | +-------------+ | |
	|tiation +------------------------+		| |tiation +-----------^------------+ |policy-provisioning
	| +-----+ +-----+ +-----+		| |PCEP | |information/
	| |SF-1 | |SF-2 | |SF-3 |		| |Signaling I2 | |Carried by NETCONF,
	| | | | | | |		| | | |BGP, for example
	| +---+-+ +-+---+ +--+--+		| | | |
	| | | |		| | | |
	| ++-----++ +----+--+		| | +------V+ +----+--+
	V | | | |		V V | | | |
	+-----+ Signaling | | Signaling | | Signaling		+-----+ Forwarding| | Forwarding| | Forwarding
	| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->		| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
	Classifier | | | |		Classifier | | | |
	| | | | | |		| | | | | |
	+-----+ +-------+ +-------+		+-----+ ++-----++ +-----+-+
			| | |
			+--+--+ ++----+ +--+--+
			|SF-1 | |SF-2 | |SF-3 |
			| | | | | |
			+--+--+ +---+-+ +--+--+
			|I2 |I2 |I2
			V V V
	Figure 1: PCE-based SFP instantiation		Figure 1: PCE-based SFP instantiation
	The SFC Control Element [I-D.ietf-sfc-control-plane] is responsible		In Figure 1, the PCE-based Controller [I-D.ietf-teas-pce-central-
	for defining service instructions to bind a flow to a service		control] in the SFC Control plane is responsible for computing the
	function chain and forward such flow along the corresponding SFP. It		path for a given service function chain. This PCE-based controller
	is also responsible for defining the appropriate policies (traffic		can operate as a stateful PCE ([I-D.draft_ietf-stateful-pce]) that
	classification, forwarding and routing, etc.) that will be enforced		will provide a classifier (a headend from a PCE standpoint) with the
	by SFC Classifiers and SFF Nodes as described in [RFC7665]. The SFC		PCEP-formatted information to instantiate a given SFP. As a
	Control Element can be seen as a Policy Decision Point (PDP,		consequence, the PCE-based controller derives the set of policy-
	[RFC5394]). Such PDP can then operate a stateful PCE to compute,		provisioning information (namely SFP configuration information and
	select and establish Service Function Paths. The PCE may be co-		traffic classification rules) that will be provided to the various
	located with the SFC Control element or enabled in an external		elements (Classifier, SFF) involved in the establishment of the SFP.
	entity.
			By doing so, SFC Classifier can bind a flow to a service function
			chain and forward such flow along the corresponding SFP. The SFC
			Control Plane [I-D.ietf-sfc-control-plane] is also responsible for
			defining the appropriate policies (traffic classification, forwarding
			and routing, etc.) that will be enforced by SFC Classifiers,SFF Nodes
			and SF Nodes, as described in [RFC7665]. From that standpoint, the
			SFC Control Plane embeds a Policy Decision Point that is responsible
			for defining the SFC policies. SFC policies will be provided by the
			PDP and enforced by SFC components like classifiers and SFFs by means
			of policy-provision information. A protocol like NETCONF, BGP can be
			used to carry such policy-provisioning information.
	4. Overview of PCEP Operation in SFC-Enabled Networks		4. Overview of PCEP Operation in SFC-Enabled Networks
	A PCEP speaker indicates its ability to support PCE-computed SFP		A PCEP speaker indicates its ability to support PCE-computed SFP
	paths during the PCEP Initialization phase via a mechanism described		paths during the PCEP Initialization phase via a mechanism described
	in Section 5.1. A PCE may initiate SFPs only for PCCs that		in Section 5.1. A PCE may initiate SFPs only for PCCs that
	advertised this capability; a PCC follows the procedures described in		advertised this capability; a PCC follows the procedures described in
	this document only for sessions where the PCE advertised this		this document only for sessions where the PCE advertised this
	capability.		capability.
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 31 ¶
	a Path Computation LSP Initiate Request (PCInitiate) message to the		a Path Computation LSP Initiate Request (PCInitiate) message to the
	PCC to instantiate or delete a LSP. The Explicit Route Object (ERO)		PCC to instantiate or delete a LSP. The Explicit Route Object (ERO)
	is used to encode either a full sequence of SF instances or a		is used to encode either a full sequence of SF instances or a
	specific sequence of SFFs and SFs to establish an SFP. If the said		specific sequence of SFFs and SFs to establish an SFP. If the said
	SFFs and SFs are identified with an IP address, the IP sub-object can		SFFs and SFs are identified with an IP address, the IP sub-object can
	be used as a SF/SFF identification means. This document makes no		be used as a SF/SFF identification means. This document makes no
	change to the PCInitiate message format but extends LSP objects		change to the PCInitiate message format but extends LSP objects
	described in Section 5.2.		described in Section 5.2.
	Editor's note: In case a PCE-Initiated signaling mechanism is used to		Editor's note: In case a PCE-Initiated signaling mechanism is used to
	set up the service function path, then does the classifier / PCE-		set up the service function path, does the classifier / PCE-Initiated
	Initiated signaling protocol need to understand if the IP address is		signaling protocol need to understand whether an IP address is
	for SFF or SF or the signaling protocol is only used to signal IP		assigned to a SFF or a SF, or the signaling protocol is only used to
	addresses for SFs?		signal IP addresses for SFs?
	4.1. SFP Instantiation		4.1. SFP Instantiation
	The instantiation of a SFP is the same as defined in Section 5.3 of		The instantiation of a SFP is the same as defined in Section 5.3 of
	[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error		[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error
	codes remain unchanged.		codes remain unchanged.
	4.2. SFP Withdrawal		4.2. SFP Withdrawal
	The withdrawal of an SFP is the same as defined in Section 5.4 of		The withdrawal of an SFP is the same as defined in Section 5.4 of
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 20 ¶
	The SFP instantiation capability defined as a PCEP extension and		The SFP instantiation capability defined as a PCEP extension and
	documented in this draft MUST NOT be used if PCCs or the PCE did not		documented in this draft MUST NOT be used if PCCs or the PCE did not
	advertise their stateful SFP instantiation capability,Section 5.1.		advertise their stateful SFP instantiation capability,Section 5.1.
	If this is not the case and stateful operations on SFPs are		If this is not the case and stateful operations on SFPs are
	attempted, then a PCErr message with error-type 19 (Invalid		attempted, then a PCErr message with error-type 19 (Invalid
	Operation) and error-value TBD needs to be generated.		Operation) and error-value TBD needs to be generated.
	[Editor's note: more information on exact error value is needed]		[Editor's note: more information on exact error value is needed]
	7. SFP Signaling and Forwarding Considerations		7. SFP Instantiation Signaling and Forwarding Considerations
	The SFP instantiation mechanism described in this document is not		The PCE-initiated SFP instantiation signaling described in this
	tightly coupled to any SFP signaling mechanism. For example, Generic		document does not assume any specific mechanism to exchange SFP
	SFC Encapsulation [I-D.ietf-sfc-nsh] can be used together with the		information(e.g.,path identification
	mechanism described in this document to enable SFP forwarding. SR-		information,metadata[I-D.ietf-sfc-nsh]) and establish SFP in the data
	based approach [I-D.ietf-pce-segment-routing] can also use the		plane throughout a SFC domain. For example, such mechanism can rely
	mechanism described here and does not need any other specific		upon the use of the SFC Encapsulation defined in [I-D.ietf-sfc-nsh].
	protocol extensions.		Likewise, [I-D.ietf-teas-pce-central-control] can use the signaling
			mechanism described in this draft to enforce SFC-inferred traffic
			engineering policies and provide load balancing between service
			function nodes. The approach that relies upon the Segment Routing
			technique [I-D.ietf-pce-segment-routing] can also take advantage of
			the signaling mechanism described in this document to support Service
			Path instantiation, which does not require any additional specific
			extension to the Segment Routing machinery.
	8. Security Considerations		8. Security Considerations
	The security considerations described in [RFC5440] and		The security considerations described in [RFC5440] and
	[I-D.ietf-pce-pce-initiated-lsp] are applicable to this		[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
	specification. This document does not raise any additional security		specification. This document does not raise any additional security
	issue.		issue.
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to allocate a new code point in the PCEP TLV Type		IANA is requested to allocate a new code point in the PCEP TLV Type
	Indicators registry, as follows:		Indicators registry, as follows:
	Value Meaning Reference		Value Meaning Reference
	------- ---------------------------- --------------		------- ---------------------------- --------------
	TBD SFC-PCE-CAPABILITY This document		TBD SFC-PCE-CAPABILITY This document
	10. Acknowledgements		10. Acknowledgements
	Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and		Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
	Joel M. Halpern for the discussion in formulating the content for		Joel M. Halpern for the discussion about the content for the
	the document.		document.
	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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[I-D.ietf-pce-stateful-pce]		[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP		Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-		Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-13 (work in progress), December 2015.		pce-16 (work in progress), September 2016.
	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation		[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,		DOI 10.17487/RFC5440, March 2009,
	<http://www.rfc-editor.org/info/rfc5440>.		<http://www.rfc-editor.org/info/rfc5440>.
	[I-D.ietf-pce-pce-initiated-lsp]		[I-D.ietf-pce-pce-initiated-lsp]
	Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP		Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
	Extensions for PCE-initiated LSP Setup in a Stateful PCE		Extensions for PCE-initiated LSP Setup in a Stateful PCE
	Model", draft-ietf-pce-pce-initiated-lsp-05 (work in		Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
	progress), October 2015.		progress), July 2016.
			[I-D.ietf-teas-pce-central-control]
			Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An
			Architecture for Use of PCE and PCEP in a Network with
			Central Control", draft-ietf-teas-pce-central-control-00
			(work in progress), September 2016.
	11.2. Informative References		11.2. Informative References
	[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework		[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
	for Policy-based Admission Control", RFC 2753,		for Policy-based Admission Control", RFC 2753,
	DOI 10.17487/RFC2753, January 2000,		DOI 10.17487/RFC2753, January 2000,
	<http://www.rfc-editor.org/info/rfc2753>.		<http://www.rfc-editor.org/info/rfc2753>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<http://www.rfc-editor.org/info/rfc7665>.		<http://www.rfc-editor.org/info/rfc7665>.
	[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,
	<http://www.rfc-editor.org/info/rfc5394>.		<http://www.rfc-editor.org/info/rfc5394>.
	[I-D.ietf-sfc-control-plane]		[I-D.ietf-sfc-control-plane]
	Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,		Boucadair, M., "Service Function Chaining (SFC) Control
	Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,		Plane Components & Requirements", draft-ietf-sfc-control-
	Halpern, J., Reddy, T., and P. Patil, "Service Function		plane-07 (work in progress), August 2016.
	Chaining (SFC) Control Plane Components & Requirements",
	draft-ietf-sfc-control-plane-03 (work in progress),
	January 2016.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,		Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
	Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,		Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
	"PCEP Extensions for Segment Routing", draft-ietf-pce-		"PCEP Extensions for Segment Routing", draft-ietf-pce-
	segment-routing-06 (work in progress), August 2015.		segment-routing-07 (work in progress), March 2016.
	[I-D.ietf-sfc-nsh]		[I-D.ietf-sfc-nsh]
	Quinn, P. and U. Elzur, "Network Service Header", draft-		Quinn, P. and U. Elzur, "Network Service Header", draft-
	ietf-sfc-nsh-02 (work in progress), January 2016.		ietf-sfc-nsh-07 (work in progress), August 2016.
	Authors' Addresses		Authors' Addresses
	Qin Wu		Qin Wu
	Huawei		Huawei
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	EMail: bill.wu@huawei.com		EMail: bill.wu@huawei.com
	skipping to change at page 11, line 39 ¶		skipping to change at page 12, line 4 ¶
	INDIA		INDIA
	EMail: dhruv.ietf@gmail.com		EMail: dhruv.ietf@gmail.com
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	Rennes 35000		Rennes 35000
	France		France
	EMail: mohamed.boucadair@orange.com		EMail: mohamed.boucadair@orange.com
	Christian Jacquenet		Christian Jacquenet
	Orange		Orange
	Rennes		Rennes
	France		France
	EMail: christian.jacquenet@orange.com		EMail: christian.jacquenet@orange.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		2330 Central Expressway
	300 Holger Way		Santa Clara, CA 95050
	San Jose, CA 95134
	US		US
	EMail: Jeff.Tantsura@ericsson.com		EMail: jefftant.ietf@gmail.com
End of changes. 25 change blocks.
	75 lines changed or deleted		102 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/