< draft-ietf-sfc-nsh-tlv-11.txt		draft-ietf-sfc-nsh-tlv-12.txt >
	SFC Yuehua. Wei, Ed.		SFC Yuehua. Wei, Ed.
	Internet-Draft ZTE Corporation		Internet-Draft ZTE Corporation
	Intended status: Standards Track U. Elzur		Intended status: Standards Track U. Elzur
	Expires: 16 July 2022 Intel		Expires: 29 July 2022 Intel
	S. Majee		S. Majee
	Individual contributor		Individual contributor
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	D. Eastlake		D. Eastlake
	Futurewei Technologies		Futurewei Technologies
	12 January 2022		25 January 2022
	Network Service Header Metadata Type 2 Variable-Length Context Headers		Network Service Header Metadata Type 2 Variable-Length Context Headers
	draft-ietf-sfc-nsh-tlv-11		draft-ietf-sfc-nsh-tlv-12
	Abstract		Abstract
	Service Function Chaining (SFC) uses the Network Service Header (NSH)		Service Function Chaining (SFC) uses the Network Service Header (NSH)
	(RFC 8300) to steer and provide context Metadata (MD) with each		(RFC 8300) to steer and provide context Metadata (MD) with each
	packet. Such Metadata can be of various Types including MD Type 2		packet. Such Metadata can be of various Types including MD Type 2
	variable length context headers. This document specifies several		variable length context headers. This document specifies several
	such context headers that can be used within a service function path.		such context headers that can be used within a service function path.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 16 July 2022.		This Internet-Draft will expire on 29 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3		3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3
	4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4		4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4
	4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4		4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4
	4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 6		4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 6
	4.3. Ingress Network Node Information . . . . . . . . . . . . 6		4.3. Ingress Network Node Information . . . . . . . . . . . . 6
	4.4. Ingress Network Source Interface . . . . . . . . . . . . 7		4.4. Ingress Network Source Interface . . . . . . . . . . . . 7
	4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.6. Source and/or Destination Groups . . . . . . . . . . . . 8		4.6. Source and/or Destination Groups . . . . . . . . . . . . 8
	4.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 9		4.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7.1. MD Type 2 Context Types . . . . . . . . . . . . . . . . . 10		7.1. MD Type 2 Context Types . . . . . . . . . . . . . . . . . 10
	7.2. Forwarding Context Types . . . . . . . . . . . . . . . . 10		7.2. Forwarding Context Types . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Network Service Header (NSH) [RFC8300] is the Service Function		The Network Service Header (NSH) [RFC8300] is the Service Function
	Chaining (SFC) encapsulation that supports the SFC architecture		Chaining (SFC) encapsulation that supports the SFC architecture
	[RFC7665]. As such, the NSH provides following key elements:		[RFC7665]. As such, the NSH provides following key elements:
	1. Service Function Path (SFP) identification.		1. Service Function Path (SFP) identification.
	2. Indication of location within a Service Function Path.		2. Indication of location within a Service Function Path.
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	Figure 7: Forwarding Context - 5(Session ID)		Figure 7: Forwarding Context - 5(Session ID)
	where:		where:
	Context Type (CT) is four bits-long field that defines the length		Context Type (CT) is four bits-long field that defines the length
	and the interpretation of the Forwarding Context field. Please		and the interpretation of the Forwarding Context field. Please
	see the IANA Considerations in Section 7. This document defines		see the IANA Considerations in Section 7. This document defines
	these CT values:		these CT values:
	- 0x0 - 12 bits VLAN identifier. See Figure 3. Reserved bits		- 0x0 - 12 bits VLAN identifier [IEEE.802.1Q_2018]. See
	MUST be sent as zero and ignored on receipt		Figure 3.
	- 0x1 - 24 bits double tagging identifiers. A service VLAN tag		- 0x1 - 24 bits double tagging identifiers. A service VLAN tag
	followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two		followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two
	VLAN IDs are concatenated and appear in the same order that		VLAN IDs are concatenated and appear in the same order that
	they appeared in the payload. See Figure 4. Reserved bits		they appeared in the payload. See Figure 4.
	MUST be sent as zero and ignored on receipt
	- 0x2 - 20 bits MPLS VPN label. See Figure 5. Reserved bits		- 0x2 - 20 bits MPLS VPN label([RFC3032])([RFC4364]). See
	MUST be sent as zero and ignored on receipt		Figure 5.
	- 0x3 - 24 bits virtual network identifier (VNI). See Figure 6.		- 0x3 - 24 bits virtual network identifier (VNI)[RFC8926]. See
	Reserved bits MUST be sent as zero and ignored on receipt		Figure 6.
	- 0x4 - 32 bits Session ID ([RFC3931]). This is called Key in		- 0x4 - 32 bits Session ID ([RFC3931]). This is called Key in
	GRE [RFC2890]. See Figure 7.		GRE [RFC2890]. See Figure 7.
			Reserved bits in the context fields MUST be sent as zero and
			ignored on receipt.
	4.2. Tenant Identifier		4.2. Tenant Identifier
	Tenant identification is often used for segregation within a multi-		Tenant identification is often used for segregation within a multi-
	tenant environment. Orchestration system-generated tenant IDs are an		tenant environment. Orchestration system-generated tenant IDs are an
	example of such data. This context header carries the value of the		example of such data. This context header carries the value of the
	Tenant identifier.		Tenant identifier. [OpenDaylight-VTN] Virtual Tenant Network (VTN)
			is an application that provides multi-tenant virtual network on an
			SDN controller.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metadata Class = 0x0000 | Type = TBA2 |U| Length = var|		| Metadata Class = 0x0000 | Type = TBA2 |U| Length = var|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Tenant ID ~		~ Tenant ID ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: Tenant Identifier List		Figure 8: Tenant Identifier List
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 29 ¶
	Node ID: Represents an opaque value of the ingress network node		Node ID: Represents an opaque value of the ingress network node
	ID. The structure and semantics of this field are deployment		ID. The structure and semantics of this field are deployment
	specific. For example, Node ID may be a 4 octets IPv4 address		specific. For example, Node ID may be a 4 octets IPv4 address
	Node ID, or a 16 octets IPv6 address Node ID, or a 6 octets MAC		Node ID, or a 16 octets IPv6 address Node ID, or a 6 octets MAC
	address, or 8 octets MAC address (EUI-64), etc.		address, or 8 octets MAC address (EUI-64), etc.
	4.4. Ingress Network Source Interface		4.4. Ingress Network Source Interface
	This context identifies the ingress interface of the ingress network		This context identifies the ingress interface of the ingress network
	node.		node. The l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166)
			in [IANAifType] are examples of source interfaces.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metadata Class = 0x0000 | Type = TBA4 |U| Length = var|		| Metadata Class = 0x0000 | Type = TBA4 |U| Length = var|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Source Interface ~		~ Source Interface ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Ingress Network Source Interface		Figure 10: Ingress Network Source Interface
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	Length: Indicates the length of the Source Interface in octets		Length: Indicates the length of the Source Interface in octets
	(see Section 2.5.1 of [RFC8300]).		(see Section 2.5.1 of [RFC8300]).
	Source Interface: Represents an opaque value of identifier of the		Source Interface: Represents an opaque value of identifier of the
	ingress interface of the ingress network node.		ingress interface of the ingress network node.
	4.5. Flow ID		4.5. Flow ID
	Flow ID provides a field in the NSH MD Type 2 to label packets		Flow ID provides a field in the NSH MD Type 2 to label packets
	belonging to the same flow. Absence of this field, or a value of		belonging to the same flow. For example, [RFC8200] defined IPv6 Flow
	zero denotes that packets have not been labeled.		Label as Flow ID, [RFC6790] defined an entropy label which is
			generated based on flow information in the MPLS network is another
			example of Flow ID. Absence of this field, or a value of zero
			denotes that packets have not been labeled.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 |		| Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow ID |		| Flow ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Flow ID		Figure 11: Flow ID
	The fields are described as follows:		The fields are described as follows:
	Length: Indicates the length of the Flow ID in octets (see		Length: Indicates the length of the Flow ID in octets (see
	Section 2.5.1 of [RFC8300]). [RFC8200] defined IPv6 Flow Label as		Section 2.5.1 of [RFC8300]). For example, IPv6 Flow Label in
	a 20-bit long unsigned integer. Also, [RFC6790], which defined		[RFC8200] is 20-bit long. An entropy label in the MPLS network in
	the use of an entropy label in the MPLS network, is 20-bit long.		[RFC6790] is also 20-bit long.
	Flow ID: Represents an opaque value of the Flow ID. The Flow ID		Flow ID: Represents an opaque value of the Flow ID. The Flow ID
	is right justified (appears in the least significant bits of the		is right justified (appears in the least significant bits of the
	Flow ID word) and is padded on the left with bits which MUST be		Flow ID word) and is padded on the left with bits which MUST be
	sent as zero and ignored on receipt.		sent as zero and ignored on receipt.
	4.6. Source and/or Destination Groups		4.6. Source and/or Destination Groups
	Intent-based systems can use this data to express the logical		Intent-based systems can use this data to express the logical
	grouping of source and/or destination objects. [OpenStack] and		grouping of source and/or destination objects. [OpenStack] and
	skipping to change at page 12, line 21 ¶		skipping to change at page 12, line 49 ¶
	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.,		[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>.
	8.2. Informative References		8.2. Informative References
			[IANAifType]
			IANA, "IANAifType", 2021,
			<https://www.iana.org/assignments/ianaiftype-mib/
			ianaiftype-mib>.
	[OpenDaylight]		[OpenDaylight]
	OpenDaylight, "Group Based Policy", 2021,		OpenDaylight, "Group Based Policy", 2021,
	<https://docs.opendaylight.org/en/stable-fluorine/user-		<https://docs.opendaylight.org/en/stable-fluorine/user-
	guide/group-based-policy-user-		guide/group-based-policy-user-
	guide.html?highlight=group%20policy#>.		guide.html?highlight=group%20policy#>.
			[OpenDaylight-VTN]
			OpenDaylight, "OpenDaylight VTN", 2021, <https://nexus.ope
			ndaylight.org/content/sites/site/org.opendaylight.docs/mas
			ter/userguide/manuals/userguide/bk-user-guide/
			content/_vtn.html>.
	[OpenStack]		[OpenStack]
	OpenStack, "Group Based Policy", 2021,		OpenStack, "Group Based Policy", 2021,
	<https://wiki.openstack.org/wiki/GroupBasedPolicy>.		<https://wiki.openstack.org/wiki/GroupBasedPolicy>.
	[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",		[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
	RFC 2890, DOI 10.17487/RFC2890, September 2000,		RFC 2890, DOI 10.17487/RFC2890, September 2000,
	<https://www.rfc-editor.org/info/rfc2890>.		<https://www.rfc-editor.org/info/rfc2890>.
			[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
			Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
			Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
			<https://www.rfc-editor.org/info/rfc3032>.
			[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
			Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
			2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.		<https://www.rfc-editor.org/info/rfc6790>.
	[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>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
			[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
			"Geneve: Generic Network Virtualization Encapsulation",
			RFC 8926, DOI 10.17487/RFC8926, November 2020,
			<https://www.rfc-editor.org/info/rfc8926>.
	[RFC8979] Sarikaya, B., von Hugo, D., and M. Boucadair, "Subscriber		[RFC8979] Sarikaya, B., von Hugo, D., and M. Boucadair, "Subscriber
	and Performance Policy Identifier Context Headers in the		and Performance Policy Identifier Context Headers in the
	Network Service Header (NSH)", RFC 8979,		Network Service Header (NSH)", RFC 8979,
	DOI 10.17487/RFC8979, February 2021,		DOI 10.17487/RFC8979, February 2021,
	<https://www.rfc-editor.org/info/rfc8979>.		<https://www.rfc-editor.org/info/rfc8979>.
	Authors' Addresses		Authors' Addresses
	Yuehua Wei (editor)		Yuehua Wei (editor)
	ZTE Corporation		ZTE Corporation
End of changes. 20 change blocks.
	24 lines changed or deleted		57 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/