PPVPN Working Group K. Kompella (Juniper) Internet Draft J. Achirica (Telefonica) Expiration Date: April 2002 L. Andersson (Utfors) M. Lasserre (Riverstone) P. Lin (Yipes) P. Menezes (Terabeam) A. Moranganti (Appian) H. Ould-Brahim (Nortel) S. Yeong-il (Korea Tel) Decoupled Transparent LAN Services draft-kompella-ppvpn-dtls-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. K. Kompella (editor) Expires April 2002 [Page 1] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 2. Abstract Transparent LAN Service (TLS) is a useful Service Provider offering. A common scenario where this offering is made is in the metro area, where several Multi-Tenant buildings are connected to an Office, and several Offices are connected by a metro area network. The Service Provider places a simple, low-cost box (MTU) in each building; these MTUs have uplinks to some box (PE) in one or more Offices. In such a scenario, it is useful to decouple the functions needed to offer TLS across the MTU and PE; this document proposes one way of accomplishing that. 3. Introduction Transparent LAN Service (TLS) is a useful Service Provider offering. A Transparent LAN appears in (almost) all respects as a LAN to the Service Provider customer; "transparent" is used in the sense of "transparent" bridging. However, in a TLS, the customers are not all connected to a single LAN; the customers may be spread across a metro or wide area. In essence, a TLS glues several individual LANs across a metro area to appear and function as a single LAN. A common scenario where TLS is offered is in the metro area, where several Multi-Tenant buildings are connected to an Office, and several Offices are connected by a metro area network, for example, a SONET ring. The Service Provider places a simple, low-cost box (MTU) in each building. A typical MTU has 10-100 Ethernet ports that connect to customers (we call these the "customer-facing ports"), and one or more uplinks to a Service Provider aggregation box (PE) (we call these the "WAN" links, although they may either metro area or wide area links). The customer hand-off is thus an Ethernet; the MTU acts as a metro/wide area bridge connecting the LAN at a customer site to other MTUs that are connected to other LANs belonging to the same customer. In such a scenario, it is useful to decouple the functions needed to offer TLS across the MTU and PE. These functions comprise learning MAC addresses, including learning across the metro area from other MTUs; building a spanning tree, both on the LAN side and on the metro side; and discovering other MTUs connected to a given customer. This document suggests that the former two functions (layer 2 functions) be run on the MTU, and that the last function (layer 3) be run on the PE. In addition, there needs to be some information exchange between the PE and its MTUs. This document does not suggest that decoupling is appropriate for all scenarios. The spanning tree algorithm is useful in the case that an MTU is K. Kompella (editor) Expires April 2002 [Page 2] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 connected to more than one PE which can reach a destination MTU. This gives the MTU a means to choosing one of the PEs as the primary means of reaching the destination MTU, while preserving the others as backup paths. Alternative means of accomplishing this objective may be possible, and indeed, preferable, and are not ruled out by this document. 3.1. Motivation for Decoupling We consider three ways of splitting the TLS functions across the MTU and PE: run all TLS functions on the MTU; run all TLS functions on the PE; or run learning and spanning tree on the MTU, and discovery on the PE, and some information exchange between them. In this subsection, we examine the repercussions of each. 3.1.1. Function Compatibility In this document, we assume that an MTU is a simple, low-cost layer 2 device, usually based on a bridge. That implies that an MTU is designed to learn MAC addresses, and to run a spanning tree algorithm. An MTU does not usually run complex layer 3 protocols, in particular, BGP, which is the de facto VPN discovery protocol. On the other hand, a PE device is a more complex layer 3 device. Besides being connected to MTUs and offering TLS, a PE may offer several other services. For example, a PE may be directly connected to customers through WAN circuits to offer various VPN services, and/or public Internet access; and a PE may take part in peering sessions. This requires the PE to be capable of VPN discovery, and to run BGP, so it is natural for a PE to do TLS discovery. 3.1.2. Scalability Let's posit the following hypothetical numbers to get a feel for the scaling requirements. The numbers are just orders of magnitude; there is no claim that these are realistic, or supported by market data. # of end hosts per TLS 100-1000 # of TLS's per MTU 10-100 # of MTUs per PE 10-100 # of PEs in a metro area 10-100 Armed with these, let's examine the effect of running each of the TLS functions at an MTU vs. at the PE. K. Kompella (editor) Expires April 2002 [Page 3] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 The number of MAC addresses that would need to be learned by an MTU ranges from 1000 to 100,000. The number that would need to be learned by a PE ranges from 10,000 to 10,000,000. A spanning tree may need to be built for each TLS. If so, the number of spanning trees that would need to be built by an MTU ranges from 10 to a 100. The number of spanning trees that would need to be built by a PE ranges from 100 to 10,000. The number of "discovery peers" (i.e., BGP peers if BGP is the discovery protocol) for an MTU doing discovery ranges from 100 to 10,000. The number of peers for a PE doing discovery ranges from 10 to 100. (Note that the number of peers can be mitigated using techniques similar to those recommended for RFC 2547-style VPNs [IPVPN, IPVPNbis], e.g., partitioned route-reflector topologies.) 3.1.3. Configuration Both the fact that the MTU is a simple, low-cost box, and that there are one to two orders of magnitude more MTUs than PEs suggest that the PE is more suitable as the place where TLS should be configured. If all TLS functions are run on the PE, this is automatically satisfied. If all TLS functions are run on the MTU, this is difficult to achieve. This document shows how this can be achieved in the case that the TLS functions are distributed across the MTU and PE. 4. Functional Requirements This section presents the functional requirements of MTUs and PEs in order to participate in a decoupled TLS. 4.1. Requirements on the MTU An MTU must be able to function as a transparent learning bridge, as it might well be connected to traditional bridges on customer-facing ports. Thus, it must be able to learn MAC addresses and run the spanning tree algorithm and flood packets when necessary. An MTU must also be able to run the modified learning and spanning tree algorithms described below, as well as the modified flooding. In addition, an MTU must be able to send and receive labeled packets. This labeling could either be MPLS labels, or VLAN tagging. In the latter case, the VLAN tag could either be the first tag, or a stacked tag; unfortunately, there is no standard yet for VLAN stacking. It K. Kompella (editor) Expires April 2002 [Page 4] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 is absolutely necessary that the VLAN tag that is added is assigned by the Service Provider, and is independent of customer tags. More details on the use of VLAN tags between an MTU and a PE will be forthcoming in a future version of this document. For MPLS labeling, an MTU must be able to take an Ethernet frame from a customer-facing port, verify the CRC, strip the Ethernet preamble and CRC, and encapsulate the remaining Layer 2 frame as an MPLS packet with the appropriate label stack and send it to a PE. On the receiving side, the MTU must be able to receive a labeled packet from a PE, and based on the label decide which TLS the enclosed Ethernet frame belongs to; if necessary, learn the origin of the source MAC address (as described in the section on modified learning); remove the MPLS encapsulation and label; and generate a CRC and send the packet on the appropriate customer-facing port. Furthermore, the MTU must be able to distinguish from which PE it received the labeled packet, i.e., it must support per-interface labels, for reasons described below. Also, an MTU should have some means to be provisioned and to monitor its operation. This requires some form of access to the MTU; for example, if the provisioning and monitoring is to be done via SNMP, the MTU would have to be IP-addressable, and to support SNMP functions. Finally, an MTU must run the MTU-PE protocol described below, and to carry out the actions required by the protocol. In order to accomplish the above, the MTU may maintain in some form a mapping from (learned) MAC addresses to customer ports (for traditional learning), and a mapping from MAC addresses to received labels (for the modified learning); these mappings constitute the MTU's MAC address cache. Ideally, the MTU should maintain a separate MAC address cache for each TLS it is part of, although in principle MAC addresses being globally unique, this should not be necessary. Also, the MTU must have a (configured) mapping from a customer port to a TLS, and for convenience, a mapping from a TLS to a list of customer ports. 4.2. Requirements on the PE A PE must have the Layer 2 VPN functionality described in [L2VPN], with the modifications described below. This requires that a PE be able to run BGP; MPLS: i.e., send and receive labeled packets, and swap, push and pop labels; and that a PE have some form of tunnels to every other PE taking part in any TLS in which this PE is participating. K. Kompella (editor) Expires April 2002 [Page 5] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 A PE must also support the configuration of TLSs, and be able to run the MTU-PE protocol described below. 5. PE Operation This section describes how a PE running a decoupled TLS operates, that is, how the TLS is configured, how members are discovered, how the PE forwards packets in a TLS. The discovery mechanism used here is a variant of the Layer 2 VPN discovery [L2VPN]. Familiarity with that document is a prerequisite to understanding the operation of decoupled TLSs as described here. 5.1. Configuration We first list the configuration information that MTUs and PEs need, then we suggest a means of configuring this information. As we said earlier, an MTU has several Ethernet ports that connect to customers, and some uplinks to PEs. The MTU needs to be told which of its customer-facing ports belong in which TLS. More precisely, the MTU needs to be told which TLSs it is a member of, and which PEs it is connected to. For each pair, the MTU must be told what its "site ID" is for that . Finally, for each TLS, the MTU must be given the list of its s that belong to the TLS. A PE needs to be told which MTUs it is connected to (and over which link), and which TLSs each such MTU participates in. The minimum information that a PE must be configured with is the following: < < < ... > That is, the PE is given the MTU ID (as an IP address), the interface over which it is connected to the MTU, and a list of TLSs that that MTU participates in. For each TLS in this list, the PE is given the TLS ID, the MTU's site ID in this TLS. A TLS ID is an 8 octet Route Distinguisher; a site ID is a two octet integer (see [L2VPN] for details). K. Kompella (editor) Expires April 2002 [Page 6] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 If it is desired that all TLS configuration be done at the PE, here is how this can be accomplished. The PE is configured with the following information for each MTU to which it is connected: < < < ...>> < < ...>> ... > That is, in addition to the above, the PE is given, for each MTU and each TLS that the MTU participates in, a list of customer facing port IDs and corresponding VLAN tags that belong to that TLS. An MTU port ID is a two octet integer; a VLAN tag is a two octet (12 bit) 802.1q tag. The PE then transfers all information relevant to an MTU to that MTU using the MTU-PE protocol described later. The PE transfers all information relevant to other PEs running TLS to them using a mechanism similar to [L2VPN], described below. 5.2. Generated Information A PE given the above configuration generates label ranges as in [L2VPN] consisting of a label base, an offset and a size. It is expected that for a TLS, a single, contiguous label range with offset 0 would suffice; if not, a number of non-overlapping label ranges can be used, as described in [L2VPN]. Call these label ranges the WAN label ranges for the pair. For the same pair, the PE must generate a second set of label ranges called the MTU label ranges. Each MTU label range for an pair corresponds exactly to one of the WAN label ranges for the ; in fact, the only difference is the label base. All WAN label ranges generated by a given PE must be non-overlapping; similarly, all MTU label ranges generated by a given PE must be non- overlapping. It is possible that some WAN label range and some MTU label range overlap; this depends on factors outside the scope of this document (such as whether per-interface or per-box labels are being used). An implementation may of course choose to ensure that PE WAN labels and MTU labels are always non-overlapping. K. Kompella (editor) Expires April 2002 [Page 7] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 5.2.1. Multipoint Uplinks If the PE-MTU link is a multipoint link (such as Ethernet), and there are multiple PEs on this link, there is the possibility that the MTU label ranges from the PEs overlap. In this case, some mechanism is needed to resolve the overlap. One solution is that PEs that are connected to MTUs over a multipoint link multicast their messages to the MTUs, say to the ALL-ROUTERS multicast address. If PE y hears that PE x is using a certain label range, it remembers that, and ensures that future label ranges that it sends to an MTU don't overlap. If two PEs send overlapping label ranges simultaneously, the PE with the lower router ID wins the contention, and the other PE withdraws its label range and issues a non-overlapping range. Details will be forthcoming. Other solutions may also be possible. 5.3. TLS Discovery The mechanism used for TLS member discovery is that in [L2VPN], with the following changes: there is a new code-point for encapsulations for Decoupled TLS; and the "routes" that are installed are different (described next). Furthermore, it is anticipated that there is no need for topology information, as TLSs are fully meshed. For simplicity, it is assumed that a single label range with offset 0 is used for both WAN and MTU label ranges for a given pair. Say MTU U is attached to PE X, and that MTU U participates in TLS T. Suppose MTU U' attached to PE X' also participates in TLS T. Suppose further that the site ID for MTU U in TLS T is p, and the site ID for MTU U' is p'. Suppose finally that there is a tunnel W from PE X to PE X' and a reverse tunnel W' from PE X' to PE X. PE X announces a WAN label range to all other PEs with label base K, offset 0, and length k (k >= p, p') for . According to [L2VPN], this tells PE X' to use label (K+p') to send packets from MTU U' to MTU U. PE X' announces a WAN label range to all other PEs with label base K', offset 0, and length k' (k' >= p, p') for . This tells PE X to use label (K'+p) to send packets from MTU U to MTU U'. PE X also sends an MTU label range to MTU U with label base A, offset 0, and length k for TLS T. This tells MTU U to use label (A+p') to send to the MTU with site ID p' (i.e., MTU U'); and also that packets received with label (A+p') belong to TLS T, and were originated at the MTU with site ID p'. Similarly, PE X' sends an MTU label range K. Kompella (editor) Expires April 2002 [Page 8] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 to MTU U' with label base A', offset 0, and length k' for TLS T. PE X installs "MTU routes" and "WAN routes". We describe the MTU route for packets from MTU U to MTU U': for labeled packets arriving from MTU U, swap incoming label (A+p') with (K'+p), then put the packet in tunnel W to PE X'. The WAN route is for packets from MTU U' to MTU U, and is as follows: for packets arriving on tunnel W' from PE X', remove the packets from the tunnel (if needed), then swap incoming label (K+p') with label (A+p'). To complete the path from MTU U to MTU U', the WAN route installed by PE X' is described. For packets arriving on tunnel W from PE X, remove the packets from the tunnel (if needed), then swap incoming label (K'+p) with (A'+p). Figure 1 below depicts this scenario: MTU U connected to PE X and MTU U' connected to PE X'. It further depicts MTU U dual homed to PE Z, and another MTU V dual homed to the same PE, PE Y. For each PE, it shows the WAN label range announced to other PEs, as well as the MTU label range sent to its MTU. Note that a dual homed MTU MUST be given distinct site IDs for each uplink, whether to the same PE or different PEs; and that a PE must allocate and announce WAN and MTU label ranges for each MTU that it is connected, even if it is the same MTU over different links (such as PE Y and MTU V). Figure 1 {A,0,k} <- +-------+ W -> +-------+ -> {A',0,k'} ============| PE X |<****************>| PE X' |=======[MTU U'] | +-------+ W' <- +-------+ | announces {K,0,k} \ / announces {K',0,k'} | for MTU U, site ID p\ / for MTU U', site ID p' | .............. [MTU U] . core . | .............. announces {L,0,l} for | announces {M,0,m} / \ MTU V, site ID q | MTU U, site ID r / announces \ -> {B,0,l} | +-------+ {L',0,l'} +-------+=======[ ] ============| PE Z | for MTU V, | PE Y | [MTU V] {C,0,m} <- +-------+ site ID q' +-------+=======[ ] -> {B',0,l'} K. Kompella (editor) Expires April 2002 [Page 9] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 5.4. Packet Forwarding All TLS packets from/to the MTU to/from its PE are sent as labeled packets: the entire Ethernet frame (minus preamble and checksum) is encapsulated in an MPLS frame with a single label. This label encodes both the TLS to which the packet belongs, as well as the source (for packets received) or destination (for packets sent). TLS packets from PE to PE are sent as a single label MPLS packet in a PE-PE tunnel. Thus, the packet may be an MPLS packet with a two or more label stack; or it may be MPLS in a GRE or IPSec tunnel, etc. Say an endpoint "behind" MTU U decides to send a TLS T packet to some endpoint "behind" MTU U'. All MTU U knows about MTU U' is that its site ID is p', i.e., to send packets to MTU U', MTU U must use label (A+p') (how it arrives at this is described in the section on learning). The MTU route at PE X states that the label (A+p') is swapped with (K'+p), and the packet is put in tunnel W to PE X'. When PE X' gets the packet, it removes the packet from the tunnel, and sees label (K'+p). PE X' swaps the label with (A'+p) per its MTU route, and sends this packet to MTU U'. Seeing label (A'+p), MTU U' knows that the packet is a TLS T packet which originated at MTU U (i.e., the MTU with site ID p). 6. MTU Operation This section describes the information that an MTU gets from its PE, and how learning and spanning tree computations are done in a TLS. Modified flooding and learning in the case that the MTU-PE labeling is done using VLANs is entirely analogous, and will be detailed in a future version of this document. 6.1. MTU-PE Information Exchange The PE sends the following information to attached MTUs: < < < ...> < ...>> < < ...> < ...>> ... > K. Kompella (editor) Expires April 2002 [Page 10] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 That is, the PE sends its own ID, the MTU's ID (for sanity checking), and a list of TLS IDs. For each TLS, the PE tells the MTU its site ID in the TLS, a list of MTU label ranges, and a list of customer ports in the TLS. (The last list is for the MTU's private consumption, and is optional.) An MTU label range consists of a label base, a site ID offset, the number of sites in the range, and a bit vector of currently active sites. The length of the bit vector in octets is (number of sites in the range)/8. The exact format of this information, and the protocol that is used to transfer this information, as well as a list of status codes sent by the MTU in response will be specified in greater detail in a later version. 6.2. Modified Flooding Flooding is used for example when an MTU wants to send a packet, but doesn't have the packet destination MAC address in its MAC address cache; or when the destination MAC address is a broadcast or multicast address. Such a packet may be received either from a customer port, or from a PE. The MTU must first identify to which TLS the packet belongs. It must then flood this packet, i.e., send a copy of the packet out on multiple ports. If the packet is received on a customer port, the MTU must send a copy out on every other customer port in the TLS, as well as to every other MTU participating in the TLS. If the packet is received from a PE, then the packet must be sent on every customer port; if the TLS is a full mesh, the packet need not be sent to any other PE/MTU. If the TLS is not a full mesh, the MTU must be told to which other PE/MTUs it needs to flood the packet. If an MTU wants to flood a TLS packet to all other MTUs in the TLS, the MTU sends a copy of the packet with each label in the MTU label ranges for that TLS (except of course the label corresponding to the MTU itself) and sends it to the PE. If an MTU has multiple connections to PEs (the same or different), it MUST flood to each PE over each available connection. 6.3. Modified Learning When MTU x receives a packet from one of its PEs, it matches the incoming label with all the MTU label ranges received from the sending PE. (Note: MTU label ranges sent by a PE to an MTU MUST be non-overlapping. However, an MTU label range sent by one PE MAY overlap with an MTU label range sent by another PE. An MTU MUST be able to identify the interface over which a packet arrived, and use K. Kompella (editor) Expires April 2002 [Page 11] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 that information to disambiguate incoming labels.) The incoming label tells MTU x which TLS this packet belongs to, and which MTU it originated at (say x'). If the source MAC address S of the packet is not in the MAC address cache of MTU x, MTU x "learns" S by remembering the site ID of MTU x' (or more simply, by associating S with the incoming label L). If at some future point, MTU x wants to send a packet to destination MAC address S, it looks up its cache, sees that S maps to label L, pushes label L and sends it to its PE. 6.4. Modified Spanning Tree An MTU x will receive multiple copies of a flooded packet with a given source MAC address S from MTU y if either MTU x or MTU y (or both) is multiply connected to PEs; each copy of the packet will be received with a distinct pair. In that case, MTU x must choose which pair it will use to get to MAC address S. This situation corresponds exactly to there being multiple ports connecting two bridges. If the TLS is fully meshed, MTU x can choose on its own which to use to send packets to MAC address S; i.e., MTUs need not run a spanning tree algorithm across the metro or wide area which may be a distinct benefit. If a TLS is not fully meshed, each MTU in the TLS may treat multiple incoming MTU labels for a given MAC address as multiple parallel ports to the same "bridge" (i.e., remote MTU) and use the spanning tree algorithm to pick the active port (i.e., label) to use to reach the MAC address. Finally, MTU may use an IGP (or configuration) to decide which of the multiple incoming MTU labels to use to map a given source MAC address. 6.5. Load Balancing If an MTU is multi-homed (i.e., it has multiple uplinks to one or more PEs), it may decide to load balance across those links. This decision can be made locally by the MTU. The main consideration is to make sure that packets to the same destination use the same path to avoid packet re-ordering. This can be tricky, as broadcast or multicast packets may go to the same destination. A reasonable approach is to use the same uplink for all packets in a given TLS, but to use different uplinks for different TLSs, thus achieving some degree of load balancing. K. Kompella (editor) Expires April 2002 [Page 12] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 7. Security Considerations The security aspects of this solution will be discussed at a later time. 8. IANA Considerations (To be filled in in a later revision.) 9. Acknowledgments Many thanks to Brian Brown, Ian Hood, Vasile Radaoca and the Juniper "ethernet geeks", from whose stimulating discussions this idea was born; and to Yakov Rekhter whose probing questions helped clarify and refine the details. 10. References [IPVPN] Rosen, E., and Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [IPVPNbis] Rosen, E., et al, "BGP/MPLS VPNs", work in progress. [L2VPN] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in progress. 11. Intellectual Property Considerations Juniper Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Juniper Networks, Juniper intends to disclose those patents and license them on reasonable and non-discriminatory terms. K. Kompella (editor) Expires April 2002 [Page 13] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Author Information Yeong-il,Seo Korea Telecom Telecommunication Network Laboratory Member of Technical Staff 463-1 Junmin-dong, Yusung-gu, Taejeon, Korea Tel : +82-42-870-8333 / FAX : +82-42-870-8339 Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Ashwin Moranganti Appian Communications K. Kompella (editor) Expires April 2002 [Page 14] Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001 email: amoranganti@appiancom.com phone: 978 206-7248 Pascal Menezes Terabeam Networks, Inc. 14833 NE 87th St. Redmond, WA, USA phone: (206) 686-2001 email: Pascal.Menezes@Terabeam.com Pierre Lin Yipes Communications, Inc. 114 Sansome St. San Francisco CA 94104 email: pierre.lin@yipes.com Marc Lasserre Riverstone Networks 5200 Great America Parkway Santa Clara CA 95054 marc@riverstonenet.com Loa Andersson Utfors AB Box 525, 169 29 Solna Sweden phone: +46 8 5270 5038 email: loa.andersson@utfors.se Javier Achirica Telefonica Data javier.achirica@telefonica-data.com Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 kireeti@juniper.net K. Kompella (editor) Expires April 2002 [Page 15]