draft-ietf-lisp-eid-mobility-08.txt		draft-ietf-lisp-eid-mobility-09.txt
	Network Working Group M. Portoles		Network Working Group M. Portoles
	Internet-Draft V. Ashtaputre		Internet-Draft V. Ashtaputre
	Intended status: Experimental V. Moreno		Intended status: Experimental F. Maino
	Expires: 26 January 2022 F. Maino		Expires: 22 July 2022 Cisco Systems
	Cisco Systems		V. Moreno
			Google LLC
	D. Farinacci		D. Farinacci
	lispers.net		lispers.net
	25 July 2021		18 January 2022
	LISP L2/L3 EID Mobility Using a Unified Control Plane		LISP L2/L3 EID Mobility Using a Unified Control Plane
	draft-ietf-lisp-eid-mobility-08		draft-ietf-lisp-eid-mobility-09
	Abstract		Abstract
	The LISP control plane offers the flexibility to support multiple		The LISP control plane offers the flexibility to support multiple
	overlay flavors simultaneously. This document specifies how LISP can		overlay flavors simultaneously. This document specifies how LISP can
	be used to provide control-plane support to deploy a unified L2 and		be used to provide control-plane support to deploy a unified L2 and
	L3 overlay solution for End-point Identifier (EID) mobility, as well		L3 overlay solution for End-point Identifier (EID) mobility, as well
	as analyzing possible deployment options and models.		as analyzing possible deployment options and models.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 45 ¶
	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 26 January 2022.		This Internet-Draft will expire on 22 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
	3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4		3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4
	4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5		4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5
	4.1. Reference Architecture and packet flows . . . . . . . . . 5		4.1. Reference Architecture and packet flows . . . . . . . . . 5
	4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6		4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6
	4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6		4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 17 ¶
	5.3.2. ARP registrations: MAC as a locator record . . . . . 19		5.3.2. ARP registrations: MAC as a locator record . . . . . 19
	5.3.3. Implementation Considerations . . . . . . . . . . . . 21		5.3.3. Implementation Considerations . . . . . . . . . . . . 21
	6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22		6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22
	6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22		6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22
	6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23		6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	9.1. Normative References . . . . . . . . . . . . . . . . . . 24		9.1. Normative References . . . . . . . . . . . . . . . . . . 24
	9.2. Informative References . . . . . . . . . . . . . . . . . 25		9.2. Informative References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	This document describes the architecture and design options required		This document describes the architecture and design options required
	to offer a unified L2 and L3 overlay solution for End-point		to offer a unified L2 and L3 overlay solution for End-point
	Identifier (EID) mobility using the LISP control-plane.		Identifier (EID) mobility using the LISP control-plane.
	The architecture takes advantage of the flexibility that LISP		The architecture takes advantage of the flexibility that LISP
	provides to simultaneously support different overlay types. While		provides to simultaneously support different overlay types. While
	the LISP specification defines both the data-plane and the control-		the LISP specification defines both the data-plane and the control-
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 10 ¶
	:Device 1: :Device 2: :Device 3: :Device 4:		:Device 1: :Device 2: :Device 3: :Device 4:
	'--------' '--------' '--------' '--------'		'--------' '--------' '--------' '--------'
	(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)		(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
	(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)		(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
	Figure 2: Reference Mobility Architecture		Figure 2: Reference Mobility Architecture
	4.1.1. Routed Traffic Flow: L3 Overlay use		4.1.1. Routed Traffic Flow: L3 Overlay use
	Inter-subnet traffic is encapsulated using the L3 overlay. The		Inter-subnet traffic is encapsulated using the L3 overlay. The
	process to encapsulate this traffic is the same as described in the		process to encapsulate this traffic is the same as described in
	original specification [RFC6830]. We describe the packet flow here		[I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis]. We
	for completeness		describe the packet flow here for completeness
	The following is a sequence example of the unicast packet flow and		The following is a sequence example of the unicast packet flow and
	the control plane operations when in the topology shown in Figure 1		the control plane operations when in the topology shown in Figure 1
	End-Device 1, in LISP site A, wants to communicate with End-Device 4		End-Device 1, in LISP site A, wants to communicate with End-Device 4
	in LISP site D. Note that both end systems reside in different		in LISP site D. Note that both end systems reside in different
	subnets. We'll assume that End-Device 1 knows the EID IP address of		subnets. We'll assume that End-Device 1 knows the EID IP address of
	End-Device 4 (e.g. it is learned using a DNS service).		End-Device 4 (e.g. it is learned using a DNS service).
	* End-Device 1 sends an IP packet frame with destination 2.0.0.4 and		* End-Device 1 sends an IP packet frame with destination 2.0.0.4 and
	source 1.0.0.1. As the destination address lies on a different		source 1.0.0.1. As the destination address lies on a different
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 27 ¶
	d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | EID-Prefix (IPv4 or IPv6) |		| | EID-Prefix (IPv4 or IPv6) |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| /| Priority | Weight | M Priority | M Weight |		| /| Priority | Weight | M Priority | M Weight |
	| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| o | Unused Flags |L|p|R| Loc-AFI |		| o | Unused Flags |L|p|R| Loc-AFI |
	| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| \| Locator |		| \| Locator |
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The L3 EID record follows the structure as described in [RFC6830].		The L3 EID record follows the structure as described in
			[I-D.ietf-lisp-rfc6833bis].
	4.2.3. LISP Mapping System support		4.2.3. LISP Mapping System support
	The interface between the xTRs and the Mapping System is described in		The interface between the xTRs and the Mapping System is described in
	[RFC6833] and this document follows the specification as described		[I-D.ietf-lisp-rfc6833bis] and this document follows the
	there. When available, the registrations MAY be implemented over a		specification as described there. When available, the registrations
	reliable transport as described in		MAY be implemented over a reliable transport as described in
	[I-D.kouvelas-lisp-map-server-reliable-transport].		[I-D.kouvelas-lisp-map-server-reliable-transport].
	In order to support system convergence after mobility, when the Map-		In order to support system convergence after mobility, when the Map-
	Server receives a new registration for a specific EID, it MUST send a		Server receives a new registration for a specific EID, it MUST send a
	Map-Notify to the entire RLOC set in the site that last registered		Map-Notify to the entire RLOC set in the site that last registered
	this same EID. This Map-Notify is used to track moved-away state of		this same EID. This Map-Notify is used to track moved-away state of
	L3 EIDs as described in Section 4.2.4.		L3 EIDs as described in Section 4.2.4.
	4.2.4. Using SMRs to Track Moved-Away Hosts		4.2.4. Using SMRs to Track Moved-Away Hosts
	One of the key elements to support end-host mobility using the LISP		One of the key elements to support end-host mobility using the LISP
	architecture is the Solicit-Map-Request (SMR). This is a special		architecture is the Solicit-Map-Request (SMR). This is a special
	message by means of which an ETR can request an ITR to send a new		message by means of which an ETR can request an ITR to send a new
	Map-Request for a particular EID record. In essence the SMR message		Map-Request for a particular EID record. In essence the SMR message
	is used as a signal to indicate a change in mapping information and		is used as a signal to indicate a change in mapping information and
	it is described with detail in [RFC6830].		it is described in [I-D.ietf-lisp-rfc6833bis].
	In order to support mobility, an ETR SHALL maintain a list of EID		In order to support mobility, an ETR SHALL maintain a list of EID
	records for which it has to generate a SMR message whenever it		records for which it has to generate a SMR message whenever it
	receives traffic with that EID as destination.		receives traffic with that EID as destination.
	The particular strategy to maintain an Away Table is implementation		The particular strategy to maintain an Away Table is implementation
	specific and it will be typically based on the strategy to detect the		specific and it will be typically based on the strategy to detect the
	presence of hosts and the use of Map-Notify messages received from		presence of hosts and the use of Map-Notify messages received from
	the Map-Server. In essence the table SHOULD provide support to the		the Map-Server. In essence the table SHOULD provide support to the
	following:		following:
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	4.2.5. L3 multicast support		4.2.5. L3 multicast support
	L3 Multicast traffic on the overlay MAY be supported by either		L3 Multicast traffic on the overlay MAY be supported by either
	replicated unicast, or underlay (RLOC) multicast. Specific solutions		replicated unicast, or underlay (RLOC) multicast. Specific solutions
	to support L3 multicast over LISP controlled overlays are specified		to support L3 multicast over LISP controlled overlays are specified
	in in [RFC6831], and [RFC8378].		in in [RFC6831], and [RFC8378].
	4.2.6. Time-to-Live Handling in Data-Plane		4.2.6. Time-to-Live Handling in Data-Plane
	The LISP specification ([RFC6830]) describes how to handle Time-to-		The LISP specification ([I-D.ietf-lisp-rfc6830bis]) describes how to
	Live values of the inner and outer headers during encapsulation and		handle Time-to-Live values of the inner and outer headers during
	decapsulation of packets when using the L3 overlay.		encapsulation and decapsulation of packets when using the L3 overlay.
	5. L2 Overlays and Mobility Support		5. L2 Overlays and Mobility Support
	5.1. Reference Architecture and packet flows		5.1. Reference Architecture and packet flows
	In order to support L2 packet flow descriptions in this section we		In order to support L2 packet flow descriptions in this section we
	use Figure 1 as reference. This section uses Sites B and C to		use Figure 1 as reference. This section uses Sites B and C to
	describe the flows.		describe the flows.
	/ | | \		/ | | \
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 29 ¶
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| /| ... Layer-2 MAC Address | Priority | Weight |		| /| ... Layer-2 MAC Address | Priority | Weight |
	| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| o | M Priority | M Weight | Unused Flags |L|p|R|		| o | M Priority | M Weight | Unused Flags |L|p|R|
	| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | | Loc-AFI | Locator.... |		| | | Loc-AFI | Locator.... |
	| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| \| ... Locator		| \| ... Locator
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The L2 EID record follows the structure as described in [RFC6830].		The L2 EID record follows the structure as described in
			[I-D.ietf-lisp-rfc6833bis].
	5.2.3. Interface to the LISP Mapping System		5.2.3. Interface to the LISP Mapping System
	The interface between the xTRs and the Mapping System is described in		The interface between the xTRs and the Mapping System is described in
	[RFC6833] and this document follows the specification as described		[I-D.ietf-lisp-rfc6833bis] and this document follows the
	there. When available, the registrations MAY be implemented over a		specification as described there. When available, the registrations
	reliable transport.		MAY be implemented over a reliable transport.
	In order to support system convergence after mobility, when the Map-		In order to support system convergence after mobility, when the Map-
	Server receives a new registration for a specific EID, it MUST send a		Server receives a new registration for a specific EID, it MUST send a
	Map-Notify to the entire RLOC set in the site that last registered		Map-Notify to the entire RLOC set in the site that last registered
	this same EID. This Map-Notify is used to track moved-away state of		this same EID. This Map-Notify is used to track moved-away state of
	L2 EIDs as described in Section 5.2.4.		L2 EIDs as described in Section 5.2.4.
	5.2.4. SMR support to track L2 hosts that moved away		5.2.4. SMR support to track L2 hosts that moved away
	In order to support mobility, an ETR SHALL maintain a list of EID		In order to support mobility, an ETR SHALL maintain a list of EID
	skipping to change at page 20, line 46 ¶		skipping to change at page 20, line 49 ¶
	| C | Rsvd1 | Flags | Type = 1 | Rsvd2 |		| C | Rsvd1 | Flags | Type = 1 | Rsvd2 |
	| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | | 2 + 6 | AFI = 6 |		| | | 2 + 6 | AFI = 6 |
	| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | | Layer-2 MAC Address ... |		| | | Layer-2 MAC Address ... |
	| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| \| ... Layer-2 MAC Address |		| \| ... Layer-2 MAC Address |
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
	An EID record with a locator record that carries a MAC address		An EID record with a locator record that carries a MAC address
	follows the same structure as described in [RFC6830]. However, some		follows the same structure as described in
	fields of the EID record and the locator record require special		[I-D.ietf-lisp-rfc6833bis]. However, some fields of the EID record
	consideration:		and the locator record require special consideration:
	Locator Count: This value SHOULD be set to 1.		Locator Count: This value SHOULD be set to 1.
	Instance-ID: This is the IID used to provide segmentation of the		Instance-ID: This is the IID used to provide segmentation of the
	L2-overlays, L3 overlays and ARP tables.		L2-overlays, L3 overlays and ARP tables.
	Priority and Weight: IP to MAC bindings are one to one bindings. An		Priority and Weight: IP to MAC bindings are one to one bindings. An
	ETR SHOULD not register more than one MAC address in the locator		ETR SHOULD not register more than one MAC address in the locator
	record together with an IP based EID. The Priority of the MAC		record together with an IP based EID. The Priority of the MAC
	address record is set to 255. The Weight value SHOULD be ignored		address record is set to 255. The Weight value SHOULD be ignored
	skipping to change at page 23, line 34 ¶		skipping to change at page 23, line 34 ¶
	and [VXLAN]:		and [VXLAN]:
	* VXLAN-GPE encap: This encapsulation format is defined in		* VXLAN-GPE encap: This encapsulation format is defined in
	[I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3		[I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3
	packets and the VNI field directly maps to the Instance-ID used in		packets and the VNI field directly maps to the Instance-ID used in
	the control plane. Note that when using this encapsulation for a		the control plane. Note that when using this encapsulation for a
	unified solution the P-bit is set and the Next-Protocol field is		unified solution the P-bit is set and the Next-Protocol field is
	used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in		used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in
	L3-overlays, and value 0x3 in L2-overlays).		L3-overlays, and value 0x3 in L2-overlays).
	* LISP encap: This is the encapsulation format defined in the		* LISP encap: This is the encapsulation format defined in the LISP
	original LISP specification [RFC6830]. The encapsulation allows		specification [I-D.ietf-lisp-rfc6830bis]. The encapsulation
	encapsulating both L2 and L3 packets. The Instance-ID used in the		allows encapsulating both L2 and L3 packets. The Instance-ID used
	EIDs directly maps to the Instance-ID that the LISP header		in the EIDs directly maps to the Instance-ID that the LISP header
	carries. At the ETR, after decapsulation, the IID MAY be used to		carries. At the ETR, after decapsulation, the IID MAY be used to
	decide between L2 processing or L3 processing.		decide between L2 processing or L3 processing.
	* VXLAN encap: This is a L2 encapsulation format defined in		* VXLAN encap: This is a L2 encapsulation format defined in
	[RFC7348]. While being a L2 encapsulation it can be used both for		[RFC7348]. While being a L2 encapsulation it can be used both for
	L2 and L3 overlays. The Instance-ID used in LISP signaling maps		L2 and L3 overlays. The Instance-ID used in LISP signaling maps
	to the VNI field of the VXLAN header. Providing L3 overlays using		to the VNI field of the VXLAN header. Providing L3 overlays using
	VXLAN generally requires using the ETR MAC address as destination		VXLAN generally requires using the ETR MAC address as destination
	MAC address of the inner Ethernet header. The process to learn or		MAC address of the inner Ethernet header. The process to learn or
	derive this ETR MAC address is not included as part of this		derive this ETR MAC address is not included as part of this
	skipping to change at page 25, line 21 ¶		skipping to change at page 25, line 21 ¶
	Separation Protocol (LISP) Multicast", RFC 8378,		Separation Protocol (LISP) Multicast", RFC 8378,
	DOI 10.17487/RFC8378, May 2018,		DOI 10.17487/RFC8378, May 2018,
	<https://www.rfc-editor.org/info/rfc8378>.		<https://www.rfc-editor.org/info/rfc8378>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-lisp-gpe]		[I-D.ietf-lisp-gpe]
	Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.		Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
	Smith, "LISP Generic Protocol Extension", Work in		Smith, "LISP Generic Protocol Extension", Work in
	Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July		Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July
	2020, <https://www.ietf.org/internet-drafts/draft-ietf-		2020, <https://www.ietf.org/archive/id/draft-ietf-lisp-
	lisp-gpe-19.txt>.		gpe-19.txt>.
	[I-D.ietf-lisp-pubsub]		[I-D.ietf-lisp-pubsub]
	AlbertoRodriguezNatal, Ermagan, V., Cabellos-Aparicio, A.,		Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
	Barkai, S., and M. Boucadair, "Publish/Subscribe		S., and M. Boucadair, "Publish/Subscribe Functionality for
	Functionality for LISP", Work in Progress, Internet-Draft,		LISP", Work in Progress, Internet-Draft, draft-ietf-lisp-
	draft-ietf-lisp-pubsub-09, 28 June 2021,		pubsub-09, 28 June 2021, <https://www.ietf.org/archive/id/
	<https://www.ietf.org/archive/id/draft-ietf-lisp-pubsub-		draft-ietf-lisp-pubsub-09.txt>.
	09.txt>.
			[I-D.ietf-lisp-rfc6830bis]
			Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
			Cabellos, "The Locator/ID Separation Protocol (LISP)",
			Work in Progress, Internet-Draft, draft-ietf-lisp-
			rfc6830bis-36, 18 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-lisp-
			rfc6830bis-36.txt>.
			[I-D.ietf-lisp-rfc6833bis]
			Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
			"Locator/ID Separation Protocol (LISP) Control-Plane",
			Work in Progress, Internet-Draft, draft-ietf-lisp-
			rfc6833bis-30, 18 November 2020,
			<https://www.ietf.org/archive/id/draft-ietf-lisp-
			rfc6833bis-30.txt>.
	[I-D.ietf-lisp-vpn]		[I-D.ietf-lisp-vpn]
	Moreno, V. and D. Farinacci, "LISP Virtual Private		Moreno, V. and D. Farinacci, "LISP Virtual Private
	Networks (VPNs)", Work in Progress, Internet-Draft, draft-		Networks (VPNs)", Work in Progress, Internet-Draft, draft-
	ietf-lisp-vpn-06, 3 August 2020, <http://www.ietf.org/		ietf-lisp-vpn-08, 18 January 2022,
	internet-drafts/draft-ietf-lisp-vpn-06.txt>.		<https://www.ietf.org/archive/id/draft-ietf-lisp-vpn-
			08.txt>.
	[I-D.kouvelas-lisp-map-server-reliable-transport]		[I-D.kouvelas-lisp-map-server-reliable-transport]
	Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C.,		Leong, J., Lewis, D., Pitta, B., Cassar, C., Kouvelas, I.,
	Kouvelas, I., and J. Arango, "LISP Map Server Reliable		and J. Arango, "LISP Map Server Reliable Transport", Work
	Transport", Work in Progress, Internet-Draft, draft-		in Progress, Internet-Draft, draft-kouvelas-lisp-map-
	kouvelas-lisp-map-server-reliable-transport-06, 26 April		server-reliable-transport-07, 18 January 2022,
	2021, <https://www.ietf.org/archive/id/draft-kouvelas-		<https://www.ietf.org/archive/id/draft-kouvelas-lisp-map-
	lisp-map-server-reliable-transport-06.txt>.		server-reliable-transport-07.txt>.
	Authors' Addresses		Authors' Addresses
	Marc Portoles Comeras		Marc Portoles Comeras
	Cisco Systems		Cisco Systems
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	United States of America		United States of America
	Email: mportole@cisco.com		Email: mportole@cisco.com
	Vrushali Ashtaputre		Vrushali Ashtaputre
	Cisco Systems		Cisco Systems
	skipping to change at page 26, line 20 ¶		skipping to change at page 26, line 31 ¶
	Email: mportole@cisco.com		Email: mportole@cisco.com
	Vrushali Ashtaputre		Vrushali Ashtaputre
	Cisco Systems		Cisco Systems
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	United States of America		United States of America
	Email: vrushali@cisco.com		Email: vrushali@cisco.com
	Victor Moreno
	Cisco Systems
	170 Tasman Drive
	San Jose, CA 95134
	United States of America
	Email: vimoreno@cisco.com
	Fabio Maino		Fabio Maino
	Cisco Systems		Cisco Systems
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	United States of America		United States of America
	Email: fmaino@cisco.com		Email: fmaino@cisco.com
			Victor Moreno
			Google LLC
			1600 Amphitheatre Pkwy
			Mountain View, CA 94043
			United States of America
			Email: vimoreno@google.com
	Dino Farinacci		Dino Farinacci
	lispers.net		lispers.net
	San Jose, CA		San Jose, CA
	United States of America		United States of America
	Email: farinacci@gmail.com		Email: farinacci@gmail.com
End of changes. 23 change blocks.
	57 lines changed or deleted		76 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/