draft-ietf-mpls-lsp-ping-lag-multipath-01.txt		draft-ietf-mpls-lsp-ping-lag-multipath-02.txt
	Internet Engineering Task Force N. Akiya		Internet Engineering Task Force N. Akiya
	Internet-Draft Big Switch Networks		Internet-Draft Big Switch Networks
	Updates: 4379,6424 (if approved) G. Swallow		Updates: 8029 (if approved) G. Swallow
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: January 24, 2016 S. Litkowski		Expires: November 20, 2017 S. Litkowski
	B. Decraene		B. Decraene
	Orange		Orange
	J. Drake		J. Drake
	Juniper Networks		Juniper Networks
	July 23, 2015		M. Chen
			Huawei
			May 19, 2017
	Label Switched Path (LSP) Ping/Trace Multipath Support for		Label Switched Path (LSP) Ping/Trace Multipath Support for
	Link Aggregation Group (LAG) Interfaces		Link Aggregation Group (LAG) Interfaces
	draft-ietf-mpls-lsp-ping-lag-multipath-01		draft-ietf-mpls-lsp-ping-lag-multipath-02
	Abstract		Abstract
	This document defines an extension to the MPLS Label Switched Path		This document defines an extension to the MPLS Label Switched Path
	(LSP) Ping and Traceroute as specified in RFC 4379. The extension		(LSP) Ping and Traceroute as specified in RFC 8029. The extension
	allows the MPLS LSP Ping and Traceroute to discover and exercise		allows the MPLS LSP Ping and Traceroute to discover and exercise
	specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link		specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link
	Aggregation Group (LAG) interfaces.		Aggregation Group (LAG) interfaces.
	This document updates RFC4379 and RFC6424.		This document updates RFC8029.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key 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].
	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 48 ¶		skipping to change at page 2, line 4 ¶
	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 November 20, 2017.
	This Internet-Draft will expire on January 24, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	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 3, line 13 ¶		skipping to change at page 3, line 16 ¶
	12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23		12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23
	12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24		12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24
	12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24		12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	14.1. Normative References . . . . . . . . . . . . . . . . . . 25		14.1. Normative References . . . . . . . . . . . . . . . . . . 25
	14.2. Informative References . . . . . . . . . . . . . . . . . 25		14.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26		Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26
	A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26		A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26
	A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26		A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26
	A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27		A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 26
	A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27		A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	The following acronyms/terms are used in this document:		The following acronyms/terms are used in this document:
	o MPLS - Multiprotocol Label Switching.		o MPLS - Multiprotocol Label Switching.
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 44 ¶
	o LAG - Link Aggregation Group.		o LAG - Link Aggregation Group.
	o Initiator LSR - LSR which sends MPLS echo request.		o Initiator LSR - LSR which sends MPLS echo request.
	o Responder LSR - LSR which receives MPLS echo request and sends		o Responder LSR - LSR which receives MPLS echo request and sends
	MPLS echo reply.		MPLS echo reply.
	1.2. Background		1.2. Background
	The MPLS Label Switched Path (LSP) Ping and Traceroute as specified		The MPLS Label Switched Path (LSP) Ping and Traceroute as specified
	in [RFC4379] are powerful tools designed to diagnose all available		in [RFC8029] are powerful tools designed to diagnose all available
	layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3		layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3
	Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation		Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation
	Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2)		Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2)
	ECMP, are often used for various reasons. MPLS LSP Ping and		ECMP, are often used for various reasons. MPLS LSP Ping and
	Traceroute tools were not designed to discover and exercise specific		Traceroute tools were not designed to discover and exercise specific
	paths of L2 ECMP. The result raises a limitation for following		paths of L2 ECMP. The result raises a limitation for following
	scenario when LSP X traverses over LAG Y:		scenario when LSP X traverses over LAG Y:
	o Label switching of LSP X over one or more member links of LAG Y		o Label switching of LSP X over one or more member links of LAG Y
	have succeeded.		have succeeded.
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 33 ¶
	Creation of this document was motivated by issues encountered in live		Creation of this document was motivated by issues encountered in live
	networks.		networks.
	2. Overview		2. Overview
	This document defines an extension to the MPLS LSP Ping and		This document defines an extension to the MPLS LSP Ping and
	Traceroute to describe Multipath Information for LAG member links		Traceroute to describe Multipath Information for LAG member links
	separately, thus allowing MPLS LSP Ping and Traceroute to discover		separately, thus allowing MPLS LSP Ping and Traceroute to discover
	and exercise specific paths of L2 ECMP over LAG interfaces. Reader		and exercise specific paths of L2 ECMP over LAG interfaces. Reader
	is expected to be familiar with mechanics of the MPLS LSP Ping and		is expected to be familiar with mechanics of the MPLS LSP Ping and
	Traceroute described in Section 3.3 of [RFC4379] and Downstream		Traceroute described in Section 3.3 of [RFC8029] and Downstream
	Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424].		Detailed Mapping TLV (DDMAP) described in Section 3.4 of [RFC8029].
	MPLS echo request carries a DDMAP and an optional TLV to indicate		MPLS echo request carries a DDMAP and an optional TLV to indicate
	that separate load balancing information for each L2 nexthop over LAG		that separate load balancing information for each L2 nexthop over LAG
	is desired in MPLS echo reply. Responder LSR places the same		is desired in MPLS echo reply. Responder LSR places the same
	optional TLV in the MPLS echo reply to provide acknowledgement back		optional TLV in the MPLS echo reply to provide acknowledgement back
	to the initiator. It also adds, for each downstream LAG member, a		to the initiator. It also adds, for each downstream LAG member, a
	load balance information (i.e. multipath information and interface		load balance information (i.e. multipath information and interface
	index). The following figure and the texts provides an example using		index). The following figure and the texts provides an example using
	an LDP network. However the problem and the mechanism is applicable		an LDP network. However the problem and the mechanism is applicable
	to all types of LSPs which can traverse over LAG interfaces.		to all types of LSPs which can traverse over LAG interfaces.
	skipping to change at page 10, line 23 ¶		skipping to change at page 10, line 23 ¶
	sending DDMAP.		sending DDMAP.
	o The Multipath Data Sub-TLVs MUST be updated to include just one		o The Multipath Data Sub-TLVs MUST be updated to include just one
	Multipath Data Sub-TLV. The initiator MAY keep just the Multipath		Multipath Data Sub-TLV. The initiator MAY keep just the Multipath
	Data Sub-TLV corresponding to the LAG member link being traversed,		Data Sub-TLV corresponding to the LAG member link being traversed,
	or combine the Multipath Data Sub-TLVs for all LAG member links		or combine the Multipath Data Sub-TLVs for all LAG member links
	into a single Multipath Data Sub-TLV when diagnosing further		into a single Multipath Data Sub-TLV when diagnosing further
	downstream LSRs.		downstream LSRs.
	o All other fields of the DDMAP are to comply with procedures		o All other fields of the DDMAP are to comply with procedures
	described in [RFC6424].		described in [RFC8029].
	Using the DDMAP example described in the Figure 2, the DDMAP being		Using the DDMAP example described in the Figure 2, the DDMAP being
	sent by the initiator LSR through LAG member link #1 to the next		sent by the initiator LSR through LAG member link #1 to the next
	downstream LSR should be:		downstream LSR should be:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ DDMAP fields describing LAG interface with DS Flags G set ~		~ DDMAP fields describing LAG interface with DS Flags G set ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 19, line 6 ¶		skipping to change at page 19, line 6 ¶
	| Must Be Zero | Sub-TLV Length |		| Must Be Zero | Sub-TLV Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. List of Sub-TLVs .		. List of Sub-TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: Detailed Interface and Label Stack TLV		Figure 7: Detailed Interface and Label Stack TLV
	The Detailed Interface and Label Stack TLV format is derived from the		The Detailed Interface and Label Stack TLV format is derived from the
	Interface and Label Stack TLV format (from [RFC4379]). Two changes		Interface and Label Stack TLV format (from [RFC8029]). Two changes
	are introduced. First is that label stack, which is of variable		are introduced. First is that label stack, which is of variable
	length, is converted into a sub-TLV. Second is that a new sub-TLV is		length, is converted into a sub-TLV. Second is that a new sub-TLV is
	added to describe an interface index. The fields of Detailed		added to describe an interface index. The fields of Detailed
	Interface and Label Stack TLV have the same use and meaning as in		Interface and Label Stack TLV have the same use and meaning as in
	[RFC4379]. A summary of the fields taken from the Interface and		[RFC8029]. A summary of the fields taken from the Interface and
	Label Stack TLV is as below:		Label Stack TLV is as below:
	Address Type		Address Type
	The Address Type indicates if the interface is numbered or		The Address Type indicates if the interface is numbered or
	unnumbered. It also determines the length of the IP Address		unnumbered. It also determines the length of the IP Address
	and Interface fields. The resulting total for the initial part		and Interface fields. The resulting total for the initial part
	of the TLV is listed in the table below as "K Octets". The		of the TLV is listed in the table below as "K Octets". The
	Address Type is set to one of the following values:		Address Type is set to one of the following values:
	skipping to change at page 19, line 45 ¶		skipping to change at page 19, line 45 ¶
	received is numbered, then the Address Type MUST be set to IPv4		received is numbered, then the Address Type MUST be set to IPv4
	Numbered or IPv6 Numbered, the IP Address MUST be set to either		Numbered or IPv6 Numbered, the IP Address MUST be set to either
	the LSR's Router ID or the interface address, and the Interface		the LSR's Router ID or the interface address, and the Interface
	MUST be set to the interface address.		MUST be set to the interface address.
	If the interface is unnumbered, the Address Type MUST be either		If the interface is unnumbered, the Address Type MUST be either
	IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the		IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the
	LSR's Router ID, and the Interface MUST be set to the index		LSR's Router ID, and the Interface MUST be set to the index
	assigned to the interface.		assigned to the interface.
	Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379],		Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029],
	described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A		described in Section 3.4.2 of [RFC7439]. A solution should be
	solution should be considered an applied to both [RFC4379] and		considered an applied to both [RFC8029] and this document.
	this document.
	Sub-TLV Length		Sub-TLV Length
	Total length in octets of the sub-TLVs associated with this		Total length in octets of the sub-TLVs associated with this
	TLV.		TLV.
	10.1. Sub-TLVs		10.1. Sub-TLVs
	This section defines the sub-TLVs that MAY be included as part of the		This section defines the sub-TLVs that MAY be included as part of the
	Detailed Interface and Label Stack TLV.		Detailed Interface and Label Stack TLV.
	Sub-Type Value Field		Sub-Type Value Field
	--------- ------------		--------- ------------
	skipping to change at page 21, line 50 ¶		skipping to change at page 21, line 50 ¶
	An Index assigned by the LSR to this interface.		An Index assigned by the LSR to this interface.
	11. Security Considerations		11. Security Considerations
	This document extends LSP Traceroute mechanism to discover and		This document extends LSP Traceroute mechanism to discover and
	exercise L2 ECMP paths. As a result of supporting the code points		exercise L2 ECMP paths. As a result of supporting the code points
	and procedures described in this document, additional processing are		and procedures described in this document, additional processing are
	required by initiator LSRs and responder LSRs, especially to compute		required by initiator LSRs and responder LSRs, especially to compute
	and handle increasing number of multipath information. Due to		and handle increasing number of multipath information. Due to
	additional processing, it is critical that proper security measures		additional processing, it is critical that proper security measures
	described in [RFC4379] and [RFC6424] are followed.		described in [RFC8029] are followed.
	The LSP Traceroute allows an initiator LSR to discover the paths of		The LSP Traceroute allows an initiator LSR to discover the paths of
	tested LSPs, providing deep knowledge of the MPLS network. Exposing		tested LSPs, providing deep knowledge of the MPLS network. Exposing
	such information to a malicious user is considered dangerous. To		such information to a malicious user is considered dangerous. To
	prevent leakage of vital information to untrusted users, a responder		prevent leakage of vital information to untrusted users, a responder
	LSR MUST only accept MPLS echo request messages from trusted sources		LSR MUST only accept MPLS echo request messages from trusted sources
	via filtering source IP address field of received MPLS echo request		via filtering source IP address field of received MPLS echo request
	messages.		messages.
	12. IANA Considerations		12. IANA Considerations
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 23 ¶
	14. References		14. References
	14.1. Normative References		14.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>.
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,
	DOI 10.17487/RFC4379, February 2006,
	<http://www.rfc-editor.org/info/rfc4379>.
	[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
	Performing Label Switched Path Ping (LSP Ping) over MPLS
	Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
	<http://www.rfc-editor.org/info/rfc6424>.
	[RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and		[RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and
	S. Aldrin, "IANA Registries for LSP Ping Code Points",		S. Aldrin, "IANA Registries for LSP Ping Code Points",
	RFC 7537, DOI 10.17487/RFC7537, May 2015,		RFC 7537, DOI 10.17487/RFC7537, May 2015,
	<http://www.rfc-editor.org/info/rfc7537>.		<http://www.rfc-editor.org/info/rfc7537>.
	14.2. Informative References		[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
			Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
			Switched (MPLS) Data-Plane Failures", RFC 8029,
			DOI 10.17487/RFC8029, March 2017,
			<http://www.rfc-editor.org/info/rfc8029>.
	[I-D.ietf-mpls-ipv6-only-gap]		14.2. Informative References
	George, W. and C. Pignataro, "Gap Analysis for Operating
	IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-04
	(work in progress), November 2014.
	[IANA-MPLS-LSP-PING]		[IANA-MPLS-LSP-PING]
	IANA, "Multi-Protocol Label Switching (MPLS) Label		IANA, "Multi-Protocol Label Switching (MPLS) Label
	Switched Paths (LSPs) Ping Parameters",		Switched Paths (LSPs) Ping Parameters",
	<http://www.iana.org/assignments/mpls-lsp-ping-parameters/		<http://www.iana.org/assignments/mpls-lsp-ping-parameters/
	mpls-lsp-ping-parameters.xhtml>.		mpls-lsp-ping-parameters.xhtml>.
	[IEEE802.1AX]		[IEEE802.1AX]
	IEEE Std. 802.1AX, "IEEE Standard for Local and		IEEE Std. 802.1AX, "IEEE Standard for Local and
	metropolitan area networks - Link Aggregation", November		metropolitan area networks - Link Aggregation", November
	2008.		2008.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
			[RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
			Operating IPv6-Only MPLS Networks", RFC 7439,
			DOI 10.17487/RFC7439, January 2015,
			<http://www.rfc-editor.org/info/rfc7439>.
	Appendix A. LAG with L2 Switch Issues		Appendix A. LAG with L2 Switch Issues
	Several flavors of "LAG with L2 switch" provisioning models are		Several flavors of "LAG with L2 switch" provisioning models are
	described in this section, with MPLS data plane ECMP traversal		described in this section, with MPLS data plane ECMP traversal
	validation issues with each.		validation issues with each.
	A.1. Equal Numbers of LAG Members		A.1. Equal Numbers of LAG Members
	R1 ==== S1 ==== R2		R1 ==== S1 ==== R2
	skipping to change at page 28, line 4 ¶		skipping to change at page 27, line 37 ¶
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	John E. Drake		John E. Drake
	Juniper Networks		Juniper Networks
	Email: jdrake@juniper.net		Email: jdrake@juniper.net
			Mach(Guoyi) Chen
			Huawei
			Email: mach.chen@huawei.com
End of changes. 23 change blocks.
	36 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/