< draft-song-mpls-extension-header-00.txt		draft-song-mpls-extension-header-01.txt >
	Network Working Group H. Song, Ed.		Network Working Group H. Song, Ed.
	Internet-Draft Z. Li		Internet-Draft Z. Li
	Intended status: Standards Track T. Zhou		Intended status: Standards Track T. Zhou
	Expires: January 16, 2019 Huawei		Expires: February 9, 2019 Huawei
	July 15, 2018		L. Andersson
			Bronze Dragon Consulting
			August 8, 2018
	MPLS Extension Header		MPLS Extension Header
	draft-song-mpls-extension-header-00		draft-song-mpls-extension-header-01
	Abstract		Abstract
	Motivated by the need to support multiple in-network services and		Motivated by the need to support multiple in-network services and
	functions in an MPLS network, this document describes a generic		functions in an MPLS network, this document describes a method to
	method to encapsulate extension headers into MPLS packets. The		encapsulate extension headers into MPLS packets. The encapsulation
	encapsulation method allows stacking multiple extension headers and		method allows stacking multiple extension headers and quickly
	quickly accessing any of them as well as the original upper layer		accessing any of them as well as the original upper layer protocol
	protocol header and payload. We show how the extension header can be		header and payload. We show how the extension header can be used to
	used to support several new network applications.		support several new network applications.
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119][RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	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.
	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 January 16, 2019.		This Internet-Draft will expire on February 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4		2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4
	3. Operation on MPLS Extension Headers . . . . . . . . . . . . . 7		3. Operation on MPLS Extension Headers . . . . . . . . . . . . . 8
	4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Motivation		1. Motivation
	Some applications require adding instructions and/or metadata to user		Some applications require adding instructions and/or metadata to user
	packets within a network. Such examples include In-situ OAM (IOAM)		packets within a network. Such examples include In-situ OAM (IOAM)
	[I-D.brockners-inband-oam-requirements] and Service Function Chaining		[I-D.brockners-inband-oam-requirements] and Service Function Chaining
	(SFC) [RFC7665]. New applications are emerging. It is possible that		(SFC) [RFC7665]. New applications are emerging. It is possible that
	the instructions and/or metadata for multiple applications are		the instructions and/or metadata for multiple applications are
	stacked together in one packet to support a compound service.		stacked together in one packet to support a compound service.
	However, the encapsulation of the new header(s) poses some challenges		However, the encapsulation of the new header(s) poses some challenges
	to the ubiquitous MPLS networks. A problem of the MPLS protocol		to the ubiquitous MPLS networks. The MPLS protocol header contains
	header is that there is no explicit indicator for the upper layer		no explicit indicator for the upper layer protocols by design. The
	protocols. The succinct MPLS header provide little room to encode		compact MPLS header, while beneficial to forwarding, allows little
	any extra information. Moreover, the backward compatibility issue		room for any extra information. Moreover, the backward compatibility
	discourages any attempts trying to overload the semantics of the		issue discourages any attempts trying to overload the semantics of
	existing MPLS header fields.		the existing MPLS header fields. While it is possible to designate
			"service labels" with special semantics by an operator, the non-
			standard approach burdens the control plane and impairs the
			interoperability.
	The similar "header extension" requirement for MPLS has led to		The similar "header extension" requirement for MPLS has led to
	several proposals. A special Generic Associated Channel Label (GAL)		several proposals. A special Generic Associated Channel Label (GAL)
	[RFC5586] is assigned to support the identification of an Associated		[RFC5586] is assigned to support the identification of an Associated
	Channel Header (ACH). Later, it was proposed to use GAL to indicate		Channel Header (ACH). Later, it was proposed to use GAL to indicate
	the presence of a Metadata Channel Header (MCH)		the presence of a Metadata Channel Header (MCH)
	[I-D.guichard-sfc-mpls-metadata] as well.		[I-D.guichard-sfc-mpls-metadata] as well.
	GAL has several limitations:		GAL has several limitations:
	o It must be located at the bottom of a label stack for its chief		o It must be located at the bottom of a label stack for its chief
	use case of MPLS-TP. An LSR needs to scan the entire label stack		use case of MPLS-TP. An LSR needs to search the entire label
	to be able to identify the presence of a new header. This can		stack for the BoS bit and check if the corresponding label is GAL.
	impact the performance when the label stack is deep.		This can impact the performance when the label stack is deep.
	o When GAL is present, the first nibble of the word following the		o When GAL is present, the first nibble of the word following the
	GAL needs to be checked to determine the header type. Since the		GAL needs to be checked to determine the header type. Since the
	value of the nibble cannot be greater than 3, this approach is		value of the nibble cannot be greater than 3 to avoid any possible
	neither scalable nor reliable.		confliction with IP version numbers, this approach is not
			scalable.
	o By design, GAL can only indicate the presence of a single header.		o By design, GAL can only indicate the presence of a single header.
	Therefore, the solution alone is not sufficient to support adding		Therefore, the solution alone is not sufficient to support adding
	multiple headers at the same time.		multiple headers at the same time.
	o The presence of GAL makes the network load balancing or deep		o The presence of GAL makes the network load balancing or deep
	packet inspection based on upper layer protocol headers and		packet inspection based on upper layer protocol headers and
	payload difficult.		payload difficult.
	In addition to the above limitations, it is not desirable to keep		In addition to the above limitations, it is not desirable to keep
	overloading GAL with new semantics. Instead of trying to patch on		overloading GAL with new semantics. Instead of trying to patch on
	existing schemes, we propose a general mechanism to solve the above		existing schemes, we propose a new mechanism to solve the above
	mentioned issues and create new innovation opportunities. We derive		mentioned issues and create new innovation opportunities, similar to
	our scheme from the experience of the IPv4 to IPv6 evolution. The		the way that IPv6 supports extension headers, which offer a huge
	adoption of IPv6 is gaining its momentum. Ironically, this is not
	due much to the extended address space over IPv4. One true power of
	IPv6 is that it supports extension headers, which offer a huge
	innovation potential (e.g, network security, SRv6		innovation potential (e.g, network security, SRv6
	[I-D.ietf-spring-segment-routing], network programming		[I-D.ietf-spring-segment-routing], network programming
	[I-D.filsfils-spring-srv6-network-programming], SFC		[I-D.filsfils-spring-srv6-network-programming], SFC
	[I-D.xu-clad-spring-sr-service-chaining], etc.). It is		[I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the
	straightforward to introduce new in-network services into IPv6		existing of extension headers, it is straightforward to introduce new
	networks through extension headers. For example, it has been		in-network services into IPv6 networks. For example, it has been
	proposed to carry IOAM header [I-D.brockners-inband-oam-transport]		proposed to carry IOAM header [I-D.brockners-inband-oam-transport]
	and NSH as new extension headers in IPv6 networks.		and NSH as new extension headers in IPv6 networks.
	Nevertheless, IPv6 is not perfect either. For one thing, IPv6's		Nevertheless, IPv6 is not perfect either. It has two main issues.
	header overhead is large compared to MPLS. We would like to retain		First, IPv6's header is large compared to MPLS, claiming extra
	the header compactness in MPLS networks. On the other hand, IPv6's		bandwidth overhead and complicating the packet processing. We prefer
			to retain the header compactness in MPLS networks. Second, IPv6's
	extension headers are chained with the original upper layer protocol		extension headers are chained with the original upper layer protocol
	headers in a flat stack. One has to scan all the extension headers		headers in a flat stack. One must scan all the extension headers to
	to access the upper layer protocol headers and the payload. This is		access the upper layer protocol headers and the payload. This is
	inconvenient and raises some performance concerns for some		inconvenient and raises some performance concerns for some
	applications (e.g., DPI and ECMP). The new scheme for MPLS header		applications (e.g., DPI and ECMP). The new scheme for MPLS header
	extension needs to address these issues too.		extension needs to address these issues too.
	2. MPLS Extension Header		2. MPLS Extension Header
	From the previous discussion, we have laid out the design		From the previous discussion, we have laid out the design
	requirements to support extension headers in MPLS networks:		requirements to support extension headers in MPLS networks:
	Performance: If possible, unnecessary label stack scanning and		Performance: If possible, unnecessary label stack scanning for a
	extension header scanning should be avoided.		label and extension header stack scanning for the upper layer
			protocol should be avoided.
	Scalability: New applications can be easily supported by introducing		Scalability: New applications can be easily supported by introducing
	new extension headers. Multiple extension headers can be easily		new extension headers. Multiple extension headers can be easily
	stacked together to support multiple services simultaneously.		stacked together to support multiple services simultaneously.
	Backward Compatibility: Legacy devices which do not recognize the		Backward Compatibility: Legacy devices which do not recognize the
	extension header option should still be able to forward the		extension header option should still be able to forward the
	packets as usual. If a device recognize some of the extension		packets as usual. If a device recognize some of the extension
	headers but not the others in an extension header stack, it can		headers but not the others in an extension header stack, it can
	process the known headers only while ignoring the others.		process the known headers only while ignoring the others.
	To support the extension header in MPLS, we need to assign a new		Extension headers can be be supported in several ways in an MPLS
	special label, namely the Extension Header Label (EHL). So far 8		network, we have outlined some of them in this document. However, it
	special label values are left unsigned by IANA (which are 4 to 6 and		should be noted that we do not intend to close this discussion yet,
	8 to 12). We believe this use case is significant enough to deserve		and are prepared to listen to arguments why and how any other methods
	one dedicated special label. Alternatively, a two label scheme with		could be used. One interesting line of thought is whether it would
	the use of the extension label (XL) plus an EHL is possible, but it		be possible to let a label that is received on top of the stack
	does use one more label. It is also possible to use FEC labels to		indicate whether there are extension headers beneath the stack.
	indicate the presence of extension headers. Although this approach
	avoid the need of a new special label, it introduces a good deal of		Our investigations indicate that a special purpose label and/or an
	complexity into the control plane. In the remaining of the document,		extended special purpose label will be the optimal way to go. A new
	we assume a special EHL is assigned.		special purpose label, namely the Extension Header Label (EHL), can
			be used to indicate EHs. So far 8 special purpose label values are
			left unsigned by IANA (which are 4 to 6 and 8 to 12). Alternatively,
			a two label scheme with the use of the extension label (XL) plus an
			EHL is possible, but it does use one more label. It is also possible
			to use FEC labels to indicate the presence of extension headers.
			Although this approach avoid the need of a new special purpose label,
			it introduces a good deal of complexity into the control plane. In
			the remaining of the document, we assume a special EHL is assigned
			and use it as an example to illustrate the scheme. A formal
			recommendation on the Extension Header (EH) indicator approach will
			be given in a future revision of this document.
	The format of the MPLS packets with extension headers is shown in		The format of the MPLS packets with extension headers is shown in
	Figure 1. An EHL can be located in anywhere in an MPLS label stack.		Figure 1. An EHL can be located in anywhere in an MPLS label stack.
	However, if there are legacy devices which do not recognize the EHL		However, if there are legacy devices which do not recognize the EHL
	in the network, then for backward compatibility, the EHL must be		in the network, then for backward compatibility, the EHL must be
	located at the bottom of the stack (i.e., only the MPLS tunnel ends		located at the bottom of the stack (i.e., only the MPLS tunnel ends
	and EHL-aware nodes will look up and process it). Otherwise, the EHL		and EHL-aware nodes will look up and process it). Otherwise, the EHL
	can be located close to the top of the stack for better lookup		can be located close to the top of the stack for better lookup
	performance.		performance.
	skipping to change at page 7, line 13 ¶		skipping to change at page 8, line 13 ¶
	the EH. This field is 4-octet aligned.		the EH. This field is 4-octet aligned.
	The extension headers as well as the first original upper layer		The extension headers as well as the first original upper layer
	protocol header are chained together through the NH field in HEH and		protocol header are chained together through the NH field in HEH and
	EHs. The encoding of NH uses the same values as the IPv4 protocol		EHs. The encoding of NH uses the same values as the IPv4 protocol
	field. Values for new EH types shall be assigned by IANA.		field. Values for new EH types shall be assigned by IANA.
	Specifically, the NH field of the last EH in a chain can have two		Specifically, the NH field of the last EH in a chain can have two
	special values, which shall be assigned by IANA:		special values, which shall be assigned by IANA:
	NONE: Indicates that there is no any other header and payload after		NONE (No Next Header): Indicates that there is no other header and
	this header. This can be used to transport packets with only		payload after this header. This can be used to transport packets
	extension header(s).		with only extension header(s).
	UNKNOWN: Indicates that the type of the header after this header is		UNKNOWN (Unknown Next Header): Indicates that the type of the header
	unknown. This is intended to be compatible with the original MPLS		after this header is unknown. This is intended to be compatible
	design in which the upper layer protocol type is unknown from the		with the original MPLS design in which the upper layer protocol
	MPLS header alone.		type is unknown from the MPLS header alone.
	3. Operation on MPLS Extension Headers		3. Operation on MPLS Extension Headers
	When the first EH X needs to be added to an MPLS packet, an EHL is		When the first EH X needs to be added to an MPLS packet, an EHL is
	inserted into the proper location in the MPLS label stack. A HEH is		inserted into the proper location in the MPLS label stack. A HEH is
	then inserted after the MPLS label stack, in which EHCNT is set to 1,		then inserted after the MPLS label stack, in which EHCNT is set to 1,
	EHTLEN is set to the length of X in 4-octet units, and NH is set to		EHTLEN is set to the length of X in 4-octet units, and NH is set to
	the header value of X. At last, X is inserted after the HEH, in		the header value of X. At last, X is inserted after the HEH, in
	which NH and HELN are set accordingly. Note that if this operation		which NH and HELN are set accordingly. Note that if this operation
	happens at a PE device, the upper layer protocol is known before the		happens at a PE device, the upper layer protocol is known before the
	skipping to change at page 9, line 12 ¶		skipping to change at page 10, line 12 ¶
	summarize the potential schemes that allow MPLS packets to carry		summarize the potential schemes that allow MPLS packets to carry
	extension headers and list the main issues for each scheme.		extension headers and list the main issues for each scheme.
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	|No.| Description | Issues |		|No.| Description | Issues |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 1 | GAL + MCH with multi- |- Label location limitation lead |		| 1 | GAL + MCH with multi- |- Label location limitation lead |
	| | header extension | to performance concern |		| | header extension | to performance concern |
	| | |- Interfere with load balancing |		| | |- Interfere with load balancing |
	| | | and DPI functions |		| | | and DPI functions |
	| | |- Overlaod GAL semantics |		| | |- Overload GAL semantics |
	| | |- Need standard extension |		| | |- Need standard extension |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 2 | GAL + another nibble value|- Same as above |		| 2 | GAL + another nibble value|- Same as above |
	| | to encode the EHs (e.g., | |		| | to encode the EHs (e.g., | |
	| | "0010") | |		| | "0010") | |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 3 | FEC label to indicate EH |- Complex control plane |		| 3 | FEC label to indicate EH |- Complex control plane |
			| | |- Interoperability |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 4 | XL(15) + EHL |- One extra label |		| 4 | XL(15) + EHL |- One extra label |
	| | |- Need standard extension |		| | |- Need standard extension |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 5 | Sepcial EHL |- Need standard extension |		| 5 | Special purpose EHL |- Need standard extension |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	Figure 4: Potential Schemes for MPLS Extension Headers		Figure 4: Potential Schemes for MPLS Extension Headers
	Through comprehensive considerations on the pros and cons of each		Through comprehensive considerations on the pros and cons of each
	scheme, we currently recommend the scheme No.5. The proposed MPLS		scheme, we currently recommend the scheme No.5. The proposed MPLS
	extension header scheme provides a generic way to support in-network		extension header scheme provides a generic way to support in-network
	services and functions in MPLS networks.		services and functions in MPLS networks.
	6. Security Considerations		6. Security Considerations
	TBD		TBD
	7. IANA Considerations		7. IANA Considerations
	This document requires IANA to assign a new special MPLS label value		If the EHL approach is adopted to indicate the presence of MPLS
	("EHL") which is dedicated to indicate the presence of MPLS extension		extension header(s), this document requests IANA to assign a new
	header(s).		Special-Purpose MPLS Label Value from the Special-Purpose
			Multiprotocol Label Switching (MPLS) Label Values Registry of
			"Extension Header Label (EHL)".
	This document also requires IANA to assign two new protocol numbers		This document also requests IANA to assign two new Internet Protocol
	which are used to indicate no next header ("NONE") or an unknown next		Numbers from the "Protocol Numbers" Registry to indicate "No Next
	header ("UNKNOWN").		Header" or "Unknown Next Header".
	The new header type values shall be assigned by IANA on a case-by-		This document does not create any new registries.
	case basis.
	8. Contributors		8. Contributors
	The other contributors of this document are listed as follows.		The other contributors of this document are listed as follows.
	o James Guichard		o James Guichard
	o Stewart Bryant		o Stewart Bryant
	o Andrew Malis		o Andrew Malis
	skipping to change at page 10, line 38 ¶		skipping to change at page 11, line 38 ¶
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,		[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,		"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,		DOI 10.17487/RFC5586, June 2009,
	<https://www.rfc-editor.org/info/rfc5586>.		<https://www.rfc-editor.org/info/rfc5586>.
	[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,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300,		"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,		DOI 10.17487/RFC8300, January 2018,
	<https://www.rfc-editor.org/info/rfc8300>.		<https://www.rfc-editor.org/info/rfc8300>.
	[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,		[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
	L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,		L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
	"Alternate-Marking Method for Passive and Hybrid		"Alternate-Marking Method for Passive and Hybrid
	Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,		Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
	January 2018, <https://www.rfc-editor.org/info/rfc8321>.		January 2018, <https://www.rfc-editor.org/info/rfc8321>.
	skipping to change at line 538 ¶		skipping to change at page 13, line 30 ¶
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	Tianran Zhou		Tianran Zhou
	Huawei		Huawei
	156 Beiqing Road		156 Beiqing Road
	Beijing, 100095		Beijing, 100095
	P.R. China		P.R. China
	Email: zhoutianran@huawei.com		Email: zhoutianran@huawei.com
			Loa Andersson
			Bronze Dragon Consulting
			Stockholm
			Sweden
			Email: loa@pi.nu
End of changes. 25 change blocks.
	78 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/