draft-ietf-lisp-eid-mobility-02.txt		draft-ietf-lisp-eid-mobility-03.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 V. Moreno
	Expires: November 15, 2018 F. Maino		Expires: May 17, 2019 F. Maino
	Cisco Systems		Cisco Systems
	D. Farinacci		D. Farinacci
	lispers.net		lispers.net
	May 14, 2018		November 13, 2018
	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-02		draft-ietf-lisp-eid-mobility-03
	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, as well as analyzing possible deployment options		L3 overlay solution for End-point Identifier (EID) mobility, as well
	and models.		as analyzing possible deployment options and models.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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 44 ¶		skipping to change at page 1, line 44 ¶
	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 15, 2018.		This Internet-Draft will expire on May 17, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified 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 . . . . . . . . . . . . . . 6
	4.1. Reference Architecture and packet flows . . . . . . . . . 5		4.1. Reference Architecture and packet flows . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . 7
	4.2. Implementation Considerations . . . . . . . . . . . . . . 7		4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7
	4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7		4.1.2.2. L3 Mobility Flow using Publish/Subscribe
	4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8		Mechanisms . . . . . . . . . . . . . . . . . . . 8
	4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8		4.2. Implementation Considerations . . . . . . . . . . . . . . 9
	4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9		4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9
	4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9		4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9
	4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9		4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10
	5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9		4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 11
	5.1. Reference Architecture and packet flows . . . . . . . . . 9		4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11
	5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10		4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11
	5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11		5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11
	5.2. Implementation Considerations . . . . . . . . . . . . . . 11		5.1. Reference Architecture and packet flows . . . . . . . . . 11
	5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 11		5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12
	5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12		5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13
	5.2.3. Interface to the LISP Mapping System . . . . . . . . 13		5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13
	5.2.4. SMR support to track L2 hosts that moved away . . . . 13		5.1.2.2. L2 Mobility Flow using Publish/Subscribe
	5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14		mechanisms . . . . . . . . . . . . . . . . . . . 14
	5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14		5.2. Implementation Considerations . . . . . . . . . . . . . . 14
	5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15		5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 14
	5.3. Support to ARP resolution through Mapping System . . . . 15		5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15
	5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15		5.2.3. Interface to the LISP Mapping System . . . . . . . . 16
	5.3.2. ARP registrations: MAC as a locator record . . . . . 16		5.2.4. SMR support to track L2 hosts that moved away . . . . 16
	5.3.3. Implementation Considerations . . . . . . . . . . . . 18		5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17
	6. Optional Deployment Models . . . . . . . . . . . . . . . . . 19		5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17
	6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 19		5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18
	6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 20		5.3. Support to ARP resolution through Mapping System . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		5.3.1. Map-Server support to ARP resolution: Packet Flow . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		5.3.2. ARP registrations: MAC as a locator record . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		5.3.3. Implementation Considerations . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . 21		6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22
	9.2. Informative References . . . . . . . . . . . . . . . . . 22		6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
			9.1. Normative References . . . . . . . . . . . . . . . . . . 24
			9.2. Informative References . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	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 with mobility using the		to offer a unified L2 and L3 overlay solution for End-point
	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-
	plane, this document focuses on the use of the control-plane to		plane, this document focuses on the use of the control-plane to
	provide L2 and L3 overlay services with mobility. The control plane		provide L2 and L3 overlay services with EID mobility. The control
	may be combined with a data-plane of choice e.g., [LISP], [VXLAN-		plane may be combined with a data-plane of choice e.g., [LISP],
	GPE], or [VXLAN].		[VXLAN-GPE], or [VXLAN].
	The recommendation on whether a flow is sent over the L2 or the L3		The recommendation on whether a flow is sent over the L2 or the L3
	overlay is based on whether the traffic is bridged (intra-subnet or		overlay is based on whether the traffic is bridged (intra-subnet or
	non-IP) or routed (inter-subnet), respectively. This allows treating		non-IP) or routed (inter-subnet), respectively. This allows treating
	both overlays as separate segments, and enables L2-only and L3-only		both overlays as separate segments, and enables L2-only and L3-only
	deployments (and combinations of them) without modifying the		deployments (and combinations of them) without modifying the
	architecture.		architecture.
	The unified solution for L2 and L3 overlays offers the possibility to		The unified solution for L2 and L3 overlays offers the possibility to
	extend subnets and routing domains (as required in state-of-art		extend subnets and routing domains (as required in state-of-art
	Datacenter and Enterprise architectures) with mobility support and		Datacenter and Enterprise architectures) with mobility support and
	traffic optimization.		traffic optimization.
	An important use-case of the unified architecture is that, while most		An important use-case of the unified architecture is that, while most
	data centers are complete layer-3 routing domains, legacy		data centers are complete layer-3 routing domains, legacy
	applications either have not converted to IP or still use auto-		applications either have not converted to IP or still use auto-
	discovery at layer-2 and assume all nodes in an application cluster		discovery at layer-2 and assume all nodes in an application cluster
	belong to the same subnet. For these applications, the L2-overlay		belong to the same subnet. For these applications, the L2-overlay
	limits the functionality to where the legacy app lives versus having		limits the functionality to where the legacy app lives versus having
	to extend layer-2 into the network.		to extend layer-2 into the underlay network.
	Broadcast, Unknown and Multicast traffic on the overlay are supported		Broadcast, Unknown and Multicast traffic on the overlay are supported
	by either replicated unicast, or underlay (RLOC) multicast as		by either replicated unicast, or underlay (RLOC) multicast as
	specified in [RFC6831] and [RFC8378].		specified in [RFC6831] and [RFC8378].
	2. Definition of Terms		2. Definition of Terms
	LISP related terms are defined as part of the LISP specification		LISP related terms are defined as part of the LISP specification
	[RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify,		[RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify,
	Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server		Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server
	skipping to change at page 6, line 49 ¶		skipping to change at page 7, line 30 ¶
	4.1.2. L3 Mobility Flow		4.1.2. L3 Mobility Flow
	The support to L3 mobility covers the requirements to allow an end-		The support to L3 mobility covers the requirements to allow an end-
	host to move from a given site to another and maintain correspondence		host to move from a given site to another and maintain correspondence
	with the rest of end-hosts that are connected to the same L3 routing		with the rest of end-hosts that are connected to the same L3 routing
	domain. This support MUST ensure convergence of L3 forwarding (IPv4/		domain. This support MUST ensure convergence of L3 forwarding (IPv4/
	IPv6 based) from the old location to the new one when the host		IPv6 based) from the old location to the new one when the host
	completes its move.		completes its move.
			The update of the ITR map-caches when EIDs move MAY be achieved using
			Data Driven SMRs or the Publish/Subscribe mechanisms defined in
			[I-D.ietf-lisp-pubsub]. The following two sections are sequence
			descriptions of the packet flow when End-Device 1 in the reference
			figure roams to site D.
			4.1.2.1. L3 Mobility Flow using Data Driven SMRs
	The following is a sequence description of the packet flow when End-		The following is a sequence description of the packet flow when End-
	Device 1 in the reference figure roams to site D:		Device 1 in the reference figure roams to site D. This sequence uses
			Data Driven SMRs to trigger the updates of the ITR map-caches.
	o When End-Device 1 is attached or detected in site D, ETR D sets up		o When End-Device 1 is attached or detected in site D, ETR D sets up
	the database mapping corresponding to EID=<IID1, 1.0.0.1>. ETR D		the database mapping corresponding to EID=<IID1, 1.0.0.1>. ETR D
	sends a Map-Register to the mapping system registering RLOC=IP_D		sends a Map-Register to the mapping system registering RLOC=IP_D
	as locator for EID=<IID1, 1.0.0.1>. Now the mapping system is		as locator for EID=<IID1, 1.0.0.1>. Now the mapping system is
	updated with the new EID-to-RLOC mapping (location) for End-Device		updated with the new EID-to-RLOC mapping (location) for End-Device
	1.		1.
	o The Mapping System, after receiving the new registration for		o The Mapping System, after receiving the new registration for
	EID=<IID1, 1.0.0.1> sends a Map-Notify to ETR A to inform it of		EID=<IID1, 1.0.0.1> sends a Map-Notify to the departure ETR(s)
	the move. Then, ETR A removes its local database mapping		(ETR A) to inform it of the move. Then, ETR A removes its local
	information and stops registering EID=<IID1, 1.0.0.1>.		database mapping information and stops registering EID=<IID1,
			1.0.0.1>.
	o Any ITR or PiTR participating in the L3 overlay (corresponding to		o Any ITR or PiTR participating in the L3 overlay (corresponding to
	IID1) that were sending traffic to 1.0.0.1 before the migration		IID1) that were sending traffic to 1.0.0.1 before the migration
	keep sending traffic to ETR A.		keep sending traffic to ETR A.
	o Once ETR A is notified by the Mapping system, when it receives		o Once ETR A is notified by the Mapping system, when it receives
	traffic from an ITR with destination 1.0.0.1, it generates a		traffic from an ITR with destination 1.0.0.1, it generates a
	Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=<IID1,		Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=<IID1,
	1.0.0.1>.		1.0.0.1>.
	skipping to change at page 7, line 37 ¶		skipping to change at page 8, line 27 ¶
	entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request for that		entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request for that
	EID. The Map-Reply includes the new EID-to-RLOC mapping for End-		EID. The Map-Reply includes the new EID-to-RLOC mapping for End-
	Device 1 with RLOC=IP_D.		Device 1 with RLOC=IP_D.
	o Similarly, once the local database mapping is removed from ITR A,		o Similarly, once the local database mapping is removed from ITR A,
	non-encapsulated packets arriving at ITR A from a local End-Device		non-encapsulated packets arriving at ITR A from a local End-Device
	and destined to End-Device 1 result in a cache miss, which		and destined to End-Device 1 result in a cache miss, which
	triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate		triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate
	the map-cache of ITR A.		the map-cache of ITR A.
			4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms
			When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used,
			the flow of signaling to achieve EID mobility is modified. In this
			case, when an local end-device connected via an ITR establishes
			communication with a remote mobile end-device (connected to a remote
			ETR), the ITR will issue a Map-Request for the mobile end-device.
			Following the Mapping Request Subscribe Procedures defined in
			[I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit
			set on the EID-Record so that the ITR is notified of any RLOC-set
			changes for the mobile EID-prefix.
			The following is a sequence description of the packet flow when End-
			Device 1 in the reference figure roams to site D. This sequence
			leverages Publish/Subscribe mechanisms to update the ITR map-caches.
			o When an end-Device connected via an ITR establishes communication
			with a mobile end-device (e.g. end-device 1), the ITR will issue a
			Map-Request for the mobile end-device. Following the Mapping
			Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub],
			the Map-request will be issued with the N-bit set on the EID-
			Record so that the ITR is notified of any RLOC-set changes for the
			mobile EID-prefix.
			o When the mobile end-device (End-Device 1) is attached or detected
			in a new site (e.g. site D), The ETR at the new site (e.g. ETR D)
			sets up the database mapping corresponding to the EID of the
			mobile end-device (e.g. EID=<IID1, 1.0.0.1>). The ETR at the new
			site (e.g. ETR D) sends a Map-Register to the mapping system
			registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of
			the mobile end-device (e.g. EID=<IID1, 1.0.0.1>). Now the
			mapping system is updated with the new EID-to-RLOC mapping
			(location) for the mobile end-device (e.g. End-Device 1).
			o The Mapping System, after receiving the new registration for the
			EID of the mobile end-device (EID=<IID1, 1.0.0.1>) sends a Map-
			Notify to the departure site (ETR A) to inform it of the move.
			Then, the ETR at the departure site (ETR A) removes its local
			database mapping information and stops registering the EID for the
			mobile end-device (EID=<IID1, 1.0.0.1>).
			o Any ITR or PiTR participating in the L3 overlay (corresponding to
			IID1) that were sending traffic to the mobile end-device (1.0.0.1)
			would have Subscribed to receive notifications of any changes in
			the RLOC-set for the EID of the mobile end-device (1.0.0.1). The
			Mapping System publishes the updated RLOC-set to the Subscribed
			ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
			Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub].
			o Upon receiving the Map-Notify message, the ITR updates the RLOC-
			set in its local map-cache entry for the EID of the mobile end-
			device (EID=<IID1, 1.0.0.1>). Once the map-cache is updated,
			traffic is tunneled by the ITR to the new location.
	4.2. Implementation Considerations		4.2. Implementation Considerations
	4.2.1. L3 Segmentation		4.2.1. L3 Segmentation
	LISP support of segmentation and multi-tenancy is structured around		LISP support of segmentation and multi-tenancy is structured around
	the propagation and use of Instance-IDs, and handled as part of the		the propagation and use of Instance-IDs, and handled as part of the
	EID in control plane operations. The encoding is described in		EID in control plane operations. The encoding is described in
	[RFC8060] and its use in [RFC8111].		[RFC8060] and its use in [RFC8111].
	Instance-IDs can be used to support L3 overlay segmentation, such as		Instance-IDs can be used to support L3 overlay segmentation, such as
	in extended VRFs or multi-VPN overlays.		in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]).
	4.2.2. L3 Database-Mappings		4.2.2. L3 Database-Mappings
	When an end-host is attached or detected in an ETR that provides		When an end-host is attached or detected in an ETR that provides
	L3-overlay services and mobility, a database Mapping is registered to		L3-overlay services and mobility, a database Mapping is registered to
	the mapping system with the following structure:		the mapping system with the following structure:
	o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR		o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR
	locator set (IP RLOC)		locator set (IP RLOC)
	skipping to change at page 9, line 37 ¶		skipping to change at page 11, line 35 ¶
	have moved away.		have moved away.
	o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR		o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR
	message SHOULD be generated.		message SHOULD be generated.
	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], [RFC8378] and [I-D.coras-lisp-re].		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 ([RFC6830]) describes how to handle Time-to-
	Live values of the inner and outer headers during encapsulation and		Live values of the inner and outer headers during encapsulation and
	decapsulation of packets when using the L3 overlay.		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
	skipping to change at page 11, line 14 ¶		skipping to change at page 13, line 14 ¶
	5.1.2. L2 Mobility Flow		5.1.2. L2 Mobility Flow
	The support to L2 mobility covers the requirements to allow an end-		The support to L2 mobility covers the requirements to allow an end-
	host to move from a given site to another and maintain correspondence		host to move from a given site to another and maintain correspondence
	with the rest of end-hosts that are connected to the same L2 domain		with the rest of end-hosts that are connected to the same L2 domain
	(e.g. extended VLAN). This support MUST ensure convergence of L2		(e.g. extended VLAN). This support MUST ensure convergence of L2
	forwarding (MAC based) from the old location to the new one, when the		forwarding (MAC based) from the old location to the new one, when the
	host completes its move.		host completes its move.
			The update of the ITR map-caches when EIDs move MAY be achieved using
			Data Driven SMRs or the Publish/Subscribe mechanisms defined in
			[I-D.ietf-lisp-pubsub]. The following two sections are sequence
			descriptions of the packet flow when End-Device 2 in the reference
			figure roams to site C, which is extending its own subnet network.
			5.1.2.1. L2 Mobility Flow using Data Driven SMRs
	The following is a sequence description of the packet flow when End-		The following is a sequence description of the packet flow when End-
	Device 2 in the figure moves to Site C, which is extending its own		Device 2 in the reference figure roams to site C. This sequence uses
	subnet network.		Data Driven SMRs to trigger the updates of the ITR map-caches.
	o When End-Device 2 is attached or detected in site C, ETR C sets up		o When End-Device 2 is attached or detected in site C, ETR C sets up
	the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.		the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
	ETR C sends a Map-Register to the mapping system registering		ETR C sends a Map-Register to the mapping system registering
	RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>.		RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>.
	o The Mapping System, after receiving the new registration for		o The Mapping System, after receiving the new registration for
	EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the new		EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the new
	locator set (IP_B). ETR B removes then its local database mapping		locator set (IP_B). ETR B removes then its local database mapping
	and stops registering <IID2, 0:0:3:0:0:2>.		and stops registering <IID2, 0:0:3:0:0:2>.
	skipping to change at page 11, line 45 ¶		skipping to change at page 14, line 5 ¶
	generate a Solicit-Map-Request (SMR) message that is sent to the		generate a Solicit-Map-Request (SMR) message that is sent to the
	ITR for (IID2,0:0:3:0:0:2).		ITR for (IID2,0:0:3:0:0:2).
	o Upon receiving the SMR the ITR sends a new Map-Request for the		o Upon receiving the SMR the ITR sends a new Map-Request for the
	EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a Map-Reply		EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a Map-Reply
	that includes the new EID-to-RLOC mapping for <IID2,0:0:3:0:0:2>		that includes the new EID-to-RLOC mapping for <IID2,0:0:3:0:0:2>
	with RLOC=IP_B. This entry is cached in the L2 table of the ITR,		with RLOC=IP_B. This entry is cached in the L2 table of the ITR,
	replacing the previous one, and traffic is then forwarded to the		replacing the previous one, and traffic is then forwarded to the
	new location.		new location.
			5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms
			When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used,
			the flow of signaling to achieve EID mobility is modified. In this
			case, when an End-Device connected via an ITR establishes
			communication with a mobile EID-prefix, the ITR will issue a Map-
			Request for the mobile End-device. Following the Mapping Request
			Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map-
			request will be issued with the N-bit set on the EID-Record so that
			the ITR is notified of any RLOC-set changes for the mobile EID-
			prefix.
			The following is a sequence description of the packet flow when End-
			Device 2 in the reference figure roams to site C. This sequence
			leverages Publish/Subscribe mechanisms to update the ITR map-caches.
			o When End-Device 2 is attached or detected in site C, ETR C sets up
			the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
			ETR C sends a Map-Register to the mapping system registering
			RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>.
			o The Mapping System, after receiving the new registration for
			EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to the departure site
			(ETR B) with the new locator set (IP_B). ETR B removes then its
			local database mapping and stops registering <IID2, 0:0:3:0:0:2>.
			o Any ITR or PiTR participating in the same L2-overlay
			(corresponding to IID2) that was encapsulating traffic to
			0:0:3:0:0:2 before the migration would have Subscribed to receive
			notifications of any changes in the RLOC-set for 0:0:3:0:0:2. The
			Mapping System publishes the updated RLOC-set to the Subscribed
			ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
			Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub].
			o Upon receiving the Map-Notify message, the ITR updates the RLOC-
			set in its local map-cache entry for EID=<IID2, 0:0:3:0:0:2>.
			Once the map-cache is updated, traffic is tunneled by the ITR to
			the new location.
	5.2. Implementation Considerations		5.2. Implementation Considerations
	5.2.1. L2 Segmentation		5.2.1. L2 Segmentation
	As with L3 overlays, LISP support of L2 segmentation is structured		As with L3 overlays, LISP support of L2 segmentation is structured
	around the propagation and use of Instance-IDs, and handled as part		around the propagation and use of Instance-IDs, and handled as part
	of the EID in control plane operations. The encoding is described in		of the EID in control plane operations. The encoding is described in
	[RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a		[RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a
	Mapping System and MAY be used to identify the overlay type (e.g., L2		Mapping System and MAY be used to identify the overlay type (e.g., L2
	or L3 overlay).		or L3 overlay).
	skipping to change at page 13, line 36 ¶		skipping to change at page 16, line 36 ¶
	| \| ... Locator		| \| ... Locator
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The L2 EID record follows the structure as described in [RFC6830].		The L2 EID record follows the structure as described in [RFC6830].
	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		[RFC6833] and this document follows the specification as described
	there. When available, the registrations MAY be implemented over a		there. When available, the registrations MAY be implemented over a
	reliable transport as described in		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
	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 27 ¶		skipping to change at page 23, line 27 ¶
	6.2. Data-plane Encapsulation Options		6.2. Data-plane Encapsulation Options
	The LISP control-plane offers independence from the data-plane		The LISP control-plane offers independence from the data-plane
	encapsulation. Any encapsulation format that can carry a 24-bit		encapsulation. Any encapsulation format that can carry a 24-bit
	instance-ID can be used to provide the unified overlay.		instance-ID can be used to provide the unified overlay.
	Common encapsulation formats that can be used are [VXLAN-GPE], [LISP]		Common encapsulation formats that can be used are [VXLAN-GPE], [LISP]
	and [VXLAN]:		and [VXLAN]:
	o VXLAN-GPE encap: This encapsulation format is defined in		o VXLAN-GPE encap: This encapsulation format is defined in
	[I-D.ietf-nvo3-vxlan-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).
	o LISP encap: This is the encapsulation format defined in the		o LISP encap: This is the encapsulation format defined in the
	original LISP specification [RFC6830]. The encapsulation allows		original LISP specification [RFC6830]. The encapsulation allows
	encapsulating both L2 and L3 packets. The Instance-ID used in the		encapsulating both L2 and L3 packets. The Instance-ID used in the
	EIDs directly maps to the Instance-ID that the LISP header		EIDs directly maps to the Instance-ID that the LISP header
	skipping to change at page 22, line 17 ¶		skipping to change at page 25, line 17 ¶
	Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,		Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
	May 2017, <https://www.rfc-editor.org/info/rfc8111>.		May 2017, <https://www.rfc-editor.org/info/rfc8111>.
	[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID		[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
	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.coras-lisp-re]		[I-D.ietf-lisp-gpe]
	Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,		Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
	Maino, F., and D. Farinacci, "LISP Replication		Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
	Engineering", draft-coras-lisp-re-08 (work in progress),		gpe-06 (work in progress), September 2018.
	November 2015.
	[I-D.ietf-nvo3-vxlan-gpe]		[I-D.ietf-lisp-pubsub]
	Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol		Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
	Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work		Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
	in progress), April 2018.		Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
			Subscribe Functionality for LISP", draft-ietf-lisp-
			pubsub-02 (work in progress), November 2018.
			[I-D.ietf-lisp-vpn]
			Moreno, V. and D. Farinacci, "LISP Virtual Private
			Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in
			progress), May 2018.
	[I-D.kouvelas-lisp-map-server-reliable-transport]		[I-D.kouvelas-lisp-map-server-reliable-transport]
	Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.		Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.
	Arango, "LISP Map Server Reliable Transport", draft-		Arango, "LISP Map Server Reliable Transport", draft-
	kouvelas-lisp-map-server-reliable-transport-04 (work in		kouvelas-lisp-map-server-reliable-transport-04 (work in
	progress), September 2017.		progress), September 2017.
	Authors' Addresses		Authors' Addresses
	Marc Portoles Comeras		Marc Portoles Comeras
End of changes. 23 change blocks.
	67 lines changed or deleted		189 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/