idnits 2.17.1 draft-marques-l3vpn-end-system-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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC4364]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '...ficance only and SHOULD be allocated b...' RFC 2119 keyword, line 274: '...peering sessions SHALL be support the ...' RFC 2119 keyword, line 284: '... Network devices MAY have direct BGP s...' RFC 2119 keyword, line 389: '...nt XMPP sessions. These sessions MUST...' RFC 2119 keyword, line 393: '... An End-system MAY connect to multip...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2011) is 4574 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) No issues found here. Summary: 4 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 P. Marques 3 Internet-Draft L. Fang 4 Expires: April 13, 2012 Cisco Systems 5 P. Pan 6 Infinera Corp 7 A. Shukla 8 Juniper Networks 9 October 2011 11 End-system support for BGP-signaled IP/VPNs. 12 draft-marques-l3vpn-end-system-02 14 Abstract 16 Network Service Providers often use BGP/MPLS IP VPNs [RFC4364] as the 17 control plane for overlay networks. That solution has proven to 18 scale to large number of VPNs and attachment points and is one 19 familiar to network equipment software. 21 There is a significant interest in the industry in building overlay 22 networks in which end-systems are themselves the direct participant, 23 along with network equipment such as service appliances. 25 This document proposes an extension of the BGP IP VPN model to serve 26 as the signaling protocol for host-based overlay networks along with 27 an XMPP interface that provides a bridge between the software 28 concepts familiar to end-points and those familiar to network 29 equipment. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 13, 2012. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. End-system functionality . . . . . . . . . . . . . . . . . . . 3 66 3. Virtual Machine Networking . . . . . . . . . . . . . . . . . . 4 67 4. Operational Model . . . . . . . . . . . . . . . . . . . . . . 5 68 5. XMPP client interface . . . . . . . . . . . . . . . . . . . . 8 69 6. VPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Data center applications require private networks connecting multiple 78 "Virtual Machines" belonging to the same administrative "user" and 79 between them and network elements and appliances. 81 In this context, it is a common goal, for the data-center forwarding 82 infrastructure to be isolated from the knowledge of the private 83 network. The set of routers and switches that interconnects physical 84 machines in the data-center is assumed to provide an IP service (with 85 or without the use of IEEE 802.1 technologies). 87 The Virtual Private Networks (VPNs) associated with each individual 88 administrative domain can be built without the knowledge of the data- 89 center connectivity layer as an overlay network. This proposal 90 leverages the technology used in the Service Provide managed VPN 91 space and extends it to address the problem of interconnecting 92 virtual interfaces on end-systems. In both applications there is the 93 need to be able to manage at scale a very large number of VPNs and 94 attachement points. And in both cases there is the need to support 95 the interchange of traffic between different VPNs. 97 This document defines how BGP-signaled IP/VPNs can be used to 98 interconnect end-systems and network elements. It assumes that the 99 forwarding layer uses IP over GRE as defined by [RFC4023]. Other 100 transport layers such as native MPLS or 802.1ah can also be used with 101 the same signaling approach. 103 When this document uses the term 'Infrastructure IP' addresses, it 104 refers to the addresses used in the outer header of GRE packets. In 105 the case of a transport other than IP over GRE, this would be the 106 Subnetwork Point of Attachement (SNPA) address corresponding to the 107 multi-access network providing connectivity to the end-systems. 109 BGP is not an interface that application software is familiar with. 110 In order to bridge the gap between concepts familiar to network 111 devices and those familiar to end-system developers, this document 112 defines an XMPP client interface to be used by end-systems. It 113 defines the procedures to interchange data between XMPP and BGP IP 114 VPN sessions along with the corresponding data schemas. Networking 115 devices may opt to receive the signaling information directly via 116 BGP. 118 2. End-system functionality 120 For the purposes of this document we assume that each end-system 121 executes an 'Host Operating System' with the ability to: 123 Create virtual interfaces (typically ethernet interfaces). 125 Associate a given virtual interface with a specific "Virtual and 126 Routing Forwarding (VRF)" table. 128 Store entries in the VRF table that map an VRF-specific IP prefix 129 into a next-hop which contains a destination IP address and a 130 20-bit label. 132 Encapsulate outgoing packets according [RFC4023] using the result 133 of the VRF lookup. 135 Associate incoming packets with a VRF according to the 20-bit 136 label contained immediately after the GRE header. 138 Expose a programmatic interface to create, update and delete VRF 139 table entries. 141 The 'Host Operating System' may choose to associate the virtual 142 interfaces with specific 'Virtual Machines' or use other policies to 143 manage the application access to these interfaces. 145 Hosts should support the ability to associate multiple virtual 146 interfaces with the same VRF. The 20-bit label which is associated 147 with a VRF is of local significance only and SHOULD be allocated by 148 the end-system. 150 The procedure that determines that a VRF should be configured on a 151 particular end-system as well as which IP addresses to be associated 152 with each interface are outside the scope of this document. We 153 assume that statically assigned IP addresses are used. 155 The VRFs support IP unicast traffic only. Multicast support is 156 subject for further study and will be detailed in a separate 157 document. Both IPv4 and IPv6 are supported and the term 'IP' can 158 refer to either version of the Internet Protocol. 160 The VRF table is populated by the signaling mechanisms described 161 bellow and may contain both host length (i.e. /32 and /128 for IPv4 162 and v6 respectively) or subnet prefixes. As an example a VPN with 163 access to the external networks would probably contain a default 164 route plus a set of host length entries for all the Virtual Machines 165 (VMs) in the same VPN. 167 In the terminology used in the BGP-signaled IP/VPN standard 168 [RFC4364], a end-system acts as a 'Provider Edge' (PE) device in 169 terms of its forwarding capabilities, with the virtual interfaces 170 that it exposes (for instance to virtual machines) as the 'Customer 171 Edge' (CE) interfaces. 173 3. Virtual Machine Networking 175 When virtual machines are associated with a virtual interface on the 176 end-system, this document assumes that there is a single route entry 177 to a default route on the Virtual Machine (VM). Packets are then 178 routed by the Host OS, which imposes the VPN encapsulation header. 179 Link-local addresses on the virtual ethernet interface that connects 180 the virtual machine are not globally significant. 182 When discussing VM connectivity, it is frequent to encounter the 183 assumption that the VM routing table contains a subnet route entry 184 with reachability to all other VMs in the VPN. 186 VM route table using LAN adjacency: 188 +-------------+----------+-----------+ 189 | IP prefix | Next-hop | Interface | 190 +-------------+----------+-----------+ 191 | 10.1.1.1/32 | local | veth0 | 192 | 10.1/16 | direct | veth0 | 193 +-------------+----------+-----------+ 195 In the scenario above, the VM assumes a direct LAN adjacency with its 196 peers (e.g. 10.1.1.2). It uses ARP to build an L2 adjacency to its 197 communication peers. Scaling ARP broadcasts and updating ARP entries 198 across the data-center becomes an important problem. Often the 199 conclusion reached is that the VM mac-addresses must be global and 200 constant for a given VM. That can be a problematic requirement when 201 interconnecting data-centers administered by different orchestration 202 systems. 204 This document proposes a VM routing table configuration where there 205 are no ARP adjacencies between different VMs. 207 VM route table using default gateway: 209 +--------------------+-----------------+-----------+ 210 | IP prefix | Next-hop | Interface | 211 +--------------------+-----------------+-----------+ 212 | 10.1.1.1/32 | local | veth0 | 213 | 169.254.254.254/32 | direct | veth0 | 214 | 0/0 | 169.254.254.254 | veth0 | 215 +--------------------+-----------------+-----------+ 217 The configuration above eliminates the need for L2 adjacencies 218 between VMs. The VM contains a single ARP entry to its default 219 gateway, which is the Host OS. The Host OS performs a route lookup in 220 the corresponding VRF in order to route the packet. In this 221 approach, the Host OS VRF is the point of control that determines the 222 destination end-system associated with the VPN destination IP 223 address. 225 One of the advantages of this model is that it eliminates the need to 226 support broadcast across a VPN. 228 The guest OS should be configured with a default gateway address in 229 the IP link-local address space. This address should be constant 230 across all hosts that the VM can be instantiated on. The example 231 above uses the highest numbered address in the IPv4 link-local range 232 and assumes that the Host OS has been configured to recognize that 233 address as local and answer local ARP requests on the virtual 234 interface. 236 4. Operational Model 238 In the simplest case, a VPN is a collection of systems that are 239 allowed to exchange traffic with each other and where all the VRFs in 240 the VPN contain all the routing entries for the VPN. Only members of 241 the VPN are allowed to exchange traffic with each other. We can 242 refer to these as symmetrical VPNs since all VRFs contain the same 243 routing information. 245 When end-systems join a given VPN they advertise their membership by 246 advertising the VPN-specific IP address associated with a particular 247 virtual interface as well as its binding to the infrastructure IP 248 address associated with the host. 250 Infrastructure addresses are routable in the underlying transport 251 network (e.g. the data-center network). While VPN addresses are 252 routable on the VPN network only. 254 End-systems subscribe to the contents of the VPN routing tables for 255 which they have members associated with. This information is then 256 used to populate the host's routing tables. It may contain both host 257 routes (i.e. IPv4 32-bit prefixes or IPv6 128-bit prefixes) or 258 routes to gateways that interconnect other networks. 260 The signaling network delivers the membership advertisements 261 generated by the end-systems to other members of the same VPN, subjet 262 to policy controls. 264 When a particular VM "moves" from one physical end-system to another, 265 its respective VPN address will be advertised by the new system and 266 that notification propagated to all attachment points of that VPN. 268 This document assumes two types of applications that perform network 269 signaling functions: BGP Route Reflectors (RRs) and BGP/XMPP 270 signaling gateways. Both functions may be collocated in the same 271 physical device. 273 The BGP Route Reflectors accept connection from gateways or native 274 BGP devices. These BGP peering sessions SHALL be support the address 275 families: VPN-IPv4 (1, 128), VPN-IPv6 (2, 128) and RT-Constraint (1, 276 132) [RFC4684]. 278 The XMPP signaling gateways maintain persistent connection to a 279 subset of the end-systems of the domain and provide a 'pubsub' API to 280 the contents of each specific VPN routing table. These systems are 281 not in the forwarding plane and do not need to be collocated with a 282 network device. 284 Network devices MAY have direct BGP sessions to the BGP Route 285 Reflectors. For instance, a router or security appliance that 286 supports BGP/MPLS IP VPNs over GRE may use its existing functionality 287 to inter-operate directly with a collection of Virtual Machines. 289 The BGP/XMPP gateways implement the VRF policy functionality that is 290 associated with PE routers in the pure BGP IP/VPN case. In these 291 signaling gateways, the 'publish-subscribe' messages from the end- 292 systems are associated with a VRF-specific signaling table. Each of 293 these routing tables contains import and export policies which 294 provide fine grain control over the table contents. 296 An export policy associates VPN routing information with one or more 297 6 byte values known as 'Route Targets'. These 'Route Targets' are 298 associated with the routes as they are advertised out to other BGP 299 speakers. 301 Import policies, on the other hand, select via 'Route Targets', from 302 all the available routing information which routes should be imported 303 into a VPN-specific routing table. 305 A symmetrical VPN uses the same configuration for both import and 306 export. By controlling these policies it is possible to selectively 307 allow direct traffic exchanges between members of different VPNs, 308 assuming their respective IP addresses are non-overlapping. 310 +--------+ +--------+ 311 VM1 -- veth0 --| host 1 |=== [network] ===| host 2 |-- veth0 -- VM2 312 +--------+ +--------+ 314 IP pkt ===> GRE encap ===> [IP net] ===> GRE decap ===> IP pkt 315 [192.168.2.1, 20] map 20 to veth0 317 +----------------+--------------+-------+ 318 | VPN IP address | Host address | label | 319 +----------------+--------------+-------+ 320 | 10.1.1.1/32 | localhost | 10 | 321 | 10.1.1.2/32 | 192.168.2.1 | 20 | 322 +----------------+--------------+-------+ 324 VRF table on host1 326 The figure and table above contain an example in which IP packets are 327 transmitted from one VPN interface (with address 10.1.1.1) to another 328 VPN interface (with address 10.1.1.2). As previously mentioned, the 329 virtual ethernet interfaces function as a CE interace in a 330 traditional BGP-signaled IP VPN. While the end-system provide the 331 forwarding functionality equivalent to a PE device. 333 +--------+ +-----------+ +--------+ 334 | host 1 | <===> | signaling | <===> | BGP RR | 335 +--------+ | gateway | +--------+ 336 +-----------+ 338 +----------------+-------------+-------+-----------+ 339 | VPN IP address | SNPA | label | Known via | 340 +----------------+-------------+-------+-----------+ 341 | 10.1.1.1/32 | 192.168.1.1 | 10 | XMPP | 342 | 10.1.1.2/32 | 192.168.2.1 | 20 | BGP | 343 +----------------+-------------+-------+-----------+ 345 VPN Routing table on signaling gateway 347 The signaling network corresponding to the same example is depicted 348 above. The signaling gateway is an out-of-band system which speaks 349 both XMPP to the host as well as BGP to the BGP RRs. The table above 350 represents the routing table on the gateway that corresponds to the 351 VPN of the example. Host 2 would be connected to another signaling 352 gateway which would be in turn connected to the BGP RR mesh. 354 The gateway is configured via an external mechanism with the 355 parameters that correspond to the VPNs in use by its clients along 356 with its respective vrf import and export policies. 358 XMPP publish request are translated into routing entries on this 359 table, which are then advertised via BGP, using standard BGP-signaled 360 IP VPN mechanism.BGP learned routes are also imported into this 361 routing table. Any changes to its content are advertised to local 362 XMPP clients. 364 In comparison with traditional IP VPNs, the signaling gateway is 365 performing the PE functionality, with XMPP used as a PE-CE routing 366 protocol. 368 An example of an asymmetrical VPN configuration is one where all the 369 traffic from VMs must be redirected though a middle-box (on a VM) for 370 inspection. Assuming that the VMs of a particular user are 371 configured to be in the VPN "tenant1" at an initial stage. This 372 "tenant1" VPN is symmetrical and uses a single Route Target in both 373 its import and export policies. The middle-box functionality can be 374 incrementally deployed by defining a new VPN, "tenant1-hub", and an 375 associated Route Target. Accompanied with a change in the gateway 376 configuration such that VPN "tenant1" only imports routes with the 377 Route Target associated with the hub. The "hub" VPN is assumed to 378 advertise a prefix that covers all the VMs IP addresses. The "hub" 379 VPN imports the VMs routes in order for it to be able to generate the 380 XMPP updates to the "hub" end-system. This information is required 381 for the return traffic from the hub to the spokes (the standard VMs). 383 5. XMPP client interface 385 The communication between end-systems and the signaling gateway uses 386 the XMPP protocol with the PubSub Collection Nodes [pubsub] extension 387 in order to exchange VPN route information. 389 End-systems establish persistent XMPP sessions. These sessions MUST 390 use the XMPP Ping [xmpp-ping] extension in order to detect end-system 391 failures. 393 An End-system MAY connect to multiple VPN-signaling gateways for 394 reliability. In this case it SHOULD publish its information to each 395 of the gateways. It MAY choose to subscribe to VPN routing 396 information once only from one of the available gateways. 398 The information advertised by a end-system SHOULD be deleted after a 399 configurable timeout, when the session closes. This timeout should 400 default to 60 seconds. 402 +---------+ +--------+ 403 | gateway | ----------- | BGP RR | 404 +---------+ +--------+ 405 // \ / 406 XMPP \ / 407 // \ / 408 +------------+ \ / 409 | end-system | \ / 410 +------------+ \/ 411 \\ /\ 412 XMPP / \ 413 \\ / \ 414 +---------+ / \ +--------+ 415 | gateway | ----------- | BGP RR | 416 +---------+ +--------+ 418 The figure above represents a typical configuration in which a end- 419 system is homed to multiple gateways, which are in turn connected to 420 multiple BGP route reflectors. In a deployment there would be a 421 number of gateways corresponding to the number of end-systems divided 422 by the gateway capacity in terms of number of XMPP sessions. While 423 the BGP RR scale in terms of the number of gateways attached to it. 425 The XMPP "jid" used by the end-system shall be a 6-byte value that 426 uniquely identifies the host in the domain. This specification 427 recommends the use of the 802 MAC address of one of the physical 428 ethernet interfaces of the end-system, when present. 430 Each VPN shall be identified by a 64 ASCII character string. 432 The host system software on an end-system SHALL establish an XMPP 433 session with its configured signaling gateways before creating 434 virtual interfaces. 436 When a virtual interface is created, for instance as result of a 437 Virtual Machine being instantiated on a end-system, the host 438 operating-system software shall generate an XMPP Publish message to 439 the VPN-signaling gateway. 441 Publish request from end-system to gateway: 443 445 to='network-control.domain.org' 446 id='request1'> 447 448 449 450 451 'vpn-ip-address>/32' 452 'infrastructure-ip-address' 453 454 455 456 457 458 459 461 465 466 467 468 469 470 471 In the request above the node 'vpn-customer-name' is assumed to be a 472 collection which is implicitly created by the VPN-signaling gateway. 474 The VPN-signaling gateway will convert the information received in a 475 the 'publish' request into the corresponding BGP route information 476 such that:. 478 It associates the specific request with a local VRF with the name 479 specified in the collection 'node' attribute. 481 It creates a BGP VPN route with a 'Route Distinguisher' (RD) which 482 contains the the end-system's 'system-id' value and the specified 483 IP prefix and 'label' as the Network Layer Reachability 484 Information (NLRI) . 486 It associates this route with the specified SNPA address. 488 It associates the route with an extended community TDB containing 489 the version number. 491 Subscription request from end-system to gateway: 493 497 498 499 500 502 Update notification from gateway to end-system: 504 505 506 507 508 509 'vpn-ip-address>/32' 510 'infrastructure-ip-address' 511 512 513 514 515 516 ... 517 518 519 520 522 Notifications should be generated whenever a VPN route is added, 523 modified or deleted. 525 Note that the Update from the signaling gateway to the end-point does 526 not contain the system-id of the destination end-point. When 527 multiple possible routes exist for a given VPN IP address, for 528 instance because the VM may be in the process of moving location, it 529 is the responsibility of the gateway to select the best path to 530 advertise to the end-system. 532 When routes are withdrawn, the signaling gateway generates both a 533 "collection disassociate" request as well as a node "delete" request. 535 In situations where an automated system is controlling the 536 instantiation of VMs it may be possible to have that system assign a 537 non-decreasing version number for each instantiation of that 538 particular VM. In that case, this number, carried in the 'version' 539 field may be used to help gateways select the most recent 540 instantiation of a VM during the interval of time where multiple 541 routes are present. 543 6. VPN NLRI 545 When a VPN-signaling gateway receives a request to create or modify a 546 VPN route is SHALL generate a BGP VPN route advertisement with the 547 corresponding information using the BGP address family corresponding 548 to the address family specified by the end-system. 550 It is assumed that the VPN-signaling gateways contain information 551 regarding the mapping between 'vpn-customer-names' and BGP Route 552 Targets used to import and export information from the associated 553 VRFs. This mapping is known via an out-of-band mechanism not 554 specified in this document. 556 Whenever a VRF in the gateway contains local routing information, the 557 gateway shall advertise the corresponding RT-Constraint route target 558 routes in BGP, which perform a parallel function to the subscription 559 requests in XMPP. 561 The 32bit route version number defined in the XML schema is 562 advertised into BGP as a Extended community with type TBD. 564 Signaling gateways SHOULD use automatically assign a BGP route 565 distinguisher per VPN routing table. 567 7. Security Considerations 569 The signaling protocol defines the access control policies for each 570 virtual interface and any VM associated with it. It is important to 571 secure the end-system access to signaling gateways and the BGP 572 infrastructure itself. 574 The XMPP session between end-systems and the XMPP gateways MUST use 575 mutual authentication. One possible strategy is to distribute pre- 576 signed certificates to end-systems which are presented as proof of 577 authorization to the signaling gateway. 579 BGP sessions MUST be authenticated using a shared secret. This 580 document recommends that BGP speaking systems filter traffic on port 581 179 such that only IP addresses which are known to participate in the 582 BGP signaling protocol are allowed. 584 8. Acknowledgements 586 The authors would like to thank Thomas Morin for his comments. 588 9. References 590 [RFC4023] Worster, T., Rekhter, Y. and E. Rosen, "Encapsulating MPLS 591 in IP or Generic Routing Encapsulation (GRE)", RFC 4023, 592 March 2005. 594 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 595 Networks (VPNs)", RFC 4364, February 2006. 597 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 598 R., Patel, K. and J. Guichard, "Constrained Route 599 Distribution for Border Gateway Protocol/MultiProtocol 600 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 601 Private Networks (VPNs)", RFC 4684, November 2006. 603 [xmpp-ping] 604 "XMPP Ping", XEP 0199, June 2009. 606 [pubsub] "PubSub Collection Nodes", XEP 0248, September 2010. 608 Authors' Addresses 610 Pedro Marques 612 Email: pedro.r.marques@gmail.com 614 Luyuan Fang 615 Cisco Systems 616 111 Wood Avenue South 617 Iselin, NJ 08830 619 Email: lufang@cisco.com 621 Ping Pan 622 Infinera Corp 623 140 Caspian Ct. 624 Sunnyvale, CA 94089 626 Email: ppan@infinera.com 627 Amit Shukla 628 Juniper Networks 629 1194 N. Mathilda Av. 630 Sunnyvale, CA 94089 632 Email: amit@juniper.net