idnits 2.17.1 draft-gu-opsawg-policies-migration-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 35 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (Mar 5, 2012) is 4427 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) == Unused Reference: 'RFC3303' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'GapAnalysis' is defined on line 593, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3303 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gu 3 Internet-Draft Huawei 4 Intended status: Standards Track C. Li 5 Expires: September 6, 2012 China Mobile 6 K. Li 7 China Telecom 8 Z. Zhuo 9 Ruijie Network 10 D. Zhang 11 Huawei 12 Mar 5, 2012 14 State Migration 15 draft-gu-opsawg-policies-migration-02 17 Abstract 19 In accompany with the migration of a Virtual Machine (VM), state 20 associated with the VM located on the Hypervisors and the network 21 side devices (e.g., Firewalls) need to be updated in order to 22 guarantee that the services executed on the migrated VM will not be 23 disrupted. VM vendors have their own ways to migrate VM's state on 24 Hypervisors, and so this is out the scope of this draft.This draft 25 introduces the background of state migration on network devices using 26 several application scenarios and tries to specify a clear scope for 27 the future standardization work on state migration on network 28 devices. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 2, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 65 3. States On Firewalls . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Session Table . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Cumulative Data . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Access Control List . . . . . . . . . . . . . . . . . . . 5 69 4. Scenarios for Migration of States on Firewall . . . . . . . . 5 70 4.1. VM Migration between different DCs . . . . . . . . . . . . 5 71 4.2. VM Migration under Distributed Deployed Firewalls . . . . 10 72 5. Active-Active or VM Migration . . . . . . . . . . . . . . . . 12 73 6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 76 9. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Under the assistance of a VM live migration mechanism, a VM can move 85 across physical servers, racks, subnets, or even DCs (Data Centers). 86 During the migration, the services executed on the VM should not be 87 significantly interrupted. In order to achieve objective, not only 88 the hypervisor that the VM moves to but also any related devices on 89 the network side must update their state cooperatively. For 90 instance, assume that a VM executed on a server is under the 91 protection of a Firewall A. The VM creates several connections with 92 external clients. The state information associated with the 93 connections is generated and maintained in the session table of A. 94 Any inbound packets to the VM will be checked against the session 95 table, and the packets that doesn't match any recorded connection 96 will be discarded. Now, the VM migrates to another rack, which is 97 under the management of Firewall B. Because B has no knowledge about 98 the connections created by the VM, any packets belonging to the 99 connections will be discarded by B. As a result, the connections will 100 finally be broken. A more detailed description can be found in 101 Section 4. 103 There are various middleboxes embedded in the network (e.g., 104 Firewalls, IPSes, IDSes, NATs and etc) which may need state 105 migration. To benefit the discussion, Firewalls are used as an 106 example to analyze the state updating issues caused by VM live 107 migration. 109 2. Terminologies and concepts 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 Virtual Machine (VM), A completely isolated operation system which is 116 installed by software on a normal operation system. An normal 117 operation system can be virtualized into several VM. 119 Firewall (FW), A policy based security device, typically used for 120 restricting access to/from specific devices and applications. 122 3. States On Firewalls 124 Basically, there are In this draft, we consider two complimentary 125 physical Firewall deployment solutions in DCs. 127 o Centralized Deployment. In this case, typically, a pair of 128 centralized powerful Firewalls are deployed at WAN connect point. 129 Any traffic, even the traffic between VMs within the same LAN, 130 need to pass though the Firewall. Centralized deployed Firewalls 131 need to be reliable and capable to deal with large amounts of 132 traffic. 134 o Distributed deployment. In this case, Firewalls are deployed at 135 aggregation switches or lower access switches in a distributed 136 way. The goal of this kind of distributed deployed Firewall is to 137 off load the huge workload on centralized Firewall. This case is 138 especially reasonable for large layer 2 network with tens even 139 hundreds of thousands of Virtual Machines.Note that both the 140 centralized and distributed solutions can co-exist in DCs. 142 In either solution, the Firewalls need to generate and maintain the 143 state (e.g., security policies and connection information) to process 144 packets. In the remainder of this section, three types of state 145 information supported by most stateful Firewalls are introduced 146 respectively. 148 3.1. Session Table 150 A stateful Firewall needs to establish a record for every connection 151 associated a host (which could a physical server or a VM) under its 152 protection. Typically, a connection record should contain following 153 parameters. 155 +---------------+---------------------------------------------------+ 156 | Item | Interpretation | 157 +---------------+---------------------------------------------------+ 158 | Src-IP | Source IP Address of the connection | 159 | Dst-IP | Destination IP Address of the connection | 160 | Src-Port | Source Port Number used to establish the session | 161 | Dst-Port | Destination Port Number used to establish the | 162 | | session | 163 | Protocol | Protocol type, e.g. TCP | 164 | Status | The status of a connection, e.g. Established or | 165 | | SYN_ACK. | 166 | Interface | The inbound interface of the connection | 167 | Creation-Time | The time that the session is created | 168 | Last-heard | The last time that a packet belong to this | 169 | | connection is received by Firewall | 170 +---------------+---------------------------------------------------+ 172 Of course, not all of the information in the session table on a 173 source Firewall is meaningful for the destination Firewall. For 174 instance, the Interface parameter is meaningless to destination 175 Firewall. Thus, not all of the information need to be migrated to 176 destination Firewall in state migration,. 178 3.2. Cumulative Data 180 In order to deal with DOS (Deny of Service ) attacks, Firewalls need 181 to cumulate certain types of data. For instance, assume there are 182 both individual clients and enterprise servers in a DC. A malicious 183 client tries to perform a SYN Flooding attack to degrade the 184 performance of a server in the same DC. That is, the client keeps 185 sending SYN message to the server with a un-reasonably high rate. To 186 detect this attack, Firewalls in the DC need to cumulate the SYN 187 message sent from the clients. If a Firewall finds that the 188 frequency of SYN message sent by a client exceed a pre-defined rate, 189 the IP address of this client will be drawn into a black list by the 190 Firewall. 192 3.3. Access Control List 194 Static Access Control List (ACL) can be configured on Firewall to 195 filter packets between internal and external network, or between 196 different security zones. Usually 5-tuple, VLAN information and 197 interface information are designated in ACL. Static ACL is not 198 generated dynamically based on flow, so there could be other way to 199 re-configure ACL except for state migration, e.g. manually configure 200 the static ACL on destination Firewall before VM migration. 202 4. Scenarios for Migration of States on Firewall 204 This section demonstrates the necessity of migrating Firewall states 205 when a VM is moved to a new place using several real-life scenarios. 207 4.1. VM Migration between different DCs 209 China Telecom has several geographically distributed DCs. These DCs 210 were built several years ago and can only provide limited computing 211 and storage services. Because the accelerating urbanization in 212 China, the places where the DCs locate has become downtown areas, and 213 it is very expensive to extend their scales, which cannot be afforded 214 by China Telecom. As a result, sometimes, China Telecom has to use 215 computing and storage resources of multiple DCs to support a single 216 service (e.g., Instance messaging or search engine). Such 217 combination of DCs should be seamless so that the service provider 218 can work in the same way as they work in a single DC, even when its 219 VMs need to migrate from one DC to another. 221 Figure 1 illustrates an example in which a DC provider has two DCs on 222 different locations. One is at City A; the other is at City B, which 223 is 30 kilometers away from City A. Assume that the physical distance 224 and network bandwidth between City A and B satisfy the requirements 225 of VM live migration. Two DCs are interconnected by, for example, 226 VPLS (, [RFC4761][RFC4762]) or OTV ([OTV]). Each DC has a pair of 227 centralized Firewalls. For simplicity, each DC only has only one 228 Firewall as shown the figure. 230 In the figure, Firewalls are shown separately from CEs. But in real- 231 life deployment, they could be integrated within CEs. 233 At the very beginning, VMs are evenly created on Pod1 and Pod2. As 234 time elapses, the overload imposed on Pod1 and Pod2 increases. Now, 235 for some reasons (e.g., hardware errors), Pod2 need to be switched 236 off and Pod1 does not have sufficient capability to support the VMs 237 on Pod2. In order to guarantee SLA, Pod3 is created and some of the 238 VMs on Pod1 and Pod2 are migrated to Pod3, and the running service 239 must be kept during the migration. 241 ------- ------- 242 | GW1 | | GW1'| 243 ------- ------- 244 | /\ | 245 | : | 246 ------------------------------------------------ ---------- 247 | VPLS-PE1 |-----------|VPLS-PE1'| 248 ------------------------------------------------ ---------- 249 | /\ | 250 | : | 251 -------- States on FW1 -------- 252 | FW1 | | FW1' | 253 -------- -------- 254 |/\ | 255 | : | 256 ------------------------------------------------ ---------- 257 | CE1 | | CE1' | 258 ------------------------------------------------ ---------- 259 | /\ | | 260 | : | | 261 --------------------- --------------------- ---------------------- 262 |Aggregation Switch1| |Aggregation Switch2| |Aggregation Switch1'| 263 --------------------- --------------------- ---------------------- 264 | /\ | | 265 | : | | 266 ---------------- ---------------- ----------------- 267 |Access Switch1| |Access Switch2| |Access Switch1'| 268 ---------------- ---------------- ----------------- 269 | /\ | | 270 | : | | 271 ---------------- ----------------- ----------------- 272 | VM1 VM2 VM3| | VM10 VM11 VM12| | VM31 VM32 VM33| 273 | VM4 VM5 VM6| | VM13 VM14 VM15| | | 274 | VM7 VM8 VM9| | VM16 VM17 VM18| | | 275 ---------------- ----------------- ----------------- 276 Pod1 Pod2 Pod3 278 VM1: 10.1.1.1 VLAN 1 280 .... VM Traffic 282 Figure 1: Example architecture 284 One way to achieve this is to migrate VMs but let the flow still pass 285 through FW1, VPLS-PE1 and GW1. But in that case, the traffic is not 286 optimized, which means more packet delay and more bandwidth 287 consumption. And another essential problem is that FW1' would drop 288 the packets since FW1' cannot map the flow to any recorded session. 290 So another way is to migrate states on FW1 to FW1' and let the flow 291 pass through FW1', VPLS-PE1' and GW1'. 293 The DCs could be in different subnets and we need to make sure the IP 294 address of VM be kept unchanged during the VM live migration. Some 295 existing work, e.g. in IETF LISP WG ([LISP]), can make VM migration 296 between subnets feasible. In State Migration, we won't try to define 297 technologies that can be used to keep VM's IP address unchanged while 298 migrating between subnets. 300 ------- ------- 301 | GW1 | | GW1'| 302 ------- ------- 303 | /\ | 304 | : | 305 ------------------------------------------------ ---------- 306 | VPLS-PE1 |-----------|VPLS-PE1'| 307 ------------------------------------------------ ---------- 308 | /\ | 309 | : | 310 -------- States on FW1 -------- 311 | FW1 | ******************************> | FW1' | 312 -------- -------- 313 |/\ | 314 | : | 315 ------------------------------------------------ ---------- 316 | CE1 | | CE1' | 317 ------------------------------------------------ ---------- 318 | /\ | | 319 | : | | 320 --------------------- --------------------- ---------------------- 321 |Aggregation Switch1| |Aggregation Switch2| |Aggregation Switch1'| 322 --------------------- --------------------- ---------------------- 323 | /\ | | 324 | : | | 325 ---------------- ---------------- ----------------- 326 |Access Switch1| |Access Switch2| |Access Switch1'| 327 ---------------- ---------------- ----------------- 328 | /\ | | 329 | : | | 330 ----------------- -------------------- ----------------- 331 | VM1 VM2 VM3 | | VM10 VM11 VM12 | | VM31 VM32 VM33| 332 |'VM4''VM5''VM6'| | VM13 VM14 VM15 | | VN4 VM5 VM6 | 333 | VM7 VM8 VM9 | | VM16 VM17 VM18 | | | 334 ----------------- -------------------- ----------------- 335 * /\ 336 ***************************************************** 337 Pod1 Pod2 Pod3 339 ******** VM or States Migration 340 ........ VM Traffic 342 Figure 2: VM and State Migration stage 343 ------- ------- 344 | GW1 | | GW1'| 345 ------- ------- 346 | | /\ 347 | | : 348 ------------------------------------------------ ---------- 349 | VPLS-PE1 |-----------|VPLS-PE1'| 350 ------------------------------------------------ ---------- 351 | | /\ 352 | | : 353 -------- -------- 354 | FW1 | | FW1' | 355 -------- -------- 356 | | /\ 357 | | : 358 ------------------------------------------------ ---------- 359 | CE1 | | CE1' | 360 ------------------------------------------------ ---------- 361 | | | /\ 362 | | | : 363 --------------------- --------------------- ---------------------- 364 |Aggregation Switch1| |Aggregation Switch2| |Aggregation Switch1'| 365 --------------------- --------------------- ---------------------- 366 | | | /\ 367 | | | : 368 ---------------- ---------------- ----------------- 369 |Access Switch1| |Access Switch2| |Access Switch1'| 370 ---------------- ---------------- ----------------- 371 | | | /\ 372 | | | : 373 ----------------- -------------------- ----------------- 374 | VM1 VM2 VM3 | | VM10 VM11 VM12 | | VM31 VM32 VM33| 375 | | | VM13 VM14 VM15 | | VN4 VM5 VM6 | 376 | VM7 VM8 VM9 | | VM16 VM17 VM18 | | | 377 ----------------- -------------------- ----------------- 378 Pod1 Pod2 Pod3 380 .... VM Traffic 382 Figure 3: VM Migration Completion 384 4.2. VM Migration under Distributed Deployed Firewalls 386 In a DC with distributed deployed Firewalls on Aggregation Switches, 387 assuming an enterprise customer lease hundreds of physical servers, 388 and each physical server carries 10 plus Virtual Machines (VM). The 389 VMs provide VDI service to employees in remote branch. At day time, 390 the VMs are evenly deployed on each Pod. 392 -------------------------------------------------------------------------- 393 | | 394 | Core Switch | 395 | | 396 -------------------------------------------------------------------------- 397 | | /\ VM traffic 398 | | : 399 | | : 400 ---------------------- ------ ---------------------- ------- 401 |Aggregation Switch |--|FW1 | |Aggregation Switch |--|FW1' | 402 ---------------------- ------ ---------------------- ------- 403 | \ | /\ States 404 | \ | : 405 ---------------- ---------------- ---------------- 406 |Access Switch1| |Access Switch2| |Access Switch3| 407 ---------------- ---------------- ---------------- 408 | | | /\ 409 | | | : 410 ---------------- ----------------- ----------------- 411 | VM1 VM2 VM3| | VM10 VM11 VM12| | VM19 VM21 | 412 | | | | | VM22 VM24 | 413 | VM7 VM8 VM9| | VM16 VM17 VM18| | VM25 VM27 | 414 ---------------- ----------------- ----------------- 415 Pod1 Pod2 Pod3 417 .... VM Traffic 419 Figure 4: VDI service in DC 421 During nighttime, most of the VMs are shut down. In order to save 422 energy, the VMs still active are migrated to a few physical servers 423 and other physical servers are switched off. In this case, the 424 states on FW1 need to be updated under the assistance of FW1, 425 otherwise the running service on migrating VM will be disrupted. 427 ----------------------------------------------------------------------- 428 | | 429 | Core Switch | 430 | | 431 ----------------------------------------------------------------------- 432 | | /\ 433 | | : 434 | | : 435 ---------------------- ------ ---------------------- ------ 436 |Aggregation Switch |--|FW1 | |Aggregation Switch |--|FW1'| 437 ---------------------- ------ ---------------------- ------ 438 | \ /\ | * 439 | \ *****************|**************** 440 ---------------- ---------------- ---------------- 441 |Access Switch1| |Access Switch2| |Access Switch3| 442 ---------------- ---------------- ---------------- 443 | | | /\ 444 | | | : 445 ---------------- ----------------- ----------------- 446 |VM1 VM12 VM19| | 'VM12'| | 'VM19' | 447 | VM27 | | | | | 448 |VM18 VM8 VM25| | 'VM18'| | 'VM25' 'VM27'| 449 ---------------- ----------------- ----------------- 450 /\ * * 451 * * * 452 **************************************** 453 Pod1 Pod2 Pod3 455 ******** VM or States Migration 457 ........ VM Taffic 459 Figure 5: VM and State migration 461 5. Active-Active or VM Migration 463 In previous WG discussion on State Migration, there is suggestions to 464 use alternative mechanism to migrate user's service instead of VM 465 Migration, and hence no necessity to do State Migration. The 466 suggested mechanism is to run active-active VMs on both old and new 467 locations. The new services related to the old VM is directed to the 468 new VM and shut down the old VM while all the existing services are 469 finished. In fact, this is not within the scope of State Migration 470 intention. But since State Migration proposal is based on the 471 precondition that VM is migrating, the authors would like to list 472 some reasons to clarify why VM Migration is necessary. 474 o Long lived connections: Some applications may establish 475 connections with virtual machines and the connections are kept 476 for a long time until the applications disconnect. An example is 477 the HTTP persistent connection technique,. The idea is to 478 generate a pool of TCP connections. Instead of opening a new one 479 for every single request/response pair, a TCP connection may be 480 re-used to send and receive multiple HTTP requests/ 481 responses.Unused TCP connections are then stored in the pool. 482 This solution is also widely used for improving performance of 483 network systems (e.g., distributed database systems). The above 484 examples make it very clear that it's unexpected how long the 485 existing services will be alive, that is it's unexpected how long 486 the old VM need to be kept active. 488 o Hardware failure: While there is hardware problem, it may not 489 leave enough time to wait until all the existing services are 490 finished. For example, there may be a power shortage in a 491 particular area, and the DC providers have to move their VMs, 492 services and data to another location in limited time. In this 493 case, active-active mechanism may cause services disruption, if 494 the existing services on old VMs keep running. 496 Active-active and VM migration are both useful for particular 497 scenarios. In State Migration concept, we only consider the 498 scenarios where VM Migration is a better choice. 500 6. Scope 502 For the first stage, SAMI (StAte MIgration) only do research on and 503 develop solution for Session Table migration on Firewall. But the 504 solution should be extensible to enable migration of other states 505 that we may find in the future which is necessary for VM live 506 migration. 508 In SAMI, we require that the network, wherein VM live migration 509 happens, must satisfy the basic network condition requirements raised 510 by Virtualization Platform vendors. Examples of network condition 511 requirements include reasonable geographic distance, higher than 512 minimum bandwidth and acceptable packet delay. The requirements 513 could vary from one Virtualization Platform vendor to another, and 514 SAMI won't define the requirements. Another important requirement is 515 that the IP address of VM must be kept unchanged during VM live 516 migration, but SAMI won't work on these technologies or make any 517 suggestions on these technologies. When we do research on SAMI, we 518 assume there are technologies to guarantee IP address unchanged 519 during VM live migration. 521 To be more specific on scope, we list some of scenarios that SAMI 522 will consider. All of these scenarios, are in scope for now, and 523 revision will be made when we get further achievements during 524 research. 526 1) State migration within the same DC, same subnet and same 527 administration domain; 529 2) State migration within the same DC and same administration 530 domain, but between different subnets; 532 3) State migration between DCs, which is under different 533 administration domains and different subnets; 535 Existing IETF work should be re-used to resolve the SAMI problem as 536 much as possible. Only when there is no existing IETF work can use, 537 to achieve State migration, a new mechanism needs to be developed. 538 [GapAnalysis]makes a brief analysis on existing related IETF work, 539 including MIDCOM, ForCES and PCP. And more will be introduced later. 541 7. Security Considerations 543 The states described above are all about security. Besides, we need 544 to be careful to avoid poisoned states from untrusted source. That 545 means no matter how the states are migrated, authentication and 546 verification are required. 548 8. Acknowledgments 550 The authors would like to thank the following people for contributing 551 to this draft: Ning Zong, David harrington, Linda dunbar, Susan 552 Hares, Serge manning, Barry Leiba, Jiang xingfeng, Song Wei, Robert 553 Sultan. 555 9. Author List 557 Jingtao Yang 559 yangjingtao@huawei.com 561 Huiyang Xu 563 xuhuiyang@chinamobile.com 565 Yongbin Fan 566 fanyb@gsta.com 568 Ming Liu 570 lium@ruijie.com.cn 572 10. References 574 10.1. Normative Reference 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", March 1997. 579 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 580 A. Rayhan, "Middlebox communication architecture and 581 framework", August 2002. 583 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 584 (VPLS) Using BGP for Auto-Discovery and Signaling", 585 Jan. 2007. 587 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 588 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 589 Jan. 2007. 591 10.2. Informative Reference 593 [GapAnalysis] 594 Wang, D. and Y. Gu, "I-D.wang-opsawg-policy-migration-gap- 595 analysis", 2011. 597 [Vmotion_between_DCs] 598 VMware, "VMotion between Data Centers--a VMware and Cisco 599 Proof of Concept, (http://http://blogs.vmware.com/ 600 networking/2009/06/ 601 vmotion-between-data-centersa-vmware-and-cisco-proof-of- 602 concept.html)", June 2009. 604 [OTV] Grover, H., Rao, D., and D. Farinacci, "Overlay Transport 605 Virtualization", July 2011. 607 [LISP] "Location/ID separation protocol, 608 http://tools.ietf.org/wg/lisp/". 610 Authors' Addresses 612 Gu Yingjie 613 Huawei 614 No. 101 Software Avenue 615 Nanjing, Jiangsu Province 210001 616 P.R.China 618 Email: guyingjie@huawei.com 620 Li Chen 621 China Mobile 623 Email: lichenyj@chinamobile.com 625 Li Kai 626 China Telecom 628 Email: leekai@ctbri.com.cn 630 Zhuo Zhiqiang 631 Ruijie Network 633 Email: zhuozq@ruijie.com.cn 635 Zhang Dacheng 636 Huawei 638 Phone: 86-01060610033 639 Fax: 640 Email: zhangdacheng@huawei.com