< draft-song-mpls-eh-indicator-02.txt		draft-song-mpls-eh-indicator-03.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: November 6, 2021 T. Zhou		Expires: January 3, 2022 T. Zhou
	Huawei		Huawei
	L. Andersson		L. Andersson
	Bronze Dragon Consulting		Bronze Dragon Consulting
	May 5, 2021		July 2, 2021
	Options for MPLS Extension Header Indicator		Options for MPLS Extension Header Indicator
	draft-song-mpls-eh-indicator-02		draft-song-mpls-eh-indicator-03
	Abstract		Abstract
	The intention of this document is to enumerate and describe the		The intention of this document is to enumerate and describe the
	candidate schemes that can be used to indicate the presence of the		candidate schemes that can be used to indicate the presence of the
	MPLS extension header(s) following the MPLS label stack. After a		MPLS extension header(s) following the MPLS label stack. After a
	careful evaluation of these options by comparing their pros and cons,		careful evaluation of these options by comparing their pros and cons,
	it is expected that one should be chosen as the final standard scheme		it is expected that one should be chosen as the final standard scheme
	for MPLS extension header indicator.		for MPLS extension header indicator.
	skipping to change at page 1, line 47 ¶		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 November 6, 2021.		This Internet-Draft will expire on January 3, 2022.
	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 29 ¶		skipping to change at page 2, line 29 ¶
	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 . 4		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 . . . . . . . . . . . . 5		3.2. GAL and a Different Nibble Value . . . . . . . . . . . . 5
	4. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 6		4. Extend MPLS Entropy Label . . . . . . . . . . . . . . . . . . 6
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Configured FEC Labels . . . . . . . . . . . . . . . . . . . . 7
	6. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 7		6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Considerations of EHI . . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		12.1. Normative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		12.2. Informative References . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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). An indicator is needed in the MPLS label stack to indicate the		(EH). An indicator is needed in the MPLS label stack to indicate the
	presence of the extension header(s). Multiple options are possible		presence of the extension header(s). Multiple options are possible
	for this purpose. As the discussion progresses, more options could		for this purpose. As the discussion progresses, more options could
	emerge.		emerge.
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 48 ¶
	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. If such		fields can potentially be used to encode other information. If such
	code points are open for other purpose, it will make the single EHL		code points are open for other purpose, it will make the single EHL
	idea more compelling. E.g., the EH category and/or other		idea more compelling. E.g., the EH category and/or other
	information, if needed, can be encoded in these fields, so that only		information, if needed, can be encoded in these fields, so that only
	one special label value is needed.		one special label value is needed.
	The following figure shows a potential scheme in which one bit from		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 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		the packet. If 'H' bit is 0, it means no HbH EH follows so a
	P-router will not need to check the EH.		P-router will not need to check the EH. The last 8 bits is used to
			find the location of the extension headers (i.e., the first byte
			after the MPLS label stack). This information can help to avoid the
			scan of the label stack in case the extension headers need to be
			accessed.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EHL (TBD) |H| |S| TTL |		| EHL (TBD) |H| |S| Offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Special EHL with EH Category Encoding		Figure 1: Special EHL with EH Category Encoding
			Note that the Cos/TTL fields can be encoded to include more
			information. For example, in addition to indicate the EH, it can
			also indicate the presence of some other label-based services (e.g.,
			EL). If we want to explore such possibilities, we have 11 bits in
			total at our disposal.
	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
	shares the same property as the single special purpose EHL scheme.		shares the same property as the single special purpose EHL scheme.
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 41 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 1 0| EHCNT | EHTLEN | NH |<-HEH		|0 0 1 0| EHCNT | EHTLEN | NH |<-HEH
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| EH(s) |		| EH(s) |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Merge HEH to EHI		Figure 4: Merge HEH to EHI
	4. Configured FEC Labels		4. Extend MPLS Entropy Label
			Instead of introducing a new SPL as the EH indicator, we can
			piggyback the indicator in some existing SPL to avoid claiming extra
			SPL resource and save a label overhead. The best candidate is the
			entropy label (EL) [RFC6790]. If we can make EL default for every
			MPLS packet, we can encode the EH indicator in the unused ELI/EL
			label fields such as CoS and TTL.
			In Figure 5 we show a possible encoding method, in which the first
			bit of the CoS field in ELI is used to indicate the presence of EH
			and teh TTL field in ELI is used to indicate the location of the EH.
			Note that the CoS field of the EL can also be used to encode other
			information, if necessary.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| ELI (7) |I| |S| Offset |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| EL | |S| 0 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 5: Special EHL with EH Category Encoding
			5. 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
	plane. Since every label needs an FEC label to indicate EH, this		plane. Since every label needs an FEC label to indicate EH, this
	scheme also significantly reduces the available label space. Another		scheme also significantly reduces the available label space. Another
	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		6. 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 5, we		a standard way to support extension headers. In Figure 6, 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 |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 2 | XL(15) + EHL |+ Location freedom |		| 2 | XL(15) + EHL |+ Location freedom |
	| | |+ Established mechanism |		| | |+ Established mechanism |
	| | |+ Abundant resource |		| | |+ Abundant resource |
	| | |- One extra label than Optiona 1 |		| | |- One extra label than Option 1 |
	| | |- Need standard extension |		| | |- Need standard extension |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 3 | GAL + ACH with channel |+ Reuse existing mechanism |		| 3 | GAL + ACH with channel |+ Reuse existing mechanism |
	| | type extension |+ Abundant resource |		| | type extension |+ Abundant resource |
	| | |- Label location limitation |		| | |- Label location limitation |
	| | |- One more word than Option 1 |		| | |- One more word than Option 1 |
	| | |- Not for user traffic |		| | |- Not for user traffic |
	| | |- Need standard extension/update |		| | |- Need standard extension/update |
	+---+---------------------------+---------------------------------+		+---+---------------------------+---------------------------------+
	| 4 | GAL + another nibble value|+ No change to ACH semantics |		| 4 | GAL + another nibble value|+ No change to ACH semantics |
	| | to indicate EHs (e.g., |+ Potential overhead saving |		| | to indicate EHs (e.g., |+ Potential overhead saving |
	| | "0010") |- Label location limitation |		| | "0010") |- Label location limitation |
	| | |- 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 | Extend ELI/EL |+ No need for new label |
			| | |- Need standard update |
			| | |- Need to make EL mandatory |
			| | |- One extra label than Option 1 |
			+---+---------------------------+---------------------------------+
			| 6 | 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 5: Potential Schemes for MPLS Extension Headers		Figure 6: Potential Schemes for MPLS Extension Headers
	Through comprehensive considerations on the pros and cons of each		Basically we have three groups of solutions. The scheme 1 and 2
	scheme, we expect a working group consensus can be reached to pick		introduce new labels, the scheme 3, 4, and 5 extend the existing
	the final winner.		solutions, and the scheme 6 relies on the control plane. Through
			comprehensive considerations on the pros and cons of each scheme, we
			expect a working group consensus can be reached to pick the final
			winner.
	6. Considerations of EHI		7. 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 (we make provision in HEH to help		header which may not be efficient (we make provision in HEH to help
	accelerate this process). In this case, the Entropy Label (EL) is		accelerate this process). In this case, the Entropy Label (EL) is
	preferred for ECMP. The Entropy Label Indicator (ELI) and EL should		preferred for ECMP. The Entropy Label Indicator (ELI) and EL should
	be put in front of the EHI to avoid confusing the legacy routers.		be put in front of the EHI to avoid confusing the legacy routers.
	7. Security Considerations		8. Security Considerations
	TBD		TBD
	8. IANA Considerations		9. 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
	Multiprotocol Label Switching (MPLS) Label Values Registry of		Multiprotocol Label Switching (MPLS) Label Values Registry of
	"Extension Header Label (EHL)".		"Extension Header Label (EHL)".
	9. Contributors		10. 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
	10. Acknowledgments		o Bruno Decraene
			11. Acknowledgments
	TBD.		TBD.
	11. References		12. References
	11.1. Normative References		12.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
			[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
			L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
			RFC 6790, DOI 10.17487/RFC6790, November 2012,
			<https://www.rfc-editor.org/info/rfc6790>.
	[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating		[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
	and Retiring Special-Purpose MPLS Labels", RFC 7274,		and Retiring Special-Purpose MPLS Labels", RFC 7274,
	DOI 10.17487/RFC7274, June 2014,		DOI 10.17487/RFC7274, June 2014,
	<https://www.rfc-editor.org/info/rfc7274>.		<https://www.rfc-editor.org/info/rfc7274>.
	[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>.
	11.2. Informative References		12.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-04		Extension Header", draft-song-mpls-extension-header-04
	(work in progress), April 2021.		(work in progress), April 2021.
End of changes. 24 change blocks.
	34 lines changed or deleted		86 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/