< draft-song-mpls-extension-header-01.txt		draft-song-mpls-extension-header-02.txt >
	Network Working Group H. Song, Ed.		MPLS H. Song, Ed.
	Internet-Draft Z. Li		Internet-Draft Z. Li
	Intended status: Standards Track T. Zhou		Intended status: Standards Track T. Zhou
	Expires: February 9, 2019 Huawei		Expires: August 9, 2019 Huawei
	L. Andersson		L. Andersson
	Bronze Dragon Consulting		Bronze Dragon Consulting
	August 8, 2018		February 5, 2019
	MPLS Extension Header		MPLS Extension Header
	draft-song-mpls-extension-header-01		draft-song-mpls-extension-header-02
	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 method to		functions in an MPLS network, this document describes a method to
	encapsulate extension headers into MPLS packets. The encapsulation		encapsulate extension headers into MPLS packets. The encapsulation
	method allows stacking multiple extension headers and quickly		method allows stacking multiple extension headers and quickly
	accessing any of them as well as the original upper layer protocol		accessing any of them as well as the original upper layer protocol
	header and payload. We show how the extension header can be used to		header and payload. We show how the extension header can be used to
	support several new network applications.		support several new network applications and optimize some existing
			network services.
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 9, 2019.		This Internet-Draft will expire on August 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . . . 8		3. Type of MPLS Extension Headers . . . . . . . . . . . . . . . 7
	4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Operation on MPLS Extension Headers . . . . . . . . . . . . . 7
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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		Conceivably, such instructions and/or metadata would be encoded as
	to the ubiquitous MPLS networks. The MPLS protocol header contains		new headers and encapsulated in user packets. Such headers may
	no explicit indicator for the upper layer protocols by design. The		require to be processed in fast path or in slow path. Moreover, such
	compact MPLS header, while beneficial to forwarding, allows little		headers may require being attended at each hop on the forwarding path
	room for any extra information. Moreover, the backward compatibility		(i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to-
	issue discourages any attempts trying to overload the semantics of		end or E2E).
	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
	several proposals. A special Generic Associated Channel Label (GAL)
	[RFC5586] is assigned to support the identification of an Associated
	Channel Header (ACH). Later, it was proposed to use GAL to indicate
	the presence of a Metadata Channel Header (MCH)
	[I-D.guichard-sfc-mpls-metadata] as well.
	GAL has several limitations:
	o It must be located at the bottom of a label stack for its chief		The encapsulation of the new header(s) poses some challenges to MPLS
	use case of MPLS-TP. An LSR needs to search the entire label		networks, because the MPLS protocol header contains no explicit
	stack for the BoS bit and check if the corresponding label is GAL.		indicator for the upper layer protocols by design. We leave the
	This can impact the performance when the label stack is deep.		discussion on the indicator of new header(s) in an MPLS packet to
			another companion document. In this document, we focus on the encode
			and encapsulation of new headers in an MPLS packet.
	o When GAL is present, the first nibble of the word following the		The similar problem has been tackled for some particular application
	GAL needs to be checked to determine the header type. Since the		before. However, the solutions have some drawbacks:
	value of the nibble cannot be greater than 3 to avoid any possible
	confliction with IP version numbers, this approach is not
	scalable.
	o By design, GAL can only indicate the presence of a single header.		o These solutions rely on either the built-in next-protocol
	Therefore, the solution alone is not sufficient to support adding		indicator in the header or the knowledge of the format and size of
	multiple headers at the same time.		the header to access the following packet data. The node is
			required to be able to parse the new header, which is unrealistic
			in an incremental deployment environment.
	o The presence of GAL makes the network load balancing or deep		o A piecemeal solution often assumes the new header is the only
	packet inspection based on upper layer protocol headers and		extra header and its location in the packet is fixed by default.
	payload difficult.		It is impossible or difficult to support multiple new headers in
			one packet due to the conflicted assumption.
	In addition to the above limitations, it is not desirable to keep		To solve these issues, we propose to introduce extension header as a
	overloading GAL with new semantics. Instead of trying to patch on		general and extensible means to support new in-network functions and
	existing schemes, we propose a new mechanism to solve the above		applications in MPLS networks. The idea is similar to IPv6 extension
	mentioned issues and create new innovation opportunities, similar to		headers which offer a huge innovation potential (e.g, network
	the way that IPv6 supports extension headers, which offer a huge		security, SRv6 [I-D.ietf-spring-segment-routing], network programming
	innovation potential (e.g, network security, SRv6
	[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.). Thanks to the		[I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the
	existing of extension headers, it is straightforward to introduce new		existing of extension headers, it is straightforward to introduce new
	in-network services into IPv6 networks. 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] as
	and NSH as new extension headers in IPv6 networks.		a new extension header in IPv6 networks.
	Nevertheless, IPv6 is not perfect either. It has two main issues.		Nevertheless, IPv6 is not perfect either. It has two main issues.
	First, IPv6's header is large compared to MPLS, claiming extra		First, IPv6's header is large compared to MPLS, claiming extra
	bandwidth overhead and complicating the packet processing. We prefer		bandwidth overhead and complicating the packet processing. We prefer
	to retain the header compactness in MPLS networks. Second, IPv6's		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 must scan all the extension headers to		headers in a flat stack. One must scan all the extension headers 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
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 24 ¶
	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.
	Extension headers can be be supported in several ways in an MPLS		We assume the MPLS label stack has included some indicator of the
	network, we have outlined some of them in this document. However, it		extension header(s). The actual extension headers are inserted
	should be noted that we do not intend to close this discussion yet,		between the MPLS label stack and the original upper layer packet
	and are prepared to listen to arguments why and how any other methods		header. The format of the MPLS packets with extension headers is
	could be used. One interesting line of thought is whether it would		shown in Figure 1.
	be possible to let a label that is received on top of the stack
	indicate whether there are extension headers beneath the stack.
	Our investigations indicate that a special purpose label and/or an
	extended special purpose label will be the optimal way to go. A new
	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
	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
	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
	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
	performance.
	The format of an EHL is the same as an MPLS label. The first 20-bit
	label value will be assigned by IANA. The BoS bit is used to
	indicate the location of the label. The other fields, CoS and TTL,
	are unused in the context of EHL.
	0 31		0 31
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ -
	| |		| | |
	~ MPLS Label Stack ~		~ MPLS Label Stack ~ |
	| |		| | |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ |
	| EHL |		| EH Indicator (TBD) | > MPLS Label Stack
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ | (extended with EHI)
	| |		| | |
	~ MPLS Label Stack ~		~ MPLS Label Stack ~ |
	| |		| | |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ =
	| Header of Extension Headers (HEH) |		| Header of Extension Headers (HEH) | |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ |
	| |		| | |
	~ Extension Header (EH) 1 ~		~ Extension Header (EH) 1 ~ |
	| |		| | |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ > MPLS EH Fields
	~ ~		~ ~ | (new)
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ |
	| |		| | |
	~ Extension Header (EH) N ~		~ Extension Header (EH) N ~ |
	| |		| | |
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ =
	| |		| | |
	~ Upper Layer Protocols/Payload ~		~ Upper Layer Headers/Payload ~ > MPLS Payload
	| |		| | | (as is)
	+--------+--------+--------+--------+		+--------+--------+--------+--------+ -
	Figure 1: MPLS with Extension Header		Figure 1: MPLS with Extension Headers
	Following the MPLS label stack is the 4-octet Header of Extension		Following the MPLS label stack is the 4-octet Header of Extension
	Headers (HEH), which indicates the total number of extension headers		Headers (HEH), which indicates the total number of extension headers
	in this packet, the overall length of the extension headers, and the		in this packet, the overall length of the extension headers, and the
	type of the next header. The format of the HEH is shown in Figure 2.		type of the next header. The format of the HEH is shown in Figure 2.
	0 1 2 3		0 1 2 3
	0123 45678901 234567890123 45678901		0123 45678901 234567890123 45678901
	+----+--------+------------+--------+		+----+--------+------------+--------+
	| R | EHCNT | EHTLEN | NH |		| R | EHCNT | EHTLEN | NH |
	skipping to change at page 8, line 22 ¶		skipping to change at page 7, line 22 ¶
	NONE (No Next Header): Indicates that there is no other header and		NONE (No Next Header): Indicates that there is no other header and
	payload after this header. This can be used to transport packets		payload after this header. This can be used to transport packets
	with only extension header(s).		with only extension header(s).
	UNKNOWN (Unknown Next Header): Indicates that the type of the header		UNKNOWN (Unknown Next Header): Indicates that the type of the header
	after this header is unknown. This is intended to be compatible		after this header is unknown. This is intended to be compatible
	with the original MPLS design in which the upper layer protocol		with the original MPLS design in which the upper layer protocol
	type is unknown from the MPLS header alone.		type is unknown from the MPLS header alone.
	3. Operation on MPLS Extension Headers		3. Type of MPLS Extension Headers
	When the first EH X needs to be added to an MPLS packet, an EHL is		Basically, there are two types of MPLS EHs: HBH and E2E. E2E means
	inserted into the proper location in the MPLS label stack. A HEH is		that the EH is only supposed to be inserted/removed and processed at
	then inserted after the MPLS label stack, in which EHCNT is set to 1,		the MPLS tunnel end points where the MPLS header is inserted or
	EHTLEN is set to the length of X in 4-octet units, and NH is set to		removed. The EHs that are inserted or removed within the MPLS tunnel
	the header value of X. At last, X is inserted after the HEH, in		are of the HBH type. However, any node in the tunnel can be
	which NH and HELN are set accordingly. Note that if this operation		configured to ignore an HBH EH, even if it is capable of processing
	happens at a PE device, the upper layer protocol is known before the		the EH.
	MPLS encapsulation, so its value can be saved in the NH field if
	desired. Otherwise, the NH field is filled with the value of		If there are two types of EHs in a packet, the HBH EHs must take
	"UNKNOWN".		precedence over the E2E EHs.
			Making a distinction of the EH types and ordering the EHs in a packet
			help improve the forwardidng performance. For example, if a node
			within an MPLS tunnel finds only E2E EHs in a packet, it can avoid
			scanning the EH list.
			4. Operation on MPLS Extension Headers
			When the first EH X needs to be added to an MPLS packet, an EH
			indicator 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, 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 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 MPLS encapsulation, so its value can be saved in the NH
			field if desired. Otherwise, the NH field is filled with the value
			of "UNKNOWN".
	When an EH Y needs to be added to an MPLS packet which already		When an EH Y needs to be added to an MPLS packet which already
	contains extension header(s), the EHCNT and EHTLEN in the HEH are		contains extension header(s), the EHCNT and EHTLEN in the HEH are
	updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is		updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is
	incremented by the size of Y in 4-octet units). Then a proper		incremented by the size of Y in 4-octet units). Then a proper
	location for Y in the EH chain is located. Y is inserted at this		location for Y in the EH chain is located. Y is inserted at this
	location. The NH field of Y is copied from the previous EH's NH		location. The NH field of Y is copied from the previous EH's NH
	field (or from the HEH's NH field, if Y is the first EH in the		field (or from the HEH's NH field, if Y is the first EH in the
	chain). The previous EH's NH value, or, if Y is the first EH in the		chain). The previous EH's NH value, or, if Y is the first EH in the
	chain, the HEH's NH, is set to the header value of Y.		chain, the HEH's NH, is set to the header value of Y.
	Deleting an EH simply reverses the above operation. If the deleted		Deleting an EH simply reverses the above operation. If the deleted
	EH is the last one, the EHL and HEH can also be deleted.		EH is the last one, the EH indicator and HEH can also be removed.
	When processing an MPLS packet with extension headers, the node needs		When processing an MPLS packet with extension headers, the node needs
	to scan through the entire EH chain and process the EH one by one.		to scan through the entire EH chain and process the EH one by one.
	The node should ignore any unrecognized EH.		The node should ignore any unrecognized EH.
	4. Use Cases		The EH can be categorized into HBH or E2E. If the EH indicator can
			indicate the EH types and the EHs are ordered (i.e., HBH EHs are
			located before E2E EHs), a node can avoid some unnecessary EH scan.
			5. Use Cases
	In this section, we show how MPLS extension header can be used to		In this section, we show how MPLS extension header can be used to
	support several new network applications.		support several new network applications.
	In-situ OAM: In-situ OAM (IOAM) records flow OAM information within		In-situ OAM: In-situ OAM (IOAM) records flow OAM information within
	user packets while the packets traverse a network. The		user packets while the packets traverse a network. The
	instruction and collected data are kept in an IOAM header		instruction and collected data are kept in an IOAM header
	[I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network,		[I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network,
	the IOAM header can be encapsulated as an MPLS extension header.		the IOAM header can be encapsulated as an MPLS extension header.
	NSH: Network Service Header (NSH) [RFC8300] provides a service plane
	for Service Function Chaining (SFC). NSH maintains the SFC
	context and metadata. If MPLS is used as the transport protocol
	for NSH, NSH can be encapsulated as an MPLS extension header.
	Network Telemetry and Measurement: A network telemetry and		Network Telemetry and Measurement: A network telemetry and
	instruction header can be carried as an extension header to		instruction header can be carried as an extension header to
	instruct a node what type of network measurements should be done.		instruct a node what type of network measurements should be done.
	For example, the method described in [RFC8321] can be implemented		For example, the method described in [RFC8321] can be implemented
	in MPLS networks since the EH provides a natural way to color MPLS		in MPLS networks since the EH provides a natural way to color MPLS
	packets.		packets.
	Network Security: Security related functions often require user		Network Security: Security related functions often require user
	packets to carry some metadata. In a DoS limiting network		packets to carry some metadata. In a DoS limiting network
	architecture, a "packet passport" header is used to embed packet		architecture, a "packet passport" header is used to embed packet
	authentication information for each node to verify.		authentication information for each node to verify.
	Segment Routing: MPLS extension header can support the		Segment Routing and Network Programming: MPLS extension header can
	implementation of a new flavor of the MPLS-based segment routing,		support the implementation of a new flavor of the MPLS-based
	with better performance and richer functionalities. The details		segment routing, with better performance and richer
	will be described in another draft.		functionalities. The details will be described in another draft.
	With MPLS extension headers, multiple in-network applications can be		With MPLS extension headers, multiple in-network applications can be
	stacked together. For example, IOAM and SFC can be applied at the		stacked together. For example, IOAM and SFC can be applied at the
	same time to support network OAM and service function chaining. A		same time to support network OAM and service function chaining. A
	node can stop scanning the extension header stack if all the known		node can stop scanning the extension header stack if all the known
	headers it can process have been located. For example, if IOAM is		headers it can process have been located. For example, if IOAM is
	the first EH in a stack and a node is configured to process IOAM		the first EH in a stack and a node is configured to process IOAM
	only, it will stop searching the EH stack when the IOAM EH is found.		only, it will stop searching the EH stack when the IOAM EH is found.
	5. Summary
	Evidenced by the existing and emerging use cases, MPLS networks need
	a standard way to support extension headers. In Figure 4, we
	summarize the potential schemes that allow MPLS packets to carry
	extension headers and list the main issues for each scheme.
	+---+---------------------------+---------------------------------+
	|No.| Description | Issues |
	+---+---------------------------+---------------------------------+
	| 1 | GAL + MCH with multi- |- Label location limitation lead |
	| | header extension | to performance concern |
	| | |- Interfere with load balancing |
	| | | and DPI functions |
	| | |- Overload GAL semantics |
	| | |- Need standard extension |
	+---+---------------------------+---------------------------------+
	| 2 | GAL + another nibble value|- Same as above |
	| | to encode the EHs (e.g., | |
	| | "0010") | |
	+---+---------------------------+---------------------------------+
	| 3 | FEC label to indicate EH |- Complex control plane |
	| | |- Interoperability |
	+---+---------------------------+---------------------------------+
	| 4 | XL(15) + EHL |- One extra label |
	| | |- Need standard extension |
	+---+---------------------------+---------------------------------+
	| 5 | Special purpose EHL |- Need standard extension |
	+---+---------------------------+---------------------------------+
	Figure 4: Potential Schemes for MPLS Extension Headers
	Through comprehensive considerations on the pros and cons of each
	scheme, we currently recommend the scheme No.5. The proposed MPLS
	extension header scheme provides a generic way to support in-network
	services and functions in MPLS networks.
	6. Security Considerations		6. Security Considerations
	TBD		TBD
	7. IANA Considerations		7. IANA Considerations
	If the EHL approach is adopted to indicate the presence of MPLS		This document requests IANA to assign two new Internet Protocol
	extension header(s), this document requests IANA to assign a new
	Special-Purpose MPLS Label Value from the Special-Purpose
	Multiprotocol Label Switching (MPLS) Label Values Registry of
	"Extension Header Label (EHL)".
	This document also requests IANA to assign two new Internet Protocol
	Numbers from the "Protocol Numbers" Registry to indicate "No Next		Numbers from the "Protocol Numbers" Registry to indicate "No Next
	Header" or "Unknown Next Header".		Header" or "Unknown Next Header".
	This document does not create any new registries.		This document does not create any new registries.
	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
	skipping to change at page 11, line 42 ¶		skipping to change at page 10, line 14 ¶
	[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		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,
	<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>.
	10.2. Informative References		10.2. Informative References
	[I-D.brockners-inband-oam-requirements]		[I-D.brockners-inband-oam-requirements]
	Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,		Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,		Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
	T., <>, P., and r. remy@barefootnetworks.com,		T., Lapukhov, P., and r. remy@barefootnetworks.com,
	"Requirements for In-situ OAM", draft-brockners-inband-		"Requirements for In-situ OAM", draft-brockners-inband-
	oam-requirements-03 (work in progress), March 2017.		oam-requirements-03 (work in progress), March 2017.
	[I-D.brockners-inband-oam-transport]		[I-D.brockners-inband-oam-transport]
	Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,		Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,		Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
	D., Lapukhov, P., and R. Chang, "Encapsulations for In-		D., Lapukhov, P., and R. Chang, "Encapsulations for In-
	situ OAM Data", draft-brockners-inband-oam-transport-05		situ OAM Data", draft-brockners-inband-oam-transport-05
	(work in progress), July 2017.		(work in progress), July 2017.
	[I-D.filsfils-spring-srv6-network-programming]		[I-D.filsfils-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J.,		Filsfils, C., Camarillo, P., Leddy, J.,
	daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6		daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
	Network Programming", draft-filsfils-spring-srv6-network-		Network Programming", draft-filsfils-spring-srv6-network-
	programming-05 (work in progress), July 2018.		programming-06 (work in progress), October 2018.
	[I-D.guichard-sfc-mpls-metadata]		[I-D.guichard-sfc-mpls-metadata]
	Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant,		Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant,
	"Carrying Metadata in MPLS Networks", draft-guichard-sfc-		"Carrying Metadata in MPLS Networks", draft-guichard-sfc-
	mpls-metadata-00 (work in progress), September 2013.		mpls-metadata-00 (work in progress), September 2013.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,		Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
	Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,		Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
	P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,		P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
	"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-		"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
	data-03 (work in progress), June 2018.		data-04 (work in progress), October 2018.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-15 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), January 2018.		in progress), January 2018.
	[I-D.xu-clad-spring-sr-service-chaining]		[I-D.xu-clad-spring-sr-service-chaining]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,		Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,		d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
End of changes. 30 change blocks.
	199 lines changed or deleted		125 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/