draft-ietf-lisp-gpe-13.txt		draft-ietf-lisp-gpe-14.txt
	Internet Engineering Task Force F. Maino, Ed.		Internet Engineering Task Force F. Maino, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Lemon		Intended status: Standards Track J. Lemon
	Expires: July 9, 2020 Broadcom		Expires: July 11, 2020 Broadcom
	P. Agarwal		P. Agarwal
	Innovium		Innovium
	D. Lewis		D. Lewis
	M. Smith		M. Smith
	Cisco		Cisco
	January 6, 2020		January 8, 2020
	LISP Generic Protocol Extension		LISP Generic Protocol Extension
	draft-ietf-lisp-gpe-13		draft-ietf-lisp-gpe-14
	Abstract		Abstract
	This document describes extentions to the Locator/ID Separation		This document describes extentions to the Locator/ID Separation
	Protocol (LISP) Data-Plane, via changes to the LISP header, to		Protocol (LISP) Data-Plane, via changes to the LISP header, to
	support multi-protocol encapsulation.		support multi-protocol encapsulation.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 July 9, 2020.		This Internet-Draft will expire on July 11, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	This document defines two changes to the LISP header in order to		This document defines two changes to the LISP header in order to
	support multi-protocol encapsulation: the introduction of the P-bit		support multi-protocol encapsulation: the introduction of the P-bit
	and the definition of a Next Protocol field. This document specifies		and the definition of a Next Protocol field. This document specifies
	the protocol behavior when the P-bit is set to 1, no changes are		the protocol behavior when the P-bit is set to 1, no changes are
	introduced when the P-bit is set to 0. The LISP-GPE header is shown		introduced when the P-bit is set to 0. The LISP-GPE header is shown
	in Figure 2 and described below.		in Figure 2 and described below.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|N|L|E|V|I|P|K|K| Reserved | Next Protocol |		|N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Instance ID |		| Instance ID/Locator-Status-Bits |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: LISP-GPE Header		Figure 2: LISP-GPE Header
	P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is		P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
	set to 1 to indicate the presence of the 8 bit Next Protocol		set to 1 to indicate the presence of the 8 bit Next Protocol
	field.		field.
	If the P-bit is clear (0) the LISP header is bit-by-bit equivalent		If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
	to the definition in [I-D.ietf-lisp-rfc6830bis].		to the definition in [I-D.ietf-lisp-rfc6830bis].
	When the P-bit is set to 1, bits N, E, and V MUST be set zero on		When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the
			'Nonce/Map-Version/Next Protocol' field MUST be set to zero on
	transmission and ignored on receipt. Features equivalent to those		transmission and ignored on receipt. Features equivalent to those
	that were implemented with bits N,E and V in		that were implemented with bits N,E and V in
	[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-		[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
	versioning, can be implemented by defining appropriate LISP-GPE		versioning, can be implemented by defining appropriate LISP-GPE
	shim headers.		shim headers.
	Next Protocol: The lower 8 bits of the first 32-bit word are used to		When the P-bit is set to 1, the LISP-GPE header is encoded as:
	carry a Next Protocol. This Next Protocol field contains the
	protocol of the encapsulated payload packet.		0 x 0 0 x 1 x x
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Instance ID/Locator-Status-Bits |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 3: LISP-GPE with P-bit set to 1
			Next Protocol: When the P-bit is set to 1, the lower 8 bits of the
			first 32-bit word are used to carry a Next Protocol. This Next
			Protocol field contains the protocol of the encapsulated payload
			packet.
	This document defines the following Next Protocol values:		This document defines the following Next Protocol values:
	0x01 : IPv4		0x01 : IPv4
	0x02 : IPv6		0x02 : IPv6
	0x03 : Ethernet		0x03 : Ethernet
	0x04 : Network Service Header (NSH) [RFC8300]		0x04 : Network Service Header (NSH) [RFC8300]
	0x05 to 0x7F: Unassigned		0x05 to 0x7F: Unassigned
	0x80 to 0xFF: Unassigned (shim headers)		0x80 to 0xFF: Unassigned (shim headers)
	The values are tracked in the IANA LISP-GPE Next Protocol Registry		The values are tracked in the IANA LISP-GPE Next Protocol Registry
	as described in Section 6.1.		as described in Section 6.1.
	Next protocol values from Ox80 to 0xFF are assigned to protocols		Next protocol values from Ox80 to 0xFF are assigned to protocols
	encoded as generic "shim" headers. All shim protocols MUST use the		encoded as generic "shim" headers. All shim protocols MUST use the
	header structure in Figure 3, which includes a Next Protocol field.		header structure in Figure 4, which includes a Next Protocol field.
	When a shim header is used with other protocols identified by next		When a shim header is used with other protocols identified by next
	protocol values from 0x0 to 0x7F, the shim header MUST come before		protocol values from 0x0 to 0x7F, the shim header MUST come before
	the further protocol, and the next header of the shim will indicate		the further protocol, and the next header of the shim will indicate
	which protocol follows the shim header.		which protocol follows the shim header.
	Shim headers can be used to incrementally deploy new GPE features,		Shim headers can be used to incrementally deploy new GPE features,
	keeping the processing of shim headers known to a given xTR		keeping the processing of shim headers known to a given xTR
	implementation in the 'fast' path (typically an ASIC), while punting		implementation in the 'fast' path (typically an ASIC), while punting
	the processing of the remaining new GPE features to the 'slow' path.		the processing of the remaining new GPE features to the 'slow' path.
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved | Next Protocol |		| Type | Length | Reserved | Next Protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Protocol Specific Fields ~		~ Protocol Specific Fields ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Shim Header		Figure 4: Shim Header
	Where:		Where:
	Type: This field identifies the different messages of this protocol.		Type: This field identifies the different messages of this protocol.
	Length: The length, in 4-octect units, of this protocol message not		Length: The length, in 4-octect units, of this protocol message not
	including the first 4 octects.		including the first 4 octects.
	Reserved: The use of this field is reserved to the protocol defined		Reserved: The use of this field is reserved to the protocol defined
	in this message.		in this message.
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 20 ¶
	Email: jennifer.lemon@broadcom.com		Email: jennifer.lemon@broadcom.com
	Puneet Agarwal		Puneet Agarwal
	Innovium		Innovium
	USA		USA
	Email: puneet@acm.org		Email: puneet@acm.org
	Darrel Lewis		Darrel Lewis
	Cisco Systems		Cisco Systems
			San Jose, CA 95134
			USA
	Email: darlewis@cisco.com		Email: darlewis@cisco.com
	Michael Smith		Michael Smith
	Cisco Systems		Cisco Systems
			San Jose, CA 95134
			USA
	Email: michsmit@cisco.com		Email: michsmit@cisco.com
End of changes. 12 change blocks.
	12 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/