idnits 2.17.1 draft-portoles-lisp-eid-mobility-00.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 27 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. == 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: o TTL value of the inner-IP header SHOULD not be modified when traversing the L2 overlay. -- The document date (April 7, 2016) is 2913 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'VXLAN-GPE' is mentioned on line 715, but not defined == Missing Reference: 'VXLAN' is mentioned on line 716, but not defined == Missing Reference: 'LISP' is mentioned on line 715, 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-11 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-00 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-01 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-01 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Portoles 3 Internet-Draft V. Ashtaputre 4 Intended status: Experimental V. Moreno 5 Expires: October 9, 2016 F. Maino 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 April 7, 2016 11 LISP L2/L3 EID Mobility Using a Unified Control Plane 12 draft-portoles-lisp-eid-mobility-00 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 http://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 October 9, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 3 64 3. Reference System and Packet Flows . . . . . . . . . . . . . . 4 65 3.1. Reference System . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Packet Flows . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2.1. Bridged Traffic: Intra-subnet and Non-IP . . . . . . 5 68 3.2.2. Routed Traffic: Inter-subnet . . . . . . . . . . . . 6 69 3.2.3. ARP Resolution . . . . . . . . . . . . . . . . . . . 6 70 4. LISP Protocol with L2 and L3 Support . . . . . . . . . . . . 8 71 4.1. L2 and L3 Segmentation . . . . . . . . . . . . . . . . . 8 72 4.2. Database Mappings in Unified L2 and L3 Overlays . . . . . 8 73 4.3. MAC as a Locator Record for ARP Resolution . . . . . . . 9 74 4.4. LISP Mapping System . . . . . . . . . . . . . . . . . . . 11 75 4.5. Time-to-Live Handling in Data-Plane . . . . . . . . . . . 11 76 4.6. Using SMRs to Track Moved-Away State . . . . . . . . . . 11 77 4.7. Non-Extended Subnets . . . . . . . . . . . . . . . . . . 12 78 4.8. L2 Overlays and Multicast Groups . . . . . . . . . . . . 12 79 4.9. L2 Broadcast, Unknown Unicast and Multicast traffic . . . 12 80 5. EID Mobility Support . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Reference Architecture . . . . . . . . . . . . . . . . . 13 82 5.2. L2 Mobility: Packet Flow . . . . . . . . . . . . . . . . 13 83 5.3. L3 Mobility: Packet Flow . . . . . . . . . . . . . . . . 14 84 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 15 85 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 15 86 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 16 87 6.3. L2-only Deployments . . . . . . . . . . . . . . . . . . . 17 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 9.2. Informative References . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 This document describes the architecture and design options required 99 to offer a unified L2 and L3 overlay solution with the LISP control- 100 plane. 102 The architecture takes advantage of the flexibility that LISP 103 provides to simultaneously support different overlay flavors. In 104 this sense, while the LISP specification defines both data-plane and 105 control-plane solutions, this document focuses on the use of the 106 control-plane piece, which can be combined with the data-plane of 107 choice (e.g., [VXLAN-GPE], [VXLAN], or [LISP]. 109 The recommended selection of whether a flow is sent over the L2 or 110 the L3 overlay is mapped to bridged (intra-subnet or non-IP) or 111 routed (inter-subnet) traffic, respectively. This allows treating 112 both overlays as separate segments, and enables L2-only and L3-only 113 deployments (and combinations of them) without modifying the 114 architecture. 116 The unified solution for L2 and L3 overlays offers the possibility to 117 extend subnets and routing domains (as required in state-of-art 118 Datacenter and Enterprise architectures) with traffic optimization. 120 An important use-case of the unified architecture is that, while most 121 data centers are complete layer-3 routing domains, legacy 122 applications either have not converted to IP or still use auto- 123 discovery at layer-2 and assume all nodes in an application cluster 124 belong to the same subnet. For these applications, the L2-overlay 125 limits the functionality to where the legacy app lives versus having 126 to extend layer-2 into the network. 128 Broadcast, Unknown and Multicast traffic on the overlay are supported 129 by either replicated unicast, or underlay (RLOC) multicast as 130 specified in [RFC6831], [I-D.ietf-lisp-signal-free-multicast]. 132 2. Definition of Terms 134 LISP related terms are defined as part of the LISP specification 135 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 136 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 137 (MS) and Map-Resolver (MR). 139 3. Reference System and Packet Flows 141 This section introduces a reference system to support the description 142 of the solution and it walks the supported packet flows. 144 3.1. Reference System 146 The following figure illustrates the reference system used to support 147 the packet flow description. The system presents 4 sites. Site A 148 and Site D provide access to different subnets (non-extended), while 149 Site B and Site C extend a common subnet. The xTR in each one of the 150 sites registers EIDs from the sites with the LISP Mapping System and 151 provides support to encapsulate overlay (EID) traffic through the 152 underlay (RLOC space). 154 ,-------------. 155 (Mapping System ) 156 -+------------+ 157 +--+--+ +-+---+ 158 |MS/MR| |MS/MR| 159 +-+---+ +-----+ 160 .-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-. 161 .-.' '.-. 162 ( L3 Underlay ) 163 ( (RLOC Space) ) 164 '.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.' 165 / | | \ 166 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 167 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 168 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 169 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 170 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 171 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 172 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 173 / '--' | '--' | '--' \ '--' 174 '--------' '--------' '--------' '--------' 175 : End : : End : : End : : End : 176 :Device 1: :Device 2: :Device 3: :Device 4: 177 '--------' '--------' '--------' '--------' 178 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 179 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 181 Figure 1: Reference System Architecture with unified L2 and L3 182 overlays 184 3.2. Packet Flows 186 The recommended selection between the use of L2 and L3 overlays is to 187 map them to bridged (intra-subnet or non-IP) and routed (inter- 188 subnet) traffic. This section follows this recommendation to 189 describe the packet flows. 191 However, note that in a different selection approach, intra-subnet 192 traffic MAY also be sent over the L3 overlay. Section 6.1 specifies 193 the changes needed to send all IP traffic using the L3 overlay and 194 restricting the use of the L2 overlay to non-IP traffic. 196 When required, the control plane makes use of two basic types of EID- 197 to-RLOC mappings associated to end-hosts and in order to support the 198 unified architecture: 200 o EID = to RLOC=. This is used to support the L2 201 overlay. 203 o EID = to RLOC=. This is the traditional mapping as 204 defined in the original LISP specification and supports the L3 205 overlay. 207 3.2.1. Bridged Traffic: Intra-subnet and Non-IP 209 Bridged traffic is encapsulated using the L2 overlay. This section 210 provides an example of the unicast packet flow and the control plane 211 operations when in the topology shown in Figure 1, the End-Device 2 212 in site B communicates with the End-Device 3 in site C. In this case 213 we assume that End Device 2, knows the MAC address of End-Device 3 214 (e.g., learned through ARP). 216 o End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination 217 0:0:3:0:0:3 and source 0:0:3:0:0:2. 219 o ITR B does a L2 lookup in its local map-cache for the destination 220 MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the 221 ITR sends a Map-Request to the mapping database system looking up 222 for MAC 0:0:3:0:0:3. 224 o The mapping systems forwards the Map-Request to ETR C, that has 225 registered the EID-to-RLOC mapping for MAC 0:0:3:0:0:3. 226 Alternatively, depending on the mapping system configuration, a 227 Map-Server which is part of the mapping database system MAY send a 228 Map-Reply directly to ITR B. 230 o ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC 231 mapping: MAC 0:0:3:0:0:3 -> RLOC=IP_C, where IP_C is the locator 232 of ETR C. 234 o ITR B populates the local map-cache with the EID to RLOC mapping, 235 and encapsulates all subsequent packets with a destination MAC 236 0:0:3:0:0:3 using destination RLOC=IP_C. 238 3.2.2. Routed Traffic: Inter-subnet 240 Inter-subnet traffic is encapsulated using the L3 overlay. The 241 process to encapsulate this traffic is the same as described in the 242 original specification [RFC6830]. We describe the packet flow here 243 for completeness 245 The following is a sequence example of the unicast packet flow and 246 the control plane operations when in the topology shown in Figure 1 247 End-Device 1, in LISP site A, wants to communicate with End-Device 4 248 in LISP site D. Note that both end systems reside in different 249 subnets. We'll assume that End-Device 1 knows the EID IP address of 250 End-Device 4 (e.g. it is learned using a DNS service). 252 o End-Device 1 sends an IP packet frame with destination 2.0.0.4 and 253 source 1.0.0.1. As the destination address lies on a different 254 subnet End-Device 1 sends the packet following its routing table 255 to ITR A (e.g., it is its default gateway). 257 o ITR A does a L3 lookup in its local map-cache for the destination 258 IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a 259 Map-request to the mapping database system looking up for IP 260 2.0.0.4. 262 o The mapping systems forwards the Map-Request to ETR D, that has 263 registered the EID-to-RLOC mapping of IP 2.0.0.4. 265 o ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC 266 mapping: EID IP 2.0.0.4 -> RLOC=IP_D, where IP_D is the locator of 267 ETR D. 269 o ITR A populates the local map-cache with the EID to RLOC mapping, 270 and encapsulates all subsequent packets with a destination IP 271 2.0.0.4 using destination RLOC=IP_D. 273 3.2.3. ARP Resolution 275 A large majority of applications are IP based and, as a consequence, 276 end systems are typically provisioned with IP addresses as well as 277 MAC addresses. 279 In this case, to limit the flooding of ARP traffic and reduce the use 280 of multicast in the RLOC network, the LISP mapping system is used to 281 support ARP resolution at the ITR. 283 In order to provide this support, ETRs handle and register an 284 additional EID-to-RLOC mapping as follows, 286 o EID = to RLOC = . 288 The following packet flow sequence describes the use of the LISP 289 Mapping System to support ARP resolution for hosts residing in a 290 subnet that is extended to multiple sites. Using Figure 1, End- 291 Device 2 tries to find the MAC address of End-Device 3. Note that 292 both have IP addresses within the same subnet: 294 o End-Device 2 sends a broadcast ARP message to discover the MAC 295 address of End-Device 3. The ARP request targets IP 3.0.0.3. 297 o ITR B receives the ARP message, but rather than flooding it on the 298 overlay network sends a Map-Request to the mapping database system 299 for IP 3.0.0.3. 301 o When receiving the Map-Request, the Map-Server sends a Proxy-Map- 302 Reply back to ITR B with the mapping IP 3.0.0.3 -> MAC 303 0:0:3:0:0:3. 305 o Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device 306 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 308 o End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can 309 now send a L2 traffic to End-Device 3. When this traffic reaches 310 ITR B is sent over the L2-overlay as described above in 311 Section 3.2.1. 313 This example shows how LISP, by replacing dynamic data plane learning 314 (such as Flood-and-Learn) can reduce the use of multicast in the 315 underlay network. 317 Note that ARP resolution using the Mapping System is a stateful 318 operation on the ITR. The source IP,MAC tuple coming from the ARP 319 request have to be stored to generate the ARP-reply when the Map- 320 Reply is received. 322 Note that the ITR SHOULD cache the ARP entry. In that case future 323 ARP-requests can be handled without sending additional Map-Requests. 325 4. LISP Protocol with L2 and L3 Support 327 This section describes the specific elements required to support a 328 unified L2 and L3 overlay solution and the packet flows described in 329 the previous section. 331 4.1. L2 and L3 Segmentation 333 LISP support of segmentation and multi-tenancy is structured around 334 the propagation and use of Instance-IDs, and handled as part of the 335 EID in control plane operations. The encoding is described in 336 [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. 338 Depending on the particular deployment, both the L2 and L3 overlays 339 can be segmented. An Instance-ID can be used for L2 overlay 340 segmentation (e.g., VLAN extension) and for L3 overlay segments 341 (e.g., VRF extension or multi-VPN overlays). In all cases, the 342 Instance-ID is a 24-bit value. Instance-IDs are unique to a Mapping 343 System and MAY be used to identify the overlay type. 345 An important aspect of L2 overlay segmentation is the mapping of 346 VLANs to IIDs. In this case a Bridge Domain (which is the L2 347 equivalent to a VRF as a forwarding context) maps to an IID, a VLAN- 348 ID may map 1:1 to a bridge domain or different VLAN-IDs on different 349 ports may map to a common Bridge Domain, which in turn maps to an IID 350 in the L2 overlay. When ethernet traffic is double tagged, usually 351 the external 802.1Q tag will be mapped to a bridge domain on a per 352 port basis, and the inner 802.1Q tag will remain part of the payload 353 to be handled by the overlay. The IID should therefore be able to 354 carry ethernet traffic with or without an 802.1Q header. A port may 355 also be configured as a trunk and we may chose to take the 356 encapsulated traffic and map it to a single IID in order to multiplex 357 traffic from multiple VLANs on a single IID. These are all examples 358 of local operations that could be effected on VLANs in order to map 359 them to IIDs, they are provided as examples and are not exhaustive. 361 4.2. Database Mappings in Unified L2 and L3 Overlays 363 When an end-host is attached or detected in an ETR that provides 364 L2-overlay and L3-overlay services, two Database Mapping entries are 365 registered to the mapping system: 367 o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR 368 locator set (IP RLOC) 370 o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP 371 RLOC) 373 These two database mappings are the ones required to support L3 and 374 L2 forwarding. 376 The registration of these EIDs MUST follow the LCAF format as defined 377 in [I-D.ietf-lisp-lcaf]. 379 4.3. MAC as a Locator Record for ARP Resolution 381 When an end-host is attached or detected in an ETR that provides 382 L2-overlay services and supports ARP resolution using the LISP 383 control-plane, an additional mapping entry is registered to the 384 mapping system: 386 o The EID 2-tuple (IID, IP) and its binding to a corresponding host 387 MAC address. 389 In this case both the xTRs and the Mapping System MUST support an 390 EID-to-RLOC mapping where the MAC address is set as a locator record. 392 This mapping is registered with the Mapping System using the 393 following EID record structure, 394 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | Record TTL | 396 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 E | Locator Count | EID mask-len | ACT |A| Reserved | 398 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 D | Rsvd | Map-Version Number | AFI = 16387 | 400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 r | Rsvd1 | Flags | Type = 2 | IID mask-len | 402 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 c | 4 + n | Instance-ID... | 404 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 r | ...Instance-ID | EID-AFI = 1 or 2 | 406 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | EID-Prefix (IPv4 or IPv6) | 408 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | /| Priority | Weight | M Priority | M Weight | 410 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | M | Unused Flags |L|p|R| AFI = 16387 | 412 | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | 414 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | | 2 + 6 | AFI = 6 | 416 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | | Layer-2 MAC Address ... | 418 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | \| ... Layer-2 MAC Address | 420 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 422 An EID record with a locator record that carries a MAC address 423 follows the same structure as described in [RFC6830]. However, some 424 fields of the EID record and the locator record require special 425 consideration: 427 Locator Count: This value SHOULD be set to 1. 429 Instance-ID: This is the IID used to provide L2-overlay 430 segmentation. 432 Priority and Weight: IP to MAC bindings are one to one bindings. An 433 ETR SHOULD not register more than one MAC address in the locator 434 record together with an IP based EID. The Priority of the MAC 435 address record is set to 255. The Weight value SHOULD be ignored 436 and the recommendation is to set it to 0. 438 L bit: This bit of the locator record SHOULD only be set to 1 when 439 an ETR is registering its own IP to MAC binding. 441 p bit: This bit of the locator record SHOULD be set to 0. 443 R bit: This bit of the locator record SHOULD be set to 0. 445 Note that an IP EID record that carries a MAC address in the locator 446 record, SHOULD be registered with the Proxy Map-Reply bit set. 448 4.4. LISP Mapping System 450 The interface between the xTRs and the Mapping System is described in 451 [RFC6833] and this document follows the specification as described 452 there. When available, the registrations MAY be implemented over a 453 reliable transport as described in 454 [I-D.kouvelas-lisp-map-server-reliable-transport]. 456 4.5. Time-to-Live Handling in Data-Plane 458 The LISP specification ([RFC6830]) describes how to handle Time-to- 459 Live values of the inner and outer headers during encapsulation and 460 decapsulation of packets when using the L3 overlay. The same 461 approach SHOULD be followed for the unified overlay. 463 When using the L2 overlay and the encapsulated traffic is IP traffic, 464 the Time-to-Live value of the inner IP header MUST remain unmodified 465 at encapsulation and decapsulation. Network hops traversed as part 466 of the L2 overlay SHOULD be hidden to tools like traceroute and 467 applications that require direct L2 connectivity. 469 4.6. Using SMRs to Track Moved-Away State 471 One of the key elements to support end-host mobility using the LISP 472 architecture is the Solicit-Map-Request (SMR). This is an special 473 message by means of which an ETR can request an ITR to send a new 474 Map-Request for a particular EID record. In essence the SMR message 475 is used as a signal to indicate a change in mapping information and 476 it is described with detail in [RFC6830]. Section 5 provides a 477 packet flow description of the mobility support in a unified overlay. 479 In order to support mobility, an ETR SHALL maintain a list of EID 480 records for which it has to generate a SMR message whenever it 481 receives traffic with that EID as destination. This is called an 482 Away Table. 484 The particular strategy to maintain an Away Table is implementation 485 specific and it will be typically based on the strategy to detect the 486 presence of hosts and the use of the Map-Notifies received from the 487 Map-Server. In essence the table SHOULD provide support to the 488 following: 490 o Keep track of end-hosts that were once connected to an ETR and 491 have moved away. 493 o Support for L2 EID records, the 2-tuple (IID, MAC), for which a 494 SMR message SHOULD be generated. 496 o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR 497 message SHOULD be generated. 499 4.7. Non-Extended Subnets 501 The registration and access to non-extended subnets using the L3 502 overlay follows [RFC6830]. 504 Note also that non-extended subnets can also be treated as non-LISP 505 networks. In that case, providing access to the subnet to 506 participants of LISP overlays requires the use of a PxTR, following 507 the specification in [RFC6830]. 509 4.8. L2 Overlays and Multicast Groups 511 xTRs that offer L2 overlay services and are part of the same 512 Instance-ID join a common Multicast Group. When required, this group 513 allows ITRs to send traffic that needs to be replicated (flooded) to 514 all ETRs participating in the L2-overlay (e.g., broadcast traffic 515 within a subnet). When the core network (RLOC space) supports native 516 multicast ETRs participating in the L2-overlay join a (*,G) group 517 associated to the Instance-ID. 519 When multicast is not available in the core network, each xTR that is 520 part of the same instance-ID SHOULD join a (S,G) entry to the mapping 521 system using the procedures described in 522 [I-D.ietf-lisp-signal-free-multicast], where S is 0000-0000-0000/0 523 and G is ffff-ffff-ffff/48. This strategy allows and ITR to know 524 which ETRs are part of the L2 overlay and it can head-end replicate 525 traffic to. 527 4.9. L2 Broadcast, Unknown Unicast and Multicast traffic 529 Broadcast, Unknown Unicast and Multicast (BUM) traffic on the 530 L2-overlay is supported by either replicated unicast, or underlay 531 (RLOC) multicast. 533 5. EID Mobility Support 535 Support to end-host mobility is a basic requirement of state-of-art 536 overlay solutions. The unified overlay architecture described here 537 supports mobility both over L2-overlays and L3-overlays. This 538 section provides a packet flow sequence description of the mobility 539 support, detailing the use of the elements defined in the previous 540 section. 542 5.1. Reference Architecture 544 In order to support the packet flow description we use again the same 545 example as in Figure 1. In this particular case hosts may roam and 546 we distinguish the case when we have L2-mobility (e.g., IP hosts move 547 within their own subnet) or L3-mobility. 549 / | | \ 550 RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D 551 +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ 552 .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. 553 ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) 554 .' Site A ) .' Site B ) .' Site C ) .' Site D ) 555 ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . 556 ' ) ' ) 557 '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) 558 / '--' | '--' | '--' \ '--' 559 '--------' '--------' '--------' '--------' 560 : End : : End : : End : : End : 561 :Device 1: :Device 2: :Device 3: :Device 4: 562 '--------' '--------' '--------' '--------' 563 (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) 564 (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) 566 Figure 2: Reference Mobility Architecture 568 5.2. L2 Mobility: Packet Flow 570 The support to L2 mobility covers the requirements to allow an end- 571 host to move from a given site to another and maintain correspondence 572 with the rest of end-hosts that are connected to the same L2 domain 573 (e.g. extended VLAN). This support MUST ensure convergence of L2 574 forwarding (MAC based) from the old location to the new one, when the 575 host completes its move. 577 The following is a sequence description of the packet flow when End- 578 Device 2 in the figure moves to Site C, which is extending its own 579 subnet network. 581 o When End-Device 2 is attached or detected in site C, ETR C sets up 582 the database mapping corresponding to EID=. 583 ETR C sends a Map-Register to the mapping system registering 584 RLOC=IP_B as locator for EID=. 586 o The Mapping System, after receiving the new registration for 587 EID= sends a Map-Notify to ETR B with the new 588 locator set (IP_B). ETR B removes then its local database mapping 589 and stops registering . 591 o Any PiTR or ITR participating in the same L2-overlay 592 (corresponding to IID2) that was encapsulating traffic to 593 0:0:3:0:0:2 before the migration continues encapsulating this 594 traffic to ETR B. 596 o Once ETR B is notified by the Mapping system, when it receives 597 traffic from an ITR which is destined to 0:0:3:0:0:2, it will 598 generate a Solicit-Map-Request (SMR) message that is sent to the 599 ITR for (IID2,0:0:3:0:0:2). 601 o Upon receiving the SMR the ITR sends a new Map-Request for the 602 EID=. As a response ETR B sends a Map-Reply 603 that includes the new EID-to-RLOC mapping for 604 with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 605 replacing the previous one, and traffic is then forwarded to the 606 new location. 608 5.3. L3 Mobility: Packet Flow 610 The support to L3 mobility covers the requirements to allow an end- 611 host to move from a given site to another and maintain correspondence 612 with the rest of end-hosts that are connected to the same L3 routing 613 domain. This support MUST ensure convergence of L3 forwarding (IPv4/ 614 IPv6 based) from the old location to the new one when the host 615 completes its move. 617 The following is a sequence description of the packet flow when End- 618 Device 1 in the reference figure roams to site D: 620 o When End-Device 1 is attached or detected in site D, ETR D sets up 621 the database mapping corresponding to EID=. ETR D 622 sends a Map-Register to the mapping system registering RLOC=IP_D 623 as locator for EID=. Now the mapping system is 624 updated with the new EID-to-RLOC mapping (location) for End-Device 625 1. 627 o The Mapping System, after receiving the new registration for 628 EID= sends a Map-Notify to ETR A to inform it of 629 the move. Then, ETR A removes its local database mapping 630 information and stop registering EID=. 632 o Any ITR or PiTR participating in the L3 overlay (corresponding to 633 IID1) that were sending traffic to 1.0.0.1 before the migration 634 keep sending traffic to ETR A. 636 o Once ETR A is notified by the Mapping system, when it receives 637 traffic from an ITR with destination 1.0.0.1, it generates a 638 Solicit-Map-Request (SMR) back the ITR (or PiTR) for EID=. 641 o Upon receiving the SMR the ITR invalidates its local map- cache 642 entry for EID= and sends a new Map-Request for that 643 EID. The Map-Reply includes the new EID-to-RLOC mapping for End- 644 Device 1 with RLOC=IP_D. 646 o Similarly, once the local database mapping is removed from ITR A, 647 non-encapsulated packets arriving at ITR A from a local End-Device 648 and destined to End-Device 1 result in a cache miss, which 649 triggers sending a Map-Request for EID= to populate 650 the map-cache of ITR A. 652 6. Optional Deployment Models 654 The support of an integrated L2 and L3 overlay solution takes 655 multiple architectural design options, that depend on the specific 656 requirements of the deployment environment. While some of the 657 previous describe specific packet flows and solutions based on the 658 recommended solution, this section documents OPTIONAL design 659 considerations that differ from the recommended one but that MAY be 660 required on alternative deployment environments. 662 6.1. IP Forwarding of Intra-subnet Traffic 664 As pointed out at the beginning the recommended selection of the L2 665 and L3 overlays is not the only one possible. In fact, providing L2 666 extension to some cloud platforms is not always possible and subnets 667 need to be extended using the L3 overlay. 669 In order to send all IP traffic (intra- and inter-subnet) through the 670 L3 overlay the solution MUST change the ARP resolution process 671 described in Section 3.2.3 to the following one (we follow again 672 Figure 1 to drive the example. End-Device 2 queries about End-Device 673 3): 675 o End-Device 1 sends a broadcast ARP message to discover the MAC 676 address of 3.0.0.3. 678 o ITR B receives the ARP message and sends a Map-Request to the 679 Mapping System for 3.0.0.3. 681 o In this case, the Map-Request is routed by the Mapping system 682 infrastructure to ETR C, that will send a Map-Reply back to ITR B 683 containing the mapping 3.0.0.3 -> RLOC=IP_C. 685 o ITR B populates its local cache with the received entry on the L3 686 forwarding table. Then, using the cache information it sends a 687 Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- 688 Device 1. 690 o End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends 691 traffic with destination address 3.0.0.3 and destination MAC, 692 MAC_xTR_B. 694 o As the destination MAC address is the one from xTR B, when xTR B 695 receives this traffic is it forwarded using the L3-overlay. 697 o Note that when implementing this solution, when a host that is 698 local to an ETR moves away, the ETR SHOULD locally send a 699 Gratuitous ARP with its own MAC address and the IP of the moved 700 host, to refresh the ARP tables of local hosts and guarantee the 701 use of the L3 overlay when connecting to the remote host. 703 It is also important to note that using this strategy to extend 704 subnets through the L3 overlay but still keeping the L2 overlay for 705 the rest of traffic MAY lead to flow asymmetries. This MAY be the 706 case in deployments that filter Gratuitous ARPs, or when moved hosts 707 continue using actual L2 information collected before a migration. 709 6.2. Data-plane Encapsulation Options 711 The LISP control-plane offers independence from the data-plane 712 encapsulation. Any encapsulation format that can carry a 24-bit 713 instance-ID can be used to provide the unified overlay. 715 Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] 716 and [VXLAN]: 718 o VXLAN-GPE encap: This encapsulation format is defined in 719 [I-D.ietf-nvo3-vxlan-gpe]. It allows encapsulation both L2 and L3 720 packets and the VNI field directly maps to the Instance-ID used in 721 the control plane. Note that when using this encapsulation for a 722 unified solution the P-bit is set and the Next-Protocol field is 723 used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in 724 L3-overlays, and value 0x3 in L2-overlays). 726 o LISP encap: This is the encapsulation format defined in the 727 original LISP specification [RFC6830]. The encapsulation allows 728 encapsulating both L2 and L3 packets. The Instance-ID used in the 729 EIDs directly maps to the Instance-ID that the LISP header 730 carries. At the ETR, after decapsulation, the IID MAY be used to 731 decide between L2 processing or L3 processing. 733 o VXLAN encap: This is a L2 encapsulation format defined in 734 [RFC7348]. While being a L2 encapsulation it can be used both for 735 L2 and L3 overlays. The Instance-ID used in LISP signaling maps 736 to the VNI field of the VXLAN header. Providing L3 overlays using 737 VXLAN generally requires using the ETR MAC address as destination 738 MAC address of the inner Ethernet header. The process to learn or 739 derive this ETR MAC address is not included as part of this 740 document. 742 6.3. L2-only Deployments 744 The Unified architecture that this document specifies allows the 745 deployment of L3-only or L2-only overlays. By having a single 746 control plane where the mapping database can hold both MAC EIDs and 747 IP EIDs, the deployment of L2-only or L3-only architectures consists 748 in using only the relevant database mappings. 750 The requirements and use of LISP to support a L3-only overlay are 751 extensively documented in the original LISP specification and related 752 documents. 754 The provision of a L2-only overlay MUST provide support for intra- 755 subnet connectivity of end-hosts belonging to the same tenant, 756 including them in a unique L2 broadcast domain extended across the 757 network. 759 Provision such L2-only overlay SHALL take the following aspects into 760 account, as described before in Section 4: 762 o When an end-host is attached the ETR maintains and registers the 763 mappings EID = -> RLOC = and EID = -> 764 RLOC = . The second mapping is optional and is meant to be 765 used for ARP resolution. 767 o An ITR and Mapping-System provides support for ARP lookup and MAC 768 lookup using the lisp control-plane as described before in this 769 document. 771 o xTRs MUST provide support for Broadcast, Unknown and Multicast 772 (BUM) traffic through either replicated unicast or underlay (RLOC) 773 multicast. 775 o An ITR MUST treat a destination MAC for which it receives a 776 Negative Map-Reply with Native Forward action as BUM traffic and 777 replicate it to the ETRs in the Layer-2 overlay. 779 o To support end-host mobility, an ETR MUST be able to support an 780 Away Table (as described above) to keep track of end-hosts and 781 generate SMR messages when receiving traffic for end-hosts not 782 locally attached. 784 o TTL value of the inner-IP header SHOULD not be modified when 785 traversing the L2 overlay. 787 7. IANA Considerations 789 This memo includes no request to IANA. 791 8. Acknowledgements 793 This draft builds on top of two expired drafts that introduced the 794 concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft- 795 hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the 796 combined authors of those drafts, that SHOULD be considered main 797 contributors of this draft as well: Vina Ermagan, Dino Farinacci, 798 Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael 799 Smith. 801 9. References 803 9.1. Normative References 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, 807 DOI 10.17487/RFC2119, March 1997, 808 . 810 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 811 Locator/ID Separation Protocol (LISP)", RFC 6830, 812 DOI 10.17487/RFC6830, January 2013, 813 . 815 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 816 Locator/ID Separation Protocol (LISP) for Multicast 817 Environments", RFC 6831, DOI 10.17487/RFC6831, January 818 2013, . 820 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 821 Protocol (LISP) Map-Server Interface", RFC 6833, 822 DOI 10.17487/RFC6833, January 2013, 823 . 825 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 826 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 827 eXtensible Local Area Network (VXLAN): A Framework for 828 Overlaying Virtualized Layer 2 Networks over Layer 3 829 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 830 . 832 9.2. Informative References 834 [I-D.ietf-lisp-ddt] 835 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 836 Delegated Database Tree", draft-ietf-lisp-ddt-04 (work in 837 progress), March 2016. 839 [I-D.ietf-lisp-lcaf] 840 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 841 Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in 842 progress), September 2015. 844 [I-D.ietf-lisp-signal-free-multicast] 845 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 846 draft-ietf-lisp-signal-free-multicast-00 (work in 847 progress), December 2015. 849 [I-D.ietf-nvo3-vxlan-gpe] 850 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 851 Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, 852 P., and D. Melman, "Generic Protocol Extension for VXLAN", 853 draft-ietf-nvo3-vxlan-gpe-01 (work in progress), November 854 2015. 856 [I-D.kouvelas-lisp-map-server-reliable-transport] 857 Cassar, C., Kouvelas, I., Lewis, D., Arango, J., and J. 858 Leong, "LISP Map Server Reliable Transport", draft- 859 kouvelas-lisp-map-server-reliable-transport-01 (work in 860 progress), February 2016. 862 Authors' Addresses 863 Marc Portoles Comeras 864 Cisco Systems 865 170 Tasman Drive 866 San Jose, CA 95134 867 USA 869 Email: mportole@cisco.com 871 Vrushali Ashtaputre 872 Cisco Systems 873 170 Tasman Drive 874 San Jose, CA 95134 875 USA 877 Email: vrushali@cisco.com 879 Victor Moreno 880 Cisco Systems 881 170 Tasman Drive 882 San Jose, CA 95134 883 USA 885 Email: vimoreno@cisco.com 887 Fabio Maino 888 Cisco Systems 889 170 Tasman Drive 890 San Jose, CA 95134 891 USA 893 Email: fmaino@cisco.com 895 Dino Farinacci 896 lispers.net 897 San Jose, CA 898 USA 900 Email: farinacci@gmail.com