idnits 2.17.1 draft-ietf-lisp-eid-mobility-09.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 (18 January 2022) is 827 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 1022, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 1022, but not defined == Missing Reference: 'VXLAN' is mentioned on line 1023, but not defined == Unused Reference: 'RFC6833' is defined on line 1082, but no explicit reference was found in the text ** 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 (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-08 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-07 Summary: 3 errors (**), 0 flaws (~~), 12 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 F. Maino 5 Expires: 22 July 2022 Cisco Systems 6 V. Moreno 7 Google LLC 8 D. Farinacci 9 lispers.net 10 18 January 2022 12 LISP L2/L3 EID Mobility Using a Unified Control Plane 13 draft-ietf-lisp-eid-mobility-09 15 Abstract 17 The LISP control plane offers the flexibility to support multiple 18 overlay flavors simultaneously. This document specifies how LISP can 19 be used to provide control-plane support to deploy a unified L2 and 20 L3 overlay solution for End-point Identifier (EID) mobility, as well 21 as analyzing possible deployment options and models. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 22 July 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . 5 66 4.1. Reference Architecture and packet flows . . . . . . . . . 5 67 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 68 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 15 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 95 5.3. Support to ARP resolution through Mapping System . . . . 18 96 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 18 97 5.3.2. ARP registrations: MAC as a locator record . . . . . 19 98 5.3.3. Implementation Considerations . . . . . . . . . . . . 21 99 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 100 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 101 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 106 9.2. Informative References . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Introduction 111 This document describes the architecture and design options required 112 to offer a unified L2 and L3 overlay solution for End-point 113 Identifier (EID) mobility using the LISP control-plane. 115 The architecture takes advantage of the flexibility that LISP 116 provides to simultaneously support different overlay types. While 117 the LISP specification defines both the data-plane and the control- 118 plane, this document focuses on the use of the control-plane to 119 provide L2 and L3 overlay services with EID mobility. The control 120 plane may be combined with a data-plane of choice e.g., [LISP], 121 [VXLAN-GPE], or [VXLAN]. 123 The recommendation on whether a flow is sent over the L2 or the L3 124 overlay is based on whether the traffic is bridged (intra-subnet or 125 non-IP) or routed (inter-subnet), respectively. This allows treating 126 both overlays as separate segments, and enables L2-only and L3-only 127 deployments (and combinations of them) without modifying the 128 architecture. 130 The unified solution for L2 and L3 overlays offers the possibility to 131 extend subnets and routing domains (as required in state-of-art 132 Datacenter and Enterprise architectures) with mobility support and 133 traffic optimization. 135 An important use-case of the unified architecture is that, while most 136 data centers are complete layer-3 routing domains, legacy 137 applications either have not converted to IP or still use auto- 138 discovery at layer-2 and assume all nodes in an application cluster 139 belong to the same subnet. For these applications, the L2-overlay 140 limits the functionality to where the legacy app lives versus having 141 to extend layer-2 into the underlay network. 143 Broadcast, Unknown and Multicast traffic on the overlay are supported 144 by either replicated unicast, or underlay (RLOC) multicast as 145 specified in [RFC6831] and [RFC8378]. 147 2. Definition of Terms 149 LISP related terms are defined as part of the LISP specification 150 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 151 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 152 (MS) and Map-Resolver (MR). 154 3. Reference System 156 The following figure illustrates the reference system used to support 157 the packet flow description throughout this document. The system 158 presents 4 sites. Site A and Site D provide access to different 159 subnets (non-extended), while Site B and Site C extend a common 160 subnet. The xTR in each one of the sites registers EIDs from the 161 sites with the LISP Mapping System and provides support to 162 encapsulate overlay (EID) traffic through the underlay (RLOC space). 164 ,-------------. 165 (Mapping System ) 166 -+------------+ 167 +--+--+ +-+---+ 168 |MS/MR| |MS/MR| 169 +-+---+ +-----+ 170 .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-. 171 .-.' '.-. 172 ( L3 Underlay ) 173 ( (RLOC Space) ) 174 '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.' 175 / | | \ 176 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 177 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 178 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 179 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 180 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 181 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 182 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 183 / '--' | '--' | '--' \ '--' 184 '--------' '--------' '--------' '--------' 185 : End : : End : : End : : End : 186 :Device 1: :Device 2: :Device 3: :Device 4: 187 '--------' '--------' '--------' '--------' 188 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 189 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 191 Figure 1: Reference System Architecture with unified L2 and L3 192 overlays 194 The recommended selection between the use of L2 and L3 overlays is to 195 map them to bridged (intra-subnet or non-IP) and routed (inter- 196 subnet) traffic. The rest of the document follows this 197 recommendation to describe the packet flows. 199 However, note that in a different selection approach, intra-subnet 200 traffic MAY also be sent over the L3 overlay. Section 6.1 specifies 201 the changes needed to send all IP traffic using the L3 overlay and 202 restricting the use of the L2 overlay to non-IP traffic. 204 When required, the control plane makes use of two basic types of EID- 205 to-RLOC mappings associated to end-hosts and in order to support the 206 unified architecture: 208 * EID = to RLOC=. This is used to support the L2 209 overlay. 211 * EID = to RLOC=. This is the traditional mapping as 212 defined in the original LISP specification and supports the L3 213 overlay. 215 4. L3 Overlays and Mobility Support 217 4.1. Reference Architecture and packet flows 219 In order to support the packet flow descriptions in this section we 220 use Figure 1 as reference. This section uses Sites A and D to 221 describe the flows. 223 / | | \ 224 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 225 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 226 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 227 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 228 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 229 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 230 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 231 / '--' | '--' | '--' \ '--' 232 '--------' '--------' '--------' '--------' 233 : End : : End : : End : : End : 234 :Device 1: :Device 2: :Device 3: :Device 4: 235 '--------' '--------' '--------' '--------' 236 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 237 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 239 Figure 2: Reference Mobility Architecture 241 4.1.1. Routed Traffic Flow: L3 Overlay use 243 Inter-subnet traffic is encapsulated using the L3 overlay. The 244 process to encapsulate this traffic is the same as described in 245 [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis]. We 246 describe the packet flow here for completeness 248 The following is a sequence example of the unicast packet flow and 249 the control plane operations when in the topology shown in Figure 1 250 End-Device 1, in LISP site A, wants to communicate with End-Device 4 251 in LISP site D. Note that both end systems reside in different 252 subnets. We'll assume that End-Device 1 knows the EID IP address of 253 End-Device 4 (e.g. it is learned using a DNS service). 255 * End-Device 1 sends an IP packet frame with destination 2.0.0.4 and 256 source 1.0.0.1. As the destination address lies on a different 257 subnet End-Device 1 sends the packet following its routing table 258 to ITR A (e.g., it is its default gateway). 260 * ITR A does a L3 lookup in its local map-cache for the destination 261 IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a 262 Map-request to the mapping database system looking up for 263 EID=. 265 * The mapping systems forwards the Map-Request to ETR D, that has 266 registered the EID-to-RLOC mapping of EID=. 268 * ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC 269 mapping: EID= -> RLOC=IP_D, where IP_D is the 270 locator of ETR D. 272 * ITR A populates the local map-cache with the EID to RLOC mapping, 273 and encapsulates all subsequent packets with a destination IP 274 2.0.0.4 using destination RLOC=IP_D. 276 4.1.2. L3 Mobility Flow 278 The support to L3 mobility covers the requirements to allow an end- 279 host to move from a given site to another and maintain correspondence 280 with the rest of end-hosts that are connected to the same L3 routing 281 domain. This support MUST ensure convergence of L3 forwarding (IPv4/ 282 IPv6 based) from the old location to the new one when the host 283 completes its move. 285 The update of the ITR map-caches when EIDs move MAY be achieved using 286 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 287 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 288 descriptions of the packet flow when End-Device 1 in the reference 289 figure roams to site D. 291 4.1.2.1. L3 Mobility Flow using Data Driven SMRs 293 The following is a sequence description of the packet flow when End- 294 Device 1 in the reference figure roams to site D. This sequence uses 295 Data Driven SMRs to trigger the updates of the ITR map-caches. 297 * When End-Device 1 is attached or detected in site D, ETR D sets up 298 the database mapping corresponding to EID=. ETR D 299 sends a Map-Register to the mapping system registering RLOC=IP_D 300 as locator for EID=. Now the mapping system is 301 updated with the new EID-to-RLOC mapping (location) for End-Device 302 1. 304 * The Mapping System, after receiving the new registration for 305 EID= sends a Map-Notify to the departure ETR(s) 306 (ETR A) to inform it of the move. Then, ETR A removes its local 307 database mapping information and stops registering EID=. 310 * Any ITR or PiTR participating in the L3 overlay (corresponding to 311 IID1) that were sending traffic to 1.0.0.1 before the migration 312 keep sending traffic to ETR A. 314 * Once ETR A is notified by the Mapping system, when it receives 315 traffic from an ITR with destination 1.0.0.1, it generates a 316 Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=. 319 * Upon receiving the SMR the ITR invalidates its local map- cache 320 entry for EID= and sends a new Map-Request for that 321 EID. The Map-Reply includes the new EID-to-RLOC mapping for End- 322 Device 1 with RLOC=IP_D. 324 * Similarly, once the local database mapping is removed from ITR A, 325 non-encapsulated packets arriving at ITR A from a local End-Device 326 and destined to End-Device 1 result in a cache miss, which 327 triggers sending a Map-Request for EID= to populate 328 the map-cache of ITR A. 330 4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms 332 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 333 the flow of signaling to achieve EID mobility is modified. In this 334 case, when an local end-device connected via an ITR establishes 335 communication with a remote mobile end-device (connected to a remote 336 ETR), the ITR will issue a Map-Request for the mobile end-device. 337 Following the Mapping Request Subscribe Procedures defined in 338 [I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit 339 set on the EID-Record so that the ITR is notified of any RLOC-set 340 changes for the mobile EID-prefix. 342 The following is a sequence description of the packet flow when End- 343 Device 1 in the reference figure roams to site D. This sequence 344 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 346 * When an end-Device connected via an ITR establishes communication 347 with a mobile end-device (e.g. end-device 1), the ITR will issue a 348 Map-Request for the mobile end-device. Following the Mapping 349 Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], 350 the Map-request will be issued with the N-bit set on the EID- 351 Record so that the ITR is notified of any RLOC-set changes for the 352 mobile EID-prefix. 354 * When the mobile end-device (End-Device 1) is attached or detected 355 in a new site (e.g. site D), The ETR at the new site (e.g. ETR D) 356 sets up the database mapping corresponding to the EID of the 357 mobile end-device (e.g. EID=). The ETR at the new 358 site (e.g. ETR D) sends a Map-Register to the mapping system 359 registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of 360 the mobile end-device (e.g. EID=). Now the 361 mapping system is updated with the new EID-to-RLOC mapping 362 (location) for the mobile end-device (e.g. End-Device 1). 364 * The Mapping System, after receiving the new registration for the 365 EID of the mobile end-device (EID=) sends a Map- 366 Notify to the departure site (ETR A) to inform it of the move. 367 Then, the ETR at the departure site (ETR A) removes its local 368 database mapping information and stops registering the EID for the 369 mobile end-device (EID=). 371 * Any ITR or PiTR participating in the L3 overlay (corresponding to 372 IID1) that were sending traffic to the mobile end-device (1.0.0.1) 373 would have Subscribed to receive notifications of any changes in 374 the RLOC-set for the EID of the mobile end-device (1.0.0.1). The 375 Mapping System publishes the updated RLOC-set to the Subscribed 376 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 377 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 379 * Upon receiving the Map-Notify message, the ITR updates the RLOC- 380 set in its local map-cache entry for the EID of the mobile end- 381 device (EID=). Once the map-cache is updated, 382 traffic is tunneled by the ITR to the new location. 384 4.2. Implementation Considerations 386 4.2.1. L3 Segmentation 388 LISP support of segmentation and multi-tenancy is structured around 389 the propagation and use of Instance-IDs, and handled as part of the 390 EID in control plane operations. The encoding is described in 391 [RFC8060] and its use in [RFC8111]. 393 Instance-IDs can be used to support L3 overlay segmentation, such as 394 in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]). 396 4.2.2. L3 Database-Mappings 398 When an end-host is attached or detected in an ETR that provides 399 L3-overlay services and mobility, a database Mapping is registered to 400 the mapping system with the following structure: 402 * The EID 2-tuple (IID, IP) with its binding to a corresponding ETR 403 locator set (IP RLOC) 405 The registration of these EIDs MUST follow the LCAF format as defined 406 in [RFC8060] and the specific EID record to be used is illustrated in 407 the following figure: 409 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | Record TTL | 411 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 E | Locator Count | EID mask-len | ACT |A| Reserved | 413 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 D | Rsvd | Map-Version Number | AFI = 16387 | 415 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 417 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 c | 4 + n | Instance-ID... | 419 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 r | ...Instance-ID | EID-AFI = 1 or 2 | 421 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | EID-Prefix (IPv4 or IPv6) | 423 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | /| Priority | Weight | M Priority | M Weight | 425 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | o | Unused Flags |L|p|R| Loc-AFI | 427 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | \| Locator | 429 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The L3 EID record follows the structure as described in 432 [I-D.ietf-lisp-rfc6833bis]. 434 4.2.3. LISP Mapping System support 436 The interface between the xTRs and the Mapping System is described in 437 [I-D.ietf-lisp-rfc6833bis] and this document follows the 438 specification as described there. When available, the registrations 439 MAY be implemented over a reliable transport as described in 440 [I-D.kouvelas-lisp-map-server-reliable-transport]. 442 In order to support system convergence after mobility, when the Map- 443 Server receives a new registration for a specific EID, it MUST send a 444 Map-Notify to the entire RLOC set in the site that last registered 445 this same EID. This Map-Notify is used to track moved-away state of 446 L3 EIDs as described in Section 4.2.4. 448 4.2.4. Using SMRs to Track Moved-Away Hosts 450 One of the key elements to support end-host mobility using the LISP 451 architecture is the Solicit-Map-Request (SMR). This is a special 452 message by means of which an ETR can request an ITR to send a new 453 Map-Request for a particular EID record. In essence the SMR message 454 is used as a signal to indicate a change in mapping information and 455 it is described in [I-D.ietf-lisp-rfc6833bis]. 457 In order to support mobility, an ETR SHALL maintain a list of EID 458 records for which it has to generate a SMR message whenever it 459 receives traffic with that EID as destination. 461 The particular strategy to maintain an Away Table is implementation 462 specific and it will be typically based on the strategy to detect the 463 presence of hosts and the use of Map-Notify messages received from 464 the Map-Server. In essence the table SHOULD provide support to the 465 following: 467 * Keep track of end-hosts that were once connected to an ETR and 468 have moved away. 470 * Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR 471 message SHOULD be generated. 473 4.2.5. L3 multicast support 475 L3 Multicast traffic on the overlay MAY be supported by either 476 replicated unicast, or underlay (RLOC) multicast. Specific solutions 477 to support L3 multicast over LISP controlled overlays are specified 478 in in [RFC6831], and [RFC8378]. 480 4.2.6. Time-to-Live Handling in Data-Plane 482 The LISP specification ([I-D.ietf-lisp-rfc6830bis]) describes how to 483 handle Time-to-Live values of the inner and outer headers during 484 encapsulation and decapsulation of packets when using the L3 overlay. 486 5. L2 Overlays and Mobility Support 488 5.1. Reference Architecture and packet flows 490 In order to support L2 packet flow descriptions in this section we 491 use Figure 1 as reference. This section uses Sites B and C to 492 describe the flows. 494 / | | \ 495 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 496 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 497 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 498 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 499 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 500 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 501 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 502 / '--' | '--' | '--' \ '--' 503 '--------' '--------' '--------' '--------' 504 : End : : End : : End : : End : 505 :Device 1: :Device 2: :Device 3: :Device 4: 506 '--------' '--------' '--------' '--------' 507 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 508 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 510 Figure 3: Reference Mobility Architecture 512 5.1.1. Bridged Traffic Flow: L2 Overlay use 514 Bridged traffic is encapsulated using the L2 overlay. This section 515 provides an example of the unicast packet flow and the control plane 516 operations when in the topology shown in Figure 1, the End-Device 2 517 in site B communicates with the End-Device 3 in site C. In this case 518 we assume that End Device 2, knows the MAC address of End-Device 3 519 (e.g., learned through ARP). 521 * End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination 522 0:0:3:0:0:3 and source 0:0:3:0:0:2. 524 * ITR B does a L2 lookup in its local map-cache for the destination 525 MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the 526 ITR sends a Map-Request to the mapping database system looking up 527 for EID=. 529 * The mapping systems forwards the Map-Request to ETR C, that has 530 registered the EID-to-RLOC mapping for EID=. 531 Alternatively, depending on the mapping system configuration, a 532 Map-Server which is part of the mapping database system MAY send a 533 Map-Reply directly to ITR B. 535 * ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC 536 mapping: EID= -> RLOC=IP_C, where IP_C is the 537 locator of ETR C. 539 * ITR B populates the local map-cache with the EID to RLOC mapping, 540 and encapsulates all subsequent packets with a destination MAC 541 0:0:3:0:0:3 using destination RLOC=IP_C. 543 5.1.2. L2 Mobility Flow 545 The support to L2 mobility covers the requirements to allow an end- 546 host to move from a given site to another and maintain correspondence 547 with the rest of end-hosts that are connected to the same L2 domain 548 (e.g. extended VLAN). This support MUST ensure convergence of L2 549 forwarding (MAC based) from the old location to the new one, when the 550 host completes its move. 552 The update of the ITR map-caches when EIDs move MAY be achieved using 553 Data Driven SMRs or the Publish/Subscribe mechanisms defined in 554 [I-D.ietf-lisp-pubsub]. The following two sections are sequence 555 descriptions of the packet flow when End-Device 2 in the reference 556 figure roams to site C, which is extending its own subnet network. 558 5.1.2.1. L2 Mobility Flow using Data Driven SMRs 560 The following is a sequence description of the packet flow when End- 561 Device 2 in the reference figure roams to site C. This sequence uses 562 Data Driven SMRs to trigger the updates of the ITR map-caches. 564 * When End-Device 2 is attached or detected in site C, ETR C sets up 565 the database mapping corresponding to EID=. 566 ETR C sends a Map-Register to the mapping system registering 567 RLOC=IP_B as locator for EID=. 569 * The Mapping System, after receiving the new registration for 570 EID= sends a Map-Notify to ETR B with the new 571 locator set (IP_B). ETR B removes then its local database mapping 572 and stops registering . 574 * Any PiTR or ITR participating in the same L2-overlay 575 (corresponding to IID2) that was encapsulating traffic to 576 0:0:3:0:0:2 before the migration continues encapsulating this 577 traffic to ETR B. 579 * Once ETR B is notified by the Mapping system, when it receives 580 traffic from an ITR which is destined to 0:0:3:0:0:2, it will 581 generate a Solicit-Map-Request (SMR) message that is sent to the 582 ITR for (IID2,0:0:3:0:0:2). 584 * Upon receiving the SMR the ITR sends a new Map-Request for the 585 EID=. As a response ETR B sends a Map-Reply 586 that includes the new EID-to-RLOC mapping for 587 with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 588 replacing the previous one, and traffic is then forwarded to the 589 new location. 591 5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms 593 When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, 594 the flow of signaling to achieve EID mobility is modified. In this 595 case, when an End-Device connected via an ITR establishes 596 communication with a mobile EID-prefix, the ITR will issue a Map- 597 Request for the mobile End-device. Following the Mapping Request 598 Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map- 599 request will be issued with the N-bit set on the EID-Record so that 600 the ITR is notified of any RLOC-set changes for the mobile EID- 601 prefix. 603 The following is a sequence description of the packet flow when End- 604 Device 2 in the reference figure roams to site C. This sequence 605 leverages Publish/Subscribe mechanisms to update the ITR map-caches. 607 * When End-Device 2 is attached or detected in site C, ETR C sets up 608 the database mapping corresponding to EID=. 609 ETR C sends a Map-Register to the mapping system registering 610 RLOC=IP_B as locator for EID=. 612 * The Mapping System, after receiving the new registration for 613 EID= sends a Map-Notify to the departure site 614 (ETR B) with the new locator set (IP_B). ETR B removes then its 615 local database mapping and stops registering . 617 * Any ITR or PiTR participating in the same L2-overlay 618 (corresponding to IID2) that was encapsulating traffic to 619 0:0:3:0:0:2 before the migration would have Subscribed to receive 620 notifications of any changes in the RLOC-set for 0:0:3:0:0:2. The 621 Mapping System publishes the updated RLOC-set to the Subscribed 622 ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping 623 Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. 625 * Upon receiving the Map-Notify message, the ITR updates the RLOC- 626 set in its local map-cache entry for EID=. 627 Once the map-cache is updated, traffic is tunneled by the ITR to 628 the new location. 630 5.2. Implementation Considerations 631 5.2.1. L2 Segmentation 633 As with L3 overlays, LISP support of L2 segmentation is structured 634 around the propagation and use of Instance-IDs, and handled as part 635 of the EID in control plane operations. The encoding is described in 636 [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a 637 Mapping System and MAY be used to identify the overlay type (e.g., L2 638 or L3 overlay). 640 An Instance-ID can be used for L2 overlay segmentation. An important 641 aspect of L2 segmentation is the mapping of VLANs to IIDs. In this 642 case a Bridge Domain (which is the L2 equivalent to a VRF as a 643 forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge 644 domain or different VLAN-IDs on different ports may map to a common 645 Bridge Domain, which in turn maps to an IID in the L2 overlay. When 646 ethernet traffic is double tagged, usually the outer 802.1Q tag will 647 be mapped to a bridge domain on a per port basis, and the inner 648 802.1Q tag will remain part of the payload to be handled by the 649 overlay. The IID should therefore be able to carry ethernet traffic 650 with or without an 802.1Q header. A port may also be configured as a 651 trunk and we may chose to take the encapsulated traffic and map it to 652 a single IID in order to multiplex traffic from multiple VLANs on a 653 single IID. These are all examples of local operations that could be 654 effected on VLANs in order to map them to IIDs, they are provided as 655 examples and are not exhaustive. 657 5.2.2. L2 Database-Mappings 659 When an end-host is attached or detected in an ETR that provides 660 L2-overlay services, a database Mapping is registered to the mapping 661 system with the following structure: 663 * The EID 2-tuple (IID, MAC) with its binding to a locator set (IP 664 RLOC) 666 The registration of these EIDs MUST follow the LCAF format as defined 667 in [RFC8060] and as illustrated in the following figure: 669 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | | Record TTL | 671 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 E | Locator Count | EID mask-len | ACT |A| Reserved | 673 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 D | Rsvd | Map-Version Number | AFI = 16387 | 675 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 677 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 c | 4 + n | Instance-ID... | 679 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 r | ...Instance-ID | EID-AFI = 6 | 681 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | | Layer-2 MAC Address ... | 683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | /| ... Layer-2 MAC Address | Priority | Weight | 685 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | o | M Priority | M Weight | Unused Flags |L|p|R| 687 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | | | Loc-AFI | Locator.... | 689 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | \| ... Locator 691 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 The L2 EID record follows the structure as described in 694 [I-D.ietf-lisp-rfc6833bis]. 696 5.2.3. Interface to the LISP Mapping System 698 The interface between the xTRs and the Mapping System is described in 699 [I-D.ietf-lisp-rfc6833bis] and this document follows the 700 specification as described there. When available, the registrations 701 MAY be implemented over a reliable transport. 703 In order to support system convergence after mobility, when the Map- 704 Server receives a new registration for a specific EID, it MUST send a 705 Map-Notify to the entire RLOC set in the site that last registered 706 this same EID. This Map-Notify is used to track moved-away state of 707 L2 EIDs as described in Section 5.2.4. 709 5.2.4. SMR support to track L2 hosts that moved away 711 In order to support mobility, an ETR SHALL maintain a list of EID 712 records for which it has to generate a SMR message whenever it 713 receives traffic with that EID as destination. 715 The particular strategy to maintain a SMR table is implementation 716 specific. In essence the table SHOULD provide support for the 717 following: 719 * Keep track of end-hosts that were once connected to an ETR and 720 have moved away. 722 * Support for L2 EID records, the 2-tuple (IID, MAC), for which a 723 SMR message SHOULD be generated. 725 5.2.5. L2 Broadcast and Multicast traffic 727 Broadcast and Multicast traffic on the L2-overlay is supported by 728 either replicated unicast, or underlay (RLOC) multicast. 730 xTRs that offer L2 overlay services and are part of the same 731 Instance-ID join a common Multicast Group. When required, this group 732 allows ITRs to send traffic that needs to be replicated (flooded) to 733 all ETRs participating in the L2-overlay (e.g., broadcast traffic 734 within a subnet). When the core network (RLOC space) supports native 735 multicast ETRs participating in the L2-overlay join a (*,G) group 736 associated to the Instance-ID. 738 When multicast is not available in the core network, each xTR that is 739 part of the same instance-ID SHOULD register a (S,G) entry to the 740 mapping system using the procedures described in [RFC8378], where S 741 is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows 742 and ITR to know which ETRs are part of the L2 overlay and it can 743 head-end replicate traffic to. 745 Following the same case, when multicast is not available in the core 746 network, the procedures in [RFC8378] can be used to ensure proper 747 distribution of link-local multicast traffic across xTRs 748 participating in the L2 overlay. In such case, the xTRs SHOULD join 749 a (S,G) entry with S being 0000-0000-0000/0 and where G is 750 0100-0000-0000/8. 752 5.2.6. L2 Unknown Unicast Support 754 An ITR attempts to resolve MAC destination misses through the Mapping 755 System. When the destination host remains undiscovered the 756 destination is considered an Unknown Unicast. 758 A Map-Server SHOULD respond to a Map-Request for an undiscovered host 759 with a Negative Map-Reply with action "Native Forward". 760 Alternatively the action "Drop" may be used in order to suppress 761 Unknown Unicast forwarding. 763 An ITR that receives a Negative Map-Reply with Action "Native 764 Forward" will handle traffic for the undiscovered host as L2 765 Broadcast traffic and will be unicast replicated or flooded using 766 underlay multicast to the rest of ETRs in the Layer-2 overlay. 768 Upon discovery of a previously unknown unicast MAC EID, a data 769 triggered SMR for the discovered EID should be sent by the discovery 770 ETR back to the ITRs that are flooding the unknown unicast traffic. 771 This would allow ITRs to refresh their caches and stop flooding 772 unknown unicast traffic as necessary. 774 5.2.7. Time-to-Live Handling in Data-Plane 776 When using a L2 overlay and the encapsulated traffic is IP traffic, 777 the Time-to-Live value of the inner IP header MUST remain unmodified 778 during encapsulation and decapsulation. Network hops traversed as 779 part of the L2 overlay SHOULD be hidden to tools like traceroute and 780 applications that require direct L2 connectivity. 782 5.3. Support to ARP resolution through Mapping System 784 5.3.1. Map-Server support to ARP resolution: Packet Flow 786 A large majority of applications are IP based and, as a consequence, 787 end systems are typically provisioned with IP addresses as well as 788 MAC addresses. 790 In this case, to limit the flooding of ARP traffic and reduce the use 791 of multicast in the RLOC network, the LISP mapping system MAY be used 792 to support ARP resolution at the ITR. 794 In order to provide this support, ETRs handle and register an 795 additional EID-to-RLOC mapping as follows, 797 * EID-record contents = , RLOC-record contents . 799 There is a dedicated IID used for the registration of the ARP/ND 800 related mappings. Thus, a system with L2 and L3 overlays as well as 801 ARP/ND mappings would have three IIDs at play. In the spirit of 802 providing clarity, we will refer to those IIDs as L2-IID, L3-IID and 803 ARP-IID respectively. By using these definitions, we do not intend 804 to coin new terminology, nor is there anything special about those 805 IIDs that would make them differ from the generic definition of an 806 IID. The types of mappings expected in such a system are summarized 807 below: 809 * EID = to RLOC = (L3-overlay) 810 * EID = to RLOC = (L2-overlay) 812 * EID = to RLOC = (ARP/ND mapping) 814 The following packet flow sequence describes the use of the LISP 815 Mapping System to support ARP resolution for hosts residing in a 816 subnet that is extended to multiple sites. Using Figure 1, End- 817 Device 2 tries to find the MAC address of End-Device 3. Note that 818 both have IP addresses within the same subnet: 820 * End-Device 2 sends a broadcast ARP message to discover the MAC 821 address of End-Device 3. The ARP request targets IP 3.0.0.3. 823 * ITR B receives the ARP message, but rather than flooding it on the 824 overlay network sends a Map-Request to the mapping database system 825 for EID = . 827 * When receiving the Map-Request, the Map-Server sends a Proxy-Map- 828 Reply back to ITR B with the mapping EID = -> MAC 829 0:0:3:0:0:3. 831 * Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 832 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 834 * End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 835 now send a L2 traffic to End-Device 3. When this traffic reaches 836 ITR B is sent over the L2-overlay as described above in 837 Section 5.1.1. 839 This example shows how LISP, by replacing dynamic data plane learning 840 (such as Flood-and-Learn) can reduce the use of multicast in the 841 underlay network. 843 Note that ARP resolution using the Mapping System is a stateful 844 operation on the ITR. The source IP,MAC tuple coming from the ARP 845 request have to be stored to generate the ARP-reply when the Map- 846 Reply is received. 848 Note that the ITR SHOULD cache the ARP entry. In that case future 849 ARP-requests can be handled without sending additional Map-Requests. 851 5.3.2. ARP registrations: MAC as a locator record 853 When an end-host is attached or detected in an ETR that provides 854 L2-overlay services and also supports ARP resolution using the LISP 855 control-plane, an additional mapping entry is registered to the 856 mapping system: 858 * The EID 2-tuple (IID, IP) and its binding to a corresponding host 859 MAC address. 861 In this case both the xTRs and the Mapping System MUST support an 862 EID-to-RLOC mapping where the MAC address is set as a locator record. 864 In order to guarantee compatibility with current implementations of 865 xTRs, the MAC locator record SHALL be encoded following the AFI-List 866 LCAF Type defined in [RFC8060]. This option would also allow adding 867 additional attributes to the locator record, while maintaining 868 compatibility with legacy devices. 870 This mapping is registered with the Mapping System using the 871 following EID record structure, 873 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | | Record TTL | 875 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 E | Locator Count | EID mask-len | ACT |A| Reserved | 877 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 D | Rsvd | Map-Version Number | AFI = 16387 | 879 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 881 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 c | 4 + n | Instance-ID... | 883 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 r | ...Instance-ID | EID-AFI = 1 or 2 | 885 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | | EID-Prefix (IPv4 or IPv6) | 887 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | /| Priority | Weight | M Priority | M Weight | 889 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | M | Unused Flags |L|p|R| AFI = 16387 | 891 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 893 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | | 2 + 6 | AFI = 6 | 895 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | | | Layer-2 MAC Address ... | 897 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | \| ... Layer-2 MAC Address | 899 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 901 An EID record with a locator record that carries a MAC address 902 follows the same structure as described in 903 [I-D.ietf-lisp-rfc6833bis]. However, some fields of the EID record 904 and the locator record require special consideration: 906 Locator Count: This value SHOULD be set to 1. 908 Instance-ID: This is the IID used to provide segmentation of the 909 L2-overlays, L3 overlays and ARP tables. 911 Priority and Weight: IP to MAC bindings are one to one bindings. An 912 ETR SHOULD not register more than one MAC address in the locator 913 record together with an IP based EID. The Priority of the MAC 914 address record is set to 255. The Weight value SHOULD be ignored 915 and the recommendation is to set it to 0. 917 L bit: This bit of the locator record SHOULD only be set to 1 when 918 an ETR is registering its own IP to MAC binding. 920 p bit: This bit of the locator record SHOULD be set to 0. 922 R bit: This bit of the locator record SHOULD be set to 0. 924 Note that an IP EID record that carries a MAC address in the locator 925 record, SHALL be registered with the Proxy Map-Reply bit set. 927 5.3.3. Implementation Considerations 929 While ARP support through the LISP Mapping System fits the LISP 930 Control-Plane there are a series of considerations to take into 931 account when providing this feature: 933 * As indicated, when and end-host is attached the ETR maintains and 934 registers a mapping with the binding EID = -> RLOC = 935 . 937 * ARP support through the LISP Mapping System is OPTIONAL and the 938 xTRs should allow the possibility to enable or disable the 939 feature. 941 * When the ARP entry has not been registered, a Map Server SHOULD 942 send a Negative Map-Reply with action "No Action" as a response to 943 an ARP based Map Request. 945 * In case the ITR receives a Negative Map-Reply for an ARP request 946 it should fallback to flooding the ARP packet as any other L2 947 Broadcast packet (as described in Section 5.2.5). 949 * When receiving a positive Map-Reply for an ARP based Map-Request, 950 the ETR MUST recreate the actual ARP Reply, impersonating the real 951 host. As a consequence, ARP support is a stateful operation where 952 the ITR needs to store enough information about the host that 953 generates an ARP request in order to recreate the ARP Reply. 955 * ARP replies learned from the Mapping System SHOULD be cached and 956 the information used to reply to subsequent ARP requests to the 957 same hosts. 959 6. Optional Deployment Models 961 The support of an integrated L2 and L3 overlay solution takes 962 multiple architectural design options, that depend on the specific 963 requirements of the deployment environment. While some of the 964 previous describe specific packet flows and solutions based on the 965 recommended solution, this section documents OPTIONAL design 966 considerations that differ from the recommended one but that MAY be 967 required on alternative deployment environments. 969 6.1. IP Forwarding of Intra-subnet Traffic 971 As pointed out at the beginning the recommended selection of the L2 972 and L3 overlays is not the only one possible. In fact, providing L2 973 extension to some cloud platforms is not always possible and subnets 974 need to be extended using the L3 overlay. 976 In order to send all IP traffic (intra- and inter-subnet) through the 977 L3 overlay the solution MUST change the ARP resolution process 978 described in Section 5.3.1 to the following one (we follow again 979 Figure 1 to drive the example. End-Device 2 queries about End-Device 980 3): 982 * End-Device 1 sends a broadcast ARP message to discover the MAC 983 address of 3.0.0.3. 985 * ITR B receives the ARP message and sends a Map-Request to the 986 Mapping System for EID = . 988 * In this case, the Map-Request is routed by the Mapping system 989 infrastructure to ETR C, that will send a Map-Reply back to ITR B 990 containing the mapping EID = -> RLOC=IP_C. 992 * ITR B populates its local cache with the received entry on the L3 993 forwarding table. Then, using the cache information it sends a 994 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 995 Device 1. 997 * End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 998 traffic with destination address 3.0.0.3 and destination MAC, 999 MAC_xTR_B. 1001 * As the destination MAC address is the one from xTR B, when xTR B 1002 receives this traffic it is forwarded using the L3-overlay. 1004 * Note that when implementing this solution, when a host that is 1005 local to an ETR moves away, the ETR SHOULD locally send a 1006 Gratuitous ARP with its own MAC address and the IP of the moved 1007 host, to refresh the ARP tables of local hosts and guarantee the 1008 use of the L3 overlay when connecting to the remote host. 1010 It is also important to note that using this strategy to extend 1011 subnets through the L3 overlay but still keeping the L2 overlay for 1012 the rest of traffic MAY lead to flow asymmetries. This MAY be the 1013 case in deployments that filter Gratuitous ARPs, or when moved hosts 1014 continue using actual L2 information collected before a migration. 1016 6.2. Data-plane Encapsulation Options 1018 The LISP control-plane offers independence from the data-plane 1019 encapsulation. Any encapsulation format that can carry a 24-bit 1020 instance-ID can be used to provide the unified overlay. 1022 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 1023 and [VXLAN]: 1025 * VXLAN-GPE encap: This encapsulation format is defined in 1026 [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 1027 packets and the VNI field directly maps to the Instance-ID used in 1028 the control plane. Note that when using this encapsulation for a 1029 unified solution the P-bit is set and the Next-Protocol field is 1030 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 1031 L3-overlays, and value 0x3 in L2-overlays). 1033 * LISP encap: This is the encapsulation format defined in the LISP 1034 specification [I-D.ietf-lisp-rfc6830bis]. The encapsulation 1035 allows encapsulating both L2 and L3 packets. The Instance-ID used 1036 in the EIDs directly maps to the Instance-ID that the LISP header 1037 carries. At the ETR, after decapsulation, the IID MAY be used to 1038 decide between L2 processing or L3 processing. 1040 * VXLAN encap: This is a L2 encapsulation format defined in 1041 [RFC7348]. While being a L2 encapsulation it can be used both for 1042 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 1043 to the VNI field of the VXLAN header. Providing L3 overlays using 1044 VXLAN generally requires using the ETR MAC address as destination 1045 MAC address of the inner Ethernet header. The process to learn or 1046 derive this ETR MAC address is not included as part of this 1047 document. 1049 7. IANA Considerations 1051 This memo includes no request to IANA. 1053 8. Acknowledgements 1055 This draft builds on top of two expired drafts that introduced the 1056 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 1057 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 1058 combined authors of those drafts, that SHOULD be considered main 1059 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 1060 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 1061 Smith. 1063 9. References 1065 9.1. Normative References 1067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1068 Requirement Levels", BCP 14, RFC 2119, 1069 DOI 10.17487/RFC2119, March 1997, 1070 . 1072 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1073 Locator/ID Separation Protocol (LISP)", RFC 6830, 1074 DOI 10.17487/RFC6830, January 2013, 1075 . 1077 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1078 Locator/ID Separation Protocol (LISP) for Multicast 1079 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1080 2013, . 1082 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1083 Protocol (LISP) Map-Server Interface", RFC 6833, 1084 DOI 10.17487/RFC6833, January 2013, 1085 . 1087 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1088 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1089 eXtensible Local Area Network (VXLAN): A Framework for 1090 Overlaying Virtualized Layer 2 Networks over Layer 3 1091 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1092 . 1094 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1095 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1096 February 2017, . 1098 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1099 Smirnov, "Locator/ID Separation Protocol Delegated 1100 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1101 May 2017, . 1103 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1104 Separation Protocol (LISP) Multicast", RFC 8378, 1105 DOI 10.17487/RFC8378, May 2018, 1106 . 1108 9.2. Informative References 1110 [I-D.ietf-lisp-gpe] 1111 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 1112 Smith, "LISP Generic Protocol Extension", Work in 1113 Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July 1114 2020, . 1117 [I-D.ietf-lisp-pubsub] 1118 Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, 1119 S., and M. Boucadair, "Publish/Subscribe Functionality for 1120 LISP", Work in Progress, Internet-Draft, draft-ietf-lisp- 1121 pubsub-09, 28 June 2021, . 1124 [I-D.ietf-lisp-rfc6830bis] 1125 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1126 Cabellos, "The Locator/ID Separation Protocol (LISP)", 1127 Work in Progress, Internet-Draft, draft-ietf-lisp- 1128 rfc6830bis-36, 18 November 2020, 1129 . 1132 [I-D.ietf-lisp-rfc6833bis] 1133 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1134 "Locator/ID Separation Protocol (LISP) Control-Plane", 1135 Work in Progress, Internet-Draft, draft-ietf-lisp- 1136 rfc6833bis-30, 18 November 2020, 1137 . 1140 [I-D.ietf-lisp-vpn] 1141 Moreno, V. and D. Farinacci, "LISP Virtual Private 1142 Networks (VPNs)", Work in Progress, Internet-Draft, draft- 1143 ietf-lisp-vpn-08, 18 January 2022, 1144 . 1147 [I-D.kouvelas-lisp-map-server-reliable-transport] 1148 Leong, J., Lewis, D., Pitta, B., Cassar, C., Kouvelas, I., 1149 and J. Arango, "LISP Map Server Reliable Transport", Work 1150 in Progress, Internet-Draft, draft-kouvelas-lisp-map- 1151 server-reliable-transport-07, 18 January 2022, 1152 . 1155 Authors' Addresses 1157 Marc Portoles Comeras 1158 Cisco Systems 1159 170 Tasman Drive 1160 San Jose, CA 95134 1161 United States of America 1163 Email: mportole@cisco.com 1165 Vrushali Ashtaputre 1166 Cisco Systems 1167 170 Tasman Drive 1168 San Jose, CA 95134 1169 United States of America 1171 Email: vrushali@cisco.com 1173 Fabio Maino 1174 Cisco Systems 1175 170 Tasman Drive 1176 San Jose, CA 95134 1177 United States of America 1179 Email: fmaino@cisco.com 1181 Victor Moreno 1182 Google LLC 1183 1600 Amphitheatre Pkwy 1184 Mountain View, CA 94043 1185 United States of America 1187 Email: vimoreno@google.com 1188 Dino Farinacci 1189 lispers.net 1190 San Jose, CA 1191 United States of America 1193 Email: farinacci@gmail.com