idnits 2.17.1 draft-ietf-lisp-eid-mobility-08.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 (25 July 2021) is 1004 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 1018, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 1018, but not defined == Missing Reference: 'VXLAN' is mentioned on line 1019, 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 (-15) exists of draft-ietf-lisp-pubsub-09 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-06 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-06 Summary: 3 errors (**), 0 flaws (~~), 9 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: 26 January 2022 F. Maino 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 25 July 2021 11 LISP L2/L3 EID Mobility Using a Unified Control Plane 12 draft-ietf-lisp-eid-mobility-08 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 26 January 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 63 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 64 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5 65 4.1. Reference Architecture and packet flows . . . . . . . . . 5 66 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 67 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 68 4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7 69 4.1.2.2. L3 Mobility Flow using Publish/Subscribe 70 Mechanisms . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Implementation Considerations . . . . . . . . . . . . . . 9 72 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9 73 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9 74 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10 75 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 10 76 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11 77 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11 78 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11 79 5.1. Reference Architecture and packet flows . . . . . . . . . 11 80 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12 81 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13 82 5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13 83 5.1.2.2. L2 Mobility Flow using Publish/Subscribe 84 mechanisms . . . . . . . . . . . . . . . . . . . . 14 85 5.2. Implementation Considerations . . . . . . . . . . . . . . 14 86 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 15 87 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15 88 5.2.3. Interface to the LISP Mapping System . . . . . . . . 16 89 5.2.4. SMR support to track L2 hosts that moved away . . . . 16 90 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17 91 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17 92 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18 93 5.3. Support to ARP resolution through Mapping System . . . . 18 94 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 18 95 5.3.2. ARP registrations: MAC as a locator record . . . . . 19 96 5.3.3. Implementation Considerations . . . . . . . . . . . . 21 97 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 98 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 99 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 104 9.2. Informative References . . . . . . . . . . . . . . . . . 25 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 107 1. Introduction 109 This document describes the architecture and design options required 110 to offer a unified L2 and L3 overlay solution for End-point 111 Identifier (EID) mobility using the LISP control-plane. 113 The architecture takes advantage of the flexibility that LISP 114 provides to simultaneously support different overlay types. While 115 the LISP specification defines both the data-plane and the control- 116 plane, this document focuses on the use of the control-plane to 117 provide L2 and L3 overlay services with EID mobility. The control 118 plane may be combined with a data-plane of choice e.g., [LISP], 119 [VXLAN-GPE], or [VXLAN]. 121 The recommendation on whether a flow is sent over the L2 or the L3 122 overlay is based on whether the traffic is bridged (intra-subnet or 123 non-IP) or routed (inter-subnet), respectively. This allows treating 124 both overlays as separate segments, and enables L2-only and L3-only 125 deployments (and combinations of them) without modifying the 126 architecture. 128 The unified solution for L2 and L3 overlays offers the possibility to 129 extend subnets and routing domains (as required in state-of-art 130 Datacenter and Enterprise architectures) with mobility support and 131 traffic optimization. 133 An important use-case of the unified architecture is that, while most 134 data centers are complete layer-3 routing domains, legacy 135 applications either have not converted to IP or still use auto- 136 discovery at layer-2 and assume all nodes in an application cluster 137 belong to the same subnet. For these applications, the L2-overlay 138 limits the functionality to where the legacy app lives versus having 139 to extend layer-2 into the underlay network. 141 Broadcast, Unknown and Multicast traffic on the overlay are supported 142 by either replicated unicast, or underlay (RLOC) multicast as 143 specified in [RFC6831] and [RFC8378]. 145 2. Definition of Terms 147 LISP related terms are defined as part of the LISP specification 148 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 149 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 150 (MS) and Map-Resolver (MR). 152 3. Reference System 154 The following figure illustrates the reference system used to support 155 the packet flow description throughout this document. The system 156 presents 4 sites. Site A and Site D provide access to different 157 subnets (non-extended), while Site B and Site C extend a common 158 subnet. The xTR in each one of the sites registers EIDs from the 159 sites with the LISP Mapping System and provides support to 160 encapsulate overlay (EID) traffic through the underlay (RLOC space). 162 ,-------------. 163 (Mapping System ) 164 -+------------+ 165 +--+--+ +-+---+ 166 |MS/MR| |MS/MR| 167 +-+---+ +-----+ 168 .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-. 169 .-.' '.-. 170 ( L3 Underlay ) 171 ( (RLOC Space) ) 172 '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.' 173 / | | \ 174 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 175 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 176 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 177 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 178 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 179 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 180 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 181 / '--' | '--' | '--' \ '--' 182 '--------' '--------' '--------' '--------' 183 : End : : End : : End : : End : 184 :Device 1: :Device 2: :Device 3: :Device 4: 185 '--------' '--------' '--------' '--------' 186 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 187 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 189 Figure 1: Reference System Architecture with unified L2 and L3 190 overlays 192 The recommended selection between the use of L2 and L3 overlays is to 193 map them to bridged (intra-subnet or non-IP) and routed (inter- 194 subnet) traffic. The rest of the document follows this 195 recommendation to describe the packet flows. 197 However, note that in a different selection approach, intra-subnet 198 traffic MAY also be sent over the L3 overlay. Section 6.1 specifies 199 the changes needed to send all IP traffic using the L3 overlay and 200 restricting the use of the L2 overlay to non-IP traffic. 202 When required, the control plane makes use of two basic types of EID- 203 to-RLOC mappings associated to end-hosts and in order to support the 204 unified architecture: 206 * EID = to RLOC=. This is used to support the L2 207 overlay. 209 * EID = to RLOC=. This is the traditional mapping as 210 defined in the original LISP specification and supports the L3 211 overlay. 213 4. L3 Overlays and Mobility Support 215 4.1. Reference Architecture and packet flows 217 In order to support the packet flow descriptions in this section we 218 use Figure 1 as reference. This section uses Sites A and D to 219 describe the flows. 221 / | | \ 222 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 223 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 224 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 225 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 226 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 227 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 228 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 229 / '--' | '--' | '--' \ '--' 230 '--------' '--------' '--------' '--------' 231 : End : : End : : End : : End : 232 :Device 1: :Device 2: :Device 3: :Device 4: 233 '--------' '--------' '--------' '--------' 234 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 235 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 237 Figure 2: Reference Mobility Architecture 239 4.1.1. Routed Traffic Flow: L3 Overlay use 241 Inter-subnet traffic is encapsulated using the L3 overlay. The 242 process to encapsulate this traffic is the same as described in the 243 original specification [RFC6830]. We describe the packet flow here 244 for completeness 246 The following is a sequence example of the unicast packet flow and 247 the control plane operations when in the topology shown in Figure 1 248 End-Device 1, in LISP site A, wants to communicate with End-Device 4 249 in LISP site D. Note that both end systems reside in different 250 subnets. We'll assume that End-Device 1 knows the EID IP address of 251 End-Device 4 (e.g. it is learned using a DNS service). 253 * End-Device 1 sends an IP packet frame with destination 2.0.0.4 and 254 source 1.0.0.1. As the destination address lies on a different 255 subnet End-Device 1 sends the packet following its routing table 256 to ITR A (e.g., it is its default gateway). 258 * ITR A does a L3 lookup in its local map-cache for the destination 259 IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a 260 Map-request to the mapping database system looking up for 261 EID=. 263 * The mapping systems forwards the Map-Request to ETR D, that has 264 registered the EID-to-RLOC mapping of EID=. 266 * ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC 267 mapping: EID= -> RLOC=IP_D, where IP_D is the 268 locator of ETR D. 270 * ITR A populates the local map-cache with the EID to RLOC mapping, 271 and encapsulates all subsequent packets with a destination IP 272 2.0.0.4 using destination RLOC=IP_D. 274 4.1.2. L3 Mobility Flow 276 The support to L3 mobility covers the requirements to allow an end- 277 host to move from a given site to another and maintain correspondence 278 with the rest of end-hosts that are connected to the same L3 routing 279 domain. This support MUST ensure convergence of L3 forwarding (IPv4/ 280 IPv6 based) from the old location to the new one when the host 281 completes its move. 283 The update of the ITR map-caches when EIDs move MAY be achieved using 284 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 285 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 286 descriptions of the packet flow when End-Device 1 in the reference 287 figure roams to site D. 289 4.1.2.1. L3 Mobility Flow using Data Driven SMRs 291 The following is a sequence description of the packet flow when End- 292 Device 1 in the reference figure roams to site D. This sequence uses 293 Data Driven SMRs to trigger the updates of the ITR map-caches. 295 * When End-Device 1 is attached or detected in site D, ETR D sets up 296 the database mapping corresponding to EID=. ETR D 297 sends a Map-Register to the mapping system registering RLOC=IP_D 298 as locator for EID=. Now the mapping system is 299 updated with the new EID-to-RLOC mapping (location) for End-Device 300 1. 302 * The Mapping System, after receiving the new registration for 303 EID= sends a Map-Notify to the departure ETR(s) 304 (ETR A) to inform it of the move. Then, ETR A removes its local 305 database mapping information and stops registering EID=. 308 * Any ITR or PiTR participating in the L3 overlay (corresponding to 309 IID1) that were sending traffic to 1.0.0.1 before the migration 310 keep sending traffic to ETR A. 312 * Once ETR A is notified by the Mapping system, when it receives 313 traffic from an ITR with destination 1.0.0.1, it generates a 314 Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=. 317 * Upon receiving the SMR the ITR invalidates its local map- cache 318 entry for EID= and sends a new Map-Request for that 319 EID. The Map-Reply includes the new EID-to-RLOC mapping for End- 320 Device 1 with RLOC=IP_D. 322 * Similarly, once the local database mapping is removed from ITR A, 323 non-encapsulated packets arriving at ITR A from a local End-Device 324 and destined to End-Device 1 result in a cache miss, which 325 triggers sending a Map-Request for EID= to populate 326 the map-cache of ITR A. 328 4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms 330 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 331 the flow of signaling to achieve EID mobility is modified. In this 332 case, when an local end-device connected via an ITR establishes 333 communication with a remote mobile end-device (connected to a remote 334 ETR), the ITR will issue a Map-Request for the mobile end-device. 335 Following the Mapping Request Subscribe Procedures defined in 336 [I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit 337 set on the EID-Record so that the ITR is notified of any RLOC-set 338 changes for the mobile EID-prefix. 340 The following is a sequence description of the packet flow when End- 341 Device 1 in the reference figure roams to site D. This sequence 342 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 344 * When an end-Device connected via an ITR establishes communication 345 with a mobile end-device (e.g. end-device 1), the ITR will issue a 346 Map-Request for the mobile end-device. Following the Mapping 347 Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], 348 the Map-request will be issued with the N-bit set on the EID- 349 Record so that the ITR is notified of any RLOC-set changes for the 350 mobile EID-prefix. 352 * When the mobile end-device (End-Device 1) is attached or detected 353 in a new site (e.g. site D), The ETR at the new site (e.g. ETR D) 354 sets up the database mapping corresponding to the EID of the 355 mobile end-device (e.g. EID=). The ETR at the new 356 site (e.g. ETR D) sends a Map-Register to the mapping system 357 registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of 358 the mobile end-device (e.g. EID=). Now the 359 mapping system is updated with the new EID-to-RLOC mapping 360 (location) for the mobile end-device (e.g. End-Device 1). 362 * The Mapping System, after receiving the new registration for the 363 EID of the mobile end-device (EID=) sends a Map- 364 Notify to the departure site (ETR A) to inform it of the move. 365 Then, the ETR at the departure site (ETR A) removes its local 366 database mapping information and stops registering the EID for the 367 mobile end-device (EID=). 369 * Any ITR or PiTR participating in the L3 overlay (corresponding to 370 IID1) that were sending traffic to the mobile end-device (1.0.0.1) 371 would have Subscribed to receive notifications of any changes in 372 the RLOC-set for the EID of the mobile end-device (1.0.0.1). The 373 Mapping System publishes the updated RLOC-set to the Subscribed 374 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 375 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 377 * Upon receiving the Map-Notify message, the ITR updates the RLOC- 378 set in its local map-cache entry for the EID of the mobile end- 379 device (EID=). Once the map-cache is updated, 380 traffic is tunneled by the ITR to the new location. 382 4.2. Implementation Considerations 384 4.2.1. L3 Segmentation 386 LISP support of segmentation and multi-tenancy is structured around 387 the propagation and use of Instance-IDs, and handled as part of the 388 EID in control plane operations. The encoding is described in 389 [RFC8060] and its use in [RFC8111]. 391 Instance-IDs can be used to support L3 overlay segmentation, such as 392 in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]). 394 4.2.2. L3 Database-Mappings 396 When an end-host is attached or detected in an ETR that provides 397 L3-overlay services and mobility, a database Mapping is registered to 398 the mapping system with the following structure: 400 * The EID 2-tuple (IID, IP) with its binding to a corresponding ETR 401 locator set (IP RLOC) 403 The registration of these EIDs MUST follow the LCAF format as defined 404 in [RFC8060] and the specific EID record to be used is illustrated in 405 the following figure: 407 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | Record TTL | 409 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 E | Locator Count | EID mask-len | ACT |A| Reserved | 411 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 D | Rsvd | Map-Version Number | AFI = 16387 | 413 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 415 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 c | 4 + n | Instance-ID... | 417 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 r | ...Instance-ID | EID-AFI = 1 or 2 | 419 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | EID-Prefix (IPv4 or IPv6) | 421 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | /| Priority | Weight | M Priority | M Weight | 423 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | o | Unused Flags |L|p|R| Loc-AFI | 425 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | \| Locator | 427 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 The L3 EID record follows the structure as described in [RFC6830]. 431 4.2.3. LISP Mapping System support 433 The interface between the xTRs and the Mapping System is described in 434 [RFC6833] and this document follows the specification as described 435 there. When available, the registrations MAY be implemented over a 436 reliable transport as described in 437 [I-D.kouvelas-lisp-map-server-reliable-transport]. 439 In order to support system convergence after mobility, when the Map- 440 Server receives a new registration for a specific EID, it MUST send a 441 Map-Notify to the entire RLOC set in the site that last registered 442 this same EID. This Map-Notify is used to track moved-away state of 443 L3 EIDs as described in Section 4.2.4. 445 4.2.4. Using SMRs to Track Moved-Away Hosts 447 One of the key elements to support end-host mobility using the LISP 448 architecture is the Solicit-Map-Request (SMR). This is a special 449 message by means of which an ETR can request an ITR to send a new 450 Map-Request for a particular EID record. In essence the SMR message 451 is used as a signal to indicate a change in mapping information and 452 it is described with detail in [RFC6830]. 454 In order to support mobility, an ETR SHALL maintain a list of EID 455 records for which it has to generate a SMR message whenever it 456 receives traffic with that EID as destination. 458 The particular strategy to maintain an Away Table is implementation 459 specific and it will be typically based on the strategy to detect the 460 presence of hosts and the use of Map-Notify messages received from 461 the Map-Server. In essence the table SHOULD provide support to the 462 following: 464 * Keep track of end-hosts that were once connected to an ETR and 465 have moved away. 467 * Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR 468 message SHOULD be generated. 470 4.2.5. L3 multicast support 472 L3 Multicast traffic on the overlay MAY be supported by either 473 replicated unicast, or underlay (RLOC) multicast. Specific solutions 474 to support L3 multicast over LISP controlled overlays are specified 475 in in [RFC6831], and [RFC8378]. 477 4.2.6. Time-to-Live Handling in Data-Plane 479 The LISP specification ([RFC6830]) describes how to handle Time-to- 480 Live values of the inner and outer headers during encapsulation and 481 decapsulation of packets when using the L3 overlay. 483 5. L2 Overlays and Mobility Support 485 5.1. Reference Architecture and packet flows 487 In order to support L2 packet flow descriptions in this section we 488 use Figure 1 as reference. This section uses Sites B and C to 489 describe the flows. 491 / | | \ 492 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 493 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 494 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 495 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 496 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 497 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 498 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 499 / '--' | '--' | '--' \ '--' 500 '--------' '--------' '--------' '--------' 501 : End : : End : : End : : End : 502 :Device 1: :Device 2: :Device 3: :Device 4: 503 '--------' '--------' '--------' '--------' 504 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 505 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 507 Figure 3: Reference Mobility Architecture 509 5.1.1. Bridged Traffic Flow: L2 Overlay use 511 Bridged traffic is encapsulated using the L2 overlay. This section 512 provides an example of the unicast packet flow and the control plane 513 operations when in the topology shown in Figure 1, the End-Device 2 514 in site B communicates with the End-Device 3 in site C. In this case 515 we assume that End Device 2, knows the MAC address of End-Device 3 516 (e.g., learned through ARP). 518 * End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination 519 0:0:3:0:0:3 and source 0:0:3:0:0:2. 521 * ITR B does a L2 lookup in its local map-cache for the destination 522 MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the 523 ITR sends a Map-Request to the mapping database system looking up 524 for EID=. 526 * The mapping systems forwards the Map-Request to ETR C, that has 527 registered the EID-to-RLOC mapping for EID=. 528 Alternatively, depending on the mapping system configuration, a 529 Map-Server which is part of the mapping database system MAY send a 530 Map-Reply directly to ITR B. 532 * ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC 533 mapping: EID= -> RLOC=IP_C, where IP_C is the 534 locator of ETR C. 536 * ITR B populates the local map-cache with the EID to RLOC mapping, 537 and encapsulates all subsequent packets with a destination MAC 538 0:0:3:0:0:3 using destination RLOC=IP_C. 540 5.1.2. L2 Mobility Flow 542 The support to L2 mobility covers the requirements to allow an end- 543 host to move from a given site to another and maintain correspondence 544 with the rest of end-hosts that are connected to the same L2 domain 545 (e.g. extended VLAN). This support MUST ensure convergence of L2 546 forwarding (MAC based) from the old location to the new one, when the 547 host completes its move. 549 The update of the ITR map-caches when EIDs move MAY be achieved using 550 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 551 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 552 descriptions of the packet flow when End-Device 2 in the reference 553 figure roams to site C, which is extending its own subnet network. 555 5.1.2.1. L2 Mobility Flow using Data Driven SMRs 557 The following is a sequence description of the packet flow when End- 558 Device 2 in the reference figure roams to site C. This sequence uses 559 Data Driven SMRs to trigger the updates of the ITR map-caches. 561 * When End-Device 2 is attached or detected in site C, ETR C sets up 562 the database mapping corresponding to EID=. 563 ETR C sends a Map-Register to the mapping system registering 564 RLOC=IP_B as locator for EID=. 566 * The Mapping System, after receiving the new registration for 567 EID= sends a Map-Notify to ETR B with the new 568 locator set (IP_B). ETR B removes then its local database mapping 569 and stops registering . 571 * Any PiTR or ITR participating in the same L2-overlay 572 (corresponding to IID2) that was encapsulating traffic to 573 0:0:3:0:0:2 before the migration continues encapsulating this 574 traffic to ETR B. 576 * Once ETR B is notified by the Mapping system, when it receives 577 traffic from an ITR which is destined to 0:0:3:0:0:2, it will 578 generate a Solicit-Map-Request (SMR) message that is sent to the 579 ITR for (IID2,0:0:3:0:0:2). 581 * Upon receiving the SMR the ITR sends a new Map-Request for the 582 EID=. As a response ETR B sends a Map-Reply 583 that includes the new EID-to-RLOC mapping for 584 with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 585 replacing the previous one, and traffic is then forwarded to the 586 new location. 588 5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms 590 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 591 the flow of signaling to achieve EID mobility is modified. In this 592 case, when an End-Device connected via an ITR establishes 593 communication with a mobile EID-prefix, the ITR will issue a Map- 594 Request for the mobile End-device. Following the Mapping Request 595 Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map- 596 request will be issued with the N-bit set on the EID-Record so that 597 the ITR is notified of any RLOC-set changes for the mobile EID- 598 prefix. 600 The following is a sequence description of the packet flow when End- 601 Device 2 in the reference figure roams to site C. This sequence 602 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 604 * When End-Device 2 is attached or detected in site C, ETR C sets up 605 the database mapping corresponding to EID=. 606 ETR C sends a Map-Register to the mapping system registering 607 RLOC=IP_B as locator for EID=. 609 * The Mapping System, after receiving the new registration for 610 EID= sends a Map-Notify to the departure site 611 (ETR B) with the new locator set (IP_B). ETR B removes then its 612 local database mapping and stops registering . 614 * Any ITR or PiTR participating in the same L2-overlay 615 (corresponding to IID2) that was encapsulating traffic to 616 0:0:3:0:0:2 before the migration would have Subscribed to receive 617 notifications of any changes in the RLOC-set for 0:0:3:0:0:2. The 618 Mapping System publishes the updated RLOC-set to the Subscribed 619 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 620 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 622 * Upon receiving the Map-Notify message, the ITR updates the RLOC- 623 set in its local map-cache entry for EID=. 624 Once the map-cache is updated, traffic is tunneled by the ITR to 625 the new location. 627 5.2. Implementation Considerations 628 5.2.1. L2 Segmentation 630 As with L3 overlays, LISP support of L2 segmentation is structured 631 around the propagation and use of Instance-IDs, and handled as part 632 of the EID in control plane operations. The encoding is described in 633 [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a 634 Mapping System and MAY be used to identify the overlay type (e.g., L2 635 or L3 overlay). 637 An Instance-ID can be used for L2 overlay segmentation. An important 638 aspect of L2 segmentation is the mapping of VLANs to IIDs. In this 639 case a Bridge Domain (which is the L2 equivalent to a VRF as a 640 forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge 641 domain or different VLAN-IDs on different ports may map to a common 642 Bridge Domain, which in turn maps to an IID in the L2 overlay. When 643 ethernet traffic is double tagged, usually the outer 802.1Q tag will 644 be mapped to a bridge domain on a per port basis, and the inner 645 802.1Q tag will remain part of the payload to be handled by the 646 overlay. The IID should therefore be able to carry ethernet traffic 647 with or without an 802.1Q header. A port may also be configured as a 648 trunk and we may chose to take the encapsulated traffic and map it to 649 a single IID in order to multiplex traffic from multiple VLANs on a 650 single IID. These are all examples of local operations that could be 651 effected on VLANs in order to map them to IIDs, they are provided as 652 examples and are not exhaustive. 654 5.2.2. L2 Database-Mappings 656 When an end-host is attached or detected in an ETR that provides 657 L2-overlay services, a database Mapping is registered to the mapping 658 system with the following structure: 660 * The EID 2-tuple (IID, MAC) with its binding to a locator set (IP 661 RLOC) 663 The registration of these EIDs MUST follow the LCAF format as defined 664 in [RFC8060] and as illustrated in the following figure: 666 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | Record TTL | 668 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 E | Locator Count | EID mask-len | ACT |A| Reserved | 670 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 D | Rsvd | Map-Version Number | AFI = 16387 | 672 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 674 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 c | 4 + n | Instance-ID... | 676 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 r | ...Instance-ID | EID-AFI = 6 | 678 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | | Layer-2 MAC Address ... | 680 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | /| ... Layer-2 MAC Address | Priority | Weight | 682 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | o | M Priority | M Weight | Unused Flags |L|p|R| 684 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | | | Loc-AFI | Locator.... | 686 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | \| ... Locator 688 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 The L2 EID record follows the structure as described in [RFC6830]. 692 5.2.3. Interface to the LISP Mapping System 694 The interface between the xTRs and the Mapping System is described in 695 [RFC6833] and this document follows the specification as described 696 there. When available, the registrations MAY be implemented over a 697 reliable transport. 699 In order to support system convergence after mobility, when the Map- 700 Server receives a new registration for a specific EID, it MUST send a 701 Map-Notify to the entire RLOC set in the site that last registered 702 this same EID. This Map-Notify is used to track moved-away state of 703 L2 EIDs as described in Section 5.2.4. 705 5.2.4. SMR support to track L2 hosts that moved away 707 In order to support mobility, an ETR SHALL maintain a list of EID 708 records for which it has to generate a SMR message whenever it 709 receives traffic with that EID as destination. 711 The particular strategy to maintain a SMR table is implementation 712 specific. In essence the table SHOULD provide support for the 713 following: 715 * Keep track of end-hosts that were once connected to an ETR and 716 have moved away. 718 * Support for L2 EID records, the 2-tuple (IID, MAC), for which a 719 SMR message SHOULD be generated. 721 5.2.5. L2 Broadcast and Multicast traffic 723 Broadcast and Multicast traffic on the L2-overlay is supported by 724 either replicated unicast, or underlay (RLOC) multicast. 726 xTRs that offer L2 overlay services and are part of the same 727 Instance-ID join a common Multicast Group. When required, this group 728 allows ITRs to send traffic that needs to be replicated (flooded) to 729 all ETRs participating in the L2-overlay (e.g., broadcast traffic 730 within a subnet). When the core network (RLOC space) supports native 731 multicast ETRs participating in the L2-overlay join a (*,G) group 732 associated to the Instance-ID. 734 When multicast is not available in the core network, each xTR that is 735 part of the same instance-ID SHOULD register a (S,G) entry to the 736 mapping system using the procedures described in [RFC8378], where S 737 is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows 738 and ITR to know which ETRs are part of the L2 overlay and it can 739 head-end replicate traffic to. 741 Following the same case, when multicast is not available in the core 742 network, the procedures in [RFC8378] can be used to ensure proper 743 distribution of link-local multicast traffic across xTRs 744 participating in the L2 overlay. In such case, the xTRs SHOULD join 745 a (S,G) entry with S being 0000-0000-0000/0 and where G is 746 0100-0000-0000/8. 748 5.2.6. L2 Unknown Unicast Support 750 An ITR attempts to resolve MAC destination misses through the Mapping 751 System. When the destination host remains undiscovered the 752 destination is considered an Unknown Unicast. 754 A Map-Server SHOULD respond to a Map-Request for an undiscovered host 755 with a Negative Map-Reply with action "Native Forward". 756 Alternatively the action "Drop" may be used in order to suppress 757 Unknown Unicast forwarding. 759 An ITR that receives a Negative Map-Reply with Action "Native 760 Forward" will handle traffic for the undiscovered host as L2 761 Broadcast traffic and will be unicast replicated or flooded using 762 underlay multicast to the rest of ETRs in the Layer-2 overlay. 764 Upon discovery of a previously unknown unicast MAC EID, a data 765 triggered SMR for the discovered EID should be sent by the discovery 766 ETR back to the ITRs that are flooding the unknown unicast traffic. 767 This would allow ITRs to refresh their caches and stop flooding 768 unknown unicast traffic as necessary. 770 5.2.7. Time-to-Live Handling in Data-Plane 772 When using a L2 overlay and the encapsulated traffic is IP traffic, 773 the Time-to-Live value of the inner IP header MUST remain unmodified 774 during encapsulation and decapsulation. Network hops traversed as 775 part of the L2 overlay SHOULD be hidden to tools like traceroute and 776 applications that require direct L2 connectivity. 778 5.3. Support to ARP resolution through Mapping System 780 5.3.1. Map-Server support to ARP resolution: Packet Flow 782 A large majority of applications are IP based and, as a consequence, 783 end systems are typically provisioned with IP addresses as well as 784 MAC addresses. 786 In this case, to limit the flooding of ARP traffic and reduce the use 787 of multicast in the RLOC network, the LISP mapping system MAY be used 788 to support ARP resolution at the ITR. 790 In order to provide this support, ETRs handle and register an 791 additional EID-to-RLOC mapping as follows, 793 * EID-record contents = , RLOC-record contents . 795 There is a dedicated IID used for the registration of the ARP/ND 796 related mappings. Thus, a system with L2 and L3 overlays as well as 797 ARP/ND mappings would have three IIDs at play. In the spirit of 798 providing clarity, we will refer to those IIDs as L2-IID, L3-IID and 799 ARP-IID respectively. By using these definitions, we do not intend 800 to coin new terminology, nor is there anything special about those 801 IIDs that would make them differ from the generic definition of an 802 IID. The types of mappings expected in such a system are summarized 803 below: 805 * EID = to RLOC = (L3-overlay) 807 * EID = to RLOC = (L2-overlay) 809 * EID = to RLOC = (ARP/ND mapping) 810 The following packet flow sequence describes the use of the LISP 811 Mapping System to support ARP resolution for hosts residing in a 812 subnet that is extended to multiple sites. Using Figure 1, End- 813 Device 2 tries to find the MAC address of End-Device 3. Note that 814 both have IP addresses within the same subnet: 816 * End-Device 2 sends a broadcast ARP message to discover the MAC 817 address of End-Device 3. The ARP request targets IP 3.0.0.3. 819 * ITR B receives the ARP message, but rather than flooding it on the 820 overlay network sends a Map-Request to the mapping database system 821 for EID = . 823 * When receiving the Map-Request, the Map-Server sends a Proxy-Map- 824 Reply back to ITR B with the mapping EID = -> MAC 825 0:0:3:0:0:3. 827 * Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 828 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 830 * End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 831 now send a L2 traffic to End-Device 3. When this traffic reaches 832 ITR B is sent over the L2-overlay as described above in 833 Section 5.1.1. 835 This example shows how LISP, by replacing dynamic data plane learning 836 (such as Flood-and-Learn) can reduce the use of multicast in the 837 underlay network. 839 Note that ARP resolution using the Mapping System is a stateful 840 operation on the ITR. The source IP,MAC tuple coming from the ARP 841 request have to be stored to generate the ARP-reply when the Map- 842 Reply is received. 844 Note that the ITR SHOULD cache the ARP entry. In that case future 845 ARP-requests can be handled without sending additional Map-Requests. 847 5.3.2. ARP registrations: MAC as a locator record 849 When an end-host is attached or detected in an ETR that provides 850 L2-overlay services and also supports ARP resolution using the LISP 851 control-plane, an additional mapping entry is registered to the 852 mapping system: 854 * The EID 2-tuple (IID, IP) and its binding to a corresponding host 855 MAC address. 857 In this case both the xTRs and the Mapping System MUST support an 858 EID-to-RLOC mapping where the MAC address is set as a locator record. 860 In order to guarantee compatibility with current implementations of 861 xTRs, the MAC locator record SHALL be encoded following the AFI-List 862 LCAF Type defined in [RFC8060]. This option would also allow adding 863 additional attributes to the locator record, while maintaining 864 compatibility with legacy devices. 866 This mapping is registered with the Mapping System using the 867 following EID record structure, 869 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | | Record TTL | 871 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 E | Locator Count | EID mask-len | ACT |A| Reserved | 873 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 D | Rsvd | Map-Version Number | AFI = 16387 | 875 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 877 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 c | 4 + n | Instance-ID... | 879 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 r | ...Instance-ID | EID-AFI = 1 or 2 | 881 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | | EID-Prefix (IPv4 or IPv6) | 883 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | /| Priority | Weight | M Priority | M Weight | 885 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | M | Unused Flags |L|p|R| AFI = 16387 | 887 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 889 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | | 2 + 6 | AFI = 6 | 891 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | | Layer-2 MAC Address ... | 893 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | \| ... Layer-2 MAC Address | 895 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 897 An EID record with a locator record that carries a MAC address 898 follows the same structure as described in [RFC6830]. However, some 899 fields of the EID record and the locator record require special 900 consideration: 902 Locator Count: This value SHOULD be set to 1. 904 Instance-ID: This is the IID used to provide segmentation of the 905 L2-overlays, L3 overlays and ARP tables. 907 Priority and Weight: IP to MAC bindings are one to one bindings. An 908 ETR SHOULD not register more than one MAC address in the locator 909 record together with an IP based EID. The Priority of the MAC 910 address record is set to 255. The Weight value SHOULD be ignored 911 and the recommendation is to set it to 0. 913 L bit: This bit of the locator record SHOULD only be set to 1 when 914 an ETR is registering its own IP to MAC binding. 916 p bit: This bit of the locator record SHOULD be set to 0. 918 R bit: This bit of the locator record SHOULD be set to 0. 920 Note that an IP EID record that carries a MAC address in the locator 921 record, SHALL be registered with the Proxy Map-Reply bit set. 923 5.3.3. Implementation Considerations 925 While ARP support through the LISP Mapping System fits the LISP 926 Control-Plane there are a series of considerations to take into 927 account when providing this feature: 929 * As indicated, when and end-host is attached the ETR maintains and 930 registers a mapping with the binding EID = -> RLOC = 931 . 933 * ARP support through the LISP Mapping System is OPTIONAL and the 934 xTRs should allow the possibility to enable or disable the 935 feature. 937 * When the ARP entry has not been registered, a Map Server SHOULD 938 send a Negative Map-Reply with action "No Action" as a response to 939 an ARP based Map Request. 941 * In case the ITR receives a Negative Map-Reply for an ARP request 942 it should fallback to flooding the ARP packet as any other L2 943 Broadcast packet (as described in Section 5.2.5). 945 * When receiving a positive Map-Reply for an ARP based Map-Request, 946 the ETR MUST recreate the actual ARP Reply, impersonating the real 947 host. As a consequence, ARP support is a stateful operation where 948 the ITR needs to store enough information about the host that 949 generates an ARP request in order to recreate the ARP Reply. 951 * ARP replies learned from the Mapping System SHOULD be cached and 952 the information used to reply to subsequent ARP requests to the 953 same hosts. 955 6. Optional Deployment Models 957 The support of an integrated L2 and L3 overlay solution takes 958 multiple architectural design options, that depend on the specific 959 requirements of the deployment environment. While some of the 960 previous describe specific packet flows and solutions based on the 961 recommended solution, this section documents OPTIONAL design 962 considerations that differ from the recommended one but that MAY be 963 required on alternative deployment environments. 965 6.1. IP Forwarding of Intra-subnet Traffic 967 As pointed out at the beginning the recommended selection of the L2 968 and L3 overlays is not the only one possible. In fact, providing L2 969 extension to some cloud platforms is not always possible and subnets 970 need to be extended using the L3 overlay. 972 In order to send all IP traffic (intra- and inter-subnet) through the 973 L3 overlay the solution MUST change the ARP resolution process 974 described in Section 5.3.1 to the following one (we follow again 975 Figure 1 to drive the example. End-Device 2 queries about End-Device 976 3): 978 * End-Device 1 sends a broadcast ARP message to discover the MAC 979 address of 3.0.0.3. 981 * ITR B receives the ARP message and sends a Map-Request to the 982 Mapping System for EID = . 984 * In this case, the Map-Request is routed by the Mapping system 985 infrastructure to ETR C, that will send a Map-Reply back to ITR B 986 containing the mapping EID = -> RLOC=IP_C. 988 * ITR B populates its local cache with the received entry on the L3 989 forwarding table. Then, using the cache information it sends a 990 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 991 Device 1. 993 * End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 994 traffic with destination address 3.0.0.3 and destination MAC, 995 MAC_xTR_B. 997 * As the destination MAC address is the one from xTR B, when xTR B 998 receives this traffic it is forwarded using the L3-overlay. 1000 * Note that when implementing this solution, when a host that is 1001 local to an ETR moves away, the ETR SHOULD locally send a 1002 Gratuitous ARP with its own MAC address and the IP of the moved 1003 host, to refresh the ARP tables of local hosts and guarantee the 1004 use of the L3 overlay when connecting to the remote host. 1006 It is also important to note that using this strategy to extend 1007 subnets through the L3 overlay but still keeping the L2 overlay for 1008 the rest of traffic MAY lead to flow asymmetries. This MAY be the 1009 case in deployments that filter Gratuitous ARPs, or when moved hosts 1010 continue using actual L2 information collected before a migration. 1012 6.2. Data-plane Encapsulation Options 1014 The LISP control-plane offers independence from the data-plane 1015 encapsulation. Any encapsulation format that can carry a 24-bit 1016 instance-ID can be used to provide the unified overlay. 1018 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 1019 and [VXLAN]: 1021 * VXLAN-GPE encap: This encapsulation format is defined in 1022 [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 1023 packets and the VNI field directly maps to the Instance-ID used in 1024 the control plane. Note that when using this encapsulation for a 1025 unified solution the P-bit is set and the Next-Protocol field is 1026 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 1027 L3-overlays, and value 0x3 in L2-overlays). 1029 * LISP encap: This is the encapsulation format defined in the 1030 original LISP specification [RFC6830]. The encapsulation allows 1031 encapsulating both L2 and L3 packets. The Instance-ID used in the 1032 EIDs directly maps to the Instance-ID that the LISP header 1033 carries. At the ETR, after decapsulation, the IID MAY be used to 1034 decide between L2 processing or L3 processing. 1036 * VXLAN encap: This is a L2 encapsulation format defined in 1037 [RFC7348]. While being a L2 encapsulation it can be used both for 1038 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 1039 to the VNI field of the VXLAN header. Providing L3 overlays using 1040 VXLAN generally requires using the ETR MAC address as destination 1041 MAC address of the inner Ethernet header. The process to learn or 1042 derive this ETR MAC address is not included as part of this 1043 document. 1045 7. IANA Considerations 1047 This memo includes no request to IANA. 1049 8. Acknowledgements 1051 This draft builds on top of two expired drafts that introduced the 1052 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 1053 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 1054 combined authors of those drafts, that SHOULD be considered main 1055 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 1056 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 1057 Smith. 1059 9. References 1061 9.1. Normative References 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", BCP 14, RFC 2119, 1065 DOI 10.17487/RFC2119, March 1997, 1066 . 1068 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1069 Locator/ID Separation Protocol (LISP)", RFC 6830, 1070 DOI 10.17487/RFC6830, January 2013, 1071 . 1073 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1074 Locator/ID Separation Protocol (LISP) for Multicast 1075 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1076 2013, . 1078 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1079 Protocol (LISP) Map-Server Interface", RFC 6833, 1080 DOI 10.17487/RFC6833, January 2013, 1081 . 1083 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1084 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1085 eXtensible Local Area Network (VXLAN): A Framework for 1086 Overlaying Virtualized Layer 2 Networks over Layer 3 1087 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1088 . 1090 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1091 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1092 February 2017, . 1094 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1095 Smirnov, "Locator/ID Separation Protocol Delegated 1096 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1097 May 2017, . 1099 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1100 Separation Protocol (LISP) Multicast", RFC 8378, 1101 DOI 10.17487/RFC8378, May 2018, 1102 . 1104 9.2. Informative References 1106 [I-D.ietf-lisp-gpe] 1107 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 1108 Smith, "LISP Generic Protocol Extension", Work in 1109 Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July 1110 2020, . 1113 [I-D.ietf-lisp-pubsub] 1114 AlbertoRodriguezNatal, Ermagan, V., Cabellos-Aparicio, A., 1115 Barkai, S., and M. Boucadair, "Publish/Subscribe 1116 Functionality for LISP", Work in Progress, Internet-Draft, 1117 draft-ietf-lisp-pubsub-09, 28 June 2021, 1118 . 1121 [I-D.ietf-lisp-vpn] 1122 Moreno, V. and D. Farinacci, "LISP Virtual Private 1123 Networks (VPNs)", Work in Progress, Internet-Draft, draft- 1124 ietf-lisp-vpn-06, 3 August 2020, . 1127 [I-D.kouvelas-lisp-map-server-reliable-transport] 1128 Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C., 1129 Kouvelas, I., and J. Arango, "LISP Map Server Reliable 1130 Transport", Work in Progress, Internet-Draft, draft- 1131 kouvelas-lisp-map-server-reliable-transport-06, 26 April 1132 2021, . 1135 Authors' Addresses 1136 Marc Portoles Comeras 1137 Cisco Systems 1138 170 Tasman Drive 1139 San Jose, CA 95134 1140 United States of America 1142 Email: mportole@cisco.com 1144 Vrushali Ashtaputre 1145 Cisco Systems 1146 170 Tasman Drive 1147 San Jose, CA 95134 1148 United States of America 1150 Email: vrushali@cisco.com 1152 Victor Moreno 1153 Cisco Systems 1154 170 Tasman Drive 1155 San Jose, CA 95134 1156 United States of America 1158 Email: vimoreno@cisco.com 1160 Fabio Maino 1161 Cisco Systems 1162 170 Tasman Drive 1163 San Jose, CA 95134 1164 United States of America 1166 Email: fmaino@cisco.com 1168 Dino Farinacci 1169 lispers.net 1170 San Jose, CA 1171 United States of America 1173 Email: farinacci@gmail.com