< draft-song-mpls-eh-indicator-01.txt		draft-song-mpls-eh-indicator-02.txt >
	MPLS H. Song, Ed.		MPLS H. Song, Ed.
	Internet-Draft Futurewei Technologies		Internet-Draft Futurewei Technologies
	Intended status: Informational Z. Li		Intended status: Informational Z. Li
	Expires: September 11, 2021 T. Zhou		Expires: November 6, 2021 T. Zhou
	Huawei		Huawei
	L. Andersson		L. Andersson
	Bronze Dragon Consulting		Bronze Dragon Consulting
	March 10, 2021		May 5, 2021
	Options for MPLS Extension Header Indicator		Options for MPLS Extension Header Indicator
	draft-song-mpls-eh-indicator-01		draft-song-mpls-eh-indicator-02
	Abstract		Abstract
	This document describes the schemes that indicates the presence of		The intention of this document is to enumerate and describe the
	the MPLS extension header(s) following the MPLS label stack. After a		candidate schemes that can be used to indicate the presence of the
	thorough evaluation of these options by comparing their pros and		MPLS extension header(s) following the MPLS label stack. After a
	cons, one should be chosen as the final scheme for MPLS extension		careful evaluation of these options by comparing their pros and cons,
	header indicator.		it is expected that one should be chosen as the final standard scheme
			for MPLS extension header indicator.
	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 46 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 September 11, 2021.		This Internet-Draft will expire on November 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Dedicated Extension Header Label . . . . . . . . . . . . . . 3		2. Dedicated Extension Header Label . . . . . . . . . . . . . . 3
	2.1. Special Purpose Label . . . . . . . . . . . . . . . . . . 3		2.1. Special Purpose Label . . . . . . . . . . . . . . . . . . 3
	2.2. Extension Label plus an Extended Special Purpose Label . 3		2.2. Extension Label plus an Extended Special Purpose Label . 4
	3. Generic Associated Channel Extension . . . . . . . . . . . . 4		3. Generic Associated Channel Extension . . . . . . . . . . . . 4
	3.1. GAL and Associated Channel Header . . . . . . . . . . . . 4		3.1. GAL and Associated Channel Header . . . . . . . . . . . . 4
	3.2. GAL and a Different Nibble Value . . . . . . . . . . . . 4		3.2. GAL and a Different Nibble Value . . . . . . . . . . . . 5
	4. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 5		4. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 6
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 7		6. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The document [I-D.song-mpls-extension-header] presents the		The document [I-D.song-mpls-extension-header] presents the
	motivation, specification, and use cases of MPLS Extension Header		motivation, specification, and use cases of MPLS Extension Header
	(EH). However, multiple options are possible to indicate the		(EH). An indicator is needed in the MPLS label stack to indicate the
	presence of the extension header(s).		presence of the extension header(s). Multiple options are possible
			for this purpose. As the discussion progresses, more options could
			emerge.
	We propound three categories of methods which can be further		In this document, we propound three categories of methods which can
	partitioned into five unique schemes. Four of them use explicit data		be further partitioned into five unique schemes. Four of them use
	plane encoding to indicate the EH and the last one implies the EH		explicit data plane encoding to indicate the EH and the last one
	through control plane configuration. This document details and		implies the EH through control plane configuration. This document
	compares these schemes, in order to foster further discussions until		details and compares these schemes, in order to foster further
	a final decision is made.		discussions until a final decision is made.
	2. Dedicated Extension Header Label		2. Dedicated Extension Header Label
	A straightforward method is to directly encode an Extension Header		A straightforward method is to directly encode an Extension Header
	Label (EHL) in the MPLS label stack. Two derived schemes are as		Label (EHL) in the MPLS label stack. Two derived schemes are as
	follows.		follows.
	2.1. Special Purpose Label		2.1. Special Purpose Label
	A new special purpose label, EHL, can be used to indicate EHs. As		A new special purpose label, EHL, can be used to indicate EHs. As
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 38 ¶
	the EHL is close to or at the top of the label stack. However, if		the EHL is close to or at the top of the label stack. However, if
	there are legacy devices which can reach the EHL but do not recognize		there are legacy devices which can reach the EHL but do not recognize
	it in a network, then for backward compatibility, the EHL must be		it in a 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).		and EHL-aware nodes will look up and process it).
	The format of an EHL is the same as an MPLS label. The first 20-bit		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		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,		indicate the location of the label. The other fields, CoS and TTL,
	currently have no use in the context of EHL. However, these two		currently have no use in the context of EHL. However, these two
	fields can potentially be used to encode other information, which is		fields can potentially be used to encode other information. If such
	beyond the scope of this document.		code points are open for other purpose, it will make the single EHL
			idea more compelling. E.g., the EH category and/or other
			information, if needed, can be encoded in these fields, so that only
			one special label value is needed.
			The following figure shows a potential scheme in which one bit from
			the CoS field ('H') is used to indicate the presence of HbH EHs in
			the packet. If 'H' bit is 0, it means no HbH EH follows so a
			P-router will not need to check the EH.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| EHL (TBD) |H| |S| TTL |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: Special EHL with EH Category Encoding
	2.2. Extension Label plus an Extended Special Purpose Label		2.2. Extension Label plus an Extended Special Purpose Label
	[RFC7274] specifies the Extension Label (XL) with the value of 15.		[RFC7274] specifies the Extension Label (XL) with the value of 15.
	An extended special purpose label (ESPL) following XL can be used as		An extended special purpose label (ESPL) following XL can be used as
	EHL. A large number of ESPL values are available for allocation.		EHL. A large number of ESPL values are available for allocation.
	The XL+EHL scheme eases the concern on the reserved label space at		The XL+EHL scheme eases the concern on the reserved label space at
	the cost of one more label in the label stack.		the cost of one more label in the label stack.
	Except for the fact that one more label is needed, The XL+EHL scheme		Except for the fact that one more label is needed, The XL+EHL scheme
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 37 ¶
	proposals before. A special Generic Associated Channel Label (GAL)		proposals before. A special Generic Associated Channel Label (GAL)
	[RFC5586] with the value of 13 has been assigned to support the		[RFC5586] with the value of 13 has been assigned to support the
	identification of an Associated Channel Header (ACH). We can extend		identification of an Associated Channel Header (ACH). We can extend
	this existing mechanism to encode the MPLS EH indicator.		this existing mechanism to encode the MPLS EH indicator.
	3.1. GAL and Associated Channel Header		3.1. GAL and Associated Channel Header
	The ACH is located below the bottom label. It has a 16-bit Channel		The ACH is located below the bottom label. It has a 16-bit Channel
	Type field which provides abundant space to encode the MPLS EH		Type field which provides abundant space to encode the MPLS EH
	indicator. This scheme has the same header overhead as the XL+EHL		indicator. This scheme has the same header overhead as the XL+EHL
	scheme. The format is depicted in Figure 1.		scheme. The format is depicted in Figure 2.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL (13) | EXP |1| TTL |		| GAL (13) | EXP |1| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Reserved | Extension Header Indicator |		|0 0 0 1|Version| Reserved | Extension Header Indicator |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| HEH and EH(s) |		| HEH and EH(s) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Associated Channel Header as Extension Header Indicator		Figure 2: Associated Channel Header as Extension Header Indicator
	GAL has several applications already yet its heritage also has		GAL has several applications already yet its heritage also has
	several limitations. The GAL must be located at the bottom of a		several limitations. The GAL must be located at the bottom of a
	label stack for its chief use cases such as MPLS-TP. So a router		label stack for its chief use cases such as MPLS-TP. So a router
	needs to search the entire label stack for the BoS bit and check if		needs to search the entire label stack for the BoS bit and check if
	the corresponding label is GAL. This can impact the performance when		the corresponding label is GAL. This can impact the performance when
	the label stack is deep. A more serious concern is that [RFC5586]		the label stack is deep. A more serious concern is that [RFC5586]
	states that GAL+ACH MUST NOT be used to transport user traffic and an		states that GAL+ACH MUST NOT be used to transport user traffic and an
	ACH is supposed to be followed by a non-service payload.		ACH is supposed to be followed by a non-service payload.
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 24 ¶
	None of these is insurmountable but it does require an overhaul of		None of these is insurmountable but it does require an overhaul of
	the existing RFC in order to extend the usage of GAL.		the existing RFC in order to extend the usage of GAL.
	3.2. GAL and a Different Nibble Value		3.2. GAL and a Different Nibble Value
	To avoid changing the established semantics of ACH, a variation can		To avoid changing the established semantics of ACH, a variation can
	be used. ACH starts with a nibble value "0001". A different nibble		be used. ACH starts with a nibble value "0001". A different nibble
	value may be used to redefine the remaining part of the word. The		value may be used to redefine the remaining part of the word. The
	idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define		idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define
	a Metadata Channel Header (MCH) with the leading nibble value "0000".		a Metadata Channel Header (MCH) with the leading nibble value "0000".
	Similarly, we can use another nibble value (e.g., "0010") to define a		Similarly, we can use another nibble value (e.g., "0010") to define a
	new header, namely the MPLS Extension Header Indicator (EHI).		new header, namely the MPLS Extension Header Indicator (EHI).
	The format of the GAL and EHI is depicted in Figure 2.		The format of the GAL and EHI is depicted in Figure 3.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL (13) | EXP |1| TTL |		| GAL (13) | EXP |1| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 1 0|Version| Reserved | Extension Header Class |<-EHI		|0 0 1 0|Version| Reserved | Extension Header Class |<-EHI
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| HEH and EH(s) |		| HEH and EH(s) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Extension Header Indicator Format		Figure 3: Extension Header Indicator Format
	The Extension Header Class field in EHI is used to differentiate the		The Extension Header Class field in EHI is used to differentiate the
	extension headers. Potentially there are three classes: Hop-by-Hop		extension headers. Potentially there are three classes: Hop-by-Hop
	(HbH), End-to-End (E2E), or both. If finally we decide to not		(HbH), End-to-End (E2E), or both. If finally we decide to not
	differentiate the extension headers, we have the opportunity to merge		differentiate the extension headers, we have the opportunity to merge
	the HEH (see [I-D.song-mpls-extension-header] for details) into EHI,		the HEH (see [I-D.song-mpls-extension-header] for details) into EHI,
	so we can reduce the header overhead by four bytes. The header		so we can reduce the header overhead by four bytes. The header
	format is depicted in Figure 3.		format is depicted in Figure 4.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL (13) | EXP |1| TTL |		| GAL (13) | EXP |1| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 1 0| EHCNT | EHTLEN | NH |<-HEH		|0 0 1 0| EHCNT | EHTLEN | NH |<-HEH
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| EH(s) |		| EH(s) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Merge HEH to EHI		Figure 4: Merge HEH to EHI
	4. Configured FEC Labels		4. Configured FEC Labels
	It is also possible to use FEC labels to indicate the presence of		It is also possible to use FEC labels to indicate the presence of
	extension headers. An FEC label has the same forwarding semantics as		extension headers. An FEC label has the same forwarding semantics as
	the original label, but it also means that one or more extension		the original label, but it also means that one or more extension
	headers exist below the label stack.		headers exist below the label stack.
	Although this approach avoids the need of new header encoding		Although this approach avoids the need of new header encoding
	standards, it introduces a good deal of complexity into the control		standards, it introduces a good deal of complexity into the control
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 40 ¶
	issue is that this solution may not work for incremental deployment		issue is that this solution may not work for incremental deployment
	where some legacy routers cannot understand and apply the FEC labels		where some legacy routers cannot understand and apply the FEC labels
	for EH. Moreover, this configuration-based solution certainly makes		for EH. Moreover, this configuration-based solution certainly makes
	the cross-domain interoperability more difficult. Hence, this is the		the cross-domain interoperability more difficult. Hence, this is the
	least preferred option. We only include it here for the completeness		least preferred option. We only include it here for the completeness
	of the discussion.		of the discussion.
	5. Summary		5. Summary
	Evidenced by the existing and emerging use cases, MPLS networks need		Evidenced by the existing and emerging use cases, MPLS networks need
	a standard way to support extension headers. In Figure 4, we		a standard way to support extension headers. In Figure 5, we
	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 pros and cons for each scheme.		extension headers and list the main pros and cons for each scheme.
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	|No.| Description | Pros and Cons |		|No.| Description | Pros and Cons |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 1 | Special purpose EHL |+ Single label |		| 1 | Special purpose EHL |+ Single label |
	| | |+ Location freedom |		| | |+ Location freedom |
	| | |- Need standard extension |		| | |- Need standard extension |
	| | |- Use scarce resource |		| | |- Use scarce resource |
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 39 ¶
	| | |- Hack scarce resource (nibble) |		| | |- Hack scarce resource (nibble) |
	| | |- Need standard extension |		| | |- Need standard extension |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 5 | FEC label as EH indicator |+ No need for header standard |		| 5 | FEC label as EH indicator |+ No need for header standard |
	| | |- Complex control plane |		| | |- Complex control plane |
	| | |- Cross-domain interoperability |		| | |- Cross-domain interoperability |
	| | |- Label space issue |		| | |- Label space issue |
	| | |- Not for incremental deployment |		| | |- Not for incremental deployment |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	Figure 4: Potential Schemes for MPLS Extension Headers		Figure 5: 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 expect a working group consensus can be reached to pick		scheme, we expect a working group consensus can be reached to pick
	the final winner.		the final winner.
	6. Considerations of EHI		6. Considerations of EHI
	The existence of Extension Headers will make the ECMP based on inner		The existence of Extension Headers will make the ECMP based on inner
	IP packet header impossible or harder. If legacy routers need to		IP packet header impossible or harder. If legacy routers need to
	conduct this kind of ECMP, the process either fails or generates		conduct this kind of ECMP, the process either fails or generates
	unexpected results. EH-aware routers can do this kind of ECMP but		unexpected results. EH-aware routers can do this kind of ECMP but
	they need to skip all the EHs in order to access the inner packet		they need to skip all the EHs in order to access the inner packet
	header which may not be efficient. In this case, the Entropy Label		header which may not be efficient (we make provision in HEH to help
	(EL) is preferred for ECMP. The Entropy Label Indicator (ELI) and EL		accelerate this process). In this case, the Entropy Label (EL) is
	should be put in front of the EHI to avoid confusing the legacy		preferred for ECMP. The Entropy Label Indicator (ELI) and EL should
	routers.		be put in front of the EHI to avoid confusing the legacy routers.
	7. Security Considerations		7. Security Considerations
	TBD		TBD
	8. IANA Considerations		8. IANA Considerations
	If the EHL approach is adopted to indicate the presence of MPLS		If the EHL approach is adopted to indicate the presence of MPLS
	extension header(s), this document requests IANA to assign one or		extension header(s), this document requests IANA to assign one or
	more new Special-Purpose MPLS Label Values from the Special-Purpose		more new Special-Purpose MPLS Label Values from the Special-Purpose
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	11.2. Informative References		11.2. Informative References
	[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.song-mpls-extension-header]		[I-D.song-mpls-extension-header]
	Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS		Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS
	Extension Header", draft-song-mpls-extension-header-02		Extension Header", draft-song-mpls-extension-header-04
	(work in progress), February 2019.		(work in progress), April 2021.
	Authors' Addresses		Authors' Addresses
	Haoyu Song (editor)		Haoyu Song (editor)
	Futurewei Technologies		Futurewei Technologies
	2330 Central Expressway		2330 Central Expressway
	Santa Clara		Santa Clara
	USA		USA
	Email: haoyu.song@huawei.com		Email: haoyu.song@futurewei.com
	Zhenbin Li		Zhenbin Li
	Huawei		Huawei
	156 Beiqing Road		156 Beiqing Road
	Beijing, 100095		Beijing, 100095
	P.R. China		P.R. China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	Tianran Zhou		Tianran Zhou
End of changes. 22 change blocks.
	38 lines changed or deleted		56 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/