idnits 2.17.1 draft-hertoghs-nvo3-lisp-controlplane-unified-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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 3 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 (July 21, 2014) is 3567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 937 -- Looks like a reference, but probably isn't: '2' on line 937 -- Looks like a reference, but probably isn't: '3' on line 939 == Unused Reference: 'I-D.barkai-lisp-nfv' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-overlay-problem-statement' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'I-D.kompella-nvo3-server2nve' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC6836' is defined on line 1111, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-barkai-lisp-nfv-04 == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-mr-signaling-04 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-06 == 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-05 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-06 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-nve-nva-cp-req-02 -- No information found for draft-ietf-nvo3 - is the name correct? == Outdated reference: A later version (-04) exists of draft-lewis-lisp-gpe-02 == Outdated reference: A later version (-04) exists of draft-quinn-vxlan-gpe-03 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-04 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- 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: 1 error (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Virtualization Overlays Working Group Y. Hertoghs 3 Internet-Draft F. Maino 4 Intended status: Informational V. Moreno 5 Expires: January 20, 2015 M. Smith 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 L. Iannone 10 Telecom ParisTech 11 July 21, 2014 13 A Unified LISP Mapping Database for L2 and L3 Network Virtualization 14 Overlays 15 draft-hertoghs-nvo3-lisp-controlplane-unified-02 17 Abstract 19 The purpose of this draft is to document how the Locator/ID 20 Separation Protocol (LISP) Control Plane can be used to offer a 21 unified (offering L2 AND L3) Overlay solution that matches the 22 framework and requirements of Network Virtualization over L3 (NVO3). 23 This information is provided as input to the NVO3 analysis of the 24 suitability of existing IETF protocols to the NVO3 requirements. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 20, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 67 3. NVO3 Framework and LISP . . . . . . . . . . . . . . . . . . . 4 68 3.1. NVO3 Generic Reference Model . . . . . . . . . . . . . . . 4 69 3.2. NVE Reference Model . . . . . . . . . . . . . . . . . . . 4 70 3.2.1. Types of NVE's . . . . . . . . . . . . . . . . . . . . 4 71 3.2.1.1. L2 only NVE . . . . . . . . . . . . . . . . . . . 5 72 3.2.1.2. L3 only NVE . . . . . . . . . . . . . . . . . . . 5 73 3.2.1.3. Unified L2/L3 NVE . . . . . . . . . . . . . . . . 5 74 3.2.2. Multihoming aspects . . . . . . . . . . . . . . . . . 7 75 3.2.3. External connectivity aspects . . . . . . . . . . . . 7 76 3.2.4. Optimal Forwarding aspects . . . . . . . . . . . . . . 8 77 3.2.5. VM Mobility aspects . . . . . . . . . . . . . . . . . 8 78 3.2.5.1. VM Mobility at L2 . . . . . . . . . . . . . . . . 9 79 3.2.5.2. VM Mobility at L3 . . . . . . . . . . . . . . . . 9 80 3.3. LISP dataplane options and NVO3 dataplane requirements . . 12 81 3.3.1. Native LISP Data Plane . . . . . . . . . . . . . . . . 12 82 3.3.2. LISP with Generic Protocol Extension (LISP-GPE) . . . 14 83 3.3.3. VxLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 15 84 3.3.4. L2 only solutions such as VxLAN and nvGRE . . . . . . 15 85 3.4. NVO3 control plane requirements and LISP . . . . . . . . . 15 86 3.4.1. Inner to Outer Address Mapping . . . . . . . . . . . . 15 87 3.4.2. Underlying network Multi-Destination Delivery . . . . 16 88 3.4.3. VN connect/disconnect . . . . . . . . . . . . . . . . 16 89 3.4.4. VN name to VN ID Mapping . . . . . . . . . . . . . . . 17 90 3.4.5. LISP Control Plane Characteristics in an NVO3 context 17 91 3.5. NVO3 OAM Requirements and LISP . . . . . . . . . . . . . . 19 92 3.6. NVO3 Management Plane Requirements and LISP . . . . . . . 19 93 3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Introduction 103 The purpose of this draft is to provide a mapping between the Network 104 Virtualization over L3 (NVO3) framework [I-D.ietf-nvo3-framework] and 105 the Locator/ID Separation Protocol (LISP) [RFC6830], and in 106 particular how LISP components map to the reference models defined 107 therein. This document extends the scope of[I-D.maino-nvo3-lisp-cp] 108 to cover the case of a unified overlay that includes L2 and L3 109 services. 111 LISP is a flexible map and encap framework that can be used for 112 overlay network applications, including Data Center Network 113 Virtualization. The LISP framework provides two main tools for NVO3: 115 1. A Data Plane that specifies how Endpoint Identifiers (EIDs) are 116 encapsulated in Routing Locators (RLOCs), and 118 2. A Control Plane that specifies the interfaces to the LISP Mapping 119 System [RFC6833]. The LISP Mapping system provides the mapping 120 between EIDs and RLOCs. 122 LISP can be leveraged to offer services to both Physical and Virtual 123 endpoints, and is architecturally EID address family agnostic. Some 124 flows will be across an L3 overlay (using IP addresses as EIDs), and 125 other flows will be across an L2 overlay (using MAC addresses as 126 EIDs). 128 If certain requirements are met within the architecture, the choice 129 of whether a flow is sent across the L2 overlay versus across the L3 130 overlay is not mapped one to one to the choice between intra subnet 131 (bridging) and inter subnet (routing) forwarding. This allows the 132 network administrator to offer infrastructure spanning subnets to its 133 tenants, while not forcing them to deploy infrastructure-wide 134 broadcast domains. 136 This document will focus on how to offer a unified L2 and L3 overlay, 137 where both L2 and L3 services can be offered to the tenant's traffic 138 simultaneously. 140 The draft will elaborate on achieving multi homing of Tenant Systems 141 (TS), as well as optimal routing and forwarding, including how VM 142 mobility is achieved and optimal traffic forwarding is achieved. 144 Although the LISP specification uses a specific data plane, its 145 control plane can be decoupled fairly easily from the data plane and 146 thus can support various data plane encapsulations. After describing 147 the various data plane options, this document also addresses the NVO3 148 data plane requirements[I-D.ietf-nvo3-dataplane-requirements]. 150 The document continues to lay out how the NVO3 control plane 151 requirements [I-D.ietf-nvo3-nve-nva-cp-req] are addressed. 153 Finally this document will provide security considerations in Section 154 5 156 2. Definition of Terms 158 Flood-and-Learn: the use of dynamic (data plane) learning in VXLAN 159 to discover the location of a given Ethernet/IEEE 802 MAC address 160 in the underlay network. 162 For definition of NVO3 related terms, notably Tenant System (TS), 163 Virtual Network (VN), Virtual Network Identifier (VNI), Network 164 Virtualization Edge (NVE), Network Virtualization Authority (NVA), 165 Data Center (DC), please consult [I-D.ietf-nvo3-framework]. 167 For definitions of LISP related terms, notably Map-Request, Map- 168 Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), 169 Endstation IDentifier (EID), Routing LOCator (RLOC), Map-Server (MS) 170 and Map-Resolver (MR) please consult the LISP specification 171 [RFC6830]. 173 3. NVO3 Framework and LISP 175 3.1. NVO3 Generic Reference Model 177 [I-D.maino-nvo3-lisp-cp] provides a mapping of the NVO3 generic 178 reference model [I-D.ietf-nvo3-framework] onto the LISP architecture. 179 In this document we will focus on the unified L2/L3 LISP control 180 plane, and on how it will optimize forwarding . 182 3.2. NVE Reference Model 184 The LISP NVE Reference Model is described in [I-D.maino-nvo3-lisp- 185 cp]. This section will look at the different types of NVEs: L2-only, 186 L3-only, and unified L2/L3, as well as looking at VM Mobility, Multi- 187 homing, optimal forwarding and external connectivity aspects. How 188 TSes connect to the network is described in Section 3.4.3. 190 3.2.1. Types of NVE's 192 [RFC6830] is defined as a L3 NVE, and it can be enhanced to support 193 L2 NVEs. 195 The separation of the L2 NVE and L3 NVE functions can be based on the 196 nature of the packets: bridged packets are assigned to the L2 NVE 197 function, while routed packets are assigned to the L3 NVE function. 198 Therefore these discrete functions could live on discrete networking 199 nodes. 201 However, it is possible to use LISP as an unified control plane, that 202 combines and co-locates the function of L2/L3 NVE onto a single node. 203 The network administrator can choose which traffic will be forwarded 204 across each service type. 206 3.2.1.1. L2 only NVE 208 [I-D.smith-lisp-layer2] describes an encapsulation method for 209 carrying Ethernet and IEEE 802 media access control (MAC) frames 210 within the Locator/ID Separation Protocol (LISP). As described in 211 [I-D.maino-nvo3-lisp-cp] MAC addresses are used as EIDs in an L2 only 212 NVE. As control plane learning is used, only broadcast and multicast 213 traffic needs mult-destination support from the underlay. 215 The frame format defined in [I-D.mahalingam-dutt-dcops-vxlan], has a 216 header compatible with the LISP data path encapsulation header, when 217 MAC addresses are used as EIDs, as described in section 4.12.2 of 218 [I-D.ietf-lisp-lcaf]. 220 The LISP control plane is extensible, and can support non-LISP data 221 path encapsulations such as NVGRE [I-D.sridharan-virtualization- 222 nvgre], or other encapsulations that provide support for network 223 virtualization. 225 3.2.1.2. L3 only NVE 227 LISP is defined as a virtualized IP routing and forwarding service in 228 [RFC6830], and as such can be used to provide L3 NVE services. 230 3.2.1.3. Unified L2/L3 NVE 232 When using a unified L2/L3 NVE, IP EIDs are registered to the LISP 233 mapping system with the MAC Address of the Tenant System (TS) as an 234 additional RLOC (next to the NVE RLOC), through the methods defined 235 in [I-D.ietf-lisp-lcaf], by encoding Key/Value Pairs. MAC Address 236 based EIDs will also be registered for TSes that are transmitting 237 non-IP based traffic. TSes that send out both IP and non-IP traffic 238 will therefore be registered twice. For the L2 overlay the Virtual 239 Networking Instance (VNI)/IID denotes a network-wide bridge domain, 240 while for the L3 overlay the VNI/IID denotes a Virtual Routing 241 Forwarding (VRF) instance. 243 Implementing an NVE with a unified L2 and L3 overlay support is 244 beneficial for multiple reasons: 246 Primarily it allows the network administrator to choose which traffic 247 traverses the L2 overlay versus the L3 overlay, not only on the basis 248 of intra-subnet (bridged) versus inter-subnet (routed) traffic flows. 249 As a matter of fact, it is highly beneficial to choose a policy where 250 all IP traffic is forwarded across the L3 overlay (i.e. both intra- 251 and inter-subnet traffic). Effectively this allows the 'spread' of 252 subnets across the Datacenter(s) without leading to network wide 253 broadcast and associated failure domains, while allowing free 254 mobility of the end-stations. 256 Secondarily, when all the TS IP and MAC addresses are registered with 257 the NVA/LISP Mapping system, optimisations in ARP and ND [RFC4861] 258 forwarding and handling can be achieved. ARPs and IPv6 NDs for 259 'unknown' destinations are by default dropped, although a policy can 260 allow for 'unknown' ARP/ND packets to be flooded across the underlay 261 if so desired by the operator (e.g. when there is a desire to 262 support 'silent hosts'). 264 Finally, as all IP traffic is forwarded across a L3 overlay, and ARP/ 265 ND operations do not need flooding services, the amount of traffic 266 that needs to traverse the L2 overlay is limited to non-IP traffic 267 only. This makes the registration of MAC-addresses as EIDs with the 268 LISP control plane optional. The system in this case could use 269 ingress replication and Flood-and-Learn to handle the non-IP traffic. 270 Of course, the use of the LISP control plane for MAC address based 271 EIDs is another option as well, but the choice is left to the network 272 administrator. 274 However, in order to achieve the benefits of this model, there are 275 some requirements of how TSs can connect to the unified L2/L3 NVE, 276 and there are also requirements on how default gateway MAC/IP 277 addresses are assigned to the NVE function, and how forwarding is 278 done on the NVE function: 280 o The NVE MUST always do an IP lookup for IP based traffic, 281 independent of whether the destination is within the same subnet 282 or not, or whether the destination TS is attached to the same VLAN 283 or L2 NVI as the source TS. 285 o The unified L2/L3 NVE NVI instance MUST have a uniform default 286 gateway MAC-address and IP address across the entire NVO3 network. 287 This is to make sure that a TS can always reach its default 288 gateway, irrespective of location. 290 o A TS can connect across a L2 switched network to a unified L2/L3 291 NVE, but traffic forwarded MUST follow a simple rule, where all 292 traffic from a TS MUST always be sent upstream to the unified L2/ 293 L3 NVE, regardless of its destination MAC address, and traffic 294 from locally attached TS's MUST be switched through the NVE. 295 Directly connecting a TS to a unified L2/L3 NVE automatically 296 solves that requirement. 298 There are various options to provide unified L2 and L3 support for 299 LISP in the data path. 301 [I-D.smith-lisp-layer2] extends LISP to support MAC addresses as 302 EIDs, and can be used in combination with [RFC6830], using the 303 destination UDP port in the outer LISP header for disambiguation. 305 Recently extensions to both LISP and VXLAN have been proposed to 306 offer multiprotocol support across the same outer header format (i.e. 307 using a single UDP port number), as described in [I-D.lewis-lisp- 308 gpe], and [I-D.quinn-vxlan-gpe] respectively. It is to be noted that 309 some functionality offered by native LISP is no longer available when 310 using the [I-D.lewis-lisp-gpe]extension (namely nonce, echo-nonce, 311 and map-versioning). These are optional control plane optimizations 312 implemented in the data plane for [RFC6830], and their use is less 313 relevant in DC applications. 315 The remainder of this document assumes a unified L2/L3 NVE deployment 316 model. 318 3.2.2. Multihoming aspects 320 If the TSes are co-located with the xTR/NVE function, no support for 321 multi-homing is needed. 323 If the network between the L2 device connecting the TSes and the LISP 324 xTRs is a simple hub and spoke switched L2 topology using VLANs (this 325 is a common assumption in DC networks), a multi-chassis Link 326 Aggregation Group (LAG) solution can be used to offer redundancy, 327 where both xTRs will be seen by the access device as one logical 328 entity. xTRs connected to the same L2 switched access network are 329 part of the same 'LISP site', and both of them can be used to send 330 traffic to TSes behind them, as both xTRs are registering to the LISP 331 mapping system for the EIDs behind them. Registrations performed by 332 the individual xTR (as a result of detection of a new EID) part of 333 the same site are performed using the RLOCs of all xTRs connected to 334 that site. How the multi-chassis LAG solution is build is out of 335 scope of this draft. 337 3.2.3. External connectivity aspects 339 External connectivity between a LISP enabled NVO3 DC, as well as any 340 LISP site, and the external world can be handled through a gateway 341 device. 343 In case the gateway device handles connectivity to VPNs or the 344 Internet, LISP interworking will be employed at the gateway device as 345 per [RFC6832]. 347 In case the gateway device is used to interconnect to another DC part 348 of the same administrative domain (one Mapping System governs both 349 DCs), the only function needed on this device is routing within the 350 RLOC address space. 352 In case separate LISP Mapping systems are used, interworking has to 353 be established between them, as well as providing routing between the 354 two administrative domain in between the RLOC address spaces of both 355 DCs respectively. Today there is no described way of interworking 356 between DDT based Mapping systems. An external controller could also 357 insert new RLOC locations into a DDT based Mapping system when an EID 358 has moved to a location not governed by this particular Mapping 359 system. 361 3.2.4. Optimal Forwarding aspects 363 Implementing a co-located and unified L2 and L3 NVE, and placing that 364 NVE as close as possible to the TSes, leads to the most optimal 365 forwarding. 367 East-to-west traffic (from NVE to NVE) will always be mapped-and- 368 encapped towards the 'right' NVE, as the NVA function (the LISP 369 Mapping system) has knowledge about all of the TSes IP and MAC 370 addresses. 372 North to South traffic (traffic ingress into the DC) will also be 373 delivered to the right NVE, without traffic tromboning, as traffic is 374 switched based on the EID IP address, which will always point to the 375 correct ETR/RLOC. 377 Traffic going from TSes to external destinations will also not be 378 affected by traffic tromboning as all NVE's part of an NVI are seen 379 as the same default gateway, independent of location. 381 Traffic tromboning can occur if the last hop router is not in the 382 same location as the egress NVE, and if only a single L2 NVE is 383 deployed. In other words, the only way for a L2-only NVE based NVO3 384 system to avoid traffic tromboning for north-south traffic, is by 385 centralizing the default gateway for all VNI's in one location (that 386 in some cases may be suboptimal). 388 3.2.5. VM Mobility aspects 390 This section shows how the LISP control plane deals with VM mobility 391 when end systems are migrated from one NVE/DC to another. 393 We'll assume that a signaling protocol, as described in [I-D 394 .kompella-nvo3-server2nve], signals to the NVE operations such as 395 creating/terminating/migrating an end system. The signaling protocol 396 consists of three basic messages: "associate", "disassociate", and 397 "pre-associate". The signaling protocol for attach/detach is in 398 addition and orthogonal to the LISP control plane. 400 Two approaches are laid out: An approach at L2, where MAC-addresses 401 are used as EID, and an approach at L3, where both IP and MAC 402 addresses are used as EIDs. 404 3.2.5.1. VM Mobility at L2 406 VM mobility at L2 is described in [I-D.maino-nvo3-lisp-cp] 408 It is to be noted that the approach of solving VM mobility at L2 409 introduces scalability problems in terms of failure domain, NVA 410 scaling (as MAC addresses are a flat and non de-aggregatable address 411 space) and BUM containment. 413 3.2.5.2. VM Mobility at L3 415 This approach solves the scaling problems of the L2 approach by 416 assuming that the majority of traffic is IP based. End Systems are 417 therefor registered with their IP addresses as EID and xTR IP address 418 as an RLOC, while their MAC-address is registered as an additional 419 RLOC for the same EID. 421 ,---------. 422 ,' `. 423 (Mapping System ) 424 `. ,' 425 `-+------+' 426 +--+--+ +-+---+ 427 |MS/MR| |MS/MR| 428 +-+---+ +-----+ 429 | | 430 .--..--. .--. .. 431 ( ' '.--. 432 .-.' L3 ' 433 ( Underlay ) 434 ( '-' 435 ._.'--'._.'.-._.'.-._) 436 RLOC=IP_A // \\ RLOC=IP_B 437 +---+--+ +-+--+--+ 438 .--.-.|xTR A |'.-. .| xTR B |.-. 439 ( +---+--+ ) ( +-+--+--+ ) 440 ( __. ( '. 441 ..' LISP Site A ) .' LISP Site B ) 442 ( .'-' ( .'-' 443 '--'._.'. )\ '--'._.'. )\ 444 / '--' \ / '--' \ 445 '--------' '--------' '--------' '--------' 446 : End : : End : ==> : End : : End : 447 : Device : : Device : ==> : Device : : Device : 448 '--------' '--------' '--------' '--------' 449 EID= EID= EID= 450 EID= 451 453 It is assumed that the LISP xTRs have a unified L2 and L3 map-en- 454 encap function, where IP packets, regardless of the fact they are 455 switched intra- or inter subnet, are mapped-and-encapped across the 456 L3 overlay. All other traffic (non-routable traffic, non-IP traffic) 457 is mapped-and-encapped by the L2 overlay. It is also assumed that 458 all XTRs offer the same default gateway IP and MAC address across the 459 network, on a per VNI instance. 461 A unified L2/L3 overlay will lead in the xTRs registering two sets of 462 EIDs for specific end systems, who deliver a mix of IP and non-IP 463 traffic: 465 o A tuple of EID= to use for IP traffic across the L3 466 overlay, whereby the IID maps to a VRF instance. It will register 467 the EID to multiple RLOCs, one being the xTR IP address, and the 468 other one being the TS MAC Address. 470 o A tuple EID= to use for non-routable, non-IP traffic, 471 across the L2 overlay, whereby the IID maps to a network-wide 472 Bridge Domain. 474 Assume the scenario described in Figure 1. Also assume that for the 475 sake of this discussion, the VMs do not send out traffic that needs 476 treatment by an L2 overlay. 478 As a result of the end system registration, the Mapping System 479 contains the EID-to-RLOC mapping for end system W that associates 480 EID= with the RLOC(s) associated with LISP site A (IP_A), 481 as well as the RLOC associated with the MAC Address MAC_W of the end 482 system W. 484 The process of migrating end system W from data center A to data 485 center B is initiated. 487 ETR B receives a pre-associate message that includes EID=. ETR B sends a Map-Register to the mapping system registering 489 RLOC=IP_B as an additional locator for end system W with priority set 490 to 255. This means that the RLOC MUST NOT be used for unicast 491 forwarding, but the mapping system is now aware of the new location. 493 During the migration process of end system W, ETR A receives a 494 dissociate message, and sends a Map-Register with Record TTL=0 to 495 signal the mapping system that end system W is no longer reachable at 496 RLOC=IP_A. xTR A will also add an entry in its forwarding table that 497 marks EID= as non-local. 499 When end system W has completed its migration, ETR B receives an 500 associate message for end system W, and sends a Map-Register to the 501 mapping system setting a non-255 priority for RLOC=IP_B. Now the 502 mapping system is updated with the new EID-to-RLOC mapping for end 503 system W with the desired priority. 505 The remote ITRs that were corresponding with end system W during the 506 migration will keep sending packets to ETR A. 508 ETR A will keep forwarding locally those packets until it receives a 509 dissociate message, and the entry in the forwarding table associated 510 with EID= is marked as non-local. 512 Subsequent packets arriving at ETR A from a remote ITR, and destined 513 to end system W will hit the entry in the forwarding table that will 514 generate an exception, and will generate a Solicit-Map-Request (SMR) 515 message that is returned to the remote ITR. 517 Upon receiving the SMR the remote ITR will invalidate its local map- 518 cache entry for EID= and send a new Map-Request for that 519 EID. The Map-Request will generate a Map-Reply that includes the new 520 EID-to-RLOC mapping for end system W with RLOC=IP_B. 522 Similarly, unencapsulated packets arriving at ITR A from local end 523 systems and destined to end system W will hit the entry in the 524 forwarding table marked as non-local, and will generate an exception 525 that by sending a Map-Request for EID= will populate the 526 map-cache of ITR A with an EID-to-RLOC mapping for end system W with 527 RLOC=IP_B. 529 3.3. LISP dataplane options and NVO3 dataplane requirements 531 This section maps the NVO3 data plane requirements [I-D.ietf-nvo3 532 -dataplane-requirements] to the various options available. 534 3.3.1. Native LISP Data Plane 536 Figure 2shows the LISP header defined in the LISP specification 537 [RFC6830]. The UDP and LISP headers are shown below for reference. 538 For header fields description see section 5.3 of [RFC6830]. 540 0 1 2 3 541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | IPv4 or IPv6 Header (with RLOC addresses) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 / | Source Port = xxxx | Dest Port = (L2-)LISP | 546 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 \ | UDP Length | UDP Checksum | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 L |N|L|E|V|I|flags| Nonce/Map-Version | 550 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 S / | Instance ID/Locator Status Bits | 552 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 When the headers are used for encapsulating IP Packets, the UDP 555 Destination Port is set to 4341. When the headers are used for 556 encapsulating L2 frames, the UDP Destination Port is set to 8472 [I-D 557 .smith-lisp-layer2]. 559 When used in private DC and Enterprise networks, the 'I'-bit 560 (Instance bit) is set, indicating the presence of an Instance ID 561 (IID) inside the header. A Virtual Networking Instance (VNI) is 562 indicated by the IID, a 24 bit field, which is used as a global 563 identifier for the tenant in LISP. When used for L3 services, the IID 564 can be seen as a VRF, when used for L2 services, the IID can be seen 565 as a L2 Bridge Domain instance. 567 Virtual Access Point (VAP) identification is naturally supported by 568 combining LISP and Integrated Routing and Bridging (IRB). IRB allows 569 local ports or logical ports (ports instantiated on a local port, 570 where frames are assigned based on some fields in the header like 571 VLAN IDs (VIDs)), to be added to a NVE-local bridge domain. That 572 bridge domain instantiates the L2 Specific VNI. The bridge domain 573 also connects to a virtual routed port, which instantiates the L3 574 specific VNI. 576 A L2 VNI provides an emulated Ethernet Multipoint service through the 577 use of the LISP control plane, where it registers MAC addresses as 578 EIDs. 580 Loop-avoidance is handled by control plane learning, and control 581 plane enabled registration of all TS EIDs as soon as they send a 582 first packet. Therefore unicast traffic will never result in loops, 583 as there is no 'unknown' unicast. multi-destination traffic 584 forwarding is performed using a multicast enabled underlay and LISP 585 procedures laid out in [RFC6831] or through ingress replication to 586 the list of participating NVEs in that NVI, and therefore is loop- 587 free. 589 A L3 VNI behaves exactly as an IP VRF and therefore supports 590 virtualized IP routing and forwarding, through per tenant forwarding 591 with IP address isolation and L3 tunneling for interconnecting 592 instances of the same VNI on NVEs. 594 Note that , within this document, it is assumed that a unified L2/L3 595 NVE is deployed and therefore all IP traffic will be forwarded using 596 the L3 overlay, even intra-subnet traffic. 598 The LISP header performs the function of the NVO3 overlay header. 600 Through using the LISP control plane, the egress NVE can be looked 601 up. 603 As the outer LISP header is an IPv4 or IPv6 header, differentiated 604 forwarding can be supported naturally. Equally, as LISP uses IP/UDP 605 as a transport, multipath over LAG and ECMP in the underlay are 606 naturally supported, through the entropy introduced in the UDP header 607 by selecting per flow source UDP port numbers. A LISP based NVO3 608 network can work in both uniform and pipe models [RFC2983] and fully 609 supports ECN marking as per [RFC6040] . 611 As it does for L3 services, the LISP control plane replaces the use 612 of dynamic data plane learning (Flood-and-Learn) for unicast traffic 613 for L2 services. Packet replication in the underlay network to 614 support L2 broadcast, unknown unicast (optional, as all MAC-address 615 are learned by the control plane) and multicast L2 and L3 overlay 616 services can be done by: 618 o Ingress replication, which reduces the need for multicast in the 619 NVO3 underlay to zero. 621 o Use of underlay multicast trees. These trees can be aggregated 622 globally, or per tenant (rather than per VNI). 624 [RFC6831] and [I-D.farinacci-lisp-mr-signaling]specifies how to map a 625 multicast flow in the EID space during distribution tree setup and 626 packet delivery in the underlay network. LISP, being an IP based 627 map-and-encap protocol, does not require any specific data plane 628 functionality to make this work. 630 LISP interworking is described in [RFC6832] and fully supports 631 connectivity to the internet or VPN gateways through the use of Proxy 632 xTR's. 634 LISP, being an IP based protocol, supports ICMP-based MTU Path 635 Discovery [RFC1191] , [RFC1981]as well as extended MTU Path Discovery 636 techniques [RFC4821]. LISP also supports a stateless and stateful 637 way of dealing with Large Encapsulated packets, see section 5.4 of 638 [RFC6830]. 640 Multi-homing is handled in the control plane, by allowing the LISP 641 mapping system to have multiple RLOC entries for every EID, allowing 642 the ITR to load balance across both ETR's. xTRs register a 'LISP 643 site id' to the mapping system when they come online. When the LISP 644 mapping system receives a registration for a given EID from a certain 645 xTRs, it will install that EID entry pointing to all the RLOCs/xTR 646 that have the same site-id. By performing LAG across multiple xTRs, 647 multi-homing can be provided for the access or virtual switch that 648 connects the TSs. 650 OAM can be performed across LISP in the same way as OAM is performed 651 over IP routed, or Ethernet L2 switched environments. 653 3.3.2. LISP with Generic Protocol Extension (LISP-GPE) 655 [I-D.lewis-lisp-gpe] introduces multiprotocol support for LISP, by 656 extending the LISP header, as shown in Figure 3 . 658 0 1 2 3 659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Source Port = xxxx | Dest Port = 4341 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | UDP Length | UDP Checksum | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |N|L|E|V|I|P|R|R| Reserved |Nonce/Map-Version/Protocol-Type| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Instance ID/Locator-Status-Bits | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 A Protocol Bit (P-bit) is introduced, that when set, allows the 671 insertion of a 16-bit Protocol Type. The UDP destination port number 672 is 4341 for all protocol types. 674 Although the use of Nonce and Map-versioning are not allowed 675 simultaneously with Protocol Type with this deployment, all of the 676 solutions to the requirements described in Section 3.3.1 are exactly 677 the same with this data plane encapsulation in an NVO3 context. 679 3.3.3. VxLAN-GPE 681 [I-D.quinn-vxlan-gpe] extends the VXLAN encapsulation with a Protocol 682 Type, by introducing a Protocol Bit (P-bit) and a 16-bit Protocol 683 Type in the VXLAN header, see Figure 4. Note that this data plane 684 encapsulation is very similar to LISP-GPE, when used in an NVO3 685 context. 687 0 1 2 3 688 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Source Port = xxxx | Dest Port = 4789 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | UDP Length | UDP Checksum | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |R|R|R|R|I|P|R|R| Reserved | Protocol Type | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | VXLAN Network Identifier (VNI) | Reserved | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 All of the solutions to the requirements described in Section 3.3.1 700 are exactly the same with this data plane encapsulation. 702 3.3.4. L2 only solutions such as VxLAN and nvGRE 704 The LISP control plane can be leveraged to offer control plane 705 learning for MAC Addresses for both the VXLAN [I-D.mahalingam-dutt- 706 dcops-vxlan], as well as NVGRE [I-D.sridharan-virtualization-nvgre]. 707 However, this solution offers sub-optimal support and hence will not 708 be looked into further. 710 3.4. NVO3 control plane requirements and LISP 712 This section maps the NVO3 NVE to NVA control plane [I-D.ietf-nvo3 713 -nve-nva-cp-req]requirements to the LISP control plane. 715 3.4.1. Inner to Outer Address Mapping 717 The LISP control plane, through the use of a Mapping service, 718 provides inner to outer address mapping. 720 TS EIDs are registered to the LISP Mapping service by LISP ETRs 721 within the context of a LISP instance ID, (i.e An NVO3 VNI). 723 A LISP based NVE will check its local cache if it needs to send a 724 packet across the overlay. If there is a cache miss, it will request 725 the EID to RLOC mapping from the LISP Mapping service. If there is a 726 cache hit, it will use the local EID to RLOC mapping. 728 Cache entries are aged out when no traffic is being sent to those 729 EIDs. The LISP control plane has ways of refreshing the local cache 730 after the destination EID has moved to another RLOC. For more 731 information, see Section 3.2.5 and [RFC6830] 733 3.4.2. Underlying network Multi-Destination Delivery 735 LISP supports delivering L2 and L3 multi-destination packets, 736 independent of the underlying network multicast capabilities. 738 [RFC6831], [I-D.farinacci-lisp-mr-signaling] , more specifically 739 section 6, describes how the LISP Control Plane is used by NVEs/ETRs 740 to join a given EID multicast group by sending LISP Map-Requests 741 rather than PIM Joins. Joining can be triggered by the receipt of a 742 PIM or IGMP join in the EID space. In the case of a L2 overlay 743 configuration on the NVE, the join is static. 745 In case the NVE/ETR is not multicast capable the ETR unicast RLOC 746 will be registered, and will be added to the existing RLOC set for 747 that given multicast EID, and the Map-Reply will contain the ITR from 748 which the ETR wants to replicate. LISP ITRs will retrieve this list 749 of ETRs from the Mapping System upon a Map-Request and will use this 750 as a replication list. 752 In case the underlying network is multicast capable the Map-Reply 753 will contain the multicast RLOC, which will be joined via PIM 754 subsequently. All this state is stored on the Mapping system, or in 755 the xTR caches per IID/VNI. In case ingress replication is deemed 756 unscaleable, [I-D.farinacci-lisp-te] can be used, allowing a Re- 757 encapsulating Tunnel Router (RTR) to be used as a distribution server 758 to replicate to all the NVEs. 760 It is also important to point out that, in a unified L2/L3 NVE 761 deployment, all IP traffic will get sent across the L3 overlay, and 762 that ARP and ND packets are not handled using flooding. 764 In case non-IP traffic needs to be supported, L2 EIDs only need to 765 use multicast or ingress replication for broadcast and multicast, as 766 unicast flows are handled by the LISP control plane. This 767 significantly reduces the multicast or ingress replication load. 769 3.4.3. VN connect/disconnect 770 We assume that a provisioning framework will be responsible for 771 provisioning end systems (e.g. VMs) in each data center. The 772 provisioning system configures each end system with an Ethernet/IEEE 773 802 MAC address and/or IP addresses and provisions the NVE with other 774 end system specific attributes such as VLAN information, and TS/VLAN 775 to VNI mapping information. LISP does not introduce new addressing 776 requirements for end systems. 778 The provisioning infrastructure is also responsible to provide a 779 network attach function, that notifies the NVE (the LISP site ETR) 780 that the end system is attached to a given virtual network 781 (identified by its VNI/IID) and that the end system is identified, 782 within that virtual network, by a given Ethernet/IEEE 802 MAC 783 address. 785 The LISP framework does not include mechanisms to provision the local 786 NVE with the appropriate Tenant Instance for each Tenant Systems. 787 Other protocols, such as VDP (in IEEE P802.1Qbg), should be used to 788 implement a network attach/detach function, besides using link-up 789 events for non-virtual end-systems. More-over it is quite common for 790 devices to be able to 'sense' new tenant end-systems dynamically by 791 tracking new mac addresses and IP addresses in case a VDP or link-up 792 event cant be relied upon. 794 The LISP control plane can take advantage of such a network attach/ 795 detach function or the discovery of new MAC/IP addresses to trigger 796 the registration of a Tenant System to the Mapping System. This is 797 particularly helpful to handle mobility across the DC of the Tenant 798 System. 800 Upon notification of end system network attach, the ETR sends a LISP 801 Map-Register to the Mapping System. The Map-Register includes the 802 EID and RLOCs of the LISP site. The EID-to-RLOC mapping is now 803 available, via the Mapping System Infrastructure, to other LISP sites 804 that are hosting end systems that belong to the same tenant. 806 For more details on end system registration see [RFC6833]. 808 3.4.4. VN name to VN ID Mapping 810 The LISP Control Plane uses the Instance ID to identify the NVI. The 811 VN Name to VNI mapping can be performed by the NVE as a result of 812 local provisioning. Also, using LISP LCAF , it is possible to store 813 ASCII Names in the Mapping Database, which can allow the system to 814 resolve a VN Name to an IID/VNI. 816 3.4.5. LISP Control Plane Characteristics in an NVO3 context 818 LISP is a Control Plane solution that can scale very well to the NVO3 819 requirements: 821 1. LISP ETRs register destination EIDs into the LISP Mapping System. 822 LISP ITRs pull destination EIDs from the LISP Mapping System and 823 cache them for as long as traffic is being sent to those 824 destinations. Hence a LISP Based NVE is only holding state for 825 the active TS to TS flows, and only for the NVIs that are 826 configured on those NVEs. 828 2. The LISP Control Plane is fast to acquire the needed state for a 829 given destination through issuing a single Map-Request. 831 3. When an ETR (lets say ETR1) detects an EID it will also register 832 this EID to the Mapping system. If that EID has moved from 833 another ETR (lets say ETR2), it will update the Mapping system 834 with a Map-Notify saying to no longer forward packets to it, and 835 will install a 'non-local' entry in the forwarding table. If an 836 ITR has not updated its map-cache, and therefor sends a packet to 837 ETR2, ETR will sent a Map-Notify directly to the ITR, updating 838 its local cache. For further information see Section 3.2.5 840 4. As LISP support virtualization, the NVE running the LISP Control 841 Plane will only be maintaining state for the Tenants VNIs that 842 are configured on it. 844 5. Through leveraging the LISP DDT-based Mapping system [I-D.ietf- 845 lisp-ddt], the necessary scaling can be achieved. The LISP DDT 846 hierarchy can be based on address family, address family prefix, 847 and IID, and scales in a very similar way as DNS. 849 6. The solution described in this document does not make use of 850 multiple protocols, and hence is low in complexity. 852 7. Through the use of the LISP LCAF [I-D.ietf-lisp-lcaf] , 853 extensibility is achieved. It is possible to add new address 854 families (the MAC address family is the proof point). The LCAF 855 format also allows lookups on a generic Key. This Key can be an 856 identifier to an ACL or policy. A combination of multiple keys 857 can be achieved by doing recursive lookups, where EID attributes 858 are used as keys for a subsequent lookup. LCAF allows backwards 859 compatibility between systems that use different LCAF 860 implementations. 862 8. As the state is maintained in the LISP Mapping system acting as 863 an NVA, adding another NVE/xTR to the network does not require 864 any changes on existing NVEs. 866 9. LISP does not rely on Multicast in the underlay, while preserving 867 the same Control Plane characteristics regardless of underlay 868 multicast capability. 870 10. [I-D.barkai-lisp-nfv]documents one implementation of how the 871 LISP Mapping System (NVA) can be programmed to create inner to 872 outer address mappings. The LISP Control Plane will inform the 873 xTR/NVE that hosts have moved, and if packets are attracted to 874 those NVEs because of stale cache entries on other ITRs, packets 875 will be routed to the right location, and the NVE will send a 876 Solicited Map-Reply back to the ITR, clearing its cache, after 877 which the ITR will request a new mapping. Obviously NVEs will 878 be able to create inner to outer address mappings without the 879 use of an orchestration solution. 881 11. See Section 5 883 3.5. NVO3 OAM Requirements and LISP 885 TBD 887 3.6. NVO3 Management Plane Requirements and LISP 889 TBD 891 3.7. Summary 893 The LISP Control Plane, makes a very good choice to implement NVO3 894 services due to the fact that it is agnostic to EID address families, 895 and the fact that it provides an NVA in the form of the LISP Map 896 Server with cache optimizations based on the pull-based LISP Map 897 Cache on the LISP xTRs . The LISP control plane can be deployed 898 across a set of different dataplane options as well. The usage of a 899 unified L2 and L3 overlay , with the appropriate set of registrations 900 in the LISP Mapping system, is recommended because of its optimal 901 forwarding, scaling and IP centric characteristics, while supporting 902 non-IP traffic as well. 904 4. IANA Considerations 906 This document makes no request of IANA. 908 Note to RFC Editor: this section may be removed on publication as an 909 RFC. 911 5. Security Considerations 913 The security requirements for a NVO3 Control Plane are defined in 914 [I-D.ietf-nvo3-security-requirements] . More specifically, seven 915 requirements are defined (REQ 1 to REQ 7) for NVE-NVA Control Plane 916 (Network Virtualization Edge to Network Virtualization Authority 917 Control Plane) and two requirements (REQ 8 and REQ 9) for NVA-NVA 918 Control Plane (Network Virtualization Authority to Network 919 Virtualization Authority Control Plane). Table 1 provides a summary 920 of which document defines LISP Control Plane mechanisms that allow to 921 satisfy each specific requirement. 923 +-----------+-------------------------------+ 924 | NVO3 Req. | LISP Control Plane Documents | 925 +-----------+-------------------------------+ 926 | REQ 1 | [RFC6833] [I-D.ietf-lisp-sec] | 927 | REQ 2 | [RFC6833] [I-D.ietf-lisp-sec] | 928 | REQ 3 | Not mandatory[1] | 929 | REQ 4 | [RFC6833] [I-D.ietf-lisp-sec] | 930 | REQ 5 | [RFC6833] [I-D.ietf-lisp-sec] | 931 | REQ 6 | [RFC6830] [RFC6833] | 932 | REQ 7 | [RFC6830][2] | 933 | REQ 8 | [I-D.ietf-lisp-ddt] | 934 | REQ 9 | Does not apply[3] | 935 +-----------+-------------------------------+ 937 [1] The requirement uses MAY as for [RFC2119] terminology. [2] 938 Amplification attacks can be avoided by careful design of the 939 mappings. [3] The existing LISP Control Planes do not use multicast 940 messages. 942 Security mechanisms to protect the LISP Map-Register messages are 943 defined in [RFC6833]. 945 [RFC6830] and [RFC6833] describe how to send control packet with 946 limited frequencies. 948 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 949 origin authentication, integrity and anti-replay protection to LISP's 950 EID-to-RLOC mapping data conveyed via mapping lookup process. [I-D 951 .ietf-lisp-sec] also enables verification of authorization on EID- 952 prefix claims in Map-Reply messages. 954 The security of the Mapping System Infrastructure (NVA) depends on 955 the particular mapping database used. The [I-D.ietf-lisp-ddt] 956 specification, as an example, defines a public-key based mechanism 957 that provides origin authentication and integrity protection to the 958 LISP DDT protocol. 960 6. Acknowledgements 962 7. References 964 7.1. Normative References 966 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 967 Requirement Levels", BCP 14, RFC 2119, March 1997. 969 7.2. Informative References 971 [I-D.barkai-lisp-nfv] 972 sbarkai@gmail.com, s., Farinacci, D., Meyer, D., Maino, 973 F., Ermagan, V., Rodriguez-Natal, A. and A. Cabellos- 974 Aparicio, "LISP Based FlowMapping for Scaling NFV", 975 Internet-Draft draft-barkai-lisp-nfv-04, February 2014. 977 [I-D.farinacci-lisp-mr-signaling] 978 Farinacci, D. and M. Napierala, "LISP Control-Plane 979 Multicast Signaling", Internet-Draft draft-farinacci-lisp- 980 mr-signaling-04, March 2014. 982 [I-D.farinacci-lisp-te] 983 Farinacci, D., Kowal, M. and P. Lahiri, "LISP Traffic 984 Engineering Use-Cases", Internet-Draft draft-farinacci- 985 lisp-te-06, March 2014. 987 [I-D.ietf-lisp-ddt] 988 Fuller, V., Lewis, D., Ermagan, V. and A. Jain, "LISP 989 Delegated Database Tree", Internet-Draft draft-ietf-lisp- 990 ddt-01, March 2013. 992 [I-D.ietf-lisp-lcaf] 993 Farinacci, D., Meyer, D. and J. Snijders, "LISP Canonical 994 Address Format (LCAF)", Internet-Draft draft-ietf-lisp- 995 lcaf-05, May 2014. 997 [I-D.ietf-lisp-sec] 998 Maino, F., Ermagan, V., Cabellos-Aparicio, A. and D. 999 Saucez, "LISP-Security (LISP-SEC)", Internet-Draft draft- 1000 ietf-lisp-sec-06, April 2014. 1002 [I-D.ietf-nvo3-dataplane-requirements] 1003 Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L. and 1004 B. Khasnabish, "NVO3 Data Plane Requirements", Internet- 1005 Draft draft-ietf-nvo3-dataplane-requirements-03, April 1006 2014. 1008 [I-D.ietf-nvo3-framework] 1009 Lasserre, M., Balus, F., Morin, T., Bitar, N. and Y. 1010 Rekhter, "Framework for DC Network Virtualization", 1011 Internet-Draft draft-ietf-nvo3-framework-09, July 2014. 1013 [I-D.ietf-nvo3-nve-nva-cp-req] 1014 Kreeger, L., Dutt, D., Narten, T. and D. Black, "Network 1015 Virtualization NVE to NVA Control Protocol Requirements", 1016 Internet-Draft draft-ietf-nvo3-nve-nva-cp-req-02, April 1017 2014. 1019 [I-D.ietf-nvo3-overlay-problem-statement] 1020 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L. and 1021 M. Napierala, "Problem Statement: Overlays for Network 1022 Virtualization", Internet-Draft draft-ietf-nvo3-overlay- 1023 problem-statement-04, July 2013. 1025 [I-D.ietf-nvo3-security-requirements] 1026 Hartman, S., Zhang, D. and M. Wasserman, "Security 1027 Requirements of NVO3", Internet-Draft draft-ietf-nvo3 1028 -security-requirements-02, January 2014. 1030 [I-D.kompella-nvo3-server2nve] 1031 Kompella, K., Rekhter, Y., Morin, T. and D. Black, 1032 "Signaling Virtual Machine Activity to the Network 1033 Virtualization Edge", Internet-Draft draft-kompella- 1034 nvo3-server2nve-02, April 2013. 1036 [I-D.lewis-lisp-gpe] 1037 Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., 1038 Smith, M. and N. Yadav, "LISP Generic Protocol Extension", 1039 Internet-Draft draft-lewis-lisp-gpe-02, July 2014. 1041 [I-D.mahalingam-dutt-dcops-vxlan] 1042 Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1043 L., Sridhar, T., Bursell, M. and C. Wright, "VXLAN: A 1044 Framework for Overlaying Virtualized Layer 2 Networks over 1045 Layer 3 Networks", Internet-Draft draft-mahalingam-dutt- 1046 dcops-vxlan-09, April 2014. 1048 [I-D.maino-nvo3-lisp-cp] 1049 Maino, F., Ermagan, V., Hertoghs, Y., Farinacci, D. and M. 1050 Smith, "LISP Control Plane for Network Virtualization 1051 Overlays", Internet-Draft draft-maino-nvo3-lisp-cp-03, 1052 October 2013. 1054 [I-D.quinn-vxlan-gpe] 1055 Quinn, P., Agarwal, P., Fernando, R., Lewis, D., Kreeger, 1056 L., Smith, M., Yadav, N., Yong, L., Xu, X., Elzur, U. and 1057 P. Garg, "Generic Protocol Extension for VXLAN", Internet- 1058 Draft draft-quinn-vxlan-gpe-03, July 2014. 1060 [I-D.smith-lisp-layer2] 1061 Smith, M., Dutt, D., Farinacci, D. and F. Maino, "Layer 2 1062 (L2) LISP Encapsulation Format", Internet-Draft draft- 1063 smith-lisp-layer2-03, September 2013. 1065 [I-D.sridharan-virtualization-nvgre] 1066 Sridharan, M., Greenberg, A., Wang, Y., Garg, P., 1067 Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson, 1068 M., Thaler, P. and C. Tumuluri, "NVGRE: Network 1069 Virtualization using Generic Routing Encapsulation", 1070 Internet-Draft draft-sridharan-virtualization-nvgre-04, 1071 February 2014. 1073 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1074 November 1990. 1076 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery 1077 for IP version 6", RFC 1981, August 1996. 1079 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 1080 2983, October 2000. 1082 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 1083 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1085 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1086 Discovery", RFC 4821, March 2007. 1088 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 1089 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1090 September 2007. 1092 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1093 Notification", RFC 6040, November 2010. 1095 [RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The 1096 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1097 2013. 1099 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J. and S. Venaas, "The 1100 Locator/ID Separation Protocol (LISP) for Multicast 1101 Environments", RFC 6831, January 2013. 1103 [RFC6832] Lewis, D., Meyer, D., Farinacci, D. and V. Fuller, 1104 "Interworking between Locator/ID Separation Protocol 1105 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 1107 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1108 Protocol (LISP) Map-Server Interface", RFC 6833, January 1109 2013. 1111 [RFC6836] Fuller, V., Farinacci, D., Meyer, D. and D. Lewis, 1112 "Locator/ID Separation Protocol Alternative Logical 1113 Topology (LISP+ALT)", RFC 6836, January 2013. 1115 Authors' Addresses 1117 Yves Hertoghs 1118 Cisco Systems 1119 6a De Kleetlaan 1120 Diegem, 1831 1121 Belgium2 1123 Phone: +32-2778-435 1124 Email: yves@cisco.com 1126 Fabio Maino 1127 Cisco Systems 1128 170 Tasman Drive 1129 San Jose, California 95134 1130 USA 1132 Email: fmaino@cisco.com 1133 Victor Moreno 1134 Cisco Systems 1135 170 Tasman Drive 1136 San Jose, California 95134 1137 USA 1139 Email: vimoreno@cisco.com 1141 Michael Smith 1142 Cisco Systems 1143 170 Tasman Drive 1144 San Jose, California 95134 1145 USA 1147 Email: michsmit@cisco.com 1149 Dino Farinacci 1150 lispers.net 1152 Email: farinacci@gmail.com 1154 Luigi Iannone 1155 Telecom ParisTech 1157 Email: luigi.iannone@telecom-paristech.fr