idnits 2.17.00 (12 Aug 2021) /tmp/idnits50349/draft-wu-nvo3-mac-learning-arp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (June 28, 2013) is 3242 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TRILL' is mentioned on line 221, but not defined == Unused Reference: 'ESADI' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-l2vpn-pbb-evpn' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-trill-directory-framework' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC6325' is defined on line 516, but no explicit reference was found in the text == Outdated reference: draft-ietf-trill-esadi has been published as RFC 7357 == Outdated reference: draft-ietf-l2vpn-evpn has been published as RFC 7432 == Outdated reference: draft-ietf-l2vpn-pbb-evpn has been published as RFC 7623 == Outdated reference: draft-ietf-trill-directory-framework has been published as RFC 7067 ** Downref: Normative reference to an Informational draft: draft-ietf-trill-directory-framework (ref. 'I-D.ietf-trill-directory-framework') ** Downref: Normative reference to an Unknown state RFC: RFC 1027 ** Downref: Normative reference to an Informational RFC: RFC 6820 ** Downref: Normative reference to an Experimental RFC: RFC 6830 == Outdated reference: draft-nachum-sarp has been published as RFC 7586 ** Downref: Normative reference to an Experimental draft: draft-nachum-sarp (ref. 'SARP') -- Possible downref: Non-RFC (?) normative reference: ref. 'SPB' Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Virtualization Overlays Working L. Xia 3 Group Q. Wu 4 Internet-Draft Huawei 5 Intended status: Standards Track June 28, 2013 6 Expires: December 30, 2013 8 Tenant system information discovery approaches Gap analysis 9 draft-wu-nvo3-mac-learning-arp-03 11 Abstract 13 This document analyzes various protocol solutions for tenant system 14 information (e.g. MAC, IP, etc) discovery in the virtualization 15 environment (e.g.,MAC in MAC, MAC in IP, IP in IP) and identifies the 16 gap against NVO3 control plane and data plane requirements. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 30, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . 4 54 3. Overview of tenant system information discovery in the 55 virtualization domain using NVO3 . . . . . . . . . . . . . . . 5 56 3.1. Issues with tenant system information discovery in the 57 virtualization domain using NVO3 . . . . . . . . . . . . . 6 58 4. Related work for Tenant system information discovery . . . . . 8 59 4.1. SPB and TRILL . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. ARMD and SARP . . . . . . . . . . . . . . . . . . . . . . 8 61 4.3. BGP/MPLS IP VPNs - Distributed control plane 62 distribution . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.4. BGP/MPLS Ethernet VPNs and PBB-EVPN . . . . . . . . . . . 10 64 4.5. VPLS - ARP + data plane learning . . . . . . . . . . . . . 10 65 4.6. LISP - Centralized control plane distribution . . . . . . 11 66 5. Gap Analysis and Discuss . . . . . . . . . . . . . . . . . . . 13 67 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 The tenant system information in this document is referred to as L2 76 address and L3 address of VM. As described in [I.D-ietf-nvo3- 77 framework], for an L2 NVE, the NVE needs to be able to determine MAC 78 addresses of the tenant system. For an L3 NVE, the NVE needs to be 79 able to determine IP addresses of the tenant system. 81 This can be achieved mainly in 3 ways: data plane learning; ARP; 82 control plane distribution (e.g. by BGP or IS-IS). This document 83 analyzes various protocol solutions for tenant system information 84 (e.g. MAC, IP, etc) discovery in the virtualization environment 85 (e.g.,MAC in MAC, MAC in IP, IP in IP) and identifies the gap against 86 NVO3 control plane and data plane requirements. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC2119 [RFC2119]. 94 3. Overview of tenant system information discovery in the 95 virtualization domain using NVO3 97 Tenant system information discovery can be achieved either using 98 dynamic data plane learning or ARP or control plane distribution. 99 This document addresses how tenant system information discovery works 100 in the overlay network enviroment. Figure 1 shows the NVO3 reference 101 architecture for tenant system information discovery. The reference 102 architecture assumes that: 104 o Tenant system A in DC site X wants to establish communication with 105 tenant system B in the DC site Y. 107 o Tenant system A is connecting to VN by attaching to NVE X. Tenant 108 System A knows IP address of Tenant System B using out of band 109 means but does not know MAC address of Tenant System B. 111 o Tenant system B is connecting to VN by attaching to NVE Y. Tenant 112 System B knows IP address of Tenant System A using out of band 113 means but does not know MAC address of Tenant System A. 115 o NVE X associated with tenant system A doesn't know IP address and 116 MAC address of tenant system B. 118 o NVE Y associated with tenant system B doesn't know IP address and 119 MAC address of tenant system A. 121 ,---------. 122 ,' Backend `. 123 ( NVA ) 124 `. ,' 125 `-+------+' 126 | | 127 .--..--. .--. .. 128 ( ' '.--. 129 .-.' L3 ' 130 ( Overlay ) 131 ( '-' 132 .'--'._.'.-._.'.-._) 133 NVE X = // \\ NVE Y = 134 (MAC_X,IP_X) +------+ +-------+(MAC_Y,IP_Y) 135 .-|NVE X | | NVE Y | 136 ( +------+--. ( +-------+.--. 137 .-.' ' .-.' ' 138 ( DC Site X ) ( DC Site Y ) 139 ( .'-' ( .'-' 140 '--'._.'. ) '--'._.'. ) 141 '--' / '--' 142 / \ / \ 143 __/_ \ /_ _\__ 144 '--------' '--------' '--------' '--------' 145 : Tenant : : Tenant : : Tenant : : Tenant : 146 : SystemA: : SystemC: : SystemD: : SystemB: 147 '--------' '--------' '--------' '--------' 148 TSID= TSID= 149 (VNID,MAC_A,IP_A) (VNID,MAC_B,IP_B) 151 Figure 1: Example of NVO3 reference architecture for tenant system 152 information discovery 154 3.1. Issues with tenant system information discovery in the 155 virtualization domain using NVO3 157 Here we give an example of tenant system information discovery in 158 large layer 2 domain using NVO3 using traditional approach for MAC 159 address learning. The packet flow and control plane operation are as 160 follows: 162 1. Tenant system A sends a broadcast ARP message to discover the MAC 163 address of Tenant system B. The message contains IP_B in the ARP 164 message payload. 166 2. The ARP proxy [RFC1027] in NVE X, receiving the ARP message and 167 knowing source and destination are in the different subnet will 168 encapsulate it with overlay header and outer header and flood it 169 on the overlay network for TSID = . VNID is 170 included in the overlay header. 172 3. The ARP message will be processed by NVE Y which maintains 173 mapping table matching TSID = . NVE Y, will forward 174 the ARP message to tenant system B. Tenant System B sends ARP 175 reply to tenant system A containing MAC_B. 177 4. NVE X processes ARP reply message and populates the mapping table 178 with the received entry, then sends it to Tenant System A that 179 includes MAC_B and IP_B of Tenant System B. 181 5. Tenant system A learns MAC_B from the ARP rely message and can 182 now send a packet to Tenant system B by including MAC_B, and 183 IP_B, as destination addresses. 185 The issues with tenant system information discovery are as follows: 187 o The demand on the forwarding table capacity at each NVE is 188 increased compared to non-virtualized environments since layer 2 189 network is no longer constrained to small local network and has a 190 need for millions of hosts. 192 o If Address resolution protocol is used for control plane learning, 193 it may cause excessive flooding since ARP packets need to be 194 flooded over the whole overlay network. the ARP/ND processing load 195 imposes great challenge on L2/L3 boundary routers. 197 o Dynamic data plane learning implies that flooding of unknown 198 destinations be supported and hence implies that broadcast and/or 199 multicast be supported or that ingress replication, which may 200 cause excessive flooding issue and lead to significant scalability 201 limitations. 203 o A control plane protocol (e.g., BGP) that carries both MAC and IP 204 addresses eliminates the need for ARP, however some NVEs or DC 205 Gateways may not support complex control plane protocol, for 206 example, BGP protocol. 208 4. Related work for Tenant system information discovery 210 Currently, 3 main solutions or their combination can be used to 211 perform the tenant system information discovery. They are dynamic 212 data plane learning, ARP, control plane distribution (including two 213 options: centralized or distributed). Additionally, the ARP proxy 214 [RFC1027] mechanism can be used for preventing the ARP flooding in 215 the core network and limiting the MAC table size of NVEs and hosts. 216 Here is a brief analysis of them and the associated protocols are 217 discussed. 219 4.1. SPB and TRILL 221 Shortest Path Bridging (SPB) [SPB] and TRILL [TRILL] are two 222 different methods of IS-IS based overlay that operates over L2 223 Ethernets. They all use the MAC in MAC encapsulation and have the 224 same default MAC address learning method: 226 o Using IS-IS extension for outer MAC address distribution over the 227 SPB area or TRILL campus network; 229 o Using ARP or data plane snooping for inner MAC address learning of 230 locally attached hosts. 232 o In addition, the TRILL maybe use 233 [draft-ietf-trill-directory-framework] distributes the inner MAC 234 address between all the RBriges 236 In the centralized approach, TRILL may use TRILL ESADI to distribute 237 the inner MAC address between all the RBridges however SPB doesn't 238 support ESADI distribution mechanism. In the distributed approach, 239 SPB and TRILL may use combination of the above 3 methods. 241 4.2. ARMD and SARP 243 The ARMD WG examined data center scaling issues with a focus on 244 address resolution and developed a problem statement document 245 [RFC6820]. In this document, the scaling issues of MAC address 246 learning related to the overlay-based approach are listed as 247 followed: 249 ARP processing on Routers: This issue mainly concerns about the 250 significant amount of ARP traffic or BUM packets traffic in large 251 L2 broadcast domains and its impact to the routers. Finally, some 252 optimized method are proposed; 254 IPv6 Neighbor Discovery has the similar issue as ARP processing on 255 router; 256 MAC Address Table Size Limitations at Switches: This issue mainly 257 concerns on the MAC Address Table Size Limitations when the VM 258 number is very large in the Virtualized data center environment. 260 In order to tackle the above problems, SARP [SARP] seamlessly 261 supports Layer 2 network virtualization services over the overlay 262 network and significantly reduces their complexity in terms of table 263 size and performance. The overlay networks are only required to map 264 MAC addresses of the SARP proxies, instead of MAC address of the 265 destination end host, to the correct tunnel. 267 4.3. BGP/MPLS IP VPNs - Distributed control plane distribution 269 BGP/MPLS IP VPNs [RFC4364] provides IP Virtual Private Networks 270 (VPNs) for its customers and support VPN traffic isolation, address 271 overlapping and separation between customer networks. The BGP/MPLS 272 control plane is used to distribute both the VPN labels and the 273 tenant system IP addresses that are used to identify the customer. 274 However BGP/MPLS IP VPN doesn't support interconnection with Data 275 Center (DC) overlay networks and provide a virtual end to end tenant 276 network service to tenant systems in the BGP/MPLS IPVPN.It also has 277 the scalability related problems when IP addresses of a large number 278 of VMs need to be propagated in control plane in the Virtualized data 279 center environments. 281 For an L3 overlay node, the overlay node only needs to determine IP 282 addresses of the tenant system but doesn't need to know the MAC 283 address of the destination system since overlay tunnels the L3 284 traffic from the tenant system in an encapsulated format to the final 285 destination and doesn't care about the MAC address of destination end 286 system for the inner L3 packet. Therefore overlay node can answer 287 any address resolution query with its own MAC address or one virtual 288 MAC address. In [I.D-ietf-l3vpn-end-system], NVE uses XMPP to 289 exchange information with the tenant system and answer the address 290 resolution query from tenant system with a virtual router MAC 291 address. 293 In order to propagate tenant system information to the whole overlay 294 network environment, [I.D-ietf-l3vpn-end-system]use Route Server to 295 gather VPN membership on each Forwarder and IP addresses that are 296 currently associated with each virtual interface of tenant system and 297 advertise them to the BGP speaker. In addition, BGP speaker also can 298 interact with Route Server to generate tenant system information 299 update to the upstream end systems. 301 4.4. BGP/MPLS Ethernet VPNs and PBB-EVPN 303 Ethernet Virtual Private Networks (E-VPNs) [I-D.ietf-l2vpn-evpn] 304 provide an emulated L2 service in which each tenant has its own 305 Ethernet network over a common IP or MPLS infrastructure. PBB-EVPN 306 [I-D.ietf -l2vpn-pbb-evpn] is a combined solution of PBB and E-VPN. 307 They all use BGP for MAC address distribution over the core MPLS/IP 308 network, and use ARP or data plane snooping for MAC address learning 309 of locally attached hosts. In other words, the mapping table 310 information should be distributed to all the remote 311 overlay nodes that belong to the same VN. After that,the tenant 312 system information is distributed from remote 313 overlay nodes to all the remote tenant system. When all the tenant 314 system information is populated, overlay nodes will process the 315 packet from each tenant system and perform a lookup operation in its 316 map table for the destination TSID= and determine which 317 tunnel the packet needs to be sent to. 319 The analysis of their MAC address learning methods is as followed: 321 Pros: 323 o ARP broadcast Suppression: They all construct ARP caches on the 324 PEs and synchronize them either via BGP or data plane snooping. 325 The PEs act as ARP proxies for locally attached hosts, thereby 326 preventing repeated ARP broadcast over the core MPLS/IP network; 328 o Comparing E-VPN, PBB-EVPN reduces the number of BGP MAC 329 advertisement routes, provide C-MAC address mobility, confine the 330 scope of C-MAC address learning to only active flows, offer per 331 site policies and avoid C-MAC address flushing on topology 332 changes. 334 Con: An E-VPN PE sends a BGP MAC Advertisement Route per customer/ 335 client MAC (C-MAC) address. This will raise the scalability related 336 problems in the case of Virtualized data center environments where 337 the number of virtual machines (VMs) is very large. 339 4.5. VPLS - ARP + data plane learning 341 VPLS is an L2 VPN technology. VPLS uses the ARP and data plane 342 learning for L2 tenant system information discovery, and not 343 advertised and distributed via a BGP/LDP control plane. The analysis 344 of this method is as followed: 346 Pros: 348 o Reducing complexity and work burden of the control plane by 349 decreasing the control packets; 351 o MAC address learning based on active flows can save the space of 352 MAC mapping table. 354 Cons: 356 o PE will learn all active MACs over the associated PW by BUM 357 flooding of data plane. But, some active MACs is not destined to 358 the PE; 360 o Unlike the active MAC withdraw mechanism in control plane, PE 361 cannot flush MAC address real-time in data plane, when host MACs 362 behind the PE are changed. 364 4.6. LISP - Centralized control plane distribution 366 LISP[RFC6830] essentially provides an IP over IP overlay where the 367 internal addresses are end station Identifiers and the outer IP 368 addresses represent the location of the end station within the core 369 IP network topology. [draft-maino-nvo3-lisp-cp-02] discusses L2 over 370 L3 LISP Encapsulation and proposes a LISP Mapping System for ARP 371 resolution to eliminate the flooding of ARP traffic and further 372 reduce the need for multicast in the underlay network. This system 373 relies on mapping system for tenant system information distribution 374 and involves MAP-request/MAP-Response message exchange between 375 overlay node and mapping system. With introduced LISP Mapping 376 system, the scalability is improved for tenant system information 377 discovery. the packet flow and control plane operation are as 378 follows: 380 o Tenant System A sends a broadcast ARP message to discover the MAC 381 address of Tenant system B. The message contains IP_B in the ARP 382 message payload. 384 o NVE X as an ARP proxy, receiving the ARP message and knowing 385 source and destination are in the different subnet[RFC1027], but 386 rather than flooding it on the overlay network, sends a Map- 387 Request(i.e.,LISP signaling) to the backend LISP mapping system 388 (i.e.,NVA) that maintains mapping information for entire overlay 389 network for TSID = . 391 o The Map-Request is reflected by the backend LISP Mapping system to 392 NVE Y, that will send a Map-Reply back to NVE X containing the 393 mapping TSID=. Alternatively, depending on the 394 Backend LISP Mapping system configuration, the backend LISP 395 Mapping system may send directly a Map-Reply to NVE X. 397 o NVE X populates the mapping table with the received entry, and 398 sends an ARP-Agent Reply to Tenant System A that includes MAC_B 399 and IP_B. 401 o Tenant system A learns MAC_B from the ARP message and can now send 402 a packet to Tenant system B by including MAC_B, and IP_B, as 403 destination addresses. 405 5. Gap Analysis and Discuss 407 The following table compares several tenant system information 408 discovery methods from different aspects under the same network 409 topology and scale. 411 +-----------+-------------+--------------+-------------+------------+ 412 | TS | Forwarding | Packets |Control plane| Directory | 413 | Discovery | table | flooding |Distribution Support | 414 | method | size | impact | support | | 415 +-----------+-------------+--------------+-------------+------------+ 416 | | | | | | 417 | SPB | | | | Trill:Yes | 418 | &TRILL | Mediaum | Medium | Yes | SPB:No | 419 | | | | | | 420 | | | | | | 421 +-----------+-------------+--------------+-------------+------------+ 422 | | | | | | 423 | | | | | | 424 | ARMD&SARP | Small | Medium | No | No | 425 | | | | | | 426 | | | | | | 427 +-----------+-------------+--------------+-------------+------------+ 428 | | | | | | 429 | LISP | | | |LISP Mapping| 430 | + | Medium | Medium | Yes | System | 431 + ARP proxy | | | | | 432 | | | | | | 433 +-----------+-------------+--------------+-------------+------------+ 434 | | | | | | 435 | BGP/MPLS | | | | | 436 | IP | Large | Large | Yes | No | 437 | VPN | | | | | 438 | | | | | | 439 +-----------+-------------+--------------+-------------+------------+ 440 | | | | | | 441 | BGP/MPLS | | | | | 442 | Ethernet | Large | Large | Yes | No | 443 | VPN | | | | | 444 | | | | | | 445 +-----------+-------------+--------------+-------------+------------+ 446 | | | | | | 447 | VPLS | | | | | 448 | + | Medium | Small | Yes | No | 449 | ARP proxy | | | | | 450 | | | | | | 451 +-----------+-------------+--------------+-------------+------------+ 452 Table 1: The comparison between several tenant system 453 information discovery methods 455 6. Conclusion 457 There are three ways for tenant system information discovery, data 458 plane learning and control plane ARP learning and control plane 459 distribution. In large layer 2 domain, the MAC address can not be 460 simply learnt by looking at the outer layer 2 header, instead, Deeper 461 parsing inner Ethernet header is required. However it also 462 introduces a lot of processing overhead. In order to address this 463 issue, the control plane distribution is proposed, and used to carry 464 both MAC address and IP address and eliminate the above data plane 465 learning issue. However distribution protocol is needed. How 466 distribution protocol is used to propagate tenant system information 467 and mapping table information in large scale and in a more efficient 468 way is still under study. 470 7. IANA Considerations 472 This document has no actions for IANA. 474 8. Security Considerations 476 TBC. 478 9. Normative References 480 [ESADI] Eastlake, D., "TRILL (Transparent Interconnection of Lots 481 of Links): ESADI (End Station Address Distribution 482 Information) Protocol", ID draft-ietf-trill-esadi-02, 483 February 2013. 485 [I-D.ietf-l2vpn-evpn] 486 Sajassi, A. and R. Aggarwal, "BGP MPLS Based Ethernet 487 VPN", ID draft-ietf-l2vpn-evpn-03, February 2013. 489 [I-D.ietf-l2vpn-pbb-evpn] 490 Sajassi, A., "PBB-EVPN", ID draft-ietf-l2vpn-pbb-evpn-04, 491 April 2013. 493 [I-D.ietf-trill-directory-framework] 494 Dunbar, L. and D. Eastlake, "TRILL (Transparent 495 Interconnection of Lots of Links): Edge Directory 496 Assistance Framework", 497 ID draft-ietf-trill-directory-framework-05, April 2013. 499 [I.D-ietf-l3vpn-end-system] 500 Marques, P., "BGP-signaled end-system IP/VPNs", 501 ID draft-maino-nvo3-lisp-cp-02, April 2013. 503 [I.D-ietf-nvo3-framework] 504 Lasserre, M., "Framework for DC Network Virtualization", 505 ID draft-ietf-nvo3-framework-00, September 2012. 507 [RFC1027] Carl-Mitchell, S., "Using ARP to Implement Transparent 508 Subnet Gateways", October 1987. 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", March 1997. 513 [RFC4364] Rosen, E., "BGP/MPLS IP Virtual Private Networks (VPNs)", 514 February 2006. 516 [RFC6325] Perlman, R., "RBridges: Base Protocol Specification", 517 July 2011. 519 [RFC6820] Farinacci, D., "The Locator/ID Separation Protocol 520 (LISP)", January 2013. 522 [RFC6830] Farinacci, D., "The Locator/ID Separation Protocol 523 (LISP)", January 2013. 525 [SARP] Dunbar, L. and I. Yerushalmi, "Scaling the Address 526 Resolution Protocol for Large Data Centers (SARP)", 527 ID draft-nachum-sarp-04, February 2013. 529 [SPB] "IEEE standard for local and metropolitan area networks: 530 Media access control (MAC) bridges and virtual bridged 531 local area networks -- Amendment 20: Shortest path 532 bridging", IEEE 802.1aq, June 2012. 534 [draft-maino-nvo3-lisp-cp] 535 Maino, F. and R. Aggarwal, "LISP Control Plane for Network 536 Virtualization Overlays", ID draft-maino-nvo3-lisp-cp-02, 537 April 2013. 539 Authors' Addresses 541 Liang Xia 542 Huawei 543 101 Software Avenue, Yuhua District 544 Nanjing, Jiangsu 210012 545 China 547 Email: frank.xialiang@huawei.com 549 Qin Wu 550 Huawei 551 101 Software Avenue, Yuhua District 552 Nanjing, Jiangsu 210012 553 China 555 Email: bill.wu@huawei.com