draft-ietf-lisp-gpe-17.txt		draft-ietf-lisp-gpe-18.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: January 8, 2021 Broadcom		Expires: January 14, 2021 Broadcom
	P. Agarwal		P. Agarwal
	Innovium		Innovium
	D. Lewis		D. Lewis
	M. Smith		M. Smith
	Cisco		Cisco
	July 7, 2020		July 13, 2020
	LISP Generic Protocol Extension		LISP Generic Protocol Extension
	draft-ietf-lisp-gpe-17		draft-ietf-lisp-gpe-18
	Abstract		Abstract
	This document describes extensions to the Locator/ID Separation		This document describes extensions 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 and allow to introduce new
			protocol capabilities.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 8, 2021.		This Internet-Draft will expire on January 14, 2021.
	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 2, line 26 ¶		skipping to change at page 2, line 27 ¶
	4. Implementation and Deployment Considerations . . . . . . . . 6		4. Implementation and Deployment Considerations . . . . . . . . 6
	4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6		4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
	4.2. Congestion Control Functionality . . . . . . . . . . . . 7		4.2. Congestion Control Functionality . . . . . . . . . . . . 7
	4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8		4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8
	4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8		4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8
	4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10		4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10
	5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10		5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
	5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11		5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11		6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12		8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It		The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It
	specifies an encapsulation format that carries IPv4 or IPv6 packets		specifies an encapsulation format that carries IPv4 or IPv6 packets
	(henceforth jointly referred to as IP) in a LISP header and outer		(henceforth jointly referred to as IP) in a LISP header and outer
	UDP/IP transport.		UDP/IP transport.
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 43 ¶
	4.2. Congestion Control Functionality		4.2. Congestion Control Functionality
	LISP-GPE does not natively provide congestion control functionality		LISP-GPE does not natively provide congestion control functionality
	and relies on the payload protocol traffic for congestion control.		and relies on the payload protocol traffic for congestion control.
	As such LISP-GPE MUST be used with congestion controlled traffic or		As such LISP-GPE MUST be used with congestion controlled traffic or
	within a network that is traffic managed to avoid congestion (TMCE).		within a network that is traffic managed to avoid congestion (TMCE).
	An operator of a traffic managed network (TMCE) may avoid congestion		An operator of a traffic managed network (TMCE) may avoid congestion
	by careful provisioning of their networks, rate-limiting of user data		by careful provisioning of their networks, rate-limiting of user data
	traffic and traffic engineering according to path capacity.		traffic and traffic engineering according to path capacity.
	Encapsulated payloads may have Explicit Congestion Notification		Keeping in mind the reccomendation above, new encapsulated payloads,
	mechanisms that may or may not be mapped to the outer IP header ECN		when registered with LISP-GPE, should be designed for explicit
	field. Such new encapsulated payloads, when registered with LISP-		congestion signals to propagate consistently from lower layer
	GPE, MUST be accompanied by a set of guidelines derived from		protocols into IP. Then the IP internetwork layer can act as a
	[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].		portability layer to carry congestion notification from non-IP-aware
			congested nodes up to the transport layer (L4). Such new
			encapsulated payloads, when registered with LISP-GPE, MUST be
			accompanied by a set of guidelines derived from [RFC6040] and SHOULD
			follow the guidelines defined in
			[I-D.ietf-tsvwg-ecn-encap-guidelines].
	4.3. UDP Checksum		4.3. UDP Checksum
	For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies		For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies
	how to handle UDP Checksums encouraging implementors to consider UDP		how to handle UDP Checksums encouraging implementors to consider UDP
	checksum usage guidelines in section 3.4 of [RFC8085] when it is		checksum usage guidelines in section 3.4 of [RFC8085] when it is
	desirable to protect UDP and LISP headers against corruption.		desirable to protect UDP and LISP headers against corruption.
	In order to provide integrity of LISP-GPE headers, options and		In order to provide integrity of LISP-GPE headers, options and
	payload, for example to avoid mis-delivery of payload to different		payload, for example to avoid mis-delivery of payload to different
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 35 ¶
	An operator MAY choose to disable UDP checksum and use zero checksum		An operator MAY choose to disable UDP checksum and use zero checksum
	if LISP-GPE packet integrity is provided by other data integrity		if LISP-GPE packet integrity is provided by other data integrity
	mechanisms such as IPsec or additional checksums or if one of the		mechanisms such as IPsec or additional checksums or if one of the
	conditions in Section 4.3.1 a, b, c are met.		conditions in Section 4.3.1 a, b, c are met.
	4.3.1. UDP Zero Checksum Handling with IPv6		4.3.1. UDP Zero Checksum Handling with IPv6
	By default, UDP checksum MUST be used when LISP-GPE is transported		By default, UDP checksum MUST be used when LISP-GPE is transported
	over IPv6. A tunnel endpoint MAY be configured for use with zero UDP		over IPv6. A tunnel endpoint MAY be configured for use with zero UDP
	checksum if additional requirements in Section 4.3.1 are met.		checksum if additional requirements described in this section are
			met.
	When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6		When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6
	headers, UDP headers and LISP-GPE headers and payload from potential		headers, UDP headers and LISP-GPE headers and payload from potential
	data corruption. As such by default LISP-GPE MUST use UDP checksum		data corruption. As such by default LISP-GPE MUST use UDP checksum
	when transported over IPv6. An operator MAY choose to configure to		when transported over IPv6. An operator MAY choose to configure to
	operate with zero UDP checksum if operating in a traffic managed		operate with zero UDP checksum if operating in a traffic managed
	controlled environment as stated in Section 4.1 if one of the		controlled environment as stated in Section 4.1 if one of the
	following conditions are met:		following conditions are met:
	a. It is known that the packet corruption is exceptionally unlikely		a. It is known that the packet corruption is exceptionally unlikely
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 24 ¶
	(such as IPsec) SHOULD be used in combination with LISP-GPE by those		(such as IPsec) SHOULD be used in combination with LISP-GPE by those
	protocol extensions that want to protect from on-path attackers.		protocol extensions that want to protect from on-path attackers.
	With LISP-GPE, issues such as data-plane spoofing, flooding, and		With LISP-GPE, issues such as data-plane spoofing, flooding, and
	traffic redirection may depend on the particular protocol payload		traffic redirection may depend on the particular protocol payload
	encapsulated.		encapsulated.
	8. Acknowledgements and Contributors		8. Acknowledgements and Contributors
	A special thank you goes to Dino Farinacci for his guidance and		A special thank you goes to Dino Farinacci for his guidance and
	detailed review.		detailed review. Thanks to Tom Herbert for the suggestion to assign
			codepoints for experimentations and testing.
	This Working Group (WG) document originated as draft-lewis-lisp-gpe;		This Working Group (WG) document originated as draft-lewis-lisp-gpe;
	the following are its coauthors and contributors along with their		the following are its coauthors and contributors along with their
	respective affiliations at the time of WG adoption. The editor of		respective affiliations at the time of WG adoption. The editor of
	this document would like to thank and recognize them and their		this document would like to thank and recognize them and their
	contributions. These coauthors and contributors provided invaluable		contributions. These coauthors and contributors provided invaluable
	concepts and content for this document's creation.		concepts and content for this document's creation.
	o Darrel Lewis, Cisco Systems, Inc.		o Darrel Lewis, Cisco Systems, Inc.
End of changes. 10 change blocks.
	15 lines changed or deleted		23 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/