idnits 2.17.1 draft-ietf-lisp-eid-mobility-02.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 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Priority and Weight: IP to MAC bindings are one to one bindings. An ETR SHOULD not register more than one MAC address in the locator record together with an IP based EID. The Priority of the MAC address record is set to 255. The Weight value SHOULD be ignored and the recommendation is to set it to 0. -- The document date (May 14, 2018) is 2167 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 904, but not defined == Missing Reference: 'VXLAN' is mentioned on line 905, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 904, 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 (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-04 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Portoles 3 Internet-Draft V. Ashtaputre 4 Intended status: Experimental V. Moreno 5 Expires: November 15, 2018 F. Maino 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 May 14, 2018 11 LISP L2/L3 EID Mobility Using a Unified Control Plane 12 draft-ietf-lisp-eid-mobility-02 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, as well as analyzing possible deployment options 20 and models. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 15, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 64 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 65 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 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.2. Implementation Considerations . . . . . . . . . . . . . . 7 70 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7 71 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8 72 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8 73 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9 74 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9 75 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9 76 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9 77 5.1. Reference Architecture and packet flows . . . . . . . . . 9 78 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10 79 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11 80 5.2. Implementation Considerations . . . . . . . . . . . . . . 11 81 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 11 82 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12 83 5.2.3. Interface to the LISP Mapping System . . . . . . . . 13 84 5.2.4. SMR support to track L2 hosts that moved away . . . . 13 85 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14 86 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14 87 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15 88 5.3. Support to ARP resolution through Mapping System . . . . 15 89 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15 90 5.3.2. ARP registrations: MAC as a locator record . . . . . 16 91 5.3.3. Implementation Considerations . . . . . . . . . . . . 18 92 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 19 93 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 19 94 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 20 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 9.2. Informative References . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 This document describes the architecture and design options required 105 to offer a unified L2 and L3 overlay solution with mobility using the 106 LISP control-plane. 108 The architecture takes advantage of the flexibility that LISP 109 provides to simultaneously support different overlay types. While 110 the LISP specification defines both the data-plane and the control- 111 plane, this document focuses on the use of the control-plane to 112 provide L2 and L3 overlay services with mobility. The control plane 113 may be combined with a data-plane of choice e.g., [LISP], [VXLAN- 114 GPE], or [VXLAN]. 116 The recommendation on whether a flow is sent over the L2 or the L3 117 overlay is based on whether the traffic is bridged (intra-subnet or 118 non-IP) or routed (inter-subnet), respectively. This allows treating 119 both overlays as separate segments, and enables L2-only and L3-only 120 deployments (and combinations of them) without modifying the 121 architecture. 123 The unified solution for L2 and L3 overlays offers the possibility to 124 extend subnets and routing domains (as required in state-of-art 125 Datacenter and Enterprise architectures) with mobility support and 126 traffic optimization. 128 An important use-case of the unified architecture is that, while most 129 data centers are complete layer-3 routing domains, legacy 130 applications either have not converted to IP or still use auto- 131 discovery at layer-2 and assume all nodes in an application cluster 132 belong to the same subnet. For these applications, the L2-overlay 133 limits the functionality to where the legacy app lives versus having 134 to extend layer-2 into the network. 136 Broadcast, Unknown and Multicast traffic on the overlay are supported 137 by either replicated unicast, or underlay (RLOC) multicast as 138 specified in [RFC6831] and [RFC8378]. 140 2. Definition of Terms 142 LISP related terms are defined as part of the LISP specification 143 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 144 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 145 (MS) and Map-Resolver (MR). 147 3. Reference System 149 The following figure illustrates the reference system used to support 150 the packet flow description throughout this document. The system 151 presents 4 sites. Site A and Site D provide access to different 152 subnets (non-extended), while Site B and Site C extend a common 153 subnet. The xTR in each one of the sites registers EIDs from the 154 sites with the LISP Mapping System and provides support to 155 encapsulate overlay (EID) traffic through the underlay (RLOC space). 157 ,-------------. 158 (Mapping System ) 159 -+------------+ 160 +--+--+ +-+---+ 161 |MS/MR| |MS/MR| 162 +-+---+ +-----+ 163 .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-. 164 .-.' '.-. 165 ( L3 Underlay ) 166 ( (RLOC Space) ) 167 '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.' 168 / | | \ 169 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 170 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 171 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 172 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 173 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 174 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 175 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 176 / '--' | '--' | '--' \ '--' 177 '--------' '--------' '--------' '--------' 178 : End : : End : : End : : End : 179 :Device 1: :Device 2: :Device 3: :Device 4: 180 '--------' '--------' '--------' '--------' 181 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 182 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 184 Figure 1: Reference System Architecture with unified L2 and L3 185 overlays 187 The recommended selection between the use of L2 and L3 overlays is to 188 map them to bridged (intra-subnet or non-IP) and routed (inter- 189 subnet) traffic. The rest of the document follows this 190 recommendation to describe the packet flows. 192 However, note that in a different selection approach, intra-subnet 193 traffic MAY also be sent over the L3 overlay. Section 6.1 specifies 194 the changes needed to send all IP traffic using the L3 overlay and 195 restricting the use of the L2 overlay to non-IP traffic. 197 When required, the control plane makes use of two basic types of EID- 198 to-RLOC mappings associated to end-hosts and in order to support the 199 unified architecture: 201 o EID = to RLOC=. This is used to support the L2 202 overlay. 204 o EID = to RLOC=. This is the traditional mapping as 205 defined in the original LISP specification and supports the L3 206 overlay. 208 4. L3 Overlays and Mobility Support 210 4.1. Reference Architecture and packet flows 212 In order to support the packet flow descriptions in this section we 213 use Figure 1 as reference. This section uses Sites A and D to 214 describe the flows. 216 / | | \ 217 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 218 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 219 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 220 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 221 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 222 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 223 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 224 / '--' | '--' | '--' \ '--' 225 '--------' '--------' '--------' '--------' 226 : End : : End : : End : : End : 227 :Device 1: :Device 2: :Device 3: :Device 4: 228 '--------' '--------' '--------' '--------' 229 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 230 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 232 Figure 2: Reference Mobility Architecture 234 4.1.1. Routed Traffic Flow: L3 Overlay use 236 Inter-subnet traffic is encapsulated using the L3 overlay. The 237 process to encapsulate this traffic is the same as described in the 238 original specification [RFC6830]. We describe the packet flow here 239 for completeness 241 The following is a sequence example of the unicast packet flow and 242 the control plane operations when in the topology shown in Figure 1 243 End-Device 1, in LISP site A, wants to communicate with End-Device 4 244 in LISP site D. Note that both end systems reside in different 245 subnets. We'll assume that End-Device 1 knows the EID IP address of 246 End-Device 4 (e.g. it is learned using a DNS service). 248 o End-Device 1 sends an IP packet frame with destination 2.0.0.4 and 249 source 1.0.0.1. As the destination address lies on a different 250 subnet End-Device 1 sends the packet following its routing table 251 to ITR A (e.g., it is its default gateway). 253 o ITR A does a L3 lookup in its local map-cache for the destination 254 IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a 255 Map-request to the mapping database system looking up for 256 EID=. 258 o The mapping systems forwards the Map-Request to ETR D, that has 259 registered the EID-to-RLOC mapping of EID=. 261 o ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC 262 mapping: EID= -> RLOC=IP_D, where IP_D is the 263 locator of ETR D. 265 o ITR A populates the local map-cache with the EID to RLOC mapping, 266 and encapsulates all subsequent packets with a destination IP 267 2.0.0.4 using destination RLOC=IP_D. 269 4.1.2. L3 Mobility Flow 271 The support to L3 mobility covers the requirements to allow an end- 272 host to move from a given site to another and maintain correspondence 273 with the rest of end-hosts that are connected to the same L3 routing 274 domain. This support MUST ensure convergence of L3 forwarding (IPv4/ 275 IPv6 based) from the old location to the new one when the host 276 completes its move. 278 The following is a sequence description of the packet flow when End- 279 Device 1 in the reference figure roams to site D: 281 o When End-Device 1 is attached or detected in site D, ETR D sets up 282 the database mapping corresponding to EID=. ETR D 283 sends a Map-Register to the mapping system registering RLOC=IP_D 284 as locator for EID=. Now the mapping system is 285 updated with the new EID-to-RLOC mapping (location) for End-Device 286 1. 288 o The Mapping System, after receiving the new registration for 289 EID= sends a Map-Notify to ETR A to inform it of 290 the move. Then, ETR A removes its local database mapping 291 information and stops registering EID=. 293 o Any ITR or PiTR participating in the L3 overlay (corresponding to 294 IID1) that were sending traffic to 1.0.0.1 before the migration 295 keep sending traffic to ETR A. 297 o Once ETR A is notified by the Mapping system, when it receives 298 traffic from an ITR with destination 1.0.0.1, it generates a 299 Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=. 302 o Upon receiving the SMR the ITR invalidates its local map- cache 303 entry for EID= and sends a new Map-Request for that 304 EID. The Map-Reply includes the new EID-to-RLOC mapping for End- 305 Device 1 with RLOC=IP_D. 307 o Similarly, once the local database mapping is removed from ITR A, 308 non-encapsulated packets arriving at ITR A from a local End-Device 309 and destined to End-Device 1 result in a cache miss, which 310 triggers sending a Map-Request for EID= to populate 311 the map-cache of ITR A. 313 4.2. Implementation Considerations 315 4.2.1. L3 Segmentation 317 LISP support of segmentation and multi-tenancy is structured around 318 the propagation and use of Instance-IDs, and handled as part of the 319 EID in control plane operations. The encoding is described in 320 [RFC8060] and its use in [RFC8111]. 322 Instance-IDs can be used to support L3 overlay segmentation, such as 323 in extended VRFs or multi-VPN overlays. 325 4.2.2. L3 Database-Mappings 327 When an end-host is attached or detected in an ETR that provides 328 L3-overlay services and mobility, a database Mapping is registered to 329 the mapping system with the following structure: 331 o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR 332 locator set (IP RLOC) 334 The registration of these EIDs MUST follow the LCAF format as defined 335 in [RFC8060] and the specific EID record to be used is illustrated in 336 the following figure: 338 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | Record TTL | 340 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 E | Locator Count | EID mask-len | ACT |A| Reserved | 342 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 D | Rsvd | Map-Version Number | AFI = 16387 | 344 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 346 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 c | 4 + n | Instance-ID... | 348 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 r | ...Instance-ID | EID-AFI = 1 or 2 | 350 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | EID-Prefix (IPv4 or IPv6) | 352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | /| Priority | Weight | M Priority | M Weight | 354 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | o | Unused Flags |L|p|R| Loc-AFI | 356 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | \| Locator | 358 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 The L3 EID record follows the structure as described in [RFC6830]. 362 4.2.3. LISP Mapping System support 364 The interface between the xTRs and the Mapping System is described in 365 [RFC6833] and this document follows the specification as described 366 there. When available, the registrations MAY be implemented over a 367 reliable transport as described in 368 [I-D.kouvelas-lisp-map-server-reliable-transport]. 370 In order to support system convergence after mobility, when the Map- 371 Server receives a new registration for a specific EID, it MUST send a 372 Map-Notify to the entire RLOC set in the site that last registered 373 this same EID. This Map-Notify is used to track moved-away state of 374 L3 EIDs as described in Section 4.2.4. 376 4.2.4. Using SMRs to Track Moved-Away Hosts 378 One of the key elements to support end-host mobility using the LISP 379 architecture is the Solicit-Map-Request (SMR). This is a special 380 message by means of which an ETR can request an ITR to send a new 381 Map-Request for a particular EID record. In essence the SMR message 382 is used as a signal to indicate a change in mapping information and 383 it is described with detail in [RFC6830]. 385 In order to support mobility, an ETR SHALL maintain a list of EID 386 records for which it has to generate a SMR message whenever it 387 receives traffic with that EID as destination. 389 The particular strategy to maintain an Away Table is implementation 390 specific and it will be typically based on the strategy to detect the 391 presence of hosts and the use of Map-Notify messages received from 392 the Map-Server. In essence the table SHOULD provide support to the 393 following: 395 o Keep track of end-hosts that were once connected to an ETR and 396 have moved away. 398 o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR 399 message SHOULD be generated. 401 4.2.5. L3 multicast support 403 L3 Multicast traffic on the overlay MAY be supported by either 404 replicated unicast, or underlay (RLOC) multicast. Specific solutions 405 to support L3 multicast over LISP controlled overlays are specified 406 in in [RFC6831], [RFC8378] and [I-D.coras-lisp-re]. 408 4.2.6. Time-to-Live Handling in Data-Plane 410 The LISP specification ([RFC6830]) describes how to handle Time-to- 411 Live values of the inner and outer headers during encapsulation and 412 decapsulation of packets when using the L3 overlay. 414 5. L2 Overlays and Mobility Support 416 5.1. Reference Architecture and packet flows 418 In order to support L2 packet flow descriptions in this section we 419 use Figure 1 as reference. This section uses Sites B and C to 420 describe the flows. 422 / | | \ 423 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 424 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 425 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 426 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 427 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 428 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 429 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 430 / '--' | '--' | '--' \ '--' 431 '--------' '--------' '--------' '--------' 432 : End : : End : : End : : End : 433 :Device 1: :Device 2: :Device 3: :Device 4: 434 '--------' '--------' '--------' '--------' 435 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 436 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 438 Figure 3: Reference Mobility Architecture 440 5.1.1. Bridged Traffic Flow: L2 Overlay use 442 Bridged traffic is encapsulated using the L2 overlay. This section 443 provides an example of the unicast packet flow and the control plane 444 operations when in the topology shown in Figure 1, the End-Device 2 445 in site B communicates with the End-Device 3 in site C. In this case 446 we assume that End Device 2, knows the MAC address of End-Device 3 447 (e.g., learned through ARP). 449 o End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination 450 0:0:3:0:0:3 and source 0:0:3:0:0:2. 452 o ITR B does a L2 lookup in its local map-cache for the destination 453 MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the 454 ITR sends a Map-Request to the mapping database system looking up 455 for EID=. 457 o The mapping systems forwards the Map-Request to ETR C, that has 458 registered the EID-to-RLOC mapping for EID=. 459 Alternatively, depending on the mapping system configuration, a 460 Map-Server which is part of the mapping database system MAY send a 461 Map-Reply directly to ITR B. 463 o ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC 464 mapping: EID= -> RLOC=IP_C, where IP_C is the 465 locator of ETR C. 467 o ITR B populates the local map-cache with the EID to RLOC mapping, 468 and encapsulates all subsequent packets with a destination MAC 469 0:0:3:0:0:3 using destination RLOC=IP_C. 471 5.1.2. L2 Mobility Flow 473 The support to L2 mobility covers the requirements to allow an end- 474 host to move from a given site to another and maintain correspondence 475 with the rest of end-hosts that are connected to the same L2 domain 476 (e.g. extended VLAN). This support MUST ensure convergence of L2 477 forwarding (MAC based) from the old location to the new one, when the 478 host completes its move. 480 The following is a sequence description of the packet flow when End- 481 Device 2 in the figure moves to Site C, which is extending its own 482 subnet network. 484 o When End-Device 2 is attached or detected in site C, ETR C sets up 485 the database mapping corresponding to EID=. 486 ETR C sends a Map-Register to the mapping system registering 487 RLOC=IP_B as locator for EID=. 489 o The Mapping System, after receiving the new registration for 490 EID= sends a Map-Notify to ETR B with the new 491 locator set (IP_B). ETR B removes then its local database mapping 492 and stops registering . 494 o Any PiTR or ITR participating in the same L2-overlay 495 (corresponding to IID2) that was encapsulating traffic to 496 0:0:3:0:0:2 before the migration continues encapsulating this 497 traffic to ETR B. 499 o Once ETR B is notified by the Mapping system, when it receives 500 traffic from an ITR which is destined to 0:0:3:0:0:2, it will 501 generate a Solicit-Map-Request (SMR) message that is sent to the 502 ITR for (IID2,0:0:3:0:0:2). 504 o Upon receiving the SMR the ITR sends a new Map-Request for the 505 EID=. As a response ETR B sends a Map-Reply 506 that includes the new EID-to-RLOC mapping for 507 with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 508 replacing the previous one, and traffic is then forwarded to the 509 new location. 511 5.2. Implementation Considerations 513 5.2.1. L2 Segmentation 515 As with L3 overlays, LISP support of L2 segmentation is structured 516 around the propagation and use of Instance-IDs, and handled as part 517 of the EID in control plane operations. The encoding is described in 518 [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a 519 Mapping System and MAY be used to identify the overlay type (e.g., L2 520 or L3 overlay). 522 An Instance-ID can be used for L2 overlay segmentation. An important 523 aspect of L2 segmentation is the mapping of VLANs to IIDs. In this 524 case a Bridge Domain (which is the L2 equivalent to a VRF as a 525 forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge 526 domain or different VLAN-IDs on different ports may map to a common 527 Bridge Domain, which in turn maps to an IID in the L2 overlay. When 528 ethernet traffic is double tagged, usually the outer 802.1Q tag will 529 be mapped to a bridge domain on a per port basis, and the inner 530 802.1Q tag will remain part of the payload to be handled by the 531 overlay. The IID should therefore be able to carry ethernet traffic 532 with or without an 802.1Q header. A port may also be configured as a 533 trunk and we may chose to take the encapsulated traffic and map it to 534 a single IID in order to multiplex traffic from multiple VLANs on a 535 single IID. These are all examples of local operations that could be 536 effected on VLANs in order to map them to IIDs, they are provided as 537 examples and are not exhaustive. 539 5.2.2. L2 Database-Mappings 541 When an end-host is attached or detected in an ETR that provides 542 L2-overlay services, a database Mapping is registered to the mapping 543 system with the following structure: 545 o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP 546 RLOC) 548 The registration of these EIDs MUST follow the LCAF format as defined 549 in [RFC8060] and as illustrated in the following figure: 551 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | Record TTL | 553 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 E | Locator Count | EID mask-len | ACT |A| Reserved | 555 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 D | Rsvd | Map-Version Number | AFI = 16387 | 557 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 559 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 c | 4 + n | Instance-ID... | 561 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 r | ...Instance-ID | EID-AFI = 6 | 563 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | Layer-2 MAC Address ... | 565 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | /| ... Layer-2 MAC Address | Priority | Weight | 567 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | o | M Priority | M Weight | Unused Flags |L|p|R| 569 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | | Loc-AFI | Locator.... | 571 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | \| ... Locator 573 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The L2 EID record follows the structure as described in [RFC6830]. 577 5.2.3. Interface to the LISP Mapping System 579 The interface between the xTRs and the Mapping System is described in 580 [RFC6833] and this document follows the specification as described 581 there. When available, the registrations MAY be implemented over a 582 reliable transport as described in 583 [I-D.kouvelas-lisp-map-server-reliable-transport]. 585 In order to support system convergence after mobility, when the Map- 586 Server receives a new registration for a specific EID, it MUST send a 587 Map-Notify to the entire RLOC set in the site that last registered 588 this same EID. This Map-Notify is used to track moved-away state of 589 L2 EIDs as described in Section 5.2.4. 591 5.2.4. SMR support to track L2 hosts that moved away 593 In order to support mobility, an ETR SHALL maintain a list of EID 594 records for which it has to generate a SMR message whenever it 595 receives traffic with that EID as destination. 597 The particular strategy to maintain a SMR table is implementation 598 specific. In essence the table SHOULD provide support for the 599 following: 601 o Keep track of end-hosts that were once connected to an ETR and 602 have moved away. 604 o Support for L2 EID records, the 2-tuple (IID, MAC), for which a 605 SMR message SHOULD be generated. 607 5.2.5. L2 Broadcast and Multicast traffic 609 Broadcast and Multicast traffic on the L2-overlay is supported by 610 either replicated unicast, or underlay (RLOC) multicast. 612 xTRs that offer L2 overlay services and are part of the same 613 Instance-ID join a common Multicast Group. When required, this group 614 allows ITRs to send traffic that needs to be replicated (flooded) to 615 all ETRs participating in the L2-overlay (e.g., broadcast traffic 616 within a subnet). When the core network (RLOC space) supports native 617 multicast ETRs participating in the L2-overlay join a (*,G) group 618 associated to the Instance-ID. 620 When multicast is not available in the core network, each xTR that is 621 part of the same instance-ID SHOULD register a (S,G) entry to the 622 mapping system using the procedures described in [RFC8378], where S 623 is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows 624 and ITR to know which ETRs are part of the L2 overlay and it can 625 head-end replicate traffic to. 627 Following the same case, when multicast is not available in the core 628 network, the procedures in [RFC8378] can be used to ensure proper 629 distribution of link-local multicast traffic across xTRs 630 participating in the L2 overlay. In such case, the xTRs SHOULD join 631 a (S,G) entry with S being 0000-0000-0000/0 and where G is 632 0100-0000-0000/8. 634 5.2.6. L2 Unknown Unicast Support 636 An ITR attempts to resolve MAC destination misses through the Mapping 637 System. When the destination host remains undiscovered the 638 destination is considered an Unknown Unicast. 640 A Map-Server SHOULD respond to a Map-Request for an undiscovered host 641 with a Negative Map-Reply with action "Native Forward". 642 Alternatively the action "Drop" may be used in order to suppress 643 Unknown Unicast forwarding. 645 An ITR that receives a Negative Map-Reply with Action "Native 646 Forward" will handle traffic for the undiscovered host as L2 647 Broadcast traffic and will be unicast replicated or flooded using 648 underlay multicast to the rest of ETRs in the Layer-2 overlay. 650 Upon discovery of a previously unknown unicast MAC EID, a data 651 triggered SMR for the discovered EID should be sent by the discovery 652 ETR back to the ITRs that are flooding the unknown unicast traffic. 653 This would allow ITRs to refresh their caches and stop flooding 654 unknown unicast traffic as necessary. 656 5.2.7. Time-to-Live Handling in Data-Plane 658 When using a L2 overlay and the encapsulated traffic is IP traffic, 659 the Time-to-Live value of the inner IP header MUST remain unmodified 660 during encapsulation and decapsulation. Network hops traversed as 661 part of the L2 overlay SHOULD be hidden to tools like traceroute and 662 applications that require direct L2 connectivity. 664 5.3. Support to ARP resolution through Mapping System 666 5.3.1. Map-Server support to ARP resolution: Packet Flow 668 A large majority of applications are IP based and, as a consequence, 669 end systems are typically provisioned with IP addresses as well as 670 MAC addresses. 672 In this case, to limit the flooding of ARP traffic and reduce the use 673 of multicast in the RLOC network, the LISP mapping system MAY be used 674 to support ARP resolution at the ITR. 676 In order to provide this support, ETRs handle and register an 677 additional EID-to-RLOC mapping as follows, 679 o EID-record contents = , RLOC-record contents . 681 There is a dedicated IID used for the registration of the ARP/ND 682 related mappings. Thus, a system with L2 and L3 overlays as well as 683 ARP/ND mappings would have three IIDs at play. In the spirit of 684 providing clarity, we will refer to those IIDs as L2-IID, L3-IID and 685 ARP-IID respectively. By using these definitions, we do not intend 686 to coin new terminology, nor is there anything special about those 687 IIDs that would make them differ from the generic definition of an 688 IID. The types of mappings expected in such a system are summarized 689 below: 691 o EID = to RLOC = (L3-overlay) 692 o EID = to RLOC = (L2-overlay) 694 o EID = to RLOC = (ARP/ND mapping) 696 The following packet flow sequence describes the use of the LISP 697 Mapping System to support ARP resolution for hosts residing in a 698 subnet that is extended to multiple sites. Using Figure 1, End- 699 Device 2 tries to find the MAC address of End-Device 3. Note that 700 both have IP addresses within the same subnet: 702 o End-Device 2 sends a broadcast ARP message to discover the MAC 703 address of End-Device 3. The ARP request targets IP 3.0.0.3. 705 o ITR B receives the ARP message, but rather than flooding it on the 706 overlay network sends a Map-Request to the mapping database system 707 for EID = . 709 o When receiving the Map-Request, the Map-Server sends a Proxy-Map- 710 Reply back to ITR B with the mapping EID = -> MAC 711 0:0:3:0:0:3. 713 o Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 714 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 716 o End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 717 now send a L2 traffic to End-Device 3. When this traffic reaches 718 ITR B is sent over the L2-overlay as described above in 719 Section 5.1.1. 721 This example shows how LISP, by replacing dynamic data plane learning 722 (such as Flood-and-Learn) can reduce the use of multicast in the 723 underlay network. 725 Note that ARP resolution using the Mapping System is a stateful 726 operation on the ITR. The source IP,MAC tuple coming from the ARP 727 request have to be stored to generate the ARP-reply when the Map- 728 Reply is received. 730 Note that the ITR SHOULD cache the ARP entry. In that case future 731 ARP-requests can be handled without sending additional Map-Requests. 733 5.3.2. ARP registrations: MAC as a locator record 735 When an end-host is attached or detected in an ETR that provides 736 L2-overlay services and also supports ARP resolution using the LISP 737 control-plane, an additional mapping entry is registered to the 738 mapping system: 740 o The EID 2-tuple (IID, IP) and its binding to a corresponding host 741 MAC address. 743 In this case both the xTRs and the Mapping System MUST support an 744 EID-to-RLOC mapping where the MAC address is set as a locator record. 746 In order to guarantee compatibility with current implementations of 747 xTRs, the MAC locator record SHALL be encoded following the AFI-List 748 LCAF Type defined in [RFC8060]. This option would also allow adding 749 additional attributes to the locator record, while maintaining 750 compatibility with legacy devices. 752 This mapping is registered with the Mapping System using the 753 following EID record structure, 755 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | | Record TTL | 757 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 E | Locator Count | EID mask-len | ACT |A| Reserved | 759 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 D | Rsvd | Map-Version Number | AFI = 16387 | 761 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 763 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 c | 4 + n | Instance-ID... | 765 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 r | ...Instance-ID | EID-AFI = 1 or 2 | 767 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | EID-Prefix (IPv4 or IPv6) | 769 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | /| Priority | Weight | M Priority | M Weight | 771 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | M | Unused Flags |L|p|R| AFI = 16387 | 773 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 775 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | | 2 + 6 | AFI = 6 | 777 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | | Layer-2 MAC Address ... | 779 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | \| ... Layer-2 MAC Address | 781 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 783 An EID record with a locator record that carries a MAC address 784 follows the same structure as described in [RFC6830]. However, some 785 fields of the EID record and the locator record require special 786 consideration: 788 Locator Count: This value SHOULD be set to 1. 790 Instance-ID: This is the IID used to provide segmentation of the 791 L2-overlays, L3 overlays and ARP tables. 793 Priority and Weight: IP to MAC bindings are one to one bindings. An 794 ETR SHOULD not register more than one MAC address in the locator 795 record together with an IP based EID. The Priority of the MAC 796 address record is set to 255. The Weight value SHOULD be ignored 797 and the recommendation is to set it to 0. 799 L bit: This bit of the locator record SHOULD only be set to 1 when 800 an ETR is registering its own IP to MAC binding. 802 p bit: This bit of the locator record SHOULD be set to 0. 804 R bit: This bit of the locator record SHOULD be set to 0. 806 Note that an IP EID record that carries a MAC address in the locator 807 record, SHALL be registered with the Proxy Map-Reply bit set. 809 5.3.3. Implementation Considerations 811 While ARP support through the LISP Mapping System fits the LISP 812 Control-Plane there are a series of considerations to take into 813 account when providing this feature: 815 o As indicated, when and end-host is attached the ETR maintains and 816 registers a mapping with the binding EID = -> RLOC = 817 . 819 o ARP support through the LISP Mapping System is OPTIONAL and the 820 xTRs should allow the possibility to enable or disable the 821 feature. 823 o When the ARP entry has not been registered, a Map Server SHOULD 824 send a Negative Map-Reply with action "No Action" as a response to 825 an ARP based Map Request. 827 o In case the ITR receives a Negative Map-Reply for an ARP request 828 it should fallback to flooding the ARP packet as any other L2 829 Broadcast packet (as described in Section 5.2.5). 831 o When receiving a positive Map-Reply for an ARP based Map-Request, 832 the ETR MUST recreate the actual ARP Reply, impersonating the real 833 host. As a consequence, ARP support is a stateful operation where 834 the ITR needs to store enough information about the host that 835 generates an ARP request in order to recreate the ARP Reply. 837 o ARP replies learned from the Mapping System SHOULD be cached and 838 the information used to reply to subsequent ARP requests to the 839 same hosts. 841 6. Optional Deployment Models 843 The support of an integrated L2 and L3 overlay solution takes 844 multiple architectural design options, that depend on the specific 845 requirements of the deployment environment. While some of the 846 previous describe specific packet flows and solutions based on the 847 recommended solution, this section documents OPTIONAL design 848 considerations that differ from the recommended one but that MAY be 849 required on alternative deployment environments. 851 6.1. IP Forwarding of Intra-subnet Traffic 853 As pointed out at the beginning the recommended selection of the L2 854 and L3 overlays is not the only one possible. In fact, providing L2 855 extension to some cloud platforms is not always possible and subnets 856 need to be extended using the L3 overlay. 858 In order to send all IP traffic (intra- and inter-subnet) through the 859 L3 overlay the solution MUST change the ARP resolution process 860 described in Section 5.3.1 to the following one (we follow again 861 Figure 1 to drive the example. End-Device 2 queries about End-Device 862 3): 864 o End-Device 1 sends a broadcast ARP message to discover the MAC 865 address of 3.0.0.3. 867 o ITR B receives the ARP message and sends a Map-Request to the 868 Mapping System for EID = . 870 o In this case, the Map-Request is routed by the Mapping system 871 infrastructure to ETR C, that will send a Map-Reply back to ITR B 872 containing the mapping EID = -> RLOC=IP_C. 874 o ITR B populates its local cache with the received entry on the L3 875 forwarding table. Then, using the cache information it sends a 876 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 877 Device 1. 879 o End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 880 traffic with destination address 3.0.0.3 and destination MAC, 881 MAC_xTR_B. 883 o As the destination MAC address is the one from xTR B, when xTR B 884 receives this traffic it is forwarded using the L3-overlay. 886 o Note that when implementing this solution, when a host that is 887 local to an ETR moves away, the ETR SHOULD locally send a 888 Gratuitous ARP with its own MAC address and the IP of the moved 889 host, to refresh the ARP tables of local hosts and guarantee the 890 use of the L3 overlay when connecting to the remote host. 892 It is also important to note that using this strategy to extend 893 subnets through the L3 overlay but still keeping the L2 overlay for 894 the rest of traffic MAY lead to flow asymmetries. This MAY be the 895 case in deployments that filter Gratuitous ARPs, or when moved hosts 896 continue using actual L2 information collected before a migration. 898 6.2. Data-plane Encapsulation Options 900 The LISP control-plane offers independence from the data-plane 901 encapsulation. Any encapsulation format that can carry a 24-bit 902 instance-ID can be used to provide the unified overlay. 904 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 905 and [VXLAN]: 907 o VXLAN-GPE encap: This encapsulation format is defined in 908 [I-D.ietf-nvo3-vxlan-gpe]. It allows encapsulation both L2 and L3 909 packets and the VNI field directly maps to the Instance-ID used in 910 the control plane. Note that when using this encapsulation for a 911 unified solution the P-bit is set and the Next-Protocol field is 912 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 913 L3-overlays, and value 0x3 in L2-overlays). 915 o LISP encap: This is the encapsulation format defined in the 916 original LISP specification [RFC6830]. The encapsulation allows 917 encapsulating both L2 and L3 packets. The Instance-ID used in the 918 EIDs directly maps to the Instance-ID that the LISP header 919 carries. At the ETR, after decapsulation, the IID MAY be used to 920 decide between L2 processing or L3 processing. 922 o VXLAN encap: This is a L2 encapsulation format defined in 923 [RFC7348]. While being a L2 encapsulation it can be used both for 924 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 925 to the VNI field of the VXLAN header. Providing L3 overlays using 926 VXLAN generally requires using the ETR MAC address as destination 927 MAC address of the inner Ethernet header. The process to learn or 928 derive this ETR MAC address is not included as part of this 929 document. 931 7. IANA Considerations 933 This memo includes no request to IANA. 935 8. Acknowledgements 937 This draft builds on top of two expired drafts that introduced the 938 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 939 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 940 combined authors of those drafts, that SHOULD be considered main 941 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 942 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 943 Smith. 945 9. References 947 9.1. Normative References 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, 951 DOI 10.17487/RFC2119, March 1997, 952 . 954 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 955 Locator/ID Separation Protocol (LISP)", RFC 6830, 956 DOI 10.17487/RFC6830, January 2013, 957 . 959 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 960 Locator/ID Separation Protocol (LISP) for Multicast 961 Environments", RFC 6831, DOI 10.17487/RFC6831, January 962 2013, . 964 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 965 Protocol (LISP) Map-Server Interface", RFC 6833, 966 DOI 10.17487/RFC6833, January 2013, 967 . 969 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 970 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 971 eXtensible Local Area Network (VXLAN): A Framework for 972 Overlaying Virtualized Layer 2 Networks over Layer 3 973 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 974 . 976 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 977 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 978 February 2017, . 980 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 981 Smirnov, "Locator/ID Separation Protocol Delegated 982 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 983 May 2017, . 985 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 986 Separation Protocol (LISP) Multicast", RFC 8378, 987 DOI 10.17487/RFC8378, May 2018, 988 . 990 9.2. Informative References 992 [I-D.coras-lisp-re] 993 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 994 Maino, F., and D. Farinacci, "LISP Replication 995 Engineering", draft-coras-lisp-re-08 (work in progress), 996 November 2015. 998 [I-D.ietf-nvo3-vxlan-gpe] 999 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1000 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 1001 in progress), April 2018. 1003 [I-D.kouvelas-lisp-map-server-reliable-transport] 1004 Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. 1005 Arango, "LISP Map Server Reliable Transport", draft- 1006 kouvelas-lisp-map-server-reliable-transport-04 (work in 1007 progress), September 2017. 1009 Authors' Addresses 1011 Marc Portoles Comeras 1012 Cisco Systems 1013 170 Tasman Drive 1014 San Jose, CA 95134 1015 USA 1017 Email: mportole@cisco.com 1019 Vrushali Ashtaputre 1020 Cisco Systems 1021 170 Tasman Drive 1022 San Jose, CA 95134 1023 USA 1025 Email: vrushali@cisco.com 1026 Victor Moreno 1027 Cisco Systems 1028 170 Tasman Drive 1029 San Jose, CA 95134 1030 USA 1032 Email: vimoreno@cisco.com 1034 Fabio Maino 1035 Cisco Systems 1036 170 Tasman Drive 1037 San Jose, CA 95134 1038 USA 1040 Email: fmaino@cisco.com 1042 Dino Farinacci 1043 lispers.net 1044 San Jose, CA 1045 USA 1047 Email: farinacci@gmail.com