idnits 2.17.1 draft-ietf-lisp-eid-mobility-01.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 (November 15, 2017) is 2352 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'LISP' is mentioned on line 905, but not defined == Missing Reference: 'VXLAN' is mentioned on line 906, but not defined == Missing Reference: 'VXLAN-GPE' is mentioned on line 905, 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 (-09) exists of draft-ietf-lisp-ddt-08 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-16 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-01 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-02 Summary: 3 errors (**), 0 flaws (~~), 11 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: May 19, 2018 F. Maino 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 November 15, 2017 11 LISP L2/L3 EID Mobility Using a Unified Control Plane 12 draft-ietf-lisp-eid-mobility-01 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 May 19, 2018. 45 Copyright Notice 47 Copyright (c) 2017 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 . . . . . . . . . 10 78 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10 79 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11 80 5.2. Implementation Considerations . . . . . . . . . . . . . . 12 81 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-lisp-signal-free-multicast]. 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 [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. 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 [I-D.ietf-lisp-lcaf] and the specific EID record to be used is 336 illustrated in 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], [I-D.ietf-lisp-signal-free-multicast] and 407 [I-D.coras-lisp-re]. 409 4.2.6. Time-to-Live Handling in Data-Plane 411 The LISP specification ([RFC6830]) describes how to handle Time-to- 412 Live values of the inner and outer headers during encapsulation and 413 decapsulation of packets when using the L3 overlay. 415 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 [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. Instance- 519 IDs are unique to a Mapping System and MAY be used to identify the 520 overlay type (e.g., L2 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 [I-D.ietf-lisp-lcaf] 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 623 [I-D.ietf-lisp-signal-free-multicast], where S is 0000-0000-0000/0 624 and G is ffff-ffff-ffff/48. This strategy allows and ITR to know 625 which ETRs are part of the L2 overlay and it can head-end replicate 626 traffic to. 628 Following the same case, when multicast is not available in the core 629 network, the procedures in [I-D.ietf-lisp-signal-free-multicast] can 630 be used to ensure proper distribution of link-local multicast traffic 631 across xTRs participating in the L2 overlay. In such case, the xTRs 632 SHOULD join a (S,G) entry with S being 0000-0000-0000/0 and where G 633 is 0100-0000-0000/8. 635 5.2.6. L2 Unknown Unicast Support 637 An ITR attempts to resolve MAC destination misses through the Mapping 638 System. When the destination host remains undiscovered the 639 destination is considered an Unknown Unicast. 641 A Map-Server SHOULD respond to a Map-Request for an undiscovered host 642 with a Negative Map-Reply with action "Native Forward". 643 Alternatively the action "Drop" may be used in order to suppress 644 Unknown Unicast forwarding. 646 An ITR that receives a Negative Map-Reply with Action "Native 647 Forward" will handle traffic for the undiscovered host as L2 648 Broadcast traffic and will be unicast replicated or flooded using 649 underlay multicast to the rest of ETRs in the Layer-2 overlay. 651 Upon discovery of a previously unknown unicast MAC EID, a data 652 triggered SMR for the discovered EID should be sent by the discovery 653 ETR back to the ITRs that are flooding the unknown unicast traffic. 654 This would allow ITRs to refresh their caches and stop flooding 655 unknown unicast traffic as necessary. 657 5.2.7. Time-to-Live Handling in Data-Plane 659 When using a L2 overlay and the encapsulated traffic is IP traffic, 660 the Time-to-Live value of the inner IP header MUST remain unmodified 661 during encapsulation and decapsulation. Network hops traversed as 662 part of the L2 overlay SHOULD be hidden to tools like traceroute and 663 applications that require direct L2 connectivity. 665 5.3. Support to ARP resolution through Mapping System 667 5.3.1. Map-Server support to ARP resolution: Packet Flow 669 A large majority of applications are IP based and, as a consequence, 670 end systems are typically provisioned with IP addresses as well as 671 MAC addresses. 673 In this case, to limit the flooding of ARP traffic and reduce the use 674 of multicast in the RLOC network, the LISP mapping system MAY be used 675 to support ARP resolution at the ITR. 677 In order to provide this support, ETRs handle and register an 678 additional EID-to-RLOC mapping as follows, 680 o EID-record contents = , RLOC-record contents . 682 There is a dedicated IID used for the registration of the ARP/ND 683 related mappings. Thus, a system with L2 and L3 overlays as well as 684 ARP/ND mappings would have three IIDs at play. In the spirit of 685 providing clarity, we will refer to those IIDs as L2-IID, L3-IID and 686 ARP-IID respectively. By using these definitions, we do not intend 687 to coin new terminology, nor is there anything special about those 688 IIDs that would make them differ from the generic definition of an 689 IID. The types of mappings expected in such a system are summarized 690 below: 692 o EID = to RLOC = (L3-overlay) 693 o EID = to RLOC = (L2-overlay) 695 o EID = to RLOC = (ARP/ND mapping) 697 The following packet flow sequence describes the use of the LISP 698 Mapping System to support ARP resolution for hosts residing in a 699 subnet that is extended to multiple sites. Using Figure 1, End- 700 Device 2 tries to find the MAC address of End-Device 3. Note that 701 both have IP addresses within the same subnet: 703 o End-Device 2 sends a broadcast ARP message to discover the MAC 704 address of End-Device 3. The ARP request targets IP 3.0.0.3. 706 o ITR B receives the ARP message, but rather than flooding it on the 707 overlay network sends a Map-Request to the mapping database system 708 for EID = . 710 o When receiving the Map-Request, the Map-Server sends a Proxy-Map- 711 Reply back to ITR B with the mapping EID = -> MAC 712 0:0:3:0:0:3. 714 o Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 715 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 717 o End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 718 now send a L2 traffic to End-Device 3. When this traffic reaches 719 ITR B is sent over the L2-overlay as described above in 720 Section 5.1.1. 722 This example shows how LISP, by replacing dynamic data plane learning 723 (such as Flood-and-Learn) can reduce the use of multicast in the 724 underlay network. 726 Note that ARP resolution using the Mapping System is a stateful 727 operation on the ITR. The source IP,MAC tuple coming from the ARP 728 request have to be stored to generate the ARP-reply when the Map- 729 Reply is received. 731 Note that the ITR SHOULD cache the ARP entry. In that case future 732 ARP-requests can be handled without sending additional Map-Requests. 734 5.3.2. ARP registrations: MAC as a locator record 736 When an end-host is attached or detected in an ETR that provides 737 L2-overlay services and also supports ARP resolution using the LISP 738 control-plane, an additional mapping entry is registered to the 739 mapping system: 741 o The EID 2-tuple (IID, IP) and its binding to a corresponding host 742 MAC address. 744 In this case both the xTRs and the Mapping System MUST support an 745 EID-to-RLOC mapping where the MAC address is set as a locator record. 747 In order to guarantee compatibility with current implementations of 748 xTRs, the MAC locator record SHALL be encoded following the AFI-List 749 LCAF Type defined in [I-D.ietf-lisp-lcaf]. This option would also 750 allow adding additional attributes to the locator record, while 751 maintaining compatibility with legacy devices. 753 This mapping is registered with the Mapping System using the 754 following EID record structure, 756 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | | Record TTL | 758 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 E | Locator Count | EID mask-len | ACT |A| Reserved | 760 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 D | Rsvd | Map-Version Number | AFI = 16387 | 762 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 764 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 c | 4 + n | Instance-ID... | 766 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 r | ...Instance-ID | EID-AFI = 1 or 2 | 768 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | EID-Prefix (IPv4 or IPv6) | 770 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | /| Priority | Weight | M Priority | M Weight | 772 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | M | Unused Flags |L|p|R| AFI = 16387 | 774 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 776 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | | 2 + 6 | AFI = 6 | 778 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | | | Layer-2 MAC Address ... | 780 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | \| ... Layer-2 MAC Address | 782 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 784 An EID record with a locator record that carries a MAC address 785 follows the same structure as described in [RFC6830]. However, some 786 fields of the EID record and the locator record require special 787 consideration: 789 Locator Count: This value SHOULD be set to 1. 791 Instance-ID: This is the IID used to provide segmentation of the 792 L2-overlays, L3 overlays and ARP tables. 794 Priority and Weight: IP to MAC bindings are one to one bindings. An 795 ETR SHOULD not register more than one MAC address in the locator 796 record together with an IP based EID. The Priority of the MAC 797 address record is set to 255. The Weight value SHOULD be ignored 798 and the recommendation is to set it to 0. 800 L bit: This bit of the locator record SHOULD only be set to 1 when 801 an ETR is registering its own IP to MAC binding. 803 p bit: This bit of the locator record SHOULD be set to 0. 805 R bit: This bit of the locator record SHOULD be set to 0. 807 Note that an IP EID record that carries a MAC address in the locator 808 record, SHALL be registered with the Proxy Map-Reply bit set. 810 5.3.3. Implementation Considerations 812 While ARP support through the LISP Mapping System fits the LISP 813 Control-Plane there are a series of considerations to take into 814 account when providing this feature: 816 o As indicated, when and end-host is attached the ETR maintains and 817 registers a mapping with the binding EID = -> RLOC = 818 . 820 o ARP support through the LISP Mapping System is OPTIONAL and the 821 xTRs should allow the possibility to enable or disable the 822 feature. 824 o When the ARP entry has not been registered, a Map Server SHOULD 825 send a Negative Map-Reply with action "No Action" as a response to 826 an ARP based Map Request. 828 o In case the ITR receives a Negative Map-Reply for an ARP request 829 it should fallback to flooding the ARP packet as any other L2 830 Broadcast packet (as described in Section 5.2.5). 832 o When receiving a positive Map-Reply for an ARP based Map-Request, 833 the ETR MUST recreate the actual ARP Reply, impersonating the real 834 host. As a consequence, ARP support is a stateful operation where 835 the ITR needs to store enough information about the host that 836 generates an ARP request in order to recreate the ARP Reply. 838 o ARP replies learned from the Mapping System SHOULD be cached and 839 the information used to reply to subsequent ARP requests to the 840 same hosts. 842 6. Optional Deployment Models 844 The support of an integrated L2 and L3 overlay solution takes 845 multiple architectural design options, that depend on the specific 846 requirements of the deployment environment. While some of the 847 previous describe specific packet flows and solutions based on the 848 recommended solution, this section documents OPTIONAL design 849 considerations that differ from the recommended one but that MAY be 850 required on alternative deployment environments. 852 6.1. IP Forwarding of Intra-subnet Traffic 854 As pointed out at the beginning the recommended selection of the L2 855 and L3 overlays is not the only one possible. In fact, providing L2 856 extension to some cloud platforms is not always possible and subnets 857 need to be extended using the L3 overlay. 859 In order to send all IP traffic (intra- and inter-subnet) through the 860 L3 overlay the solution MUST change the ARP resolution process 861 described in Section 5.3.1 to the following one (we follow again 862 Figure 1 to drive the example. End-Device 2 queries about End-Device 863 3): 865 o End-Device 1 sends a broadcast ARP message to discover the MAC 866 address of 3.0.0.3. 868 o ITR B receives the ARP message and sends a Map-Request to the 869 Mapping System for EID = . 871 o In this case, the Map-Request is routed by the Mapping system 872 infrastructure to ETR C, that will send a Map-Reply back to ITR B 873 containing the mapping EID = -> RLOC=IP_C. 875 o ITR B populates its local cache with the received entry on the L3 876 forwarding table. Then, using the cache information it sends a 877 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 878 Device 1. 880 o End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 881 traffic with destination address 3.0.0.3 and destination MAC, 882 MAC_xTR_B. 884 o As the destination MAC address is the one from xTR B, when xTR B 885 receives this traffic it is forwarded using the L3-overlay. 887 o Note that when implementing this solution, when a host that is 888 local to an ETR moves away, the ETR SHOULD locally send a 889 Gratuitous ARP with its own MAC address and the IP of the moved 890 host, to refresh the ARP tables of local hosts and guarantee the 891 use of the L3 overlay when connecting to the remote host. 893 It is also important to note that using this strategy to extend 894 subnets through the L3 overlay but still keeping the L2 overlay for 895 the rest of traffic MAY lead to flow asymmetries. This MAY be the 896 case in deployments that filter Gratuitous ARPs, or when moved hosts 897 continue using actual L2 information collected before a migration. 899 6.2. Data-plane Encapsulation Options 901 The LISP control-plane offers independence from the data-plane 902 encapsulation. Any encapsulation format that can carry a 24-bit 903 instance-ID can be used to provide the unified overlay. 905 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 906 and [VXLAN]: 908 o VXLAN-GPE encap: This encapsulation format is defined in 909 [I-D.ietf-nvo3-vxlan-gpe]. It allows encapsulation both L2 and L3 910 packets and the VNI field directly maps to the Instance-ID used in 911 the control plane. Note that when using this encapsulation for a 912 unified solution the P-bit is set and the Next-Protocol field is 913 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 914 L3-overlays, and value 0x3 in L2-overlays). 916 o LISP encap: This is the encapsulation format defined in the 917 original LISP specification [RFC6830]. The encapsulation allows 918 encapsulating both L2 and L3 packets. The Instance-ID used in the 919 EIDs directly maps to the Instance-ID that the LISP header 920 carries. At the ETR, after decapsulation, the IID MAY be used to 921 decide between L2 processing or L3 processing. 923 o VXLAN encap: This is a L2 encapsulation format defined in 924 [RFC7348]. While being a L2 encapsulation it can be used both for 925 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 926 to the VNI field of the VXLAN header. Providing L3 overlays using 927 VXLAN generally requires using the ETR MAC address as destination 928 MAC address of the inner Ethernet header. The process to learn or 929 derive this ETR MAC address is not included as part of this 930 document. 932 7. IANA Considerations 934 This memo includes no request to IANA. 936 8. Acknowledgements 938 This draft builds on top of two expired drafts that introduced the 939 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 940 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 941 combined authors of those drafts, that SHOULD be considered main 942 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 943 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 944 Smith. 946 9. References 948 9.1. Normative References 950 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 951 Requirement Levels", BCP 14, RFC 2119, 952 DOI 10.17487/RFC2119, March 1997, 953 . 955 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 956 Locator/ID Separation Protocol (LISP)", RFC 6830, 957 DOI 10.17487/RFC6830, January 2013, 958 . 960 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 961 Locator/ID Separation Protocol (LISP) for Multicast 962 Environments", RFC 6831, DOI 10.17487/RFC6831, January 963 2013, . 965 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 966 Protocol (LISP) Map-Server Interface", RFC 6833, 967 DOI 10.17487/RFC6833, January 2013, 968 . 970 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 971 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 972 eXtensible Local Area Network (VXLAN): A Framework for 973 Overlaying Virtualized Layer 2 Networks over Layer 3 974 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 975 . 977 9.2. Informative References 979 [I-D.coras-lisp-re] 980 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 981 Maino, F., and D. Farinacci, "LISP Replication 982 Engineering", draft-coras-lisp-re-08 (work in progress), 983 November 2015. 985 [I-D.ietf-lisp-ddt] 986 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 987 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 988 ddt-08 (work in progress), September 2016. 990 [I-D.ietf-lisp-lcaf] 991 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 992 Address Format (LCAF)", draft-ietf-lisp-lcaf-16 (work in 993 progress), October 2016. 995 [I-D.ietf-lisp-signal-free-multicast] 996 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 997 draft-ietf-lisp-signal-free-multicast-01 (work in 998 progress), April 2016. 1000 [I-D.ietf-nvo3-vxlan-gpe] 1001 Kreeger, L. and U. Elzur, "Generic Protocol Extension for 1002 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), 1003 April 2016. 1005 [I-D.kouvelas-lisp-map-server-reliable-transport] 1006 Cassar, C., Kouvelas, I., Lewis, D., Arango, J., and J. 1007 Leong, "LISP Map Server Reliable Transport", draft- 1008 kouvelas-lisp-map-server-reliable-transport-02 (work in 1009 progress), August 2016. 1011 Authors' Addresses 1013 Marc Portoles Comeras 1014 Cisco Systems 1015 170 Tasman Drive 1016 San Jose, CA 95134 1017 USA 1019 Email: mportole@cisco.com 1020 Vrushali Ashtaputre 1021 Cisco Systems 1022 170 Tasman Drive 1023 San Jose, CA 95134 1024 USA 1026 Email: vrushali@cisco.com 1028 Victor Moreno 1029 Cisco Systems 1030 170 Tasman Drive 1031 San Jose, CA 95134 1032 USA 1034 Email: vimoreno@cisco.com 1036 Fabio Maino 1037 Cisco Systems 1038 170 Tasman Drive 1039 San Jose, CA 95134 1040 USA 1042 Email: fmaino@cisco.com 1044 Dino Farinacci 1045 lispers.net 1046 San Jose, CA 1047 USA 1049 Email: farinacci@gmail.com