Diff: draft-pan-shared-mesh-protection-01.txt - draft-pan-shared-mesh-protection-02.txt

	< draft-pan-shared-mesh-protection-01.txt	draft-pan-shared-mesh-protection-02.txt >

	IETF Ping Pan	IETF Ping Pan

	Internet Draft Mohana Srinivas	Internet Draft Rajan Rao
	Rajan Rao
	Biao Lu	Biao Lu
	(Infinera)	(Infinera)

		Luyuan Fang
		(Cisco)
		Andy Malis
		(Verizon)
	Sam Aldrin	Sam Aldrin
	(Huawei)	(Huawei)

		Mohana Singamsetty
		(Tellabs)


	Expires: September 14, 2011 March 14, 2011	Expires: January 11, 2012 July 11, 2011

	Supporting Shared Mesh Protection in MPLS-TP Networks	Supporting Shared Mesh Protection in MPLS-TP Networks


	draft-pan-shared-mesh-protection-01.txt	draft-pan-shared-mesh-protection-02.txt

	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
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79. This document may not be modified,	provisions of BCP 78 and BCP 79. This document may not be modified,
	and derivative works of it may not be created, and it may not be	and derivative works of it may not be created, and it may not be
	published except as an Internet-Draft.	published except as an Internet-Draft.

	skipping to change at page 2, line 18 ¶	skipping to change at page 2, line 24 ¶
	months and may be updated, replaced, or obsoleted by other documents	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."	reference material or to cite them other than as "work in progress."

	The list of current Internet-Drafts can be accessed at	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt	http://www.ietf.org/ietf/1id-abstracts.txt

	The list of Internet-Draft Shadow Directories can be accessed at	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html	http://www.ietf.org/shadow.html


	This Internet-Draft will expire on September 14, 2011.	This Internet-Draft will expire on January 11, 2012.

	Copyright Notice	Copyright Notice

	Copyright (c) 2011 IETF Trust and the persons identified as the	Copyright (c) 2011 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 3, line 11 ¶	skipping to change at page 3, line 15 ¶
	In this memo, we define a lightweight signaling mechanism for	In this memo, we define a lightweight signaling mechanism for
	protecting path activation in shared mesh protection-enabled MPLS-TP	protecting path activation in shared mesh protection-enabled MPLS-TP
	networks.	networks.

	Table of Contents	Table of Contents

	1. Introduction...................................................3	1. Introduction...................................................3
	2. Background.....................................................4	2. Background.....................................................4
	3. Problem Definition.............................................5	3. Problem Definition.............................................5
	4. Protection Switching...........................................6	4. Protection Switching...........................................6

	5. Activation Operation Overview..................................7	5. Activation Operation Overview..................................8
	6. Protocol Definition............................................9	6. Protocol Definition............................................9
	6.1. Activation Messages.......................................9	6.1. Activation Messages.......................................9
	6.2. Message Encapsulation....................................10	6.2. Message Encapsulation....................................10

	6.3. Reliable Messaging.......................................12	6.3. Reliable Messaging.......................................11
	6.4. Message Scoping..........................................12	6.4. Message Scoping..........................................12

	7. Processing Rules..............................................13	7. Processing Rules..............................................12
	7.1. Enable a protecting path.................................13	7.1. Enable a protecting path.................................12
	7.2. Disable a protecting path................................13	7.2. Disable a protecting path................................13
	7.3. Get protecting path status...............................14	7.3. Get protecting path status...............................14
	7.4. Acknowledgement with STATUS..............................14	7.4. Acknowledgement with STATUS..............................14
	7.5. Preemption...............................................14	7.5. Preemption...............................................14

	8. Security Consideration........................................15	8. Security Consideration........................................14
	9. IANA Considerations...........................................15	9. IANA Considerations...........................................15
	10. Normative References.........................................15	10. Normative References.........................................15
	11. Acknowledgments..............................................15	11. Acknowledgments..............................................15

	1. Introduction	1. Introduction


	Shared mesh protection is a common protection and recovery mechanism	Shared mesh protection is a common traffic protection mechanism in
	in transport networks, where multiple paths can share the same set	transport networks, where multiple paths can share the same set of
	of network resources for protection purposes.	network resources for protection purposes.

	In the context of MPLS-TP, it has been explicitly requested as a	In the context of MPLS-TP, it has been explicitly requested as a
	part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its	part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its
	operation has been further outlined in Section 4.7.6 of MPLS-TP	operation has been further outlined in Section 4.7.6 of MPLS-TP
	Survivability Framework [2].	Survivability Framework [2].


	It's important to note that each MPLS-TP LSP may be associated with	It's important to note that each MPLS-TP LSP may be associated with
	transport network resources. In event of network failure, it may	transport network resources. In event of network failure, it may
	require explicit activation on the protecting paths before switching	require explicit activation on the protecting paths before switching
	user traffic over.	user traffic over.

	In this memo, we define a lightweight signaling mechanism for	In this memo, we define a lightweight signaling mechanism for
	protecting path activation in shared mesh protection-enabled MPLS-TP	protecting path activation in shared mesh protection-enabled MPLS-TP

	networks.	networks. The framework version of the document has been presented
		in ITU-T SG15 Interim Meeting in May 2011, and is in-sync with the
		on-going G.SMP work in ITU-T.

	Here are the key design goals:	Here are the key design goals:

	1. Fast: The protocol is to activate the previously configured	1. Fast: The protocol is to activate the previously configured
	protecting paths in a timely fashion, with minimal transport and	protecting paths in a timely fashion, with minimal transport and
	processing overhead. The goal is to support 50msec end-to-end	processing overhead. The goal is to support 50msec end-to-end
	traffic switch-over in large transport networks.	traffic switch-over in large transport networks.

	2. Reliable message delivery: Activation and deactivation operation	2. Reliable message delivery: Activation and deactivation operation
	have serious impact on user traffic. This requires the protocol to	have serious impact on user traffic. This requires the protocol to

	adapt a low-overhead reliable messaging mechanism.	adapt a low-overhead reliable messaging mechanism. The activation
		messages may either traverse through a "trusted" transport
		channel, or require some level of built-in reliability mechanism.

	3. Modular: Depending on deployment scenarios, the signaling may need	3. Modular: Depending on deployment scenarios, the signaling may need
	to support functions such as preemption, resource re-allocation	to support functions such as preemption, resource re-allocation
	and bi-directional activation in a modular fashion.	and bi-directional activation in a modular fashion.

	Here are some of the conventions used in this document. The key	Here are some of the conventions used in this document. The key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [RFC2119].	document are to be interpreted as described in RFC-2119 [RFC2119].


	skipping to change at page 5, line 44 ¶	skipping to change at page 6, line 10 ¶

	All paths are assumed to be bi-directional. An edge node is denoted	All paths are assumed to be bi-directional. An edge node is denoted
	as a headend or tailend for a particular path in accordance to the	as a headend or tailend for a particular path in accordance to the
	path setup direction.	path setup direction.

	Initially, the operators setup both working and protecting paths.	Initially, the operators setup both working and protecting paths.
	During setup, the operators specify the network resources for each	During setup, the operators specify the network resources for each
	path.	path.

	The working path X and Y will configure the appropriate resources on	The working path X and Y will configure the appropriate resources on

	the intermediate nodes, however, the protecting paths, X' and Y',	the intermediate nodes, however, the protecting paths, X' and Y'
	will reserve the resources on the nodes, but won't occupy them.	will reserve the resources on the nodes, but won't occupy them.

	Depending on network planning requirements (such as SRLG), X' and Y'	Depending on network planning requirements (such as SRLG), X' and Y'
	may share the same set of resources on node E, F and G. The resource	may share the same set of resources on node E, F and G. The resource
	assignment is a part of the control-plane CAC operation taking place	assignment is a part of the control-plane CAC operation taking place
	on each node.	on each node.

	At some time, link B-C is cut. Node A will detect the outage, and	At some time, link B-C is cut. Node A will detect the outage, and

	initiate activation messages to bring up the protecting path X'. The	initiate activation messages to bring up the protecting path X' The
	intermediate nodes, E, F and G will program the switch fabric and	intermediate nodes, E, F and G will program the switch fabric and
	configure the appropriate resources. Upon the completion of the	configure the appropriate resources. Upon the completion of the

	activation, A will switch the user traffic to X'.	activation, A will switch the user traffic to X'

	The operation may have extra caveat:	The operation may have extra caveat:

	1. Preemption: Protecting paths X' and Y' may share the same	1. Preemption: Protecting paths X' and Y' may share the same
	resources on node E, F or G due to resource constraints. Y' has	resources on node E, F or G due to resource constraints. Y' has

	higher priority than that of X'. In the previous example, X' is	higher priority than that of X' In the previous example, X' is
	up and running. When there is a link outage on I-J, H can	up and running. When there is a link outage on I-J, H can

	activate its protecting path Y'. On E, F or G, Y' can take over	activate its protecting path Y' On E, F or G, Y' can take over
	the resources from X' for its own traffic. The behavior is	the resources from X' for its own traffic. The behavior is
	acceptable with the condition that A should be notified about	acceptable with the condition that A should be notified about
	the preemption action.	the preemption action.

	2. Over-subscription (1:N): A unit of network resource may be	2. Over-subscription (1:N): A unit of network resource may be
	reserved by one or multiple protecting paths. In the example,	reserved by one or multiple protecting paths. In the example,
	the network resources on E-F and F-G are shared by two	the network resources on E-F and F-G are shared by two

	protecting paths, X' and Y'. In deployment, the over-	protecting paths, X' and Y' In deployment, the over-
	subscription ratio is an important factor on network resource	subscription ratio is an important factor on network resource
	utilization.	utilization.

	4. Protection Switching	4. Protection Switching

	The entire activation and switch-over operation need to be within	The entire activation and switch-over operation need to be within
	the range of milliseconds to meet customer's expectation [1]. This	the range of milliseconds to meet customer's expectation [1]. This
	section illustrates how this may be achieved on MPLS-TP-enabled	section illustrates how this may be achieved on MPLS-TP-enabled
	transport switches. Note that this is for illustration of protection	transport switches. Note that this is for illustration of protection
	switching operation, not mandating the implementation itself.	switching operation, not mandating the implementation itself.

	skipping to change at page 7, line 46 ¶	skipping to change at page 8, line 7 ¶
	To achieve the tight end-to-end switch-over budget, it's possible to	To achieve the tight end-to-end switch-over budget, it's possible to
	implement the entire activation procedure with hardware-assistance	implement the entire activation procedure with hardware-assistance
	(such as in FPGA or ASIC).	(such as in FPGA or ASIC).

	The activation messages are encapsulated with a MPLS-TP Generic	The activation messages are encapsulated with a MPLS-TP Generic
	Associated Channel Header (GACH) [3]. Detailed message encoding is	Associated Channel Header (GACH) [3]. Detailed message encoding is
	explained in Section 6.	explained in Section 6.

	5. Activation Operation Overview	5. Activation Operation Overview


		To achieve high performance, the activation procedure is designed to
		be simple and straightforward on the network nodes.

	In this section, we describe the activation procedure using the same	In this section, we describe the activation procedure using the same
	figure shown before:	figure shown before:

	----- B ------- C ----	----- B ------- C ----
	/ \	/ \
	/ \	/ \
	A D	A D
	\ /	\ /
	\ /	\ /
	==== E === F === G ===	==== E === F === G ===

	skipping to change at page 8, line 36 ¶	skipping to change at page 8, line 44 ¶

	We assume that there is a consistent definition of priority levels	We assume that there is a consistent definition of priority levels
	among the paths throughout the network. At activation time, each	among the paths throughout the network. At activation time, each
	node may rely on the priority levels to potentially preempt other	node may rely on the priority levels to potentially preempt other
	paths.	paths.

	When the nodes detect path preemption on a particular node, they	When the nodes detect path preemption on a particular node, they
	should inform all relevant nodes to free the resources.	should inform all relevant nodes to free the resources.

	To optimize traffic protection and resource management, each headend	To optimize traffic protection and resource management, each headend

	should periodically poll the protecting paths about resource	may periodically poll the protecting paths about resource
	availability. The intermediate nodes have the option to inform the	availability. The intermediate nodes have the option to inform the

	current resource utilization.	current resource utilization. This procedure may be conducted by
		other OAM mechanisms.

	Note that, upon the detection of a working path failure, both	Note that, upon the detection of a working path failure, both
	headend and tailend may initiate the activation simultaneously	headend and tailend may initiate the activation simultaneously
	(known as bi-directional activation). This may expedite the	(known as bi-directional activation). This may expedite the
	activation time. However, both headend and tailend nodes need to	activation time. However, both headend and tailend nodes need to
	coordinate the order of protecting paths for activation, since there	coordinate the order of protecting paths for activation, since there
	may be multiple protecting paths for each working path (i.e., 1:N	may be multiple protecting paths for each working path (i.e., 1:N
	protection). For clarity, we will describe the operation from	protection). For clarity, we will describe the operation from
	headend in the memo. The tailend operation will be available in the	headend in the memo. The tailend operation will be available in the
	subsequent revisions.	subsequent revisions.

	skipping to change at page 10, line 27 ¶	skipping to change at page 10, line 36 ¶

	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| MPLS Label stack \|	\| MPLS Label stack \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| GAL \|	\| GAL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 0 0 1\|Version\| Reserved \| Activation Channel Type \|	\|0 0 0 1\|Version\| Reserved \| Activation Channel Type \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| ACH TLV Header \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Activation Message Payload \|	\| Activation Message Payload \|

	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	o GAL is described in [3]	o GAL is described in [3]

	o Activation Channel Type is the GACH channel number assigned to	o Activation Channel Type is the GACH channel number assigned to
	the protocol. This uniquely identifies the activation messages.	the protocol. This uniquely identifies the activation messages.


	o ACH TLV Header contains the message length, and is described in	Specifically, the messages have the following message format:
	[3]

	Specifically, ENABLE, DISABLE and GET messages have the following
	message format:

	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label \| Exp \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label (13) \| Exp \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 0 0 1\|Version\| Reserved \| Activation Channel Type \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Length \| Reserved \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Ver(1)\| Type \| Reserved (0) \| Seq \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Both STATUS and NOTIFY messages have the following message format:

	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label \| Exp \|S\| TTL \|	\| Label \| Exp \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Label (13) \| Exp \|S\| TTL \|	\| Label (13) \| Exp \|S\| TTL \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 0 0 1\|Version\| Reserved \| Activation Channel Type \|	\|0 0 0 1\|Version\| Reserved \| Activation Channel Type \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Length \| Reserved \|	\| Ver(1)\| Type \| Status Code \| Seq \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Ver(1)\| Type \| Reserved (0) \| Seq \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Status Code \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	Currently, the status code used for acknowledging and preemption	For STATUS and NOTIFY messages, the Status Code has the following
	notification has the following definition:	encoding value and definition:


	o 1xx: OK	o 0-19: OK


	. 101: end-to-end ack	. 1: end-to-end ack


	o 2xx: message processing errors	o 20-39: message processing errors


	. 201: no such path	. 20: no such path


	o 3xx: processing issues:	o 40-59: processing issues:


	. 301: no more resource for the path	. 40: no more resource for the path


	. 302: preempted by another path	. 41: preempted by another path


	. 303: system failure	. 42: system failure


	o 4xx: informative data:	o 60-79: informative data:


	. 401: shared resource has been taken by other paths	. 60: shared resource has been taken by other paths

	Further, for preemption notification, we may consider of using the	Further, for preemption notification, we may consider of using the
	existing MPLS-TP OAM messaging. More details will be available in	existing MPLS-TP OAM messaging. More details will be available in
	the future revisions.	the future revisions.

	6.3. Reliable Messaging	6.3. Reliable Messaging

	The activation procedure adapts a simple two-way handshake reliable	The activation procedure adapts a simple two-way handshake reliable
	messaging.	messaging.


	skipping to change at page 16, line 9 ¶	skipping to change at page 15, line 40 ¶
	11. Acknowledgments	11. Acknowledgments

	Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and	Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and
	Deborah Brungard for detailed feedback on the earlier work, and the	Deborah Brungard for detailed feedback on the earlier work, and the
	guidance and recommendation for this proposal.	guidance and recommendation for this proposal.

	We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague,	We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague,
	Ann Gui and Tony Jorgenson for discussion on network operation,	Ann Gui and Tony Jorgenson for discussion on network operation,
	feasibility and implementation methodology.	feasibility and implementation methodology.


		During ITU-T SG15 Interim meeting in May 2011, we have had long
		discussion with the G.SMP contributors, in particular Fatai Zhang,
		Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback
		and corrections.

	Authors' Addresses	Authors' Addresses

	Ping Pan	Ping Pan
	Email: ppan@infinera.com	Email: ppan@infinera.com


	Sri Mohana Satya Srinivas Singamsetty
	Email: ssingamsetty@infinera.com

	Rajan Rao	Rajan Rao
	Email: rrao@infinera.com	Email: rrao@infinera.com

	Biao Lu	Biao Lu
	Email: blu@infinera.com	Email: blu@infinera.com


		Luyuan Fang
		Email: lufang@cisco.com

		Andy Malis
		Email: andrew.g.malis@verizon.com

	Sam Aldrin	Sam Aldrin
	Email: sam.aldrin@huawei.com	Email: sam.aldrin@huawei.com


		Sri Mohana Satya Srinivas Singamsetty
		Email: SriMohanS@Tellabs.com

End of changes. 42 change blocks.
	67 lines changed or deleted	62 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/