idnits 2.17.1 draft-maino-nvo3-lisp-cp-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-nvo3-dataplane-requirements' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-nve-nva-cp-req' is defined on line 897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-13) exists of draft-barkai-lisp-nfv-02 == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-mr-signaling-03 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-03 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-03 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-04 == Outdated reference: A later version (-03) exists of draft-ietf-nvo3-dataplane-requirements-01 == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-03 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-nve-nva-cp-req-00 == Outdated reference: A later version (-04) exists of draft-lewis-lisp-gpe-01 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-04 == Outdated reference: A later version (-04) exists of draft-quinn-vxlan-gpe-01 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-03 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino 3 Internet-Draft V. Ermagan 4 Intended status: Experimental Y. Hertoghs 5 Expires: April 21, 2014 Cisco Systems 6 D. Farinacci 7 lispers.net 8 M. Smith 9 Insieme Networks 10 October 18, 2013 12 LISP Control Plane for Network Virtualization Overlays 13 draft-maino-nvo3-lisp-cp-03 15 Abstract 17 The purpose of this draft is to analyze the mapping between the 18 Network Virtualization over L3 (NVO3) requirements and the 19 capabilities of the Locator/ID Separation Protocol (LISP) control 20 plane. This information is provided as input to the NVO3 analysis of 21 the suitability of existing IETF protocols to the NVO3 requirements. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 21, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . 4 64 3. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. LISP Site Configuration . . . . . . . . . . . . . . . . . 6 66 3.2. End System Provisioning . . . . . . . . . . . . . . . . . 6 67 3.3. End System Registration . . . . . . . . . . . . . . . . . 7 68 3.4. Packet Flow and Control Plane Operations . . . . . . . . 7 69 3.4.1. Supporting ARP Resolution with LISP Mapping System . 8 70 3.5. End System Mobility . . . . . . . . . . . . . . . . . . . 10 71 3.6. L3 LISP . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. LISP NVE Service Types . . . . . . . . . . . . . . . . . 14 74 4.1.1. LISP L2 NVE Services . . . . . . . . . . . . . . . . 14 75 4.1.2. LISP L3 NVE Services . . . . . . . . . . . . . . . . 14 76 5. Functional Components . . . . . . . . . . . . . . . . . . . . 14 77 5.1. Generic Service Virtualization Components . . . . . . . . 14 78 5.1.1. Virtual Attachment Points (VAPs) . . . . . . . . . . 15 79 5.1.2. Overlay Modules and Tenant ID . . . . . . . . . . . . 15 80 5.1.3. Tenant Instance . . . . . . . . . . . . . . . . . . . 15 81 5.1.4. Tunnel Overlays and Encapsulation Options . . . . . . 16 82 5.1.5. Control Plane Components . . . . . . . . . . . . . . 16 83 6. Key Aspects of Overlay . . . . . . . . . . . . . . . . . . . 17 84 6.1. Overlay Issues to Consider . . . . . . . . . . . . . . . 17 85 6.1.1. Data Plane vs. Control Plane Driven . . . . . . . . . 17 86 6.1.2. Data Plane and Control Plane Separation . . . . . . . 17 87 6.1.3. Handling Broadcast, Unknown Unicast and Multicast 88 (BUM) Traffic . . . . . . . . . . . . . . . . . . . . 17 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 10.2. Informative References . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 The purpose of this draft is to analyze the mapping between the 101 Network Virtualization over L3 (NVO3) 102 [I-D.ietf-nvo3-overlay-problem-statement] requirements and the 103 capabilities of the Locator/ID Separation Protocol (LISP) [RFC6830] 104 control plane. This information is provided as input to the NVO3 105 analysis of the suitability of existing IETF protocols to the NVO3 106 requirements. 108 LISP is a flexible map and encap framework that can be used for 109 overlay network applications, including Data Center Network 110 Virtualization. 112 The LISP framework provides two main tools for NVO3: (1) a Data Plane 113 that specifies how Endpoint Identifiers (EIDs) are encapsulated in 114 Routing Locators (RLOCs), and (2) a Control Plane that specifies the 115 interfaces to the LISP Mapping System that provides the mapping 116 between EIDs and RLOCs. 118 This document focuses on the control plane for L2 over L3 LISP 119 encapsulation, where EIDs are associated with MAC addresses. As such 120 the LISP control plane can be used with the data path encapsulations 121 defined in VXLAN [I-D.mahalingam-dutt-dcops-vxlan] and in NVGRE 122 [I-D.sridharan-virtualization-nvgre]. The LISP control plane can, of 123 course, be used with the L2 LISP data path encapsulation defined in 124 [I-D.smith-lisp-layer2]. 126 The LISP control plane provides the Mapping Service for the Network 127 Virtualization Edge (NVE), mapping per-tenant end system identity 128 information on the corresponding location at the NVE. As required by 129 NVO3, LISP supports network virtualization and tenant separation to 130 hide tenant addressing information, tenant-related control plane 131 activity and service contexts from the underlay network. 133 The LISP control plane is extensible, and can support non-LISP data 134 path encapsulations such as [I-D.sridharan-virtualization-nvgre], or 135 other encapsulations that provide support for network virtualization. 136 [RFC6832] specifies an open interworking framework to allow LISP to 137 non-LISP sites communication. 139 Broadcast, unknown unicast, and multicast in the overlay network are 140 supported by either replicated unicast, or core-based multicast as 141 specified in [RFC6831], [I-D.farinacci-lisp-mr-signaling], and 142 [I-D.farinacci-lisp-te]. 144 Finally, the LISP architecture has a modular design that allows the 145 use of different Mapping Databases, provided that the interface to 146 the Mapping System remains the same [RFC6833]. This allows for 147 different Mapping Databases that may fit different NVO3 deployments. 148 As an example of the modularity of the LISP Mapping System, a 149 worldwide LISP pilot network is currently using an hierarchical 150 Delegated Database Tree [I-D.ietf-lisp-ddt], after having been 151 operated for years with an overlay BGP mapping infrastructure 152 [RFC6836]. 154 The LISP mapping system supports network virtualization, and a single 155 mapping infrastructure can run multiple instances, either public or 156 private, of the mapping database. 158 The rest of this document, after giving a quick a LISP overview in 159 Section 3, follows the functional model defined in 160 [I-D.ietf-nvo3-framework] that provides in Section 4 an overview of 161 the LISP NVO3 reference model, and in Section 5 a description of its 162 functional components. Section 6 contains various considerations on 163 key aspects of LISP NVO3, followed by security considerations in 164 Section 7. 166 2. Definition of Terms 168 Flood-and-Learn: the use of dynamic (data plane) learning in VXLAN 169 to discover the location of a given Ethernet/IEEE 802 MAC address 170 in the underlay network. 172 ARP-Agent Reply: the ARP proxy-reply of an agent (e.g. an ITR) 173 with a MAC address of some other system in response to an ARP 174 request to a target which is not the agent's IP address 176 For definition of NVO3 related terms, notably Virtual Network (VN), 177 Virtual Network Identifier (VNI), Network Virtualization Edge (NVE), 178 Data Center (DC), please consult [I-D.ietf-nvo3-framework]. 180 For definitions of LISP related terms, notably Map-Request, Map- 181 Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- 182 Server (MS) and Map-Resolver (MR) please consult the LISP 183 specification [RFC6830]. 185 3. LISP Overview 187 This section provides a quick overview of L2 LISP, with focus on 188 control plane operations. 190 The modular and extensible architecture of the LISP control plane 191 allows its use with both L2 or L3 LISP data path encapsulation. In 192 fact, the LISP control plane can be used even with other L2 overlay 193 data path encapsulations such as VXLAN and NVGRE. When used with 194 VXLAN, the LISP control plane replaces the use of dynamic data plane 195 learning (Flood-and-Learn), as specified in 196 [I-D.mahalingam-dutt-dcops-vxlan] improving scalability and 197 mitigating multicast requirements in the underlay network. 199 For a detailed LISP overview please refer to [RFC6830] and related 200 drafts. 202 To exemplify LISP operations let's consider two data centers (LISP 203 sites) A and B that provide L2 network virtualization services to a 204 number of tenant end systems, as depicted in Figure 1. The Endpoint 205 Identifiers (EIDs) are encoded according to [I-D.ietf-lisp-lcaf] as 206 an tuple that contains the Instance ID, or Virtual Network 207 Identifier (VNI), and the endpoint Ethernet/IEEE 802 MAC address. 209 The data centers are connected via a L3 underlay network, hence the 210 Routing Locators (RLOCs) are IP addresses (either IPv4 or IPv6) 211 encoded according to [I-D.ietf-lisp-lcaf]. 213 In LISP the network virtualization edge function is performed by 214 Ingress Tunnel Routers (ITRs) that are responsible for encapsulating 215 the LISP ingress traffic, and Egress Tunnel Routers (ETRs) that are 216 responsible for decapsulating the LISP egress traffic. ETRs are also 217 responsible to register the EID-to-RLOC mapping for a given LISP site 218 in the LISP mapping database system. ITRs and ETRs are collectively 219 referred as xTRs. 221 The EID-to-RLOC mapping is stored in the LISP mapping database, a 222 distributed mapping infrastructure accessible via Map Servers (MS) 223 and Map Resolvers (MR). [I-D.ietf-lisp-ddt] is an example of a 224 mapping database used in many LISP deployments. Another example of 225 of mapping database is [RFC6836]. 227 For small deployments the mapping infrastructure can be very minimal, 228 in some cases even a single system running as MS/MR. 230 ,---------. 231 ,' `. 232 (Mapping System ) 233 `. ,' 234 `-+------+' 235 +--+--+ +-+---+ 236 |MS/MR| |MS/MR| 237 +-+---+ +-----+ 238 | | 239 .--..--. .--. .. 241 ( ' '.--. 242 .-.' L3 ' 243 ( Underlay ) 244 ( '-' 245 ._.'--'._.'.-._.'.-._) 246 RLOC=IP_A // \\ RLOC=IP_B 247 +---+--+ +-+--+--+ 248 .--.-.|xTR A |'.-. .| xTR B |.-. 249 ( +---+--+ ) ( +-+--+--+ ) 250 ( __. ( '. 251 ..' LISP Site A ) .' LISP Site B ) 252 ( .'-' ( .'-' 253 '--'._.'. )\ '--'._.'. )\ 254 / '--' \ / '--' \ 255 '--------' '--------' '--------' '--------' 256 : End : : End : : End : : End : 257 : Device : : Device : : Device : : Device : 258 '--------' '--------' '--------' '--------' 259 EID= EID= EID= EID= 260 262 Figure 1: Example of L2 NVO3 Services 264 3.1. LISP Site Configuration 266 In each LISP site the xTRs are configured with an IP address (the 267 site RLOCs) per each interface facing the underlay network. 269 Similarly the MS/MR are assigned an IP address in the RLOC space. 271 The configuration of the xTRs includes the RLOCs of the MS/MR and a 272 shared secret that is optionally used to secure the communication 273 between xTRs and MS/MR. 275 To provide support for multi-tenancy multiple instances of the 276 mapping database are identified by a LISP Instance ID (IID), that is 277 equivalent to the 24-bit VXLAN Network Identifier (VNI) or Tenant 278 Network Identifier (TNI) that identifies tenants in 279 [I-D.mahalingam-dutt-dcops-vxlan]. 281 3.2. End System Provisioning 282 We assume that a provisioning framework will be responsible for 283 provisioning end systems (e.g. VMs) in each data center. The 284 provisioning system configures each end system with an Ethernet/IEEE 285 802 MAC address and/or IP address and provisions the NVE with other 286 end system specific attributes such as VLAN information, and TS/VLAN 287 to VNI mapping information. LISP does not introduce new addressing 288 requirements for end systems. 290 The provisioning infrastructure is also responsible to provide a 291 network attach function, that notifies the network virtualization 292 edge (the LISP site ETR) that the end system is attached to a given 293 virtual network (identified by its VNI/IID) and that the end system 294 is identified, within that virtual network, by a given Ethernet/IEEE 295 802 MAC address. 297 3.3. End System Registration 299 Upon notification of end system network attach, that includes the 300 EID= tuple that identifies that end system, the ETR sends a 301 LISP Map-Register to the Mapping System. The Map-Register includes 302 the EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now 303 available, via the Mapping System Infrastructure, to other LISP sites 304 that are hosting end systems that belong to the same tenant. 306 For more details on end system registration see [RFC6833]. 308 3.4. Packet Flow and Control Plane Operations 310 This section provides an example of the unicast packet flow and the 311 control plane operations when in the topology shown in Figure 1 end 312 system W, in LISP site A, wants to communicate to end system Y in 313 LISP site B. We'll assume that W knows Y's EID MAC address (e.g. 314 learned via ARP). 316 o W sends an Ethernet/IEEE 802 MAC frame with destination 317 EID= and source EID=. 319 o ITR A does a lookup in its local map-cache for the destination 320 EID=. Since this is the first packet sent to MAC_Y, 321 the map-cache is a miss, and the ITR sends a Map-request to the 322 mapping database system looking up the EID=. 324 o The mapping systems forwards the Map-Request to ETR B, that is 325 aware of the EID-to-RLOC mapping for . Alternatively, 326 depending on the mapping system configuration, a Map-Server which 327 is part of the mapping database system may send a Map-Reply 328 directly to ITR A. 330 o ETR B sends a Map-Reply to ITR A that includes the EID-to-RLOC 331 mapping: EID= -> RLOC=IP_B, where IP_B is the locator 332 of ETR B, hence the locator of LISP site B. In order to facilitate 333 interoperability, the Map-Reply may also include attributes such 334 as the data plane encapsulations supported by the ETR. 336 o ITR A populates the local map-cache with the EID to RLOC mapping, 337 and either L2 LISP, VXLAN, or NVGRE encapsulates all subsequent 338 packets with a destination EID= with a destination 339 RLOC=IP_B. 341 It should be noted how the LISP mapping system replaces the use of 342 Flood-and-Learn based on multicast distribution trees instantiated in 343 the underlay network (required by VXLAN's dynamic data plane 344 learning), with a unicast control plane and a cache mechanism that 345 "pulls" on-demand the EID-to-RLOC mapping from the LISP mapping 346 database. This improves scalability, and simplifies the 347 configuration of the underlay network. 349 3.4.1. Supporting ARP Resolution with LISP Mapping System 351 A large majority of data center applications are IP based, and in 352 those use cases end systems are provisioned with IP addresses as well 353 as MAC addresses. 355 In this case, to eliminate the flooding of ARP traffic and further 356 reduce the need for multicast in the underlay network, the LISP 357 mapping system is used to support ARP resolution at the ITR. We 358 assume that as shown in Figure 2: (1) end system W has an IP address 359 IP_W, and end system Y has an IP address IP_Y, (2) end system W knows 360 Y's IP address (e.g. via DNS lookup). We also assume that during 361 registration Y has registered both its MAC address and its IP address 362 as EID. End system Y is then identified by the EID = 363 . 365 ,---------. 366 ,' `. 367 (Mapping System ) 368 `. ,' 369 `-+------+' 370 +--+--+ +-+---+ 371 |MS/MR| |MS/MR| 372 +-+---+ +-----+ 373 | | 374 .--..--. .--. .. 375 ( ' '.--. 376 .-.' L3 ' 377 ( Underlay ) 378 ( '-' 379 ._.'--'._.'.-._.'.-._) 380 RLOC=IP_A // \\ RLOC=IP_B 381 +---+--+ +-+--+--+ 382 .--.-.|xTR A |'.-. .| xTR B |.-. 383 ( +---+--+ ) ( +-+--+--+ ) 384 ( __. ( '. 385 ..' LISP Site A ) .' LISP Site B ) 386 ( .'-' ( .'-' 387 '--'._.'. )\ '--'._.'. )\ 388 / '--' \ / '--' \ 389 '--------' '--------' '--------' '--------' 390 : End : : End : : End : : End : 391 : Device : : Device : : Device : : Device : 392 '--------' '--------' '--------' '--------' 393 EID= EID= EID= EID= 394 MAC_X> MAC_Y> MAC_Z> 397 Figure 2: Example of L3 NVO3 Services 399 The packet flow and control plane operation are as follows: 401 o End system W sends a broadcast ARP message to discover the MAC 402 address of end system Y. The message contains IP_Y in the ARP 403 message payload. 405 o ITR A, acting as a L2 switch, will receive the ARP message, but 406 rather than flooding it on the overlay network sends a Map-Request 407 to the mapping database system for EID = . 409 o The Map-Request is routed by the mapping system infrastructure to 410 ETR B, that will send a Map-Reply back to ITR A containing the 411 mapping EID= -> RLOC=IP_B, (the locator of ETR 412 B). Alternatively, depending on the mapping system configuration, 413 a Map-Server in the mapping system may send directly a Map-Reply 414 to ITR A. 416 o ITR A populates the map-cache with the received entry, and sends 417 an ARP-Agent Reply to W that includes MAC_Y and IP_Y. 419 o End system W learns MAC_Y from the ARP message and can now send a 420 packet to end system Y by including MAC_Y, and IP_Y, as 421 destination addresses. 423 o ITR A will then process the packet as specified in Section 3.4. 425 This example shows how LISP, by replacing dynamic data plane learning 426 (Flood-and-Learn) largely reduces the need for multicast in the 427 underlay network, that is needed only when broadcast, unknown unicast 428 or multicast are required by the applications in the overlay. In 429 practice, the LISP mapping system, constrains ARP within the 430 boundaries of a link-local protocol. This simplifies the 431 configuration of the underlay network and removes the significant 432 scalability limitation imposed by VXLAN Flood-and-Learn. 434 It's important to note that the use of the LISP mapping system, by 435 pulling the EID-to-RLOC mapping on demand, also improves end system 436 mobility across data centers. 438 3.5. End System Mobility 440 This section shows how the LISP control plane deals with mobility 441 when end systems are migrated from one Data Center to another. We'll 442 assume that a signaling protocol, as described in 443 [I-D.kompella-nvo3-server2nve], signals to the NVE operations such as 444 creating/terminating/migrating an end system. The signaling protocol 445 consists of three basic messages: "associate", "dissociate", and 446 "pre-associate". 448 Let's consider the scenario shown in Figure 3 where end system W 449 moves from data center A to data center B. 451 ,---------. 452 ,' `. 453 (Mapping System ) 454 `. ,' 455 `-+------+' 456 +--+--+ +-+---+ 457 |MS/MR| |MS/MR| 458 +-+---+ +-----+ 459 | | 460 .--..--. .--. .. 461 ( ' '.--. 462 .-.' L3 ' 463 ( Underlay ) 464 ( '-' 465 ._.'--'._.'.-._.'.-._) 466 RLOC=IP_A // \\ RLOC=IP_B 467 +---+--+ +-+--+--+ 468 .--.-.|xTR A |'.-. .| xTR B |.-. 469 ( +---+--+ ) ( +-+--+--+ ) 470 ( __. ( '. 471 ..' LISP Site A ) .' LISP Site B ) 472 ( .'-' ( .'-' 473 '--'._.'. )\ '--'._.'. )\ 474 / '--' \ / '--' \ 475 '--------' '--------' '--------' '--------' 476 : End : : End : ==> : End : : End : 477 : Device : : Device : ==> : Device : : Device : 478 '--------' '--------' '--------' '--------' 479 EID= EID= EID= 480 482 Figure 3: End System Mobility 484 As a result of the end system registration, described in Section 3.3, 485 the Mapping System contains the EID-to-RLOC mapping for end system W 486 that associates EID= with the RLOC(s) associated with 487 LISP site A (IP_A). 489 The process of migrating end system W from data center A to data 490 center B is initiated. 492 ETR B receives a pre-associate message that includes EID=. ETR B sends a Map-Register to the mapping system registering 494 RLOC=IP_B as an additional locator for end system W with priority set 495 to 255. This means that the RLOC MUST NOT be used for unicast 496 forwarding, but the mapping system is now aware of the new location. 498 During the migration process of end system W, ETR A receives a 499 dissociate message, and sends a Map-Register with Record TTL=0 to 500 signal the mapping system that end system W is no longer reachable at 501 RLOC=IP_A. xTR A will also add an entry in its forwarding table that 502 marks EID= as non-local. When end system W has 503 completed its migration, ETR B receives an associate message for end 504 system W, and sends a Map-Register to the mapping system setting a 505 non-255 priority for RLOC=IP_B. Now the mapping system is updated 506 with the new EID-to-RLOC mapping for end system W with the desired 507 priority. 509 The remote ITRs that were corresponding with end system W during the 510 migration will keep sending packets to ETR A. ETR A will keep 511 forwarding locally those packets until it receives a dissociate 512 message, and the entry in the forwarding table associated with 513 EID= is marked as non-local. Subsequent packets 514 arriving at ETR A from a remore ITR, and destined to end system W 515 will hit the entry in the forwarding table that will generate an 516 exception, and will generate a Solicit-Map-Request (SMR) message that 517 is returned to the remote ITR. Upon receiving the SMR the remote ITR 518 will invalidate its local map-cache entry for EID= and 519 send a new Map-Request for that EID. The Map-Request will generate a 520 Map-Reply that includes the new EID-to-RLOC mapping for end system W 521 with RLOC=IP_B. Similarly, unencapsulated packets arriving at ITR A 522 from local end systems and destined to end system W will hit the 523 entry in the forwarding table marked as non-local, and will generate 524 an exception that by sending a Map-Request for EID= will 525 populate the map-cache of ITR A with an EID-to-RLOC mapping for end 526 system W with RLOC=IP_B. 528 3.6. L3 LISP 530 The two examples above shows how the LISP control plane can be used 531 in combination with either L2 LISP, VXLAN, or NVGRE encapsulation to 532 provide L2 network virtualization services across data centers. 534 There is a trend, led by Massive Scalable Data Centers, that is 535 accelerating the adoption of L3 network services in the data center, 536 to preserve the many benefits introduced by L3 (scalability, multi- 537 homing, ...). 539 LISP, as defined in [RFC6830], provides L3 network virtualization 540 services over an L3 underlay network that, as an alternative to L2 541 overlay solutions, matches the requirements for DC Network 542 Virtualization. L2 overlay solutions are necessary for Data Centers 543 that rely on non IPv4/IPv6 protocols, but when IP is pervasive L3 544 LISP provides a better and more scalable overlay. 546 4. Reference Model 548 Figure 4, taken from [I-D.ietf-nvo3-framework], introduces the NVO3 549 reference model. 551 In a LISP NVO3 network the Tenant Systems (TS) that are homed to a 552 common NVE, having specific Endpoint Identifiers (EIDs), are part of 553 a 'LISP site'. 555 The network virtualization edge (NVE) function is performed by 556 Ingress Tunnel Routers (ITRs) that are responsible for encapsulating 557 the LISP ingress traffic, and Egress Tunnel Routers (ETRs) that are 558 responsible for de-encapsulating the LISP egress traffic. 560 The outer tunnel IP addresses (either IPv4 or IPv6) on the ITR and 561 ETR NVE function are known as Routing Locators (RLOCs). 563 ETRs are also responsible to register the EID-to-RLOC mapping for a 564 given LISP site in the LISP mapping database system [RFC6833] . 566 ITRs and ETRs, collectively referred as xTRs, provide for tenant 567 separation, perform the encap/decap function, and interface with the 568 LISP Mapping System that maps tenant addressing information (in the 569 EID name space) on the underlay L3 infrastructure (in the RLOC name 570 space), with the encoding defined in [I-D.ietf-lisp-lcaf]. 572 The LISP Mapping system is a distributed mapping infrastructure, 573 accessible via Map Servers (MS) and Map Resolvers (MR), that performs 574 the NVA function. 576 The LISP Mapping system can be scaled across various physical 577 components e.g. across an EID based hierarchy as described in 578 [I-D.ietf-lisp-ddt]. EID prefixes and/or address families can thus 579 be scaled across the mapping infrastructure if needed. 581 The NVA function can offer a northbound SDN interface in order to 582 program the EID to RLOC mapping from e.g. an orchestration system. 583 An example is given in [I-D.barkai-lisp-nfv] . 585 As traffic reaches An ingress NVE, the corresponding ITR uses the 586 LISP Map-Request/Reply service to determine the location of the 587 destination End System. 589 The LISP mapping system combines the distribution of address 590 advertisement and (stateless) tunneling provisioning. 592 LISP defines several mechanisms for determining RLOC reachability, 593 including Locator Status Bits, "nonce echoing", and RLOC probing. 594 Please see Sections 5.3 and 6.3 of [RFC6830]. However, given the 595 fact that DC's are typically deployed with a single stage IGP 596 hierarchy, the IGP responsible for the RLOC space offers enough 597 reachability information. 599 +--------+ +--------+ 600 | Tenant +--+ +----| Tenant | 601 | System | | (') | System | 602 +--------+ | ................. ( ) +--------+ 603 | +---+ +---+ (_) 604 +--|NVE|---+ +---|NVE|-----+ 605 +---+ | | +---+ 606 / . +-----+ . 607 / . +--| NVA | . 608 / . | +-----+ . 609 | . | . 610 | . | L3 Overlay +--+--++--------+ 611 +--------+ | . | Network | NVE || Tenant | 612 | Tenant +--+ . | | || System | 613 | System | . \ +---+ +--+--++--------+ 614 +--------+ .....|NVE|......... 615 +---+ 616 | 617 | 618 ===================== 619 | | 620 +--------+ +--------+ 621 | Tenant | | Tenant | 622 | System | | System | 623 +--------+ +--------+ 625 Figure 4: NVO3 Generic Reference Model 627 4.1. LISP NVE Service Types 629 L2 NVE and L3 NVE service types thanks to the flexibility provided by 630 the LISP Canonical Address Format [I-D.ietf-lisp-lcaf], that allows 631 for EIDs to be encoded either as MAC addresses or IP addresses. 633 4.1.1. LISP L2 NVE Services 635 The frame format defined in [I-D.mahalingam-dutt-dcops-vxlan], has a 636 header compatible with the LISP data path encapsulation header, when 637 MAC addresses are used as EIDs, as described in section 4.12.2 of 638 [I-D.ietf-lisp-lcaf]. 640 The LISP control plane is extensible, and can support non-LISP data 641 path encapsulations such as NVGRE 642 [I-D.sridharan-virtualization-nvgre], or other encapsulations that 643 provide support for network virtualization. 645 4.1.2. LISP L3 NVE Services 647 LISP is defined as a virtualized IP routing and forwarding service in 648 [RFC6830], and as such can be used to provide L3 NVE services. 650 5. Functional Components 652 This section describes the functional components of a LISP NVE as 653 defined in Section 3 of [I-D.ietf-nvo3-framework]. 655 5.1. Generic Service Virtualization Components 657 The generic reference model for NVE is depicted in 658 [I-D.ietf-nvo3-framework]. 660 +-------- L3 Network -------+ 661 | | 662 | Tunnel Overlay | 663 +------------+---------+ +---------+------------+ 664 | +----------+-------+ | | +---------+--------+ | 665 | | Overlay Module | | | | Overlay Module | | 666 | +---------+--------+ | | +---------+--------+ | 667 | |VN context| | VN context| | 668 | | | | | | 669 | +--------+-------+ | | +--------+-------+ | 670 | | |VNI| . |VNI| | | | |VNI| . |VNI| | 671 NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2 672 | | VAPs | | | | VAPs | | 673 +----+------------+----+ +----+-----------+-----+ 674 | | | | 675 | | | | 676 Tenant Systems Tenant Systems 678 Figure 5: Generic reference model for NV Edge 680 5.1.1. Virtual Attachment Points (VAPs) 682 In a LISP NVE, Tunnel Routers (xTRs) implement the NVE functionality 683 on ToRs or Virtual Switches. Tenant Systems attach to the Virtual 684 Access Points (VAPs) provided by the xTRs (either a physical port or 685 a virtual interface). 687 The VAPs are identified by either a physical port or a virtual 688 interface, e.g. Indexed by VLAN tags, a set, range, or set of ranges 689 of VLAN tags in the case of a L2 service, or a virtual routed 690 interface Indexed by a VLAN in case of a L3 service, or a combination 691 of them in case of An L2/L3 service. 693 5.1.2. Overlay Modules and Tenant ID 695 The xTR also implements the function of NVE Overlay Module, by 696 mapping the addressing information (EIDs) of the tenant packet on the 697 appropriate locations (RLOCs) in the underlay network. The Virtual 698 Network Identifier (VNI) is encoded in the encapsulated packet 699 (either in the 24-bit IID field of the LISP header for L2/L3 LISP 700 encapsulation, or in the 24-bit VXLAN Network Identifier field for 701 VXLAN encapsulation, or in the 24-bit NVGRE Tenant Network Identifier 702 field of NVGRE). In a LISP NVE globally unique (per administrative 703 domain) VNIs are used to identify the Tenant instances. 705 The mapping of the tenant packet address onto the underlay network 706 location is "pulled" on-demand from the mapping system, and cached at 707 the NVE in a per-VNI map-cache. 709 5.1.3. Tenant Instance 711 Tenants are mapped on LISP Instance IDs (IIDs), and the LISP Control 712 Plane uses the IID to provide segmentation and virtualization. The 713 ETR is responsible to register the Tenant System to the LISP mapping 714 system, via the Map-Register service provided by LISP Map-Servers 715 (MS). The Map-Register includes the IID that is used to identify the 716 tenant. 718 5.1.4. Tunnel Overlays and Encapsulation Options 720 The LISP control protocol, as defined today, provides support for L2 721 LISP and VXLAN L2 over L3 encapsulation, and LISP L3 over L3 722 encapsulation, as well as support for the Generic Protocol Extensions 723 for LISP and VXLAN defined in [I-D.lewis-lisp-gpe] and 724 [I-D.quinn-vxlan-gpe] respectively. The Generic Protocol Extensions 725 can be used to offer a concurrent L2 and L3 overlay across the same 726 dataplane. 728 We believe that the LISP control Protocol can be easily extended to 729 support different IP tunneling options (such as NVGRE). 731 5.1.5. Control Plane Components 733 5.1.5.1. Auto-provisioning/Service Discovery 735 The LISP framework does not include mechanisms to provision the local 736 NVE with the appropriate Tenant Instance for each Tenant System. 737 Other protocols, such as VDP (in IEEE P802.1Qbg), should be used to 738 implement a network attach/detach function. 740 The LISP control plane can take advantage of such a network attach/ 741 detach function to trigger the registration of a Tenant End System to 742 the Mapping System. This is particularly helpful to handle mobility 743 across DC of the Tenant End System. 745 It is possible to extend the LISP control protocol to advertise the 746 tenant service instance (tenant and service type provided) to other 747 NVEs, and facilitate interoperability between NVEs that are using 748 different service types. 750 5.1.5.2. Address Advertisement and Tunnel mapping 752 As traffic reaches an ingress NVE, the corresponding ITR uses the 753 LISP Map-Request/Reply service to determine the location of the 754 destination End System. 756 The LISP mapping system combines the distribution of address 757 advertisement and (stateless) tunneling provisioning. 759 When EIDs are mapped on both IP addresses and MACs, the need to flood 760 ARP messages at the NVE is eliminated resolving the issues with 761 explosive ARP handling. 763 5.1.5.3. Tunnel Management 765 LISP defines several mechanisms for determining RLOC reachability, 766 including Locator Status Bits, "nonce echoing", and RLOC probing. 767 Please see Sections 5.3 and 6.3 of [RFC6830]. 769 6. Key Aspects of Overlay 771 6.1. Overlay Issues to Consider 773 6.1.1. Data Plane vs. Control Plane Driven 775 The use of LISP control plane minimizes the need for multicast in the 776 underlay network overcoming the scalability limitations of VXLAN 777 dynamic data plane learning (Flood-and-Learn). 779 Multicast or ingress replication in the underlay network are still 780 required, as specified in [RFC6831], 781 [I-D.farinacci-lisp-mr-signaling], and [I-D.farinacci-lisp-te], to 782 support broadcast, unknown, and multicast traffic in the overlay, but 783 multicast in the underlay is no longer required (at least for IP 784 traffic) for unicast overlay services. 786 6.1.2. Data Plane and Control Plane Separation 788 LISP introduces a clear separation between data plane and control 789 plane functions. LISP modular design allows for different mapping 790 databases, to achieve different scalability goals and to meet 791 requirements of different deployments. 793 6.1.3. Handling Broadcast, Unknown Unicast and Multicast (BUM) Traffic 795 Packet replication in the underlay network to support broadcast, 796 unknown unicast and multicast overlay services can be done by: 798 o Ingress replication 800 o Use of underlay multicast trees 802 [RFC6831] specifies how to map a multicast flow in the EID space 803 during distribution tree setup and packet delivery in the underlay 804 network. LISP-multicast doesn't require packet format changes in 805 multicast routing protocols, and doesn't impose changes in the 806 internal operation of multicast in a LISP site. The only operational 807 changes are required in PIM-ASM [RFC4601], MSDP [RFC3618], and PIM- 808 SSM [RFC4607]. 810 7. Security Considerations 812 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 813 origin authentication, integrity and anti-replay protection to LISP's 814 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 815 SEC also enables verification of authorization on EID-prefix claims 816 in Map-Reply messages. 818 Additional security mechanisms to protect the LISP Map-Register 819 messages are defined in [RFC6833]. 821 The security of the Mapping System Infrastructure depends on the 822 particular mapping database used. The [I-D.ietf-lisp-ddt] 823 specification, as an example, defines a public-key based mechanism 824 that provides origin authentication and integrity protection to the 825 LISP DDT protocol. 827 8. IANA Considerations 829 This document has no IANA implications 831 9. Acknowledgements 833 The authors want to thank Victor Moreno and Paul Quinn for the early 834 review, insightful comments and suggestions. 836 10. References 838 10.1. Normative References 840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, March 1997. 843 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 844 Protocol (MSDP)", RFC 3618, October 2003. 846 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 847 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 848 Protocol Specification (Revised)", RFC 4601, August 2006. 850 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 851 IP", RFC 4607, August 2006. 853 10.2. Informative References 855 [I-D.barkai-lisp-nfv] 856 sbarkai@gmail.com, s., Farinacci, D., Meyer, D., Maino, 857 F., and V. Ermagan, "LISP Based FlowMapping for Scaling 858 NFV", draft-barkai-lisp-nfv-02 (work in progress), July 859 2013. 861 [I-D.farinacci-lisp-mr-signaling] 862 Farinacci, D. and M. Napierala, "LISP Control-Plane 863 Multicast Signaling", draft-farinacci-lisp-mr-signaling-03 864 (work in progress), September 2013. 866 [I-D.farinacci-lisp-te] 867 Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 868 Engineering Use-Cases", draft-farinacci-lisp-te-03 (work 869 in progress), July 2013. 871 [I-D.ietf-lisp-ddt] 872 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 873 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 874 progress), March 2013. 876 [I-D.ietf-lisp-lcaf] 877 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 878 Address Format (LCAF)", draft-ietf-lisp-lcaf-03 (work in 879 progress), September 2013. 881 [I-D.ietf-lisp-sec] 882 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 883 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- 884 ietf-lisp-sec-04 (work in progress), October 2012. 886 [I-D.ietf-nvo3-dataplane-requirements] 887 Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., 888 and B. Khasnabish, "NVO3 Data Plane Requirements", draft- 889 ietf-nvo3-dataplane-requirements-01 (work in progress), 890 July 2013. 892 [I-D.ietf-nvo3-framework] 893 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 894 Rekhter, "Framework for DC Network Virtualization", draft- 895 ietf-nvo3-framework-03 (work in progress), July 2013. 897 [I-D.ietf-nvo3-nve-nva-cp-req] 898 Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network 899 Virtualization NVE to NVA Control Protocol Requirements", 900 draft-ietf-nvo3-nve-nva-cp-req-00 (work in progress), July 901 2013. 903 [I-D.ietf-nvo3-overlay-problem-statement] 904 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., 905 and M. Napierala, "Problem Statement: Overlays for Network 906 Virtualization", draft-ietf-nvo3-overlay-problem- 907 statement-04 (work in progress), July 2013. 909 [I-D.kompella-nvo3-server2nve] 910 Kompella, K., Rekhter, Y., Morin, T., and D. Black, 911 "Signaling Virtual Machine Activity to the Network 912 Virtualization Edge", draft-kompella-nvo3-server2nve-02 913 (work in progress), April 2013. 915 [I-D.lewis-lisp-gpe] 916 Lewis, D., Agarwal, P., Kreeger, L., Quinn, P., Smith, M., 917 and N. Yadav, "LISP Generic Protocol Extension", draft- 918 lewis-lisp-gpe-01 (work in progress), October 2013. 920 [I-D.mahalingam-dutt-dcops-vxlan] 921 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 922 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 923 Framework for Overlaying Virtualized Layer 2 Networks over 924 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-04 925 (work in progress), May 2013. 927 [I-D.quinn-vxlan-gpe] 928 Quinn, P., Agarwal, P., Fernando, R., Lewis, D., Kreeger, 929 L., Smith, M., and N. Yadav, "Generic Protocol Extension 930 for VXLAN", draft-quinn-vxlan-gpe-01 (work in progress), 931 October 2013. 933 [I-D.smith-lisp-layer2] 934 Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 935 (L2) LISP Encapsulation Format", draft-smith-lisp- 936 layer2-03 (work in progress), September 2013. 938 [I-D.sridharan-virtualization-nvgre] 939 Sridharan, M., Greenberg, A., Wang, Y., Garg, P., 940 Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson, 941 M., Thaler, P., and C. Tumuluri, "NVGRE: Network 942 Virtualization using Generic Routing Encapsulation", 943 draft-sridharan-virtualization-nvgre-03 (work in 944 progress), August 2013. 946 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 947 Locator/ID Separation Protocol (LISP)", RFC 6830, January 948 2013. 950 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 951 Locator/ID Separation Protocol (LISP) for Multicast 952 Environments", RFC 6831, January 2013. 954 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 955 "Interworking between Locator/ID Separation Protocol 956 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 958 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 959 Protocol (LISP) Map-Server Interface", RFC 6833, January 960 2013. 962 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 963 "Locator/ID Separation Protocol Alternative Logical 964 Topology (LISP+ALT)", RFC 6836, January 2013. 966 Authors' Addresses 968 Fabio Maino 969 Cisco Systems 970 170 Tasman Drive 971 San Jose, California 95134 972 USA 974 Email: fmaino@cisco.com 976 Vina Ermagan 977 Cisco Systems 978 170 Tasman Drive 979 San Jose, California 95134 980 USA 982 Email: vermagan@cisco.com 984 Yves Hertoghs 985 Cisco Systems 986 6a De Kleetlaan 987 Diegem 1831 988 Belgium 990 Phone: +32-2778-435 991 Fax: +32-2704-6000 992 Email: yves@cisco.com 993 Dino Farinacci 994 lispers.net 996 Email: farinacci@gmail.com 998 Michael Smith 999 Insieme Networks 1000 California 1001 USA 1003 Email: michsmit@insiemenetworks.com