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