idnits 2.17.1 draft-maino-nvo3-lisp-cp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4176 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-mr-signaling-00 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-00 == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-01 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-00 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-14 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-02 == Outdated reference: A later version (-04) exists of draft-ietf-nvo3-overlay-problem-statement-00 == Outdated reference: A later version (-02) exists of draft-kompella-nvo3-server2nve-00 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-01 == Outdated reference: A later version (-03) exists of draft-smith-lisp-layer2-00 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-00 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). 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 D. Farinacci 5 Expires: April 25, 2013 Cisco Systems 6 M. Smith 7 Insieme Networks 8 October 22, 2012 10 LISP Control Plane for Network Virtualization Overlays 11 draft-maino-nvo3-lisp-cp-02 13 Abstract 15 The purpose of this draft is to analyze the mapping between the 16 Network Virtualization over L3 (NVO3) requirements and the 17 capabilities of the Locator/ID Separation Protocol (LISP) control 18 plane. This information is provided as input to the NVO3 analysis of 19 the suitability of existing IETF protocols to the NVO3 requirements. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 63 3. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. LISP Site Configuration . . . . . . . . . . . . . . . . . 6 65 3.2. End System Provisioning . . . . . . . . . . . . . . . . . 7 66 3.3. End System Registration . . . . . . . . . . . . . . . . . 7 67 3.4. Packet Flow and Control Plane Operations . . . . . . . . . 7 68 3.4.1. Supporting ARP Resolution with LISP Mapping System . . 8 69 3.5. End System Mobility . . . . . . . . . . . . . . . . . . . 10 70 3.6. L3 LISP . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. Generic LISP NVE Reference Model . . . . . . . . . . . . . 13 73 4.2. LISP NVE Service Types . . . . . . . . . . . . . . . . . . 14 74 4.2.1. LISP L2 NVE Services . . . . . . . . . . . . . . . . . 14 75 4.2.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 . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 The purpose of this draft is to analyze the mapping between the 100 Network Virtualization over L3 (NVO3) 101 [I-D.ietf-nvo3-overlay-problem-statement] requirements and the 102 capabilities of the Locator/ID Separation Protocol (LISP) 103 [I-D.ietf-lisp] control plane. This information is provided as input 104 to the NVO3 analysis of the suitability of existing IETF protocols to 105 the NVO3 requirements. 107 LISP is a flexible map and encap framework that can be used for 108 overlay network applications, including Data Center Network 109 Virtualization. 111 The LISP framework provides two main tools for NVO3: (1) a Data Plane 112 that specifies how Endpoint Identifiers (EIDs) are encapsulated in 113 Routing Locators (RLOCs), and (2) a Control Plane that specifies the 114 interfaces to the LISP Mapping System that provides the mapping 115 between EIDs and RLOCs. 117 This document focuses on the control plane for L2 over L3 LISP 118 encapsulation, where EIDs are associated with MAC addresses. As such 119 the LISP control plane can be used with the data path encapsulations 120 defined in VXLAN [I-D.mahalingam-dutt-dcops-vxlan] and in NVGRE 121 [I-D.sridharan-virtualization-nvgre]. The LISP control plane can, of 122 course, be used with the L2 LISP data path encapsulation defined in 123 [I-D.smith-lisp-layer2]. 125 The LISP control plane provides the Mapping Service for the Network 126 Virtualization Edge (NVE), mapping per-tenant end system identity 127 information on the corresponding location at the NVE. As required by 128 NVO3, LISP supports network virtualization and tenant separation to 129 hide tenant addressing information, tenant-related control plane 130 activity and service contexts from the underlay network. 132 The LISP control plane is extensible, and can support non-LISP data 133 path encapsulations such as [I-D.sridharan-virtualization-nvgre], or 134 other encapsulations that provide support for network virtualization. 135 [I-D.ietf-lisp-interworking] specifies an open interworking framework 136 to allow LISP to non-LISP sites communication. 138 Broadcast, unknown unicast, and multicast in the overlay network are 139 supported by either replicated unicast, or core-based multicast as 140 specified in [I-D.ietf-lisp-multicast], 141 [I-D.farinacci-lisp-mr-signaling], and [I-D.farinacci-lisp-te]. 143 Finally, the LISP architecture has a modular design that allows the 144 use of different Mapping Databases, provided that the interface to 145 the Mapping System remains the same [I-D.ietf-lisp-ms]. This allows 146 for different Mapping Databases that may fit different NVO3 147 deployments. As an example of the modularity of the LISP Mapping 148 System, a worldwide LISP pilot network is currently using an 149 hierarchical Delegated Database Tree [I-D.fuller-lisp-ddt], after 150 having been operated for years with an overlay BGP mapping 151 infrastructure [I-D.ietf-lisp-alt]. 153 The LISP mapping system supports network virtualization, and a single 154 mapping infrastructure can run multiple instances, either public or 155 private, of the mapping database. 157 The rest of this document, after giving a quick a LISP overview in 158 Section 3, follows the functional model defined in 159 [I-D.lasserre-nvo3-framework] that provides in Section 4 an overview 160 of the LISP NVO3 reference model, and in Section 5 a description of 161 its functional components. Section 6 contains various considerations 162 on key aspects of LISP NVO3, followed by security considerations in 163 Section 7. 165 2. Definition of Terms 167 Flood-and-Learn: the use of dynamic (data plane) learning in VXLAN 168 to discover the location of a given Ethernet/IEEE 802 MAC address 169 in the underlay network. 171 ARP-Agent Reply: the ARP proxy-reply of an agent (e.g. an ITR) 172 with a MAC address of some other system in response to an ARP 173 request to a target which is not the agent's IP address 175 For definition of NVO3 related terms, notably Virtual Network (VN), 176 Virtual Network Identifier (VNI), Network Virtualization Edge (NVE), 177 Data Center (DC), please consult [I-D.lasserre-nvo3-framework]. 179 For definitions of LISP related terms, notably Map-Request, Map- 180 Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- 181 Server (MS) and Map-Resolver (MR) please consult the LISP 182 specification [I-D.ietf-lisp]. 184 3. LISP Overview 186 This section provides a quick overview of L2 LISP, with focus on 187 control plane operations. 189 The modular and extensible architecture of the LISP control plane 190 allows its use with both L2 or L3 LISP data path encapsulation. In 191 fact, the LISP control plane can be used even with other L2 overlay 192 data path encapsulations such as VXLAN and NVGRE. When used with 193 VXLAN, the LISP control plane replaces the use of dynamic data plane 194 learning (Flood-and-Learn), as specified in 195 [I-D.mahalingam-dutt-dcops-vxlan] improving scalability and 196 mitigating multicast requirements in the underlay network. 198 For a detailed LISP overview please refer to [I-D.ietf-lisp] and 199 related drafts. 201 To exemplify LISP operations let's consider two data centers (LISP 202 sites) A and B that provide L2 network virtualization services to a 203 number of tenant end systems, as depicted in Figure 1. The Endpoint 204 Identifiers (EIDs) are encoded according to [I-D.ietf-lisp-lcaf] as 205 an tuple that contains the Instance ID, or Virtual Network 206 Identifier (VNI), and the endpoint Ethernet/IEEE 802 MAC address. 208 The data centers are connected via a L3 underlay network, hence the 209 Routing Locators (RLOCs) are IP addresses (either IPv4 or IPv6) 210 encoded according to [I-D.ietf-lisp-lcaf]. 212 In LISP the network virtualization edge function is performed by 213 Ingress Tunnel Routers (ITRs) that are responsible for encapsulating 214 the LISP ingress traffic, and Egress Tunnel Routers (ETRs) that are 215 responsible for decapsulating the LISP egress traffic. ETRs are also 216 responsible to register the EID-to-RLOC mapping for a given LISP site 217 in the LISP mapping database system. ITRs and ETRs are collectively 218 referred as xTRs. 220 The EID-to-RLOC mapping is stored in the LISP mapping database, a 221 distributed mapping infrastructure accessible via Map Servers (MS) 222 and Map Resolvers (MR). [I-D.fuller-lisp-ddt] is an example of a 223 mapping database used in many LISP deployments. Another example of 224 of mapping database is [I-D.ietf-lisp-alt]. 226 For small deployments the mapping infrastructure can be very minimal, 227 in some cases even a single system running as MS/MR. 229 ,---------. 230 ,' `. 231 (Mapping System ) 232 `. ,' 233 `-+------+' 234 +--+--+ +-+---+ 235 |MS/MR| |MS/MR| 236 +-+---+ +-----+ 237 | | 238 .--..--. .--. .. 239 ( ' '.--. 240 .-.' L3 ' 241 ( Underlay ) 242 ( '-' 243 ._.'--'._.'.-._.'.-._) 244 RLOC=IP_A // \\ RLOC=IP_B 245 +---+--+ +-+--+--+ 246 .--.-.|xTR A |'.-. .| xTR B |.-. 247 ( +---+--+ ) ( +-+--+--+ ) 248 ( __. ( '. 249 ..' LISP Site A ) .' LISP Site B ) 250 ( .'-' ( .'-' 251 '--'._.'. )\ '--'._.'. )\ 252 / '--' \ / '--' \ 253 '--------' '--------' '--------' '--------' 254 : End : : End : : End : : End : 255 : Device : : Device : : Device : : Device : 256 '--------' '--------' '--------' '--------' 257 EID= EID= EID= EID= 258 260 Figure 1: Example of L2 NVO3 Services 262 3.1. LISP Site Configuration 264 In each LISP site the xTRs are configured with an IP address (the 265 site RLOCs) per each interface facing the underlay network. 267 Similarly the MS/MR are assigned an IP address in the RLOC space. 269 The configuration of the xTRs includes the RLOCs of the MS/MR and a 270 shared secret that is optionally used to secure the communication 271 between xTRs and MS/MR. 273 To provide support for multi-tenancy multiple instances of the 274 mapping database are identified by a LISP Instance ID (IID), that is 275 equivalent to the 24-bit VXLAN Network Identifier (VNI) or Tenant 276 Network Identifier (TNI) that identifies tenants in 278 [I-D.mahalingam-dutt-dcops-vxlan]. 280 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 configures each end system with an Ethernet/IEEE 802 MAC 285 address and provision the network with other end system specific 286 attributes such as IP addresses, and VLAN information. LISP does not 287 introduce new addressing requirements for end systems. 289 The provisioning infrastructure is also responsible to provide a 290 network attach function, that notifies the network virtualization 291 edge (the LISP site ETR) that the end system is attached to a given 292 virtual network (identified by its VNI/IID) and that the end system 293 is identified, within that virtual network, by a given Ethernet/IEEE 294 802 MAC address. 296 3.3. End System Registration 298 Upon notification of end system network attach, that includes the 299 EID= tuple that identifies that end system, the ETR sends a 300 LISP Map-Register to the Mapping System. The Map-Register includes 301 the EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now 302 available, via the Mapping System Infrastructure, to other LISP sites 303 that are hosting end systems that belong to the same tenant. 305 For more details on end system registration see [I-D.ietf-lisp-ms]. 307 3.4. Packet Flow and Control Plane Operations 309 This section provides an example of the unicast packet flow and the 310 control plane operations when in the topology shown in Figure 1 end 311 system W, in LISP site A, wants to communicate to end system Y in 312 LISP site B. We'll assume that W knows Y's EID MAC address (e.g. 313 learned via ARP). 315 o W sends an Ethernet/IEEE 802 MAC frame with destination 316 EID= and source EID=. 318 o ITR A does a lookup in its local map-cache for the destination 319 EID=. Since this is the first packet sent to MAC_Y, 320 the map-cache is a miss, and the ITR sends a Map-request to the 321 mapping database system looking up the EID=. 323 o The mapping systems forwards the Map-Request to ETR B, that is 324 aware of the EID-to-RLOC mapping for . Alternatively, 325 depending on the mapping system configuration, a Map-Server which 326 is part of the mapping database system may send a Map-Reply 327 directly to ITR A. 329 o ETR B sends a Map-Reply to ITR A that includes the EID-to-RLOC 330 mapping: EID= -> RLOC=IP_B, where IP_B is the locator 331 of ETR B, hence the locator of LISP site B. In order to facilitate 332 interoperability, the Map-Reply may also include attributes such 333 as the data plane encapsulations supported by the ETR. 335 o ITR A populates the local map-cache with the EID to RLOC mapping, 336 and either L2 LISP, VXLAN, or NVGRE encapsulates all subsequent 337 packets with a destination EID= with a destination 338 RLOC=IP_B. 340 It should be noted how the LISP mapping system replaces the use of 341 Flood-and-Learn based on multicast distribution trees instantiated in 342 the underlay network (required by VXLAN's dynamic data plane 343 learning), with a unicast control plane and a cache mechanism that 344 "pulls" on-demand the EID-to-RLOC mapping from the LISP mapping 345 database. This improves scalability, and simplifies the 346 configuration of the underlay network. 348 3.4.1. Supporting ARP Resolution with LISP Mapping System 350 A large majority of data center applications are IP based, and in 351 those use cases end systems are provisioned with IP addresses as well 352 as MAC addresses. 354 In this case, to eliminate the flooding of ARP traffic and further 355 reduce the need for multicast in the underlay network, the LISP 356 mapping system is used to support ARP resolution at the ITR. We 357 assume that as shown in Figure 2: (1) end system W has an IP address 358 IP_W, and end system Y has an IP address IP_Y, (2) end system W knows 359 Y's IP address (e.g. via DNS lookup). We also assume that during 360 registration Y has registered both its MAC address and its IP address 361 as EID. End system Y is then identified by the EID = 362 . 364 ,---------. 365 ,' `. 366 (Mapping System ) 367 `. ,' 368 `-+------+' 369 +--+--+ +-+---+ 370 |MS/MR| |MS/MR| 371 +-+---+ +-----+ 372 | | 373 .--..--. .--. .. 374 ( ' '.--. 375 .-.' L3 ' 376 ( Underlay ) 377 ( '-' 378 ._.'--'._.'.-._.'.-._) 379 RLOC=IP_A // \\ RLOC=IP_B 380 +---+--+ +-+--+--+ 381 .--.-.|xTR A |'.-. .| xTR B |.-. 382 ( +---+--+ ) ( +-+--+--+ ) 383 ( __. ( '. 384 ..' LISP Site A ) .' LISP Site B ) 385 ( .'-' ( .'-' 386 '--'._.'. )\ '--'._.'. )\ 387 / '--' \ / '--' \ 388 '--------' '--------' '--------' '--------' 389 : End : : End : : End : : End : 390 : Device : : Device : : Device : : Device : 391 '--------' '--------' '--------' '--------' 392 EID= EID= EID= EID= 393 MAC_X> MAC_Y> MAC_Z> 396 Figure 2: Example of L3 NVO3 Services 398 The packet flow and control plane operation are as follows: 400 o End system W sends a broadcast ARP message to discover the MAC 401 address of end system Y. The message contains IP_Y in the ARP 402 message payload. 404 o ITR A, acting as a L2 switch, will receive the ARP message, but 405 rather than flooding it on the overlay network sends a Map-Request 406 to the mapping database system for EID = . 408 o The Map-Request is routed by the mapping system infrastructure to 409 ETR B, that will send a Map-Reply back to ITR A containing the 410 mapping EID= -> RLOC=IP_B, (the locator of ETR 411 B). Alternatively, depending on the mapping system configuration, 412 a Map-Server in the mapping system may send directly a Map-Reply 413 to ITR A. 415 o ITR A populates the map-cache with the received entry, and sends 416 an ARP-Agent Reply to W that includes MAC_Y and IP_Y. 418 o End system W learns MAC_Y from the ARP message and can now send a 419 packet to end system Y by including MAC_Y, and IP_Y, as 420 destination addresses. 422 o ITR A will then process the packet as specified in Section 3.4. 424 This example shows how LISP, by replacing dynamic data plane learning 425 (Flood-and-Learn) largely reduces the need for multicast in the 426 underlay network, that is needed only when broadcast, unknown unicast 427 or multicast are required by the applications in the overlay. In 428 practice, the LISP mapping system, constrains ARP within the 429 boundaries of a link-local protocol. This simplifies the 430 configuration of the underlay network and removes the significant 431 scalability limitation imposed by VXLAN Flood-and-Learn. 433 It's important to note that the use of the LISP mapping system, by 434 pulling the EID-to-RLOC mapping on demand, also improves end system 435 mobility across data centers. 437 3.5. End System Mobility 439 This section shows how the LISP control plane deals with mobility 440 when end systems are migrated from one Data Center to another. We'll 441 assume that a signaling protocol, as described in 442 [I-D.kompella-nvo3-server2nve], signals to the NVE operations such as 443 creating/terminating/migrating an end system. The signaling protocol 444 consists of three basic messages: "associate", "dissociate", and 445 "pre-associate". 447 Let's consider the scenario shown in Figure 3 where end system W 448 moves from data center A to data center B. 450 ,---------. 451 ,' `. 452 (Mapping System ) 453 `. ,' 454 `-+------+' 455 +--+--+ +-+---+ 456 |MS/MR| |MS/MR| 457 +-+---+ +-----+ 458 | | 459 .--..--. .--. .. 460 ( ' '.--. 461 .-.' L3 ' 462 ( Underlay ) 463 ( '-' 464 ._.'--'._.'.-._.'.-._) 465 RLOC=IP_A // \\ RLOC=IP_B 466 +---+--+ +-+--+--+ 467 .--.-.|xTR A |'.-. .| xTR B |.-. 468 ( +---+--+ ) ( +-+--+--+ ) 469 ( __. ( '. 470 ..' LISP Site A ) .' LISP Site B ) 471 ( .'-' ( .'-' 472 '--'._.'. )\ '--'._.'. )\ 473 / '--' \ / '--' \ 474 '--------' '--------' '--------' '--------' 475 : End : : End : ==> : End : : End : 476 : Device : : Device : ==> : Device : : Device : 477 '--------' '--------' '--------' '--------' 478 EID= EID= EID= 479 481 Figure 3: End System Mobility 483 As a result of the end system registration, described in Section 3.3, 484 the Mapping System contains the EID-to-RLOC mapping for end system W 485 that associates EID= with the RLOC(s) associated with 486 LISP site A (IP_A). 488 The process of migrating end system W from data center A to data 489 center B is initiated. 491 ETR B receives a pre-associate message that includes EID=. ETR B sends a Map-Register to the mapping system registering 493 RLOC=IP_B as an additional locator for end system W with priority set 494 to 255. This means that the RLOC MUST NOT be used for unicast 495 forwarding, but the mapping system is now aware of the new location. 497 During the migration process of end system W, ETR A receives a 498 dissociate message, and sends a Map-Register with Record TTL=0 to 499 signal the mapping system that end system W is no longer reachable at 500 RLOC=IP_A. xTR A will also add an entry in its forwarding table that 501 marks EID= as non-local. When end system W has 502 completed its migration, ETR B receives an associate message for end 503 system W, and sends a Map-Register to the mapping system setting a 504 non-255 priority for RLOC=IP_B. Now the mapping system is updated 505 with the new EID-to-RLOC mapping for end system W with the desired 506 priority. 508 The remote ITRs that were corresponding with end system W during the 509 migration will keep sending packets to ETR A. ETR A will keep 510 forwarding locally those packets until it receives a dissociate 511 message, and the entry in the forwarding table associated with 512 EID= is marked as non-local. Subsequent packets 513 arriving at ETR A from a remore ITR, and destined to end system W 514 will hit the entry in the forwarding table that will generate an 515 exception, and will generate a Solicit-Map-Request (SMR) message that 516 is returned to the remote ITR. Upon receiving the SMR the remote ITR 517 will invalidate its local map-cache entry for EID= and 518 send a new Map-Request for that EID. The Map-Request will generate a 519 Map-Reply that includes the new EID-to-RLOC mapping for end system W 520 with RLOC=IP_B. Similarly, unencapsulated packets arriving at ITR A 521 from local end systems and destined to end system W will hit the 522 entry in the forwarding table marked as non-local, and will generate 523 an exception that by sending a Map-Request for EID= will 524 populate the map-cache of ITR A with an EID-to-RLOC mapping for end 525 system W with RLOC=IP_B. 527 3.6. L3 LISP 529 The two examples above shows how the LISP control plane can be used 530 in combination with either L2 LISP, VXLAN, or NVGRE encapsulation to 531 provide L2 network virtualization services across data centers. 533 There is a trend, led by Massive Scalable Data Centers, that is 534 accelerating the adoption of L3 network services in the data center, 535 to preserve the many benefits introduced by L3 (scalability, multi- 536 homing, ...). 538 LISP, as defined in [I-D.ietf-lisp], provides L3 network 539 virtualization services over an L3 underlay network that, as an 540 alternative to L2 overlay solutions, matches the requirements for DC 541 Network Virtualization. L2 overlay solutions are necessary for Data 542 Centers that rely on non IPv4/IPv6 protocols, but when IP is 543 pervasive L3 LISP provides a better and more scalable overlay. 545 4. Reference Model 547 4.1. Generic LISP NVE Reference Model 549 In the generic NVO3 reference model described in 550 [I-D.lasserre-nvo3-framework], a Tenant End System attaches to a 551 Network Virtualization Edge (NVE) either directly or via a switched 552 network. 554 In a LISP NVO3 network the Tenant End Systems are part of a LISP 555 site, and the NVE function is provided by LISP xTRs. xTRs provide for 556 tenant separation, perform the encap/decap function, and interface 557 with the LISP Mapping System that maps tenant addressing information 558 (in the EID name space) on the underlay L3 infrastructure (in the 559 RLOC name space). 561 Tenant segregation across LISP sites is provided by the LISP Instance 562 ID (IID), a 24-bit value that is used by the LISP routers as the 563 Virtual Network Identifier (VNI). Virtualization and Segmentation 564 with LISP is addressed in section 5.5 of [I-D.ietf-lisp]. 566 ............... ,---------. .............. 567 . +--------+ . ,' `. . +--------+ . 568 . | Tenant | . (Mapping System ) . | Tenant | . 569 . | End +---+ `. ,' +---| End | . 570 . | System | . | `-+------+' | . | System | . 571 . +--------+ . | ................... | . +--------+ . 572 . . | +-+--+ +--+-+ | . . 573 . . | | NV | | NV | | . . 574 . LISP Site . +--|Edge| |Edge|--+ . LISP Site . 575 . . +-+--+ +--+-+ . . 576 . . / (xTR) L3 Overlay (xTR)\ . . 577 . +--------+ . / . Network . \ . +--------+. 578 . | Tenant +---+ . . +----| Tenant |. 579 . | End | . . (xTR) . . | End |. 580 . | System | . . +----+ . . | System |. 581 . +--------+ . .....| NV |........ . +--------+. 582 ............... |Edge| ............. 583 +----+ 584 .........|............ 585 . |LISP Site . 586 . | . 587 . +--------+ . 588 . | Tenant | . 589 . | End | . 590 . | System | . 591 . +--------+ . 593 ...................... 595 Generic reference model for DC NVO3 LISP infrastructure 597 4.2. LISP NVE Service Types 599 LISP can be used to support both L2 NVE and L3 NVE service types 600 thanks to the flexibility provided by the LISP Canonical Address 601 Format [I-D.ietf-lisp-lcaf], that allows for EIDs to be encoded 602 either as MAC addresses or IP addresses. 604 4.2.1. LISP L2 NVE Services 606 The frame format defined in [I-D.mahalingam-dutt-dcops-vxlan], has a 607 header compatible with the LISP data path encapsulation header, when 608 MAC addresses are used as EIDs, as described in section 4.12.2 of 609 [I-D.ietf-lisp-lcaf]. 611 The LISP control plane is extensible, and can support non-LISP data 612 path encapsulations such as NVGRE 613 [I-D.sridharan-virtualization-nvgre], or other encapsulations that 614 provide support for network virtualization. 616 4.2.2. LISP L3 NVE Services 618 LISP is defined as a virtualized IP routing and forwarding service in 619 [I-D.ietf-lisp], and as such can be used to provide L3 NVE services. 621 5. Functional Components 623 This section describes the functional components of a LISP NVE as 624 defined in Section 3 of [I-D.lasserre-nvo3-framework]. 626 5.1. Generic Service Virtualization Components 628 The generic reference model for NVE is depicted in Section 3.1 of 629 [I-D.lasserre-nvo3-framework]. 631 +------- L3 Network ------+ 632 | | 633 | Tunnel Overlay | 634 +------------+---------+ +---------+------------+ 635 | +----------+-------+ | | +---------+--------+ | 636 | | Overlay Module | | | | Overlay Module | | 637 | +---------+--------+ | | +---------+--------+ | 638 | |VN context| | VN context| | 639 | | | | | | 640 | +--------+-------+ | | +--------+-------+ | 641 | | VNI | | | | VNI | | 642 NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2 643 | | VAPs | | | | VAPs | | 644 +----+------------+----+ +----+------------+----+ 645 | | | | 646 -------+------------+-----------------+------------+------- 647 | | Tenant | | 648 | | Service IF | | 649 Tenant End Systems Tenant End Systems 651 Generic reference model for NV Edge 653 5.1.1. Virtual Attachment Points (VAPs) 655 In a LISP NVE, Tunnel Routers (xTRs) implement the NVE functionality 656 on ToRs or Virtual Switches. Tenant End Systems attach to the 657 Virtual Access Points (VAPs) provided by the xTRs (either a physical 658 port or a virtual interface). 660 5.1.2. Overlay Modules and Tenant ID 662 The xTR also implements the function of NVE Overlay Module, by 663 mapping the addressing information (EIDs) of the tenant packet on the 664 appropriate locations (RLOCs) in the underlay network. The Tenant 665 Network Identifier (TNI) is encoded in the encapsulated packet 666 (either in the 24-bit IID field of the LISP header for L2/L3 LISP 667 encapsulation, or in the 24-bit VXLAN Network Identifier field for 668 VXLAN encapsulation, or in the 24-bit NVGRE Tenant Network Identifier 669 field of NVGRE). In a LISP NVE globally unique (per administrative 670 domain) TNIs are used to identify the Tenant instances. 672 The mapping of the tenant packet address onto the underlay network 673 location is "pulled" on-demand from the mapping system, and cached at 674 the NVE in a per-TNI map-cache. 676 5.1.3. Tenant Instance 678 Tenants are mapped on LISP Instance IDs (IIDs), and the xTR keeps an 679 instance of the LISP control protocol per each IID. The ETR is 680 responsible to register the Tenant End System to the LISP mapping 681 system, via the Map-Register service provided by LISP Map-Servers 682 (MS). The Map-Register includes the IID that is used to identify the 683 tenant. 685 5.1.4. Tunnel Overlays and Encapsulation Options 687 The LISP control protocol, as defined today, provides support for L2 688 LISP and VXLAN L2 over L3 encapsulation, and LISP L3 over L3 689 encapsulation. 691 We believe that the LISP control Protocol can be easily extended to 692 support different IP tunneling options (such as NVGRE). 694 5.1.5. Control Plane Components 696 5.1.5.1. Auto-provisioning/Service Discovery 698 The LISP framework does not include mechanisms to provision the local 699 NVE with the appropriate Tenant Instance for each Tenant End Systems. 700 Other protocols, such as VDP (in IEEE P802.1Qbg), should be used to 701 implement a network attach/detach function. 703 The LISP control plane can take advantage of such a network attach/ 704 detach function to trigger the registration of a Tenant End System to 705 the Mapping System. This is particularly helpful to handle mobility 706 across DC of the Tenant End System. 708 It is possible to extend the LISP control protocol to advertise the 709 tenant service instance (tenant and service type provided) to other 710 NVEs, and facilitate interoperability between NVEs that are using 711 different service types. 713 5.1.5.2. Address Advertisement and Tunnel mapping 715 As traffic reaches an ingress NVE, the corresponding ITR uses the 716 LISP Map-Request/Reply service to determine the location of the 717 destination End System. 719 The LISP mapping system combines the distribution of address 720 advertisement and (stateless) tunneling provisioning. 722 When EIDs are mapped on both IP addresses and MACs, the need to flood 723 ARP messages at the NVE is eliminated resolving the issues with 724 explosive ARP handling. 726 5.1.5.3. Tunnel Management 728 LISP defines several mechanisms for determining RLOC reachability, 729 including Locator Status Bits, "nonce echoing", and RLOC probing. 730 Please see Sections 5.3 and 6.3 of [I-D.ietf-lisp]. 732 6. Key Aspects of Overlay 734 6.1. Overlay Issues to Consider 736 6.1.1. Data Plane vs. Control Plane Driven 738 The use of LISP control plane minimizes the need for multicast in the 739 underlay network overcoming the scalability limitations of VXLAN 740 dynamic data plane learning (Flood-and-Learn). 742 Multicast or ingress replication in the underlay network are still 743 required, as specified in [I-D.ietf-lisp-multicast], 744 [I-D.farinacci-lisp-mr-signaling], and [I-D.farinacci-lisp-te], to 745 support broadcast, unknown, and multicast traffic in the overlay, but 746 multicast in the underlay is no longer required (at least for IP 747 traffic) for unicast overlay services. 749 6.1.2. Data Plane and Control Plane Separation 751 LISP introduces a clear separation between data plane and control 752 plane functions. LISP modular design allows for different mapping 753 databases, to achieve different scalability goals and to meet 754 requirements of different deployments. 756 6.1.3. Handling Broadcast, Unknown Unicast and Multicast (BUM) Traffic 758 Packet replication in the underlay network to support broadcast, 759 unknown unicast and multicast overlay services can be done by: 761 o Ingress replication 763 o Use of underlay multicast trees 765 [I-D.ietf-lisp-multicast] specifies how to map a multicast flow in 766 the EID space during distribution tree setup and packet delivery in 767 the underlay network. LISP-multicast doesn't require packet format 768 changes in multicast routing protocols, and doesn't impose changes in 769 the internal operation of multicast in a LISP site. The only 770 operational changes are required in PIM-ASM [RFC4601], MSDP 772 [RFC3618], and PIM-SSM [RFC4607]. 774 7. Security Considerations 776 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 777 origin authentication, integrity and anti-replay protection to LISP's 778 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 779 SEC also enables verification of authorization on EID-prefix claims 780 in Map-Reply messages. 782 Additional security mechanisms to protect the LISP Map-Register 783 messages are defined in [I-D.ietf-lisp-ms]. 785 The security of the Mapping System Infrastructure depends on the 786 particular mapping database used. The [I-D.fuller-lisp-ddt] 787 specification, as an example, defines a public-key based mechanism 788 that provides origin authentication and integrity protection to the 789 LISP DDT protocol. 791 8. IANA Considerations 793 This document has no IANA implications 795 9. Acknowledgements 797 The authors want to thank Victor Moreno and Paul Quinn for the early 798 review, insightful comments and suggestions. 800 10. References 802 10.1. Normative References 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 808 Protocol (MSDP)", RFC 3618, October 2003. 810 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 811 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 812 Protocol Specification (Revised)", RFC 4601, August 2006. 814 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 815 IP", RFC 4607, August 2006. 817 10.2. Informative References 819 [I-D.farinacci-lisp-mr-signaling] 820 Farinacci, D. and M. Napierala, "LISP Control-Plane 821 Multicast Signaling", draft-farinacci-lisp-mr-signaling-00 822 (work in progress), July 2012. 824 [I-D.farinacci-lisp-te] 825 Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 826 Engineering Use-Cases", draft-farinacci-lisp-te-00 (work 827 in progress), March 2012. 829 [I-D.fuller-lisp-ddt] 830 Fuller, V. and D. Lewis, "LISP Delegated Database Tree", 831 draft-fuller-lisp-ddt-01 (work in progress), March 2012. 833 [I-D.ietf-lisp] 834 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 835 "Locator/ID Separation Protocol (LISP)", 836 draft-ietf-lisp-23 (work in progress), May 2012. 838 [I-D.ietf-lisp-alt] 839 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 840 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 841 (work in progress), December 2011. 843 [I-D.ietf-lisp-interworking] 844 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 845 "Interworking LISP with IPv4 and IPv6", 846 draft-ietf-lisp-interworking-06 (work in progress), 847 March 2012. 849 [I-D.ietf-lisp-lcaf] 850 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 851 Address Format (LCAF)", draft-ietf-lisp-lcaf-00 (work in 852 progress), August 2012. 854 [I-D.ietf-lisp-ms] 855 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 856 draft-ietf-lisp-ms-14 (work in progress), December 2011. 858 [I-D.ietf-lisp-multicast] 859 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 860 "LISP for Multicast Environments", 861 draft-ietf-lisp-multicast-14 (work in progress), 862 February 2012. 864 [I-D.ietf-lisp-sec] 865 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 866 and O. Bonaventure, "LISP-Security (LISP-SEC)", 867 draft-ietf-lisp-sec-02 (work in progress), March 2012. 869 [I-D.ietf-nvo3-overlay-problem-statement] 870 Narten, T., Black, D., Dutt, D., Fang, L., Gray, E., 871 Kreeger, L., Napierala, M., and M. Sridhavan, "Problem 872 Statement: Overlays for Network Virtualization", 873 draft-ietf-nvo3-overlay-problem-statement-00 (work in 874 progress), September 2012. 876 [I-D.kompella-nvo3-server2nve] 877 Kompella, K., Rekhter, Y., and T. Morin, "Using Signaling 878 to Simplify Network Virtualization Provisioning", 879 draft-kompella-nvo3-server2nve-00 (work in progress), 880 July 2012. 882 [I-D.lasserre-nvo3-framework] 883 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 884 Rekhter, "Framework for DC Network Virtualization", 885 draft-lasserre-nvo3-framework-03 (work in progress), 886 July 2012. 888 [I-D.mahalingam-dutt-dcops-vxlan] 889 Sridhar, T., Bursell, M., Kreeger, L., Dutt, D., Wright, 890 C., Mahalingam, M., Duda, K., and P. Agarwal, "VXLAN: A 891 Framework for Overlaying Virtualized Layer 2 Networks over 892 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-01 893 (work in progress), February 2012. 895 [I-D.smith-lisp-layer2] 896 Smith, M. and D. Dutt, "Layer 2 (L2) LISP Encapsulation 897 Format", draft-smith-lisp-layer2-00 (work in progress), 898 March 2011. 900 [I-D.sridharan-virtualization-nvgre] 901 Sridhavan, M., Duda, K., Ganga, I., Greenberg, A., Lin, 902 G., Pearson, M., Thaler, P., Tumuluri, C., and Y. Wang, 903 "NVGRE: Network Virtualization using Generic Routing 904 Encapsulation", draft-sridharan-virtualization-nvgre-00 905 (work in progress), September 2011. 907 Authors' Addresses 909 Fabio Maino 910 Cisco Systems 911 170 Tasman Drive 912 San Jose, California 95134 913 USA 915 Email: fmaino@cisco.com 917 Vina Ermagan 918 Cisco Systems 919 170 Tasman Drive 920 San Jose, California 95134 921 USA 923 Email: vermagan@cisco.com 925 Dino Farinacci 926 Cisco Systems 927 170 Tasman Drive 928 San Jose, California 95134 929 USA 931 Email: dino@cisco.com 933 Michael Smith 934 Insieme Networks 935 California 936 USA 938 Email: michsmit@insiemenetworks.com