idnits 2.17.1 draft-maino-nvo3-lisp-cp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 19, 2012) is 4208 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 (-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: March 23, 2013 Cisco Systems 6 M. Smith 7 Insieme Networks 8 September 19, 2012 10 LISP Control Plane for Network Virtualization Overlays 11 draft-maino-nvo3-lisp-cp-01 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 March 23, 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. L3 LISP . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Generic LISP NVE Reference Model . . . . . . . . . . . . . 11 72 4.2. LISP NVE Service Types . . . . . . . . . . . . . . . . . . 12 73 4.2.1. LISP L2 NVE Services . . . . . . . . . . . . . . . . . 12 74 4.2.2. LISP L3 NVE Services . . . . . . . . . . . . . . . . . 12 75 5. Functional Components . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Generic Service Virtualization Components . . . . . . . . 12 77 5.1.1. Virtual Attachment Points (VAPs) . . . . . . . . . . . 13 78 5.1.2. Overlay Modules and Tenant ID . . . . . . . . . . . . 13 79 5.1.3. Tenant Instance . . . . . . . . . . . . . . . . . . . 14 80 5.1.4. Tunnel Overlays and Encapsulation Options . . . . . . 14 81 5.1.5. Control Plane Components . . . . . . . . . . . . . . . 14 82 6. Key Aspects of Overlay . . . . . . . . . . . . . . . . . . . . 15 83 6.1. Overlay Issues to Consider . . . . . . . . . . . . . . . . 15 84 6.1.1. Data Plane vs. Control Plane Driven . . . . . . . . . 15 85 6.1.2. Data Plane and Control Plane Separation . . . . . . . 15 86 6.1.3. Handling Broadcast, Unknown Unicast and Multicast 87 (BUM) Traffic . . . . . . . . . . . . . . . . . . . . 15 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 The purpose of this draft is to analyze the mapping between the 99 Network Virtualization over L3 (NVO3) 100 [I-D.ietf-nvo3-overlay-problem-statement] requirements and the 101 capabilities of the Locator/ID Separation Protocol (LISP) 102 [I-D.ietf-lisp] control plane. This information is provided as input 103 to the NVO3 analysis of the suitability of existing IETF protocols to 104 the NVO3 requirements. 106 LISP is a flexible map and encap framework that can be used for 107 overlay network applications, including Data Center Network 108 Virtualization. 110 The LISP framework provides two main tools for NVO3: (1) a Data Plane 111 that specifies how Endpoint Identifiers (EIDs) are encapsulated in 112 Routing Locators (RLOCs), and (2) a Control Plane that specifies the 113 interfaces to the LISP Mapping System that provides the mapping 114 between EIDs and RLOCs. 116 This document focuses on the control plane for L2 over L3 LISP 117 encapsulation, where EIDs are associated with MAC addresses. As such 118 the LISP control plane can be used with the data path encapsulations 119 defined in VXLAN [I-D.mahalingam-dutt-dcops-vxlan] and in NVGRE 120 [I-D.sridharan-virtualization-nvgre]. The LISP control plane can, of 121 course, be used with the L2 LISP data path encapsulation defined in 122 [I-D.smith-lisp-layer2]. 124 The LISP control plane provides the Mapping Service for the Network 125 Virtualization Edge (NVE), mapping per-tenant end system identity 126 information on the corresponding location at the NVE. As required by 127 NVO3, LISP supports network virtualization and tenant separation to 128 hide tenant addressing information, tenant-related control plane 129 activity and service contexts from the underlay network. 131 The LISP control plane is extensible, and can support non-LISP data 132 path encapsulations such as [I-D.sridharan-virtualization-nvgre], or 133 other encapsulations that provide support for network virtualization. 134 [I-D.ietf-lisp-interworking] specifies an open interworking framework 135 to allow LISP to non-LISP sites communication. 137 Broadcast, unknown unicast, and multicast in the overlay network are 138 supported by either replicated unicast, or core-based multicast as 139 specified in [I-D.ietf-lisp-multicast], 140 [I-D.farinacci-lisp-mr-signaling], and [I-D.farinacci-lisp-te]. 142 Finally, the LISP architecture has a modular design that allows the 143 use of different Mapping Databases, provided that the interface to 144 the Mapping System remains the same [I-D.ietf-lisp-ms]. This allows 145 for different Mapping Databases that may fit different NVO3 146 deployments. As an example of the modularity of the LISP Mapping 147 System, a worldwide LISP pilot network is currently using an 148 hierarchical Delegated Database Tree [I-D.fuller-lisp-ddt], after 149 having been operated for years with an overlay BGP mapping 150 infrastructure [I-D.ietf-lisp-alt]. 152 The LISP mapping system supports network virtualization, and a single 153 mapping infrastructure can run multiple instances, either public or 154 private, of the mapping database. 156 The rest of this document, after giving a quick a LISP overview in 157 Section 3, follows the functional model defined in 158 [I-D.lasserre-nvo3-framework] that provides in Section 4 an overview 159 of the LISP NVO3 reference model, and in Section 5 a description of 160 its functional components. Section 6 contains various considerations 161 on key aspects of LISP NVO3, followed by security considerations in 162 Section 7. 164 2. Definition of Terms 166 Flood-and-Learn: the use of dynamic (data plane) learning in VXLAN 167 to discover the location of a given Ethernet/IEEE 802 MAC address 168 in the underlay network. 170 ARP-Agent Reply: the ARP proxy-reply of an agent (e.g. an ITR) 171 with a MAC address of some other system in response to an ARP 172 request to a target which is not the agent's IP address 174 For definition of NVO3 related terms, notably Virtual Network (VN), 175 Virtual Network Identifier (VNI), Network Virtualization Edge (NVE), 176 Data Center (DC), please consult [I-D.lasserre-nvo3-framework]. 178 For definitions of LISP related terms, notably Map-Request, Map- 179 Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- 180 Server (MS) and Map-Resolver (MR) please consult the LISP 181 specification [I-D.ietf-lisp]. 183 3. LISP Overview 185 This section provides a quick overview of L2 LISP, with focus on 186 control plane operations. 188 The modular and extensible architecture of the LISP control plane 189 allows its use with both L2 or L3 LISP data path encapsulation. In 190 fact, the LISP control plane can be used even with other L2 overlay 191 data path encapsulations such as VXLAN and NVGRE. When used with 192 VXLAN, the LISP control plane replaces the use of dynamic data plane 193 learning (Flood-and-Learn), as specified in 194 [I-D.mahalingam-dutt-dcops-vxlan] improving scalability and 195 mitigating multicast requirements in the underlay network. 197 For a detailed LISP overview please refer to [I-D.ietf-lisp] and 198 related drafts. 200 To exemplify LISP operations let's consider two data centers (LISP 201 sites) A and B that provide L2 network virtualization services to a 202 number of tenant end systems, as depicted in Figure 1. The Endpoint 203 Identifiers (EIDs) are encoded according to [I-D.ietf-lisp-lcaf] as 204 an tuple that contains the Instance ID, or Virtual Network 205 Identifier (VNI), and the endpoint Ethernet/IEEE 802 MAC address. 207 The data centers are connected via a L3 underlay network, hence the 208 Routing Locators (RLOCs) are IP addresses (either IPv4 or IPv6) 209 encoded according to [I-D.ietf-lisp-lcaf]. 211 In LISP the network virtualization edge function is performed by 212 Ingress Tunnel Routers (ITRs) that are responsible for encapsulating 213 the LISP ingress traffic, and Egress Tunnel Routers (ETRs) that are 214 responsible for decapsulating the LISP egress traffic. ETRs are also 215 responsible to register the EID-to-RLOC mapping for a given LISP site 216 in the LISP mapping database system. ITRs and ETRs are collectively 217 referred as xTRs. 219 The EID-to-RLOC mapping is stored in the LISP mapping database, a 220 distributed mapping infrastructure accessible via Map Servers (MS) 221 and Map Resolvers (MR). [I-D.fuller-lisp-ddt] is an example of a 222 mapping database used in many LISP deployments. Another example of 223 of mapping database is [I-D.ietf-lisp-alt]. 225 For small deployments the mapping infrastructure can be very minimal, 226 in some cases even a single system running as MS/MR. 228 ,---------. 229 ,' `. 230 (Mapping System ) 231 `. ,' 232 `-+------+' 233 +--+--+ +-+---+ 234 |MS/MR| |MS/MR| 235 +-+---+ +-----+ 236 | | 237 .--..--. .--. .. 238 ( ' '.--. 239 .-.' L3 ' 240 ( Underlay ) 241 ( '-' 242 ._.'--'._.'.-._.'.-._) 243 RLOC=IP_A // \\ RLOC=IP_B 244 +---+--+ +-+--+--+ 245 .--.-.|xTR A |'.-. .| xTR B |.-. 246 ( +---+--+ ) ( +-+--+--+ ) 247 ( __. ( '. 248 ..' LISP Site A ) .' LISP Site B ) 249 ( .'-' ( .'-' 250 '--'._.'. )\ '--'._.'. )\ 251 / '--' \ / '--' \ 252 '--------' '--------' '--------' '--------' 253 : End : : End : : End : : End : 254 : Device : : Device : : Device : : Device : 255 '--------' '--------' '--------' '--------' 256 EID= EID= EID= EID= 257 259 Figure 1: Example of L2 NVO3 Services 261 3.1. LISP Site Configuration 263 In each LISP site the xTRs are configured with an IP address (the 264 site RLOCs) per each interface facing the underlay network. 266 Similarly the MS/MR are assigned an IP address in the RLOC space. 268 The configuration of the xTRs includes the RLOCs of the MS/MR and a 269 shared secret that is optionally used to secure the communication 270 between xTRs and MS/MR. 272 To provide support for multi-tenancy multiple instances of the 273 mapping database are identified by a LISP Instance ID (IID), that is 274 equivalent to the 24-bit VXLAN Network Identifier (VNI) or Tenant 275 Network Identifier (TNI) that identifies tenants in 277 [I-D.mahalingam-dutt-dcops-vxlan]. 279 3.2. End System Provisioning 281 We assume that a provisioning framework will be responsible for 282 provisioning end systems (e.g. VMs) in each data center. The 283 provisioning configures each end system with an Ethernet/IEEE 802 MAC 284 address and provision the network with other end system specific 285 attributes such as IP addresses, and VLAN information. LISP does not 286 introduce new addressing requirements for end systems. 288 The provisioning infrastructure is also responsible to provide a 289 network attach function, that notifies the network virtualization 290 edge (the LISP site ETR) that the end system is attached to a given 291 virtual network (identified by its VNI/IID) and that the end system 292 is identified, within that virtual network, by a given Ethernet/IEEE 293 802 MAC address. 295 3.3. End System Registration 297 Upon notification of end system network attach, that includes the 298 EID= tuple that identifies that end system, the ETR sends a 299 LISP Map-Register to the Mapping System. The Map-Register includes 300 the EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now 301 available, via the Mapping System Infrastructure, to other LISP sites 302 that are hosting end systems that belong to the same tenant. 304 For more details on end system registration see [I-D.ietf-lisp-ms]. 306 3.4. Packet Flow and Control Plane Operations 308 This section provides an example of the unicast packet flow and the 309 control plane operations when in the topology shown in Figure 1 end 310 system W, in LISP site A, wants to communicate to end system Y in 311 LISP site B. We'll assume that W knows Y's EID MAC address (e.g. 312 learned via ARP). 314 o W sends an Ethernet/IEEE 802 MAC frame with destination 315 EID= and source EID=. 317 o ITR A does a lookup in its local map-cache for the destination 318 EID=. Since this is the first packet sent to MAC_Y, 319 the map-cache is a miss, and the ITR sends a Map-request to the 320 mapping database system looking up the EID=. 322 o The mapping systems forwards the Map-Request to ETR B, that is 323 aware of the EID-to-RLOC mapping for . Alternatively, 324 depending on the mapping system configuration, a Map-Server which 325 is part of the mapping database system may send a Map-Reply 326 directly to ITR A. 328 o ETR B sends a Map-Reply to ITR A that includes the EID-to-RLOC 329 mapping: EID= -> RLOC=IP_B, where IP_B is the locator 330 of ETR B, hence the locator of LISP site B. In order to facilitate 331 interoperability, the Map-Reply may also include attributes such 332 as the data plane encapsulations supported by the ETR. 334 o ITR A populates the local map-cache with the EID to RLOC mapping, 335 and either L2 LISP, VXLAN, or NVGRE encapsulates all subsequent 336 packets with a destination EID= with a destination 337 RLOC=IP_B. 339 It should be noted how the LISP mapping system replaces the use of 340 Flood-and-Learn based on multicast distribution trees instantiated in 341 the underlay network (required by VXLAN's dynamic data plane 342 learning), with a unicast control plane and a cache mechanism that 343 "pulls" on-demand the EID-to-RLOC mapping from the LISP mapping 344 database. This improves scalability, and simplifies the 345 configuration of the underlay network. 347 3.4.1. Supporting ARP Resolution with LISP Mapping System 349 A large majority of data center applications are IP based, and in 350 those use cases end systems are provisioned with IP addresses as well 351 as MAC addresses. 353 In this case, to eliminate the flooding of ARP traffic and further 354 reduce the need for multicast in the underlay network, the LISP 355 mapping system is used to support ARP resolution at the ITR. We 356 assume that as shown in Figure 2: (1) end system W has an IP address 357 IP_W, and end system Y has an IP address IP_Y, (2) end system W knows 358 Y's IP address (e.g. via DNS lookup). We also assume that during 359 registration Y has registered both its MAC address and its IP address 360 as EID. End system Y is then identified by the EID = 361 . 363 ,---------. 364 ,' `. 365 (Mapping System ) 366 `. ,' 367 `-+------+' 368 +--+--+ +-+---+ 369 |MS/MR| |MS/MR| 370 +-+---+ +-----+ 371 | | 372 .--..--. .--. .. 373 ( ' '.--. 374 .-.' L3 ' 375 ( Underlay ) 376 ( '-' 377 ._.'--'._.'.-._.'.-._) 378 RLOC=IP_A // \\ RLOC=IP_B 379 +---+--+ +-+--+--+ 380 .--.-.|xTR A |'.-. .| xTR B |.-. 381 ( +---+--+ ) ( +-+--+--+ ) 382 ( __. ( '. 383 ..' LISP Site A ) .' LISP Site B ) 384 ( .'-' ( .'-' 385 '--'._.'. )\ '--'._.'. )\ 386 / '--' \ / '--' \ 387 '--------' '--------' '--------' '--------' 388 : End : : End : : End : : End : 389 : Device : : Device : : Device : : Device : 390 '--------' '--------' '--------' '--------' 391 EID= EID= EID= EID= 392 MAC_X> MAC_Y> MAC_Z> 395 Figure 2: Example of L3 NVO3 Services 397 The packet flow and control plane operation are as follows: 399 o End system W sends a broadcast ARP message to discover the MAC 400 address of end system Y. The message contains IP_Y in the ARP 401 message payload. 403 o ITR A, acting as a L2 switch, will receive the ARP message, but 404 rather than flooding it on the overlay network sends a Map-Request 405 to the mapping database system for EID = . 407 o The Map-Request is routed by the mapping system infrastructure to 408 ETR B, that will send a Map-Reply back to ITR A containing the 409 mapping EID= -> RLOC=IP_B, (the locator of ETR 410 B). Alternatively, depending on the mapping system configuration, 411 a Map-Server in the mapping system may send directly a Map-Reply 412 to ITR A. 414 o ITR A populates the map-cache with the received entry, and sends 415 an ARP-Agent Reply to W that includes MAC_Y and IP_Y. 417 o End system W learns MAC_Y from the ARP message and can now send a 418 packet to end system Y by including MAC_Y, and IP_Y, as 419 destination addresses. 421 o ITR A will then process the packet as specified in Section 3.4. 423 This example shows how LISP, by replacing dynamic data plane learning 424 (Flood-and-Learn) largely reduces the need for multicast in the 425 underlay network, that is needed only when broadcast, unknown unicast 426 or multicast are required by the applications in the overlay. In 427 practice, the LISP mapping system, constrains ARP within the 428 boundaries of a link-local protocol. This simplifies the 429 configuration of the underlay network and removes the significant 430 scalability limitation imposed by VXLAN Flood-and-Learn. 432 It's important to note that the use of the LISP mapping system, by 433 pulling the EID-to-RLOC mapping on demand, also improves end system 434 mobility across data centers. 436 3.5. L3 LISP 438 The two examples above shows how the LISP control plane can be used 439 in combination with either L2 LISP, VXLAN, or NVGRE encapsulation to 440 provide L2 network virtualization services across data centers. 442 There is a trend, led by Massive Scalable Data Centers, that is 443 accelerating the adoption of L3 network services in the data center, 444 to preserve the many benefits introduced by L3 (scalability, multi- 445 homing, ...). 447 LISP, as defined in [I-D.ietf-lisp], provides L3 network 448 virtualization services over an L3 underlay network that, as an 449 alternative to L2 overlay solutions, matches the requirements for DC 450 Network Virtualization. L2 overlay solutions are necessary for Data 451 Centers that rely on non IPv4/IPv6 protocols, but when IP is 452 pervasive L3 LISP provides a better and more scalable overlay. 454 4. Reference Model 455 4.1. Generic LISP NVE Reference Model 457 In the generic NVO3 reference model described in 458 [I-D.lasserre-nvo3-framework], a Tenant End System attaches to a 459 Network Virtualization Edge (NVE) either directly or via a switched 460 network. 462 In a LISP NVO3 network the Tenant End Systems are part of a LISP 463 site, and the NVE function is provided by LISP xTRs. xTRs provide for 464 tenant separation, perform the encap/decap function, and interface 465 with the LISP Mapping System that maps tenant addressing information 466 (in the EID name space) on the underlay L3 infrastructure (in the 467 RLOC name space). 469 Tenant segregation across LISP sites is provided by the LISP Instance 470 ID (IID), a 24-bit value that is used by the LISP routers as the 471 Virtual Network Identifier (VNI). Virtualization and Segmentation 472 with LISP is addressed in section 5.5 of [I-D.ietf-lisp]. 474 ............... ,---------. .............. 475 . +--------+ . ,' `. . +--------+ . 476 . | Tenant | . (Mapping System ) . | Tenant | . 477 . | End +---+ `. ,' +---| End | . 478 . | System | . | `-+------+' | . | System | . 479 . +--------+ . | ................... | . +--------+ . 480 . . | +-+--+ +--+-+ | . . 481 . . | | NV | | NV | | . . 482 . LISP Site . +--|Edge| |Edge|--+ . LISP Site . 483 . . +-+--+ +--+-+ . . 484 . . / (xTR) L3 Overlay (xTR)\ . . 485 . +--------+ . / . Network . \ . +--------+. 486 . | Tenant +---+ . . +----| Tenant |. 487 . | End | . . (xTR) . . | End |. 488 . | System | . . +----+ . . | System |. 489 . +--------+ . .....| NV |........ . +--------+. 490 ............... |Edge| ............. 491 +----+ 492 .........|............ 493 . |LISP Site . 494 . | . 495 . +--------+ . 496 . | Tenant | . 497 . | End | . 498 . | System | . 499 . +--------+ . 500 ...................... 502 Generic reference model for DC NVO3 LISP infrastructure 504 4.2. LISP NVE Service Types 506 LISP can be used to support both L2 NVE and L3 NVE service types 507 thanks to the flexibility provided by the LISP Canonical Address 508 Format [I-D.ietf-lisp-lcaf], that allows for EIDs to be encoded 509 either as MAC addresses or IP addresses. 511 4.2.1. LISP L2 NVE Services 513 The frame format defined in [I-D.mahalingam-dutt-dcops-vxlan], has a 514 header compatible with the LISP data path encapsulation header, when 515 MAC addresses are used as EIDs, as described in section 4.12.2 of 516 [I-D.ietf-lisp-lcaf]. 518 The LISP control plane is extensible, and can support non-LISP data 519 path encapsulations such as NVGRE 520 [I-D.sridharan-virtualization-nvgre], or other encapsulations that 521 provide support for network virtualization. 523 4.2.2. LISP L3 NVE Services 525 LISP is defined as a virtualized IP routing and forwarding service in 526 [I-D.ietf-lisp], and as such can be used to provide L3 NVE services. 528 5. Functional Components 530 This section describes the functional components of a LISP NVE as 531 defined in Section 3 of [I-D.lasserre-nvo3-framework]. 533 5.1. Generic Service Virtualization Components 535 The generic reference model for NVE is depicted in Section 3.1 of 536 [I-D.lasserre-nvo3-framework]. 538 +------- L3 Network ------+ 539 | | 540 | Tunnel Overlay | 541 +------------+---------+ +---------+------------+ 542 | +----------+-------+ | | +---------+--------+ | 543 | | Overlay Module | | | | Overlay Module | | 544 | +---------+--------+ | | +---------+--------+ | 545 | |VN context| | VN context| | 546 | | | | | | 547 | +--------+-------+ | | +--------+-------+ | 548 | | VNI | | | | VNI | | 549 NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2 550 | | VAPs | | | | VAPs | | 551 +----+------------+----+ +----+------------+----+ 552 | | | | 553 -------+------------+-----------------+------------+------- 554 | | Tenant | | 555 | | Service IF | | 556 Tenant End Systems Tenant End Systems 558 Generic reference model for NV Edge 560 5.1.1. Virtual Attachment Points (VAPs) 562 In a LISP NVE, Tunnel Routers (xTRs) implement the NVE functionality 563 on ToRs or Virtual Switches. Tenant End Systems attach to the 564 Virtual Access Points (VAPs) provided by the xTRs (either a physical 565 port or a virtual interface). 567 5.1.2. Overlay Modules and Tenant ID 569 The xTR also implements the function of NVE Overlay Module, by 570 mapping the addressing information (EIDs) of the tenant packet on the 571 appropriate locations (RLOCs) in the underlay network. The Tenant 572 Network Identifier (TNI) is encoded in the encapsulated packet 573 (either in the 24-bit IID field of the LISP header for L2/L3 LISP 574 encapsulation, or in the 24-bit VXLAN Network Identifier field for 575 VXLAN encapsulation, or in the 24-bit NVGRE Tenant Network Identifier 576 field of NVGRE). In a LISP NVE globally unique (per administrative 577 domain) TNIs are used to identify the Tenant instances. 579 The mapping of the tenant packet address onto the underlay network 580 location is "pulled" on-demand from the mapping system, and cached at 581 the NVE in a per-TNI map-cache. 583 5.1.3. Tenant Instance 585 Tenants are mapped on LISP Instance IDs (IIDs), and the xTR keeps an 586 instance of the LISP control protocol per each IID. The ETR is 587 responsible to register the Tenant End System to the LISP mapping 588 system, via the Map-Register service provided by LISP Map-Servers 589 (MS). The Map-Register includes the IID that is used to identify the 590 tenant. 592 5.1.4. Tunnel Overlays and Encapsulation Options 594 The LISP control protocol, as defined today, provides support for L2 595 LISP and VXLAN L2 over L3 encapsulation, and LISP L3 over L3 596 encapsulation. 598 We believe that the LISP control Protocol can be easily extended to 599 support different IP tunneling options (such as NVGRE). 601 5.1.5. Control Plane Components 603 5.1.5.1. Auto-provisioning/Service Discovery 605 The LISP framework does not include mechanisms to provision the local 606 NVE with the appropriate Tenant Instance for each Tenant End Systems. 607 Other protocols, such as VDP (in IEEE P802.1Qbg), should be used to 608 implement a network attach/detach function. 610 The LISP control plane can take advantage of such a network attach/ 611 detach function to trigger the registration of a Tenant End System to 612 the Mapping System. This is particularly helpful to handle mobility 613 across DC of the Tenant End System. 615 It is possible to extend the LISP control protocol to advertise the 616 tenant service instance (tenant and service type provided) to other 617 NVEs, and facilitate interoperability between NVEs that are using 618 different service types. 620 5.1.5.2. Address Advertisement and Tunnel mapping 622 As traffic reaches an ingress NVE, the corresponding ITR uses the 623 LISP Map-Request/Reply service to determine the location of the 624 destination End System. 626 The LISP mapping system combines the distribution of address 627 advertisement and (stateless) tunneling provisioning. 629 When EIDs are mapped on both IP addresses and MACs, the need to flood 630 ARP messages at the NVE is eliminated resolving the issues with 631 explosive ARP handling. 633 5.1.5.3. Tunnel Management 635 LISP defines several mechanisms for determining RLOC reachability, 636 including Locator Status Bits, "nonce echoing", and RLOC probing. 637 Please see Sections 5.3 and 6.3 of [I-D.ietf-lisp]. 639 6. Key Aspects of Overlay 641 6.1. Overlay Issues to Consider 643 6.1.1. Data Plane vs. Control Plane Driven 645 The use of LISP control plane minimizes the need for multicast in the 646 underlay network overcoming the scalability limitations of VXLAN 647 dynamic data plane learning (Flood-and-Learn). 649 Multicast or ingress replication in the underlay network are still 650 required, as specified in [I-D.ietf-lisp-multicast], 651 [I-D.farinacci-lisp-mr-signaling], and [I-D.farinacci-lisp-te], to 652 support broadcast, unknown, and multicast traffic in the overlay, but 653 multicast in the underlay is no longer required (at least for IP 654 traffic) for unicast overlay services. 656 6.1.2. Data Plane and Control Plane Separation 658 LISP introduces a clear separation between data plane and control 659 plane functions. LISP modular design allows for different mapping 660 databases, to achieve different scalability goals and to meet 661 requirements of different deployments. 663 6.1.3. Handling Broadcast, Unknown Unicast and Multicast (BUM) Traffic 665 Packet replication in the underlay network to support broadcast, 666 unknown unicast and multicast overlay services can be done by: 668 o Ingress replication 670 o Use of underlay multicast trees 672 [I-D.ietf-lisp-multicast] specifies how to map a multicast flow in 673 the EID space during distribution tree setup and packet delivery in 674 the underlay network. LISP-multicast doesn't require packet format 675 changes in multicast routing protocols, and doesn't impose changes in 676 the internal operation of multicast in a LISP site. The only 677 operational changes are required in PIM-ASM [RFC4601], MSDP 679 [RFC3618], and PIM-SSM [RFC4607]. 681 7. Security Considerations 683 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 684 origin authentication, integrity and anti-replay protection to LISP's 685 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 686 SEC also enables verification of authorization on EID-prefix claims 687 in Map-Reply messages. 689 Additional security mechanisms to protect the LISP Map-Register 690 messages are defined in [I-D.ietf-lisp-ms]. 692 The security of the Mapping System Infrastructure depends on the 693 particular mapping database used. The [I-D.fuller-lisp-ddt] 694 specification, as an example, defines a public-key based mechanism 695 that provides origin authentication and integrity protection to the 696 LISP DDT protocol. 698 8. IANA Considerations 700 This document has no IANA implications 702 9. Acknowledgements 704 The authors want to thank Victor Moreno and Paul Quinn for the early 705 review, insightful comments and suggestions. 707 10. References 709 10.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 715 Protocol (MSDP)", RFC 3618, October 2003. 717 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 718 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 719 Protocol Specification (Revised)", RFC 4601, August 2006. 721 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 722 IP", RFC 4607, August 2006. 724 10.2. Informative References 726 [I-D.farinacci-lisp-mr-signaling] 727 Farinacci, D. and M. Napierala, "LISP Control-Plane 728 Multicast Signaling", draft-farinacci-lisp-mr-signaling-00 729 (work in progress), July 2012. 731 [I-D.farinacci-lisp-te] 732 Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic 733 Engineering Use-Cases", draft-farinacci-lisp-te-00 (work 734 in progress), March 2012. 736 [I-D.fuller-lisp-ddt] 737 Fuller, V. and D. Lewis, "LISP Delegated Database Tree", 738 draft-fuller-lisp-ddt-01 (work in progress), March 2012. 740 [I-D.ietf-lisp] 741 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 742 "Locator/ID Separation Protocol (LISP)", 743 draft-ietf-lisp-23 (work in progress), May 2012. 745 [I-D.ietf-lisp-alt] 746 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 747 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 748 (work in progress), December 2011. 750 [I-D.ietf-lisp-interworking] 751 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 752 "Interworking LISP with IPv4 and IPv6", 753 draft-ietf-lisp-interworking-06 (work in progress), 754 March 2012. 756 [I-D.ietf-lisp-lcaf] 757 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 758 Address Format (LCAF)", draft-ietf-lisp-lcaf-00 (work in 759 progress), August 2012. 761 [I-D.ietf-lisp-ms] 762 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 763 draft-ietf-lisp-ms-14 (work in progress), December 2011. 765 [I-D.ietf-lisp-multicast] 766 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 767 "LISP for Multicast Environments", 768 draft-ietf-lisp-multicast-14 (work in progress), 769 February 2012. 771 [I-D.ietf-lisp-sec] 772 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 773 and O. Bonaventure, "LISP-Security (LISP-SEC)", 774 draft-ietf-lisp-sec-02 (work in progress), March 2012. 776 [I-D.ietf-nvo3-overlay-problem-statement] 777 Narten, T., Black, D., Dutt, D., Fang, L., Gray, E., 778 Kreeger, L., Napierala, M., and M. Sridhavan, "Problem 779 Statement: Overlays for Network Virtualization", 780 draft-ietf-nvo3-overlay-problem-statement-00 (work in 781 progress), September 2012. 783 [I-D.lasserre-nvo3-framework] 784 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 785 Rekhter, "Framework for DC Network Virtualization", 786 draft-lasserre-nvo3-framework-03 (work in progress), 787 July 2012. 789 [I-D.mahalingam-dutt-dcops-vxlan] 790 Sridhar, T., Bursell, M., Kreeger, L., Dutt, D., Wright, 791 C., Mahalingam, M., Duda, K., and P. Agarwal, "VXLAN: A 792 Framework for Overlaying Virtualized Layer 2 Networks over 793 Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-01 794 (work in progress), February 2012. 796 [I-D.smith-lisp-layer2] 797 Smith, M. and D. Dutt, "Layer 2 (L2) LISP Encapsulation 798 Format", draft-smith-lisp-layer2-00 (work in progress), 799 March 2011. 801 [I-D.sridharan-virtualization-nvgre] 802 Sridhavan, M., Duda, K., Ganga, I., Greenberg, A., Lin, 803 G., Pearson, M., Thaler, P., Tumuluri, C., and Y. Wang, 804 "NVGRE: Network Virtualization using Generic Routing 805 Encapsulation", draft-sridharan-virtualization-nvgre-00 806 (work in progress), September 2011. 808 Authors' Addresses 810 Fabio Maino 811 Cisco Systems 812 170 Tasman Drive 813 San Jose, California 95134 814 USA 816 Email: fmaino@cisco.com 817 Vina Ermagan 818 Cisco Systems 819 170 Tasman Drive 820 San Jose, California 95134 821 USA 823 Email: vermagan@cisco.com 825 Dino Farinacci 826 Cisco Systems 827 170 Tasman Drive 828 San Jose, California 95134 829 USA 831 Email: dino@cisco.com 833 Michael Smith 834 Insieme Networks 835 California 836 USA 838 Email: michsmit@insiemenetworks.com