idnits 2.17.1 draft-ietf-lisp-eid-mobility-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 26 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 record together with an IP based EID. The Priority of the MAC address record is set to 255. The Weight value SHOULD be ignored and the recommendation is to set it to 0. -- The document date (May 21, 2020) is 1407 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 1020, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 1020, but not defined == Missing Reference: 'VXLAN' is mentioned on line 1021, but not defined ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-02 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-02 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-04 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Portoles 3 Internet-Draft V. Ashtaputre 4 Intended status: Experimental V. Moreno 5 Expires: November 22, 2020 F. Maino 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 May 21, 2020 11 LISP L2/L3 EID Mobility Using a Unified Control Plane 12 draft-ietf-lisp-eid-mobility-06 14 Abstract 16 The LISP control plane offers the flexibility to support multiple 17 overlay flavors simultaneously. This document specifies how LISP can 18 be used to provide control-plane support to deploy a unified L2 and 19 L3 overlay solution for End-point Identifier (EID) mobility, as well 20 as analyzing possible deployment options and models. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 22, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 64 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 65 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 6 66 4.1. Reference Architecture and packet flows . . . . . . . . . 6 67 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 68 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 7 69 4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7 70 4.1.2.2. L3 Mobility Flow using Publish/Subscribe 71 Mechanisms . . . . . . . . . . . . . . . . . . . 8 72 4.2. Implementation Considerations . . . . . . . . . . . . . . 9 73 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9 74 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9 75 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10 76 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 11 77 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11 78 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11 79 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11 80 5.1. Reference Architecture and packet flows . . . . . . . . . 11 81 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12 82 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13 83 5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13 84 5.1.2.2. L2 Mobility Flow using Publish/Subscribe 85 mechanisms . . . . . . . . . . . . . . . . . . . 14 86 5.2. Implementation Considerations . . . . . . . . . . . . . . 14 87 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 14 88 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15 89 5.2.3. Interface to the LISP Mapping System . . . . . . . . 16 90 5.2.4. SMR support to track L2 hosts that moved away . . . . 16 91 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17 92 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17 93 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18 94 5.3. Support to ARP resolution through Mapping System . . . . 18 95 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 18 96 5.3.2. ARP registrations: MAC as a locator record . . . . . 19 97 5.3.3. Implementation Considerations . . . . . . . . . . . . 21 98 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 99 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 100 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 105 9.2. Informative References . . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 This document describes the architecture and design options required 111 to offer a unified L2 and L3 overlay solution for End-point 112 Identifier (EID) mobility using the LISP control-plane. 114 The architecture takes advantage of the flexibility that LISP 115 provides to simultaneously support different overlay types. While 116 the LISP specification defines both the data-plane and the control- 117 plane, this document focuses on the use of the control-plane to 118 provide L2 and L3 overlay services with EID mobility. The control 119 plane may be combined with a data-plane of choice e.g., [LISP], 120 [VXLAN-GPE], or [VXLAN]. 122 The recommendation on whether a flow is sent over the L2 or the L3 123 overlay is based on whether the traffic is bridged (intra-subnet or 124 non-IP) or routed (inter-subnet), respectively. This allows treating 125 both overlays as separate segments, and enables L2-only and L3-only 126 deployments (and combinations of them) without modifying the 127 architecture. 129 The unified solution for L2 and L3 overlays offers the possibility to 130 extend subnets and routing domains (as required in state-of-art 131 Datacenter and Enterprise architectures) with mobility support and 132 traffic optimization. 134 An important use-case of the unified architecture is that, while most 135 data centers are complete layer-3 routing domains, legacy 136 applications either have not converted to IP or still use auto- 137 discovery at layer-2 and assume all nodes in an application cluster 138 belong to the same subnet. For these applications, the L2-overlay 139 limits the functionality to where the legacy app lives versus having 140 to extend layer-2 into the underlay network. 142 Broadcast, Unknown and Multicast traffic on the overlay are supported 143 by either replicated unicast, or underlay (RLOC) multicast as 144 specified in [RFC6831] and [RFC8378]. 146 2. Definition of Terms 148 LISP related terms are defined as part of the LISP specification 149 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 150 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 151 (MS) and Map-Resolver (MR). 153 3. Reference System 155 The following figure illustrates the reference system used to support 156 the packet flow description throughout this document. The system 157 presents 4 sites. Site A and Site D provide access to different 158 subnets (non-extended), while Site B and Site C extend a common 159 subnet. The xTR in each one of the sites registers EIDs from the 160 sites with the LISP Mapping System and provides support to 161 encapsulate overlay (EID) traffic through the underlay (RLOC space). 163 ,-------------. 164 (Mapping System ) 165 -+------------+ 166 +--+--+ +-+---+ 167 |MS/MR| |MS/MR| 168 +-+---+ +-----+ 169 .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-. 170 .-.' '.-. 171 ( L3 Underlay ) 172 ( (RLOC Space) ) 173 '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.' 174 / | | \ 175 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 176 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 177 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 178 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 179 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 180 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 181 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 182 / '--' | '--' | '--' \ '--' 183 '--------' '--------' '--------' '--------' 184 : End : : End : : End : : End : 185 :Device 1: :Device 2: :Device 3: :Device 4: 186 '--------' '--------' '--------' '--------' 187 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 188 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 190 Figure 1: Reference System Architecture with unified L2 and L3 191 overlays 193 The recommended selection between the use of L2 and L3 overlays is to 194 map them to bridged (intra-subnet or non-IP) and routed (inter- 195 subnet) traffic. The rest of the document follows this 196 recommendation to describe the packet flows. 198 However, note that in a different selection approach, intra-subnet 199 traffic MAY also be sent over the L3 overlay. Section 6.1 specifies 200 the changes needed to send all IP traffic using the L3 overlay and 201 restricting the use of the L2 overlay to non-IP traffic. 203 When required, the control plane makes use of two basic types of EID- 204 to-RLOC mappings associated to end-hosts and in order to support the 205 unified architecture: 207 o EID = to RLOC=. This is used to support the L2 208 overlay. 210 o EID = to RLOC=. This is the traditional mapping as 211 defined in the original LISP specification and supports the L3 212 overlay. 214 4. L3 Overlays and Mobility Support 216 4.1. Reference Architecture and packet flows 218 In order to support the packet flow descriptions in this section we 219 use Figure 1 as reference. This section uses Sites A and D to 220 describe the flows. 222 / | | \ 223 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 224 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 225 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 226 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 227 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 228 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 229 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 230 / '--' | '--' | '--' \ '--' 231 '--------' '--------' '--------' '--------' 232 : End : : End : : End : : End : 233 :Device 1: :Device 2: :Device 3: :Device 4: 234 '--------' '--------' '--------' '--------' 235 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 236 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 238 Figure 2: Reference Mobility Architecture 240 4.1.1. Routed Traffic Flow: L3 Overlay use 242 Inter-subnet traffic is encapsulated using the L3 overlay. The 243 process to encapsulate this traffic is the same as described in the 244 original specification [RFC6830]. We describe the packet flow here 245 for completeness 247 The following is a sequence example of the unicast packet flow and 248 the control plane operations when in the topology shown in Figure 1 249 End-Device 1, in LISP site A, wants to communicate with End-Device 4 250 in LISP site D. Note that both end systems reside in different 251 subnets. We'll assume that End-Device 1 knows the EID IP address of 252 End-Device 4 (e.g. it is learned using a DNS service). 254 o End-Device 1 sends an IP packet frame with destination 2.0.0.4 and 255 source 1.0.0.1. As the destination address lies on a different 256 subnet End-Device 1 sends the packet following its routing table 257 to ITR A (e.g., it is its default gateway). 259 o ITR A does a L3 lookup in its local map-cache for the destination 260 IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a 261 Map-request to the mapping database system looking up for 262 EID=. 264 o The mapping systems forwards the Map-Request to ETR D, that has 265 registered the EID-to-RLOC mapping of EID=. 267 o ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC 268 mapping: EID= -> RLOC=IP_D, where IP_D is the 269 locator of ETR D. 271 o ITR A populates the local map-cache with the EID to RLOC mapping, 272 and encapsulates all subsequent packets with a destination IP 273 2.0.0.4 using destination RLOC=IP_D. 275 4.1.2. L3 Mobility Flow 277 The support to L3 mobility covers the requirements to allow an end- 278 host to move from a given site to another and maintain correspondence 279 with the rest of end-hosts that are connected to the same L3 routing 280 domain. This support MUST ensure convergence of L3 forwarding (IPv4/ 281 IPv6 based) from the old location to the new one when the host 282 completes its move. 284 The update of the ITR map-caches when EIDs move MAY be achieved using 285 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 286 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 287 descriptions of the packet flow when End-Device 1 in the reference 288 figure roams to site D. 290 4.1.2.1. L3 Mobility Flow using Data Driven SMRs 292 The following is a sequence description of the packet flow when End- 293 Device 1 in the reference figure roams to site D. This sequence uses 294 Data Driven SMRs to trigger the updates of the ITR map-caches. 296 o When End-Device 1 is attached or detected in site D, ETR D sets up 297 the database mapping corresponding to EID=. ETR D 298 sends a Map-Register to the mapping system registering RLOC=IP_D 299 as locator for EID=. Now the mapping system is 300 updated with the new EID-to-RLOC mapping (location) for End-Device 301 1. 303 o The Mapping System, after receiving the new registration for 304 EID= sends a Map-Notify to the departure ETR(s) 305 (ETR A) to inform it of the move. Then, ETR A removes its local 306 database mapping information and stops registering EID=. 309 o Any ITR or PiTR participating in the L3 overlay (corresponding to 310 IID1) that were sending traffic to 1.0.0.1 before the migration 311 keep sending traffic to ETR A. 313 o Once ETR A is notified by the Mapping system, when it receives 314 traffic from an ITR with destination 1.0.0.1, it generates a 315 Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=. 318 o Upon receiving the SMR the ITR invalidates its local map- cache 319 entry for EID= and sends a new Map-Request for that 320 EID. The Map-Reply includes the new EID-to-RLOC mapping for End- 321 Device 1 with RLOC=IP_D. 323 o Similarly, once the local database mapping is removed from ITR A, 324 non-encapsulated packets arriving at ITR A from a local End-Device 325 and destined to End-Device 1 result in a cache miss, which 326 triggers sending a Map-Request for EID= to populate 327 the map-cache of ITR A. 329 4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms 331 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 332 the flow of signaling to achieve EID mobility is modified. In this 333 case, when an local end-device connected via an ITR establishes 334 communication with a remote mobile end-device (connected to a remote 335 ETR), the ITR will issue a Map-Request for the mobile end-device. 336 Following the Mapping Request Subscribe Procedures defined in 337 [I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit 338 set on the EID-Record so that the ITR is notified of any RLOC-set 339 changes for the mobile EID-prefix. 341 The following is a sequence description of the packet flow when End- 342 Device 1 in the reference figure roams to site D. This sequence 343 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 345 o When an end-Device connected via an ITR establishes communication 346 with a mobile end-device (e.g. end-device 1), the ITR will issue a 347 Map-Request for the mobile end-device. Following the Mapping 348 Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], 349 the Map-request will be issued with the N-bit set on the EID- 350 Record so that the ITR is notified of any RLOC-set changes for the 351 mobile EID-prefix. 353 o When the mobile end-device (End-Device 1) is attached or detected 354 in a new site (e.g. site D), The ETR at the new site (e.g. ETR D) 355 sets up the database mapping corresponding to the EID of the 356 mobile end-device (e.g. EID=). The ETR at the new 357 site (e.g. ETR D) sends a Map-Register to the mapping system 358 registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of 359 the mobile end-device (e.g. EID=). Now the 360 mapping system is updated with the new EID-to-RLOC mapping 361 (location) for the mobile end-device (e.g. End-Device 1). 363 o The Mapping System, after receiving the new registration for the 364 EID of the mobile end-device (EID=) sends a Map- 365 Notify to the departure site (ETR A) to inform it of the move. 366 Then, the ETR at the departure site (ETR A) removes its local 367 database mapping information and stops registering the EID for the 368 mobile end-device (EID=). 370 o Any ITR or PiTR participating in the L3 overlay (corresponding to 371 IID1) that were sending traffic to the mobile end-device (1.0.0.1) 372 would have Subscribed to receive notifications of any changes in 373 the RLOC-set for the EID of the mobile end-device (1.0.0.1). The 374 Mapping System publishes the updated RLOC-set to the Subscribed 375 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 376 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 378 o Upon receiving the Map-Notify message, the ITR updates the RLOC- 379 set in its local map-cache entry for the EID of the mobile end- 380 device (EID=). Once the map-cache is updated, 381 traffic is tunneled by the ITR to the new location. 383 4.2. Implementation Considerations 385 4.2.1. L3 Segmentation 387 LISP support of segmentation and multi-tenancy is structured around 388 the propagation and use of Instance-IDs, and handled as part of the 389 EID in control plane operations. The encoding is described in 390 [RFC8060] and its use in [RFC8111]. 392 Instance-IDs can be used to support L3 overlay segmentation, such as 393 in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]). 395 4.2.2. L3 Database-Mappings 397 When an end-host is attached or detected in an ETR that provides 398 L3-overlay services and mobility, a database Mapping is registered to 399 the mapping system with the following structure: 401 o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR 402 locator set (IP RLOC) 404 The registration of these EIDs MUST follow the LCAF format as defined 405 in [RFC8060] and the specific EID record to be used is illustrated in 406 the following figure: 408 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | Record TTL | 410 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 E | Locator Count | EID mask-len | ACT |A| Reserved | 412 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 D | Rsvd | Map-Version Number | AFI = 16387 | 414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 416 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 c | 4 + n | Instance-ID... | 418 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 r | ...Instance-ID | EID-AFI = 1 or 2 | 420 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | EID-Prefix (IPv4 or IPv6) | 422 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | /| Priority | Weight | M Priority | M Weight | 424 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | o | Unused Flags |L|p|R| Loc-AFI | 426 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | \| Locator | 428 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 The L3 EID record follows the structure as described in [RFC6830]. 432 4.2.3. LISP Mapping System support 434 The interface between the xTRs and the Mapping System is described in 435 [RFC6833] and this document follows the specification as described 436 there. When available, the registrations MAY be implemented over a 437 reliable transport as described in 438 [I-D.kouvelas-lisp-map-server-reliable-transport]. 440 In order to support system convergence after mobility, when the Map- 441 Server receives a new registration for a specific EID, it MUST send a 442 Map-Notify to the entire RLOC set in the site that last registered 443 this same EID. This Map-Notify is used to track moved-away state of 444 L3 EIDs as described in Section 4.2.4. 446 4.2.4. Using SMRs to Track Moved-Away Hosts 448 One of the key elements to support end-host mobility using the LISP 449 architecture is the Solicit-Map-Request (SMR). This is a special 450 message by means of which an ETR can request an ITR to send a new 451 Map-Request for a particular EID record. In essence the SMR message 452 is used as a signal to indicate a change in mapping information and 453 it is described with detail in [RFC6830]. 455 In order to support mobility, an ETR SHALL maintain a list of EID 456 records for which it has to generate a SMR message whenever it 457 receives traffic with that EID as destination. 459 The particular strategy to maintain an Away Table is implementation 460 specific and it will be typically based on the strategy to detect the 461 presence of hosts and the use of Map-Notify messages received from 462 the Map-Server. In essence the table SHOULD provide support to the 463 following: 465 o Keep track of end-hosts that were once connected to an ETR and 466 have moved away. 468 o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR 469 message SHOULD be generated. 471 4.2.5. L3 multicast support 473 L3 Multicast traffic on the overlay MAY be supported by either 474 replicated unicast, or underlay (RLOC) multicast. Specific solutions 475 to support L3 multicast over LISP controlled overlays are specified 476 in in [RFC6831], and [RFC8378]. 478 4.2.6. Time-to-Live Handling in Data-Plane 480 The LISP specification ([RFC6830]) describes how to handle Time-to- 481 Live values of the inner and outer headers during encapsulation and 482 decapsulation of packets when using the L3 overlay. 484 5. L2 Overlays and Mobility Support 486 5.1. Reference Architecture and packet flows 488 In order to support L2 packet flow descriptions in this section we 489 use Figure 1 as reference. This section uses Sites B and C to 490 describe the flows. 492 / | | \ 493 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 494 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 495 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 496 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 497 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 498 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 499 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 500 / '--' | '--' | '--' \ '--' 501 '--------' '--------' '--------' '--------' 502 : End : : End : : End : : End : 503 :Device 1: :Device 2: :Device 3: :Device 4: 504 '--------' '--------' '--------' '--------' 505 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 506 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 508 Figure 3: Reference Mobility Architecture 510 5.1.1. Bridged Traffic Flow: L2 Overlay use 512 Bridged traffic is encapsulated using the L2 overlay. This section 513 provides an example of the unicast packet flow and the control plane 514 operations when in the topology shown in Figure 1, the End-Device 2 515 in site B communicates with the End-Device 3 in site C. In this case 516 we assume that End Device 2, knows the MAC address of End-Device 3 517 (e.g., learned through ARP). 519 o End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination 520 0:0:3:0:0:3 and source 0:0:3:0:0:2. 522 o ITR B does a L2 lookup in its local map-cache for the destination 523 MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the 524 ITR sends a Map-Request to the mapping database system looking up 525 for EID=. 527 o The mapping systems forwards the Map-Request to ETR C, that has 528 registered the EID-to-RLOC mapping for EID=. 529 Alternatively, depending on the mapping system configuration, a 530 Map-Server which is part of the mapping database system MAY send a 531 Map-Reply directly to ITR B. 533 o ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC 534 mapping: EID= -> RLOC=IP_C, where IP_C is the 535 locator of ETR C. 537 o ITR B populates the local map-cache with the EID to RLOC mapping, 538 and encapsulates all subsequent packets with a destination MAC 539 0:0:3:0:0:3 using destination RLOC=IP_C. 541 5.1.2. L2 Mobility Flow 543 The support to L2 mobility covers the requirements to allow an end- 544 host to move from a given site to another and maintain correspondence 545 with the rest of end-hosts that are connected to the same L2 domain 546 (e.g. extended VLAN). This support MUST ensure convergence of L2 547 forwarding (MAC based) from the old location to the new one, when the 548 host completes its move. 550 The update of the ITR map-caches when EIDs move MAY be achieved using 551 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 552 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 553 descriptions of the packet flow when End-Device 2 in the reference 554 figure roams to site C, which is extending its own subnet network. 556 5.1.2.1. L2 Mobility Flow using Data Driven SMRs 558 The following is a sequence description of the packet flow when End- 559 Device 2 in the reference figure roams to site C. This sequence uses 560 Data Driven SMRs to trigger the updates of the ITR map-caches. 562 o When End-Device 2 is attached or detected in site C, ETR C sets up 563 the database mapping corresponding to EID=. 564 ETR C sends a Map-Register to the mapping system registering 565 RLOC=IP_B as locator for EID=. 567 o The Mapping System, after receiving the new registration for 568 EID= sends a Map-Notify to ETR B with the new 569 locator set (IP_B). ETR B removes then its local database mapping 570 and stops registering . 572 o Any PiTR or ITR participating in the same L2-overlay 573 (corresponding to IID2) that was encapsulating traffic to 574 0:0:3:0:0:2 before the migration continues encapsulating this 575 traffic to ETR B. 577 o Once ETR B is notified by the Mapping system, when it receives 578 traffic from an ITR which is destined to 0:0:3:0:0:2, it will 579 generate a Solicit-Map-Request (SMR) message that is sent to the 580 ITR for (IID2,0:0:3:0:0:2). 582 o Upon receiving the SMR the ITR sends a new Map-Request for the 583 EID=. As a response ETR B sends a Map-Reply 584 that includes the new EID-to-RLOC mapping for 585 with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 586 replacing the previous one, and traffic is then forwarded to the 587 new location. 589 5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms 591 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 592 the flow of signaling to achieve EID mobility is modified. In this 593 case, when an End-Device connected via an ITR establishes 594 communication with a mobile EID-prefix, the ITR will issue a Map- 595 Request for the mobile End-device. Following the Mapping Request 596 Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map- 597 request will be issued with the N-bit set on the EID-Record so that 598 the ITR is notified of any RLOC-set changes for the mobile EID- 599 prefix. 601 The following is a sequence description of the packet flow when End- 602 Device 2 in the reference figure roams to site C. This sequence 603 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 605 o When End-Device 2 is attached or detected in site C, ETR C sets up 606 the database mapping corresponding to EID=. 607 ETR C sends a Map-Register to the mapping system registering 608 RLOC=IP_B as locator for EID=. 610 o The Mapping System, after receiving the new registration for 611 EID= sends a Map-Notify to the departure site 612 (ETR B) with the new locator set (IP_B). ETR B removes then its 613 local database mapping and stops registering . 615 o Any ITR or PiTR participating in the same L2-overlay 616 (corresponding to IID2) that was encapsulating traffic to 617 0:0:3:0:0:2 before the migration would have Subscribed to receive 618 notifications of any changes in the RLOC-set for 0:0:3:0:0:2. The 619 Mapping System publishes the updated RLOC-set to the Subscribed 620 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 621 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 623 o Upon receiving the Map-Notify message, the ITR updates the RLOC- 624 set in its local map-cache entry for EID=. 625 Once the map-cache is updated, traffic is tunneled by the ITR to 626 the new location. 628 5.2. Implementation Considerations 630 5.2.1. L2 Segmentation 632 As with L3 overlays, LISP support of L2 segmentation is structured 633 around the propagation and use of Instance-IDs, and handled as part 634 of the EID in control plane operations. The encoding is described in 635 [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a 636 Mapping System and MAY be used to identify the overlay type (e.g., L2 637 or L3 overlay). 639 An Instance-ID can be used for L2 overlay segmentation. An important 640 aspect of L2 segmentation is the mapping of VLANs to IIDs. In this 641 case a Bridge Domain (which is the L2 equivalent to a VRF as a 642 forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge 643 domain or different VLAN-IDs on different ports may map to a common 644 Bridge Domain, which in turn maps to an IID in the L2 overlay. When 645 ethernet traffic is double tagged, usually the outer 802.1Q tag will 646 be mapped to a bridge domain on a per port basis, and the inner 647 802.1Q tag will remain part of the payload to be handled by the 648 overlay. The IID should therefore be able to carry ethernet traffic 649 with or without an 802.1Q header. A port may also be configured as a 650 trunk and we may chose to take the encapsulated traffic and map it to 651 a single IID in order to multiplex traffic from multiple VLANs on a 652 single IID. These are all examples of local operations that could be 653 effected on VLANs in order to map them to IIDs, they are provided as 654 examples and are not exhaustive. 656 5.2.2. L2 Database-Mappings 658 When an end-host is attached or detected in an ETR that provides 659 L2-overlay services, a database Mapping is registered to the mapping 660 system with the following structure: 662 o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP 663 RLOC) 665 The registration of these EIDs MUST follow the LCAF format as defined 666 in [RFC8060] and as illustrated in the following figure: 668 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | Record TTL | 670 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 E | Locator Count | EID mask-len | ACT |A| Reserved | 672 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 D | Rsvd | Map-Version Number | AFI = 16387 | 674 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 676 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 c | 4 + n | Instance-ID... | 678 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 r | ...Instance-ID | EID-AFI = 6 | 680 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | Layer-2 MAC Address ... | 682 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | /| ... Layer-2 MAC Address | Priority | Weight | 684 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | o | M Priority | M Weight | Unused Flags |L|p|R| 686 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | | Loc-AFI | Locator.... | 688 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | \| ... Locator 690 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 The L2 EID record follows the structure as described in [RFC6830]. 694 5.2.3. Interface to the LISP Mapping System 696 The interface between the xTRs and the Mapping System is described in 697 [RFC6833] and this document follows the specification as described 698 there. When available, the registrations MAY be implemented over a 699 reliable transport. 701 In order to support system convergence after mobility, when the Map- 702 Server receives a new registration for a specific EID, it MUST send a 703 Map-Notify to the entire RLOC set in the site that last registered 704 this same EID. This Map-Notify is used to track moved-away state of 705 L2 EIDs as described in Section 5.2.4. 707 5.2.4. SMR support to track L2 hosts that moved away 709 In order to support mobility, an ETR SHALL maintain a list of EID 710 records for which it has to generate a SMR message whenever it 711 receives traffic with that EID as destination. 713 The particular strategy to maintain a SMR table is implementation 714 specific. In essence the table SHOULD provide support for the 715 following: 717 o Keep track of end-hosts that were once connected to an ETR and 718 have moved away. 720 o Support for L2 EID records, the 2-tuple (IID, MAC), for which a 721 SMR message SHOULD be generated. 723 5.2.5. L2 Broadcast and Multicast traffic 725 Broadcast and Multicast traffic on the L2-overlay is supported by 726 either replicated unicast, or underlay (RLOC) multicast. 728 xTRs that offer L2 overlay services and are part of the same 729 Instance-ID join a common Multicast Group. When required, this group 730 allows ITRs to send traffic that needs to be replicated (flooded) to 731 all ETRs participating in the L2-overlay (e.g., broadcast traffic 732 within a subnet). When the core network (RLOC space) supports native 733 multicast ETRs participating in the L2-overlay join a (*,G) group 734 associated to the Instance-ID. 736 When multicast is not available in the core network, each xTR that is 737 part of the same instance-ID SHOULD register a (S,G) entry to the 738 mapping system using the procedures described in [RFC8378], where S 739 is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows 740 and ITR to know which ETRs are part of the L2 overlay and it can 741 head-end replicate traffic to. 743 Following the same case, when multicast is not available in the core 744 network, the procedures in [RFC8378] can be used to ensure proper 745 distribution of link-local multicast traffic across xTRs 746 participating in the L2 overlay. In such case, the xTRs SHOULD join 747 a (S,G) entry with S being 0000-0000-0000/0 and where G is 748 0100-0000-0000/8. 750 5.2.6. L2 Unknown Unicast Support 752 An ITR attempts to resolve MAC destination misses through the Mapping 753 System. When the destination host remains undiscovered the 754 destination is considered an Unknown Unicast. 756 A Map-Server SHOULD respond to a Map-Request for an undiscovered host 757 with a Negative Map-Reply with action "Native Forward". 758 Alternatively the action "Drop" may be used in order to suppress 759 Unknown Unicast forwarding. 761 An ITR that receives a Negative Map-Reply with Action "Native 762 Forward" will handle traffic for the undiscovered host as L2 763 Broadcast traffic and will be unicast replicated or flooded using 764 underlay multicast to the rest of ETRs in the Layer-2 overlay. 766 Upon discovery of a previously unknown unicast MAC EID, a data 767 triggered SMR for the discovered EID should be sent by the discovery 768 ETR back to the ITRs that are flooding the unknown unicast traffic. 769 This would allow ITRs to refresh their caches and stop flooding 770 unknown unicast traffic as necessary. 772 5.2.7. Time-to-Live Handling in Data-Plane 774 When using a L2 overlay and the encapsulated traffic is IP traffic, 775 the Time-to-Live value of the inner IP header MUST remain unmodified 776 during encapsulation and decapsulation. Network hops traversed as 777 part of the L2 overlay SHOULD be hidden to tools like traceroute and 778 applications that require direct L2 connectivity. 780 5.3. Support to ARP resolution through Mapping System 782 5.3.1. Map-Server support to ARP resolution: Packet Flow 784 A large majority of applications are IP based and, as a consequence, 785 end systems are typically provisioned with IP addresses as well as 786 MAC addresses. 788 In this case, to limit the flooding of ARP traffic and reduce the use 789 of multicast in the RLOC network, the LISP mapping system MAY be used 790 to support ARP resolution at the ITR. 792 In order to provide this support, ETRs handle and register an 793 additional EID-to-RLOC mapping as follows, 795 o EID-record contents = , RLOC-record contents . 797 There is a dedicated IID used for the registration of the ARP/ND 798 related mappings. Thus, a system with L2 and L3 overlays as well as 799 ARP/ND mappings would have three IIDs at play. In the spirit of 800 providing clarity, we will refer to those IIDs as L2-IID, L3-IID and 801 ARP-IID respectively. By using these definitions, we do not intend 802 to coin new terminology, nor is there anything special about those 803 IIDs that would make them differ from the generic definition of an 804 IID. The types of mappings expected in such a system are summarized 805 below: 807 o EID = to RLOC = (L3-overlay) 809 o EID = to RLOC = (L2-overlay) 811 o EID = to RLOC = (ARP/ND mapping) 812 The following packet flow sequence describes the use of the LISP 813 Mapping System to support ARP resolution for hosts residing in a 814 subnet that is extended to multiple sites. Using Figure 1, End- 815 Device 2 tries to find the MAC address of End-Device 3. Note that 816 both have IP addresses within the same subnet: 818 o End-Device 2 sends a broadcast ARP message to discover the MAC 819 address of End-Device 3. The ARP request targets IP 3.0.0.3. 821 o ITR B receives the ARP message, but rather than flooding it on the 822 overlay network sends a Map-Request to the mapping database system 823 for EID = . 825 o When receiving the Map-Request, the Map-Server sends a Proxy-Map- 826 Reply back to ITR B with the mapping EID = -> MAC 827 0:0:3:0:0:3. 829 o Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 830 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 832 o End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 833 now send a L2 traffic to End-Device 3. When this traffic reaches 834 ITR B is sent over the L2-overlay as described above in 835 Section 5.1.1. 837 This example shows how LISP, by replacing dynamic data plane learning 838 (such as Flood-and-Learn) can reduce the use of multicast in the 839 underlay network. 841 Note that ARP resolution using the Mapping System is a stateful 842 operation on the ITR. The source IP,MAC tuple coming from the ARP 843 request have to be stored to generate the ARP-reply when the Map- 844 Reply is received. 846 Note that the ITR SHOULD cache the ARP entry. In that case future 847 ARP-requests can be handled without sending additional Map-Requests. 849 5.3.2. ARP registrations: MAC as a locator record 851 When an end-host is attached or detected in an ETR that provides 852 L2-overlay services and also supports ARP resolution using the LISP 853 control-plane, an additional mapping entry is registered to the 854 mapping system: 856 o The EID 2-tuple (IID, IP) and its binding to a corresponding host 857 MAC address. 859 In this case both the xTRs and the Mapping System MUST support an 860 EID-to-RLOC mapping where the MAC address is set as a locator record. 862 In order to guarantee compatibility with current implementations of 863 xTRs, the MAC locator record SHALL be encoded following the AFI-List 864 LCAF Type defined in [RFC8060]. This option would also allow adding 865 additional attributes to the locator record, while maintaining 866 compatibility with legacy devices. 868 This mapping is registered with the Mapping System using the 869 following EID record structure, 871 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | | Record TTL | 873 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 E | Locator Count | EID mask-len | ACT |A| Reserved | 875 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 D | Rsvd | Map-Version Number | AFI = 16387 | 877 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 879 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 c | 4 + n | Instance-ID... | 881 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 r | ...Instance-ID | EID-AFI = 1 or 2 | 883 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | EID-Prefix (IPv4 or IPv6) | 885 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | /| Priority | Weight | M Priority | M Weight | 887 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | M | Unused Flags |L|p|R| AFI = 16387 | 889 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 891 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | | 2 + 6 | AFI = 6 | 893 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | | Layer-2 MAC Address ... | 895 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | \| ... Layer-2 MAC Address | 897 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 899 An EID record with a locator record that carries a MAC address 900 follows the same structure as described in [RFC6830]. However, some 901 fields of the EID record and the locator record require special 902 consideration: 904 Locator Count: This value SHOULD be set to 1. 906 Instance-ID: This is the IID used to provide segmentation of the 907 L2-overlays, L3 overlays and ARP tables. 909 Priority and Weight: IP to MAC bindings are one to one bindings. An 910 ETR SHOULD not register more than one MAC address in the locator 911 record together with an IP based EID. The Priority of the MAC 912 address record is set to 255. The Weight value SHOULD be ignored 913 and the recommendation is to set it to 0. 915 L bit: This bit of the locator record SHOULD only be set to 1 when 916 an ETR is registering its own IP to MAC binding. 918 p bit: This bit of the locator record SHOULD be set to 0. 920 R bit: This bit of the locator record SHOULD be set to 0. 922 Note that an IP EID record that carries a MAC address in the locator 923 record, SHALL be registered with the Proxy Map-Reply bit set. 925 5.3.3. Implementation Considerations 927 While ARP support through the LISP Mapping System fits the LISP 928 Control-Plane there are a series of considerations to take into 929 account when providing this feature: 931 o As indicated, when and end-host is attached the ETR maintains and 932 registers a mapping with the binding EID = -> RLOC = 933 . 935 o ARP support through the LISP Mapping System is OPTIONAL and the 936 xTRs should allow the possibility to enable or disable the 937 feature. 939 o When the ARP entry has not been registered, a Map Server SHOULD 940 send a Negative Map-Reply with action "No Action" as a response to 941 an ARP based Map Request. 943 o In case the ITR receives a Negative Map-Reply for an ARP request 944 it should fallback to flooding the ARP packet as any other L2 945 Broadcast packet (as described in Section 5.2.5). 947 o When receiving a positive Map-Reply for an ARP based Map-Request, 948 the ETR MUST recreate the actual ARP Reply, impersonating the real 949 host. As a consequence, ARP support is a stateful operation where 950 the ITR needs to store enough information about the host that 951 generates an ARP request in order to recreate the ARP Reply. 953 o ARP replies learned from the Mapping System SHOULD be cached and 954 the information used to reply to subsequent ARP requests to the 955 same hosts. 957 6. Optional Deployment Models 959 The support of an integrated L2 and L3 overlay solution takes 960 multiple architectural design options, that depend on the specific 961 requirements of the deployment environment. While some of the 962 previous describe specific packet flows and solutions based on the 963 recommended solution, this section documents OPTIONAL design 964 considerations that differ from the recommended one but that MAY be 965 required on alternative deployment environments. 967 6.1. IP Forwarding of Intra-subnet Traffic 969 As pointed out at the beginning the recommended selection of the L2 970 and L3 overlays is not the only one possible. In fact, providing L2 971 extension to some cloud platforms is not always possible and subnets 972 need to be extended using the L3 overlay. 974 In order to send all IP traffic (intra- and inter-subnet) through the 975 L3 overlay the solution MUST change the ARP resolution process 976 described in Section 5.3.1 to the following one (we follow again 977 Figure 1 to drive the example. End-Device 2 queries about End-Device 978 3): 980 o End-Device 1 sends a broadcast ARP message to discover the MAC 981 address of 3.0.0.3. 983 o ITR B receives the ARP message and sends a Map-Request to the 984 Mapping System for EID = . 986 o In this case, the Map-Request is routed by the Mapping system 987 infrastructure to ETR C, that will send a Map-Reply back to ITR B 988 containing the mapping EID = -> RLOC=IP_C. 990 o ITR B populates its local cache with the received entry on the L3 991 forwarding table. Then, using the cache information it sends a 992 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 993 Device 1. 995 o End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 996 traffic with destination address 3.0.0.3 and destination MAC, 997 MAC_xTR_B. 999 o As the destination MAC address is the one from xTR B, when xTR B 1000 receives this traffic it is forwarded using the L3-overlay. 1002 o Note that when implementing this solution, when a host that is 1003 local to an ETR moves away, the ETR SHOULD locally send a 1004 Gratuitous ARP with its own MAC address and the IP of the moved 1005 host, to refresh the ARP tables of local hosts and guarantee the 1006 use of the L3 overlay when connecting to the remote host. 1008 It is also important to note that using this strategy to extend 1009 subnets through the L3 overlay but still keeping the L2 overlay for 1010 the rest of traffic MAY lead to flow asymmetries. This MAY be the 1011 case in deployments that filter Gratuitous ARPs, or when moved hosts 1012 continue using actual L2 information collected before a migration. 1014 6.2. Data-plane Encapsulation Options 1016 The LISP control-plane offers independence from the data-plane 1017 encapsulation. Any encapsulation format that can carry a 24-bit 1018 instance-ID can be used to provide the unified overlay. 1020 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 1021 and [VXLAN]: 1023 o VXLAN-GPE encap: This encapsulation format is defined in 1024 [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 1025 packets and the VNI field directly maps to the Instance-ID used in 1026 the control plane. Note that when using this encapsulation for a 1027 unified solution the P-bit is set and the Next-Protocol field is 1028 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 1029 L3-overlays, and value 0x3 in L2-overlays). 1031 o LISP encap: This is the encapsulation format defined in the 1032 original LISP specification [RFC6830]. The encapsulation allows 1033 encapsulating both L2 and L3 packets. The Instance-ID used in the 1034 EIDs directly maps to the Instance-ID that the LISP header 1035 carries. At the ETR, after decapsulation, the IID MAY be used to 1036 decide between L2 processing or L3 processing. 1038 o VXLAN encap: This is a L2 encapsulation format defined in 1039 [RFC7348]. While being a L2 encapsulation it can be used both for 1040 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 1041 to the VNI field of the VXLAN header. Providing L3 overlays using 1042 VXLAN generally requires using the ETR MAC address as destination 1043 MAC address of the inner Ethernet header. The process to learn or 1044 derive this ETR MAC address is not included as part of this 1045 document. 1047 7. IANA Considerations 1049 This memo includes no request to IANA. 1051 8. Acknowledgements 1053 This draft builds on top of two expired drafts that introduced the 1054 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 1055 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 1056 combined authors of those drafts, that SHOULD be considered main 1057 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 1058 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 1059 Smith. 1061 9. References 1063 9.1. Normative References 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1071 Locator/ID Separation Protocol (LISP)", RFC 6830, 1072 DOI 10.17487/RFC6830, January 2013, 1073 . 1075 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1076 Locator/ID Separation Protocol (LISP) for Multicast 1077 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1078 2013, . 1080 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1081 Protocol (LISP) Map-Server Interface", RFC 6833, 1082 DOI 10.17487/RFC6833, January 2013, 1083 . 1085 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1086 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1087 eXtensible Local Area Network (VXLAN): A Framework for 1088 Overlaying Virtualized Layer 2 Networks over Layer 3 1089 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1090 . 1092 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1093 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1094 February 2017, . 1096 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1097 Smirnov, "Locator/ID Separation Protocol Delegated 1098 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1099 May 2017, . 1101 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1102 Separation Protocol (LISP) Multicast", RFC 8378, 1103 DOI 10.17487/RFC8378, May 2018, 1104 . 1106 9.2. Informative References 1108 [I-D.ietf-lisp-gpe] 1109 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 1110 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 1111 gpe-06 (work in progress), September 2018. 1113 [I-D.ietf-lisp-pubsub] 1114 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 1115 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 1116 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 1117 Subscribe Functionality for LISP", draft-ietf-lisp- 1118 pubsub-02 (work in progress), November 2018. 1120 [I-D.ietf-lisp-vpn] 1121 Moreno, V. and D. Farinacci, "LISP Virtual Private 1122 Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in 1123 progress), May 2018. 1125 [I-D.kouvelas-lisp-map-server-reliable-transport] 1126 Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. 1127 Arango, "LISP Map Server Reliable Transport", draft- 1128 kouvelas-lisp-map-server-reliable-transport-04 (work in 1129 progress), September 2017. 1131 Authors' Addresses 1133 Marc Portoles Comeras 1134 Cisco Systems 1135 170 Tasman Drive 1136 San Jose, CA 95134 1137 USA 1139 Email: mportole@cisco.com 1140 Vrushali Ashtaputre 1141 Cisco Systems 1142 170 Tasman Drive 1143 San Jose, CA 95134 1144 USA 1146 Email: vrushali@cisco.com 1148 Victor Moreno 1149 Cisco Systems 1150 170 Tasman Drive 1151 San Jose, CA 95134 1152 USA 1154 Email: vimoreno@cisco.com 1156 Fabio Maino 1157 Cisco Systems 1158 170 Tasman Drive 1159 San Jose, CA 95134 1160 USA 1162 Email: fmaino@cisco.com 1164 Dino Farinacci 1165 lispers.net 1166 San Jose, CA 1167 USA 1169 Email: farinacci@gmail.com