draft-ietf-l2vpn-vpls-ldp-01.txt   draft-ietf-l2vpn-vpls-ldp-02.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
Provider Provisioned VPN Working Group Riverstone Networks Provider Provisioned VPN Working Group Vach Kompella
draft-ietf-ppvpn-vpls-ldp-01.txt Vach Kompella (Editors)
Nick Tingle draft-ietf-l2vpn-vpls-ldp-02.txt
Sunil Khandekar Expires: October 2004 April 2004
Timetra Networks
Ali Sajassi
Cisco Systems
Pascal Menezes Loa Andersson
Terabeam Networks Consultant
Andrew Smith Pierre Lin
Consultant Yipes Communication
Juha Heinanen Giles Heron
Song Networks PacketExchange Ltd.
Ron Haberman Tom S.C. Soon
Masergy, Inc. Yetik Serbest
Eric Puetz
Nick Slabakov SBC Communications
Rob Nath
Riverstone Networks
Luca Martini
Vasile Radoaca Level 3
Nortel Networks Communications
Expires: May 2004 November 2003
Virtual Private LAN Services over MPLS Virtual Private LAN Services over MPLS
draft-ietf-ppvpn-vpls-ldp-01.txt draft-ietf-l2vpn-vpls-ldp-02.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 8 skipping to change at page 2, line 36
JUSTIFICATION JUSTIFICATION
Existing Internet drafts specify how to provide point-to-point Existing Internet drafts specify how to provide point-to-point
Ethernet L2 VPN services over MPLS. This draft defines how Ethernet L2 VPN services over MPLS. This draft defines how
multipoint Ethernet services can be provided. multipoint Ethernet services can be provided.
Table of Contents Table of Contents
1. Status of this Memo.............................................1 1. Status of this Memo.............................................1
2. Abstract........................................................2 2. Abstract........................................................1
3. Conventions.....................................................2 3. Conventions.....................................................1
4. Overview........................................................4 4. Overview........................................................3
5. Topological Model for VPLS......................................5 5. Topological Model for VPLS......................................4
5.1. Flooding and Forwarding.......................................5 5.1. Flooding and Forwarding.......................................5
5.2. Address Learning..............................................6 5.2. Address Learning..............................................5
5.3. LSP Topology..................................................6 5.3. Tunnel Topology...............................................6
5.4. Loop free L2 VPN..............................................7 5.4. Loop free L2 VPN..............................................6
6. Discovery.......................................................7 6. Discovery.......................................................7
7. Control Plane...................................................7 7. Control Plane...................................................7
7.1. LDP Based Signaling of Demultiplexors.........................7 7.1. LDP Based Signaling of Demultiplexors.........................7
7.2. MAC Address Withdrawal........................................9 7.2. MAC Address Withdrawal........................................8
7.2.1. MAC TLV.....................................................9 7.2.1. MAC TLV.....................................................8
7.2.2. Address Withdraw Message Containing MAC TLV................10 7.2.2. Address Withdraw Message Containing MAC TLV.................9
8. Data Forwarding on an Ethernet VC Type.........................11 8. Data Forwarding on an Ethernet VC Type.........................10
8.1. VPLS Encapsulation actions...................................11 8.1. VPLS Encapsulation actions...................................10
8.1.1. VPLS Learning actions......................................12 8.1.1. VPLS Learning actions......................................11
9. Operation of a VPLS............................................13 9. Operation of a VPLS............................................12
9.1. MAC Address Aging............................................13 9.1. MAC Address Aging............................................13
10. A Hierarchical VPLS Model.....................................14 10. A Hierarchical VPLS Model.....................................13
10.1. Hierarchical connectivity...................................14 10.1. Hierarchical connectivity...................................14
10.1.1. Spoke connectivity for bridging-capable devices...........15 10.1.1. Spoke connectivity for bridging-capable devices...........14
10.1.2. Advantages of spoke connectivity..........................16 10.1.2. Advantages of spoke connectivity..........................16
10.1.3. Spoke connectivity for non-bridging devices...............17 10.1.3. Spoke connectivity for non-bridging devices...............16
10.2. Redundant Spoke Connections.................................18 10.2. Redundant Spoke Connections.................................18
10.2.1. Dual-homed MTU device.....................................18 10.2.1. Dual-homed MTU device.....................................18
10.2.2. Failure detection and recovery............................19 10.2.2. Failure detection and recovery............................19
10.3. Multi-domain VPLS service...................................20 10.3. Multi-domain VPLS service...................................19
11. Hierarchical VPLS model using Ethernet Access Network.........20 11. Hierarchical VPLS model using Ethernet Access Network.........20
11.1. Scalability.................................................21 11.1. Scalability.................................................21
11.2. Dual Homing and Failure Recovery............................22 11.2. Dual Homing and Failure Recovery............................21
12. Significant Modifications.....................................22 12. Significant Modifications.....................................22
13. Acknowledgments...............................................22 13. Contributors..................................................22
14. Security Considerations.......................................22 14. Acknowledgments...............................................22
15. Intellectual Property Considerations..........................22 15. Security Considerations.......................................22
16. Full Copyright Statement......................................23 16. Intellectual Property Considerations..........................23
17. References....................................................23 17. Full Copyright Statement......................................23
18. Authors' Addresses............................................24 18. References....................................................23
19. Authors' Addresses............................................24
4. Overview 4. Overview
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area
Networks (LANs) connectivity and is gaining acceptance as an access Networks (LANs) connectivity and is gaining acceptance as an access
technology, specifically in Metropolitan and Wide Area Networks (MAN technology, specifically in Metropolitan and Wide Area Networks (MAN
and WAN respectively). An Ethernet port is used to connect a and WAN respectively). An Ethernet port is used to connect a
customer to the Provider Edge (PE) router acting as an LER. Customer customer to the Provider Edge (PE) router acting as an LER. Customer
traffic is subsequently mapped to a specific MPLS L2 VPN by traffic is subsequently mapped to a specific MPLS L2 VPN by
configuring L2 FECs based upon the input port ID and/or VLAN tag configuring L2 FECs based upon the input port ID and/or VLAN tag
depending upon the VPLS service. depending upon the VPLS service.
skipping to change at page 4, line 30 skipping to change at page 4, line 8
learning/aging on a per LSP basis, packet replication across LSPs learning/aging on a per LSP basis, packet replication across LSPs
for multicast/broadcast traffic and for flooding of unknown unicast for multicast/broadcast traffic and for flooding of unknown unicast
destination traffic. destination traffic.
The primary motivation behind Virtual Private LAN Services (VPLS) is The primary motivation behind Virtual Private LAN Services (VPLS) is
to provide connectivity between geographically dispersed customer to provide connectivity between geographically dispersed customer
sites across MAN/WAN network(s), as if they were connected using a sites across MAN/WAN network(s), as if they were connected using a
LAN. The intended application for the end-user can be divided into LAN. The intended application for the end-user can be divided into
the following two categories: the following two categories:
- Connectivity between customer routers LAN routing application - Connectivity between customer routers LAN routing application
- Connectivity between customer Ethernet switches LAN switching - Connectivity between customer Ethernet switches LAN switching
application application
[PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point [PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point
MPLS LSPs, called pseudowires (PW). Such PWs can be carried over MPLS LSPs, called pseudowires (PW). Such PWs can be carried over
MPLS or GRE tunnels. This document describes extensions to [PWE3- MPLS or GRE tunnels. This document describes extensions to [PWE3-
CTRL] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic CTRL] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic
across multiple sites that belong to the same L2 broadcast domain or across multiple sites that belong to the same L2 broadcast domain or
VPLS. Note that the same model can be applied to other 802.1 VPLS. Note that the same model can be applied to other 802.1
technologies. It describes a simple and scalable way to offer technologies. It describes a simple and scalable way to offer
Virtual LAN services, including the appropriate flooding of Virtual LAN services, including the appropriate flooding of
skipping to change at page 17, line 4 skipping to change at page 16, line 39
10.1.2. Advantages of spoke connectivity 10.1.2. Advantages of spoke connectivity
Spoke connectivity offers several scaling and operational advantages Spoke connectivity offers several scaling and operational advantages
for creating large scale VPLS implementations, while retaining the for creating large scale VPLS implementations, while retaining the
ability to offer all the functionality of the VPLS service. ability to offer all the functionality of the VPLS service.
- Eliminates the need for a full mesh of tunnels and full mesh of - Eliminates the need for a full mesh of tunnels and full mesh of
pseudowires per service between all devices participating in the pseudowires per service between all devices participating in the
VPLS service. VPLS service.
- Minimizes signaling overhead since fewer pseudowires are required - Minimizes signaling overhead since fewer pseudowires are required
for the VPLS service. for the VPLS service.
- Segments VPLS nodal discovery. MTU-s needs to be aware of only - Segments VPLS nodal discovery. MTU-s needs to be aware of only
the PE-rs node although it is participating in the VPLS service the PE-rs node although it is participating in the VPLS service
that spans multiple devices. On the other hand, every VPLS PE-rs that spans multiple devices. On the other hand, every VPLS PE-rs
must be aware of every other VPLS PE-rs device and all of its must be aware of every other VPLS PE-rs device and all of its
locally connected MTU-s and PE-r. locally connected MTU-s and PE-r.
- Addition of other sites requires configuration of the new MTU-s - Addition of other sites requires configuration of the new MTU-s
device but does not require any provisioning of the existing MTU-s device but does not require any provisioning of the existing MTU-s
devices on that service. devices on that service.
- Hierarchical connections can be used to create VPLS service that - Hierarchical connections can be used to create VPLS service that
spans multiple service provider domains. This is explained in a spans multiple service provider domains. This is explained in a
later section. later section.
10.1.3. Spoke connectivity for non-bridging devices 10.1.3. Spoke connectivity for non-bridging devices
In some cases, a bridging PE-rs device may not be deployed in a CO In some cases, a bridging PE-rs device may not be deployed in a CO
or a multi-tenant building while a PE-r might already be deployed. or a multi-tenant building while a PE-r might already be deployed.
If there is a need to provide VPLS service from the CO where the PE- If there is a need to provide VPLS service from the CO where the PE-
rs device is not available, the service provider may prefer to use rs device is not available, the service provider may prefer to use
the PE-r device in the interim. In this section, we explain how a the PE-r device in the interim. In this section, we explain how a
PE-r device that does not support any of the VPLS bridging PE-r device that does not support any of the VPLS bridging
functionality can participate in the VPLS service. functionality can participate in the VPLS service.
As shown in this figure, the PE-r device creates a point-to-point As shown in this figure, the PE-r device creates a point-to-point
tunnel LSP to a PE-rs device. Then for every access port that needs tunnel LSP to a PE-rs device. Then for every access port that needs
skipping to change at page 20, line 20 skipping to change at page 19, line 52
secondary pseudowire got activated may send out a flush message, secondary pseudowire got activated may send out a flush message,
using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon
receiving the message, PE-rs nodes flush the MAC addresses receiving the message, PE-rs nodes flush the MAC addresses
associated with that VPLS instance. associated with that VPLS instance.
10.3. Multi-domain VPLS service 10.3. Multi-domain VPLS service
Hierarchy can also be used to create a large scale VPLS service Hierarchy can also be used to create a large scale VPLS service
within a single domain or a service that spans multiple domains within a single domain or a service that spans multiple domains
without requiring full mesh connectivity between all VPLS capable without requiring full mesh connectivity between all VPLS capable
devices. Two fully meshed VPLS networks are connected together devices. Two fully meshed VPLS networks are connected together using
using a single LSP tunnel between the VPLS gateway devices. A a single LSP tunnel between the VPLS border devices. A single
single spoke pseudowire is setup per VPLS service to connect the two spoke pseudowire per VPLS service is set up to connect the two
domains together. The VPLS gateway device joins two VPLS services domains together.
together to form a single multi-domain VPLS service. The
requirements and functionality required from a VPLS gateway device When more than two domains need to be connected, a full mesh of
will be explained in a future version of this document. inter-domain spokes is created between border PEs. Forwarding rules
over this mesh are identical to the rules defined in section 5.
This creates a three-tier hierarchical model that consists of a hub-
and-spoke topology between MTU-s and PE-rs devices, a full-mesh
topology between PE-rs, and a full mesh of inter-domain spokes
between border PE-rs devices.
11. Hierarchical VPLS model using Ethernet Access Network 11. Hierarchical VPLS model using Ethernet Access Network
In the previous section, a two-tier hierarchical model that consists In this section the hierarchical model is expanded to include an
of hub-and-spoke topology between MTU-s devices and PE-rs devices and
a full-mesh topology among PE-rs devices was discussed. In this
section the two-tier hierarchical model is expanded to include an
Ethernet access network. This model retains the hierarchical Ethernet access network. This model retains the hierarchical
architecture discussed previously in that it leverages the full-mesh architecture discussed previously in that it leverages the full-mesh
topology among PE-rs devices; however, no restriction is imposed on topology among PE-rs devices; however, no restriction is imposed on
the topology of the Ethernet access network (e.g., the topology the topology of the Ethernet access network (e.g., the topology
between MTU-s and PE-rs devices are not restricted to hub and spoke). between MTU-s and PE-rs devices are not restricted to hub and spoke).
The motivation for an Ethernet access network is that Ethernet-based The motivation for an Ethernet access network is that Ethernet-based
networks are currently deployed by some service providers to offer networks are currently deployed by some service providers to offer
VPLS services to their customers. Therefore, it is important to VPLS services to their customers. Therefore, it is important to
provide a mechanism that allows these networks to integrate with an provide a mechanism that allows these networks to integrate with an
skipping to change at page 21, line 28 skipping to change at page 21, line 11
that corresponds to a VPLS instance would look just like a P-VLAN to that corresponds to a VPLS instance would look just like a P-VLAN to
the bridge portion of the PE-rs and that is why sometimes it is the bridge portion of the PE-rs and that is why sometimes it is
referred to as Emulated VLAN. In this model the PE-rs may need to run referred to as Emulated VLAN. In this model the PE-rs may need to run
STP protocol in addition to split-horizon. Split horizon is run over STP protocol in addition to split-horizon. Split horizon is run over
MPLS-core; whereas, STP is run over the access network to accommodate MPLS-core; whereas, STP is run over the access network to accommodate
any arbitrary access topology. In this model, the PE-rs needs to map any arbitrary access topology. In this model, the PE-rs needs to map
a P-VLAN to a VPLS-instance and its associated pseudowires and vise a P-VLAN to a VPLS-instance and its associated pseudowires and vise
versa. versa.
The details regarding bridge operation for MTU-s and PE-rs (e.g., The details regarding bridge operation for MTU-s and PE-rs (e.g.,
encapsulation format for QinQ messages, customers Ethernet control encapsulation format for QinQ messages, customers Ethernet control
protocol handling, etc.) are outside of the scope of this document protocol handling, etc.) are outside of the scope of this document
and they are covered in [802.1ad]. However, the relevant part is the and they are covered in [802.1ad]. However, the relevant part is the
interaction between the bridge module and the MPLS/IP pseudowires in interaction between the bridge module and the MPLS/IP pseudowires in
the PE-rs device. the PE-rs device.
11.1. Scalability 11.1. Scalability
Given that each P-VLAN corresponds to a VPLS instance, one may think Given that each P-VLAN corresponds to a VPLS instance, one may think
that the total number of VPLS instances supported is limited to 4K. that the total number of VPLS instances supported is limited to 4K.
However, the 4K limit applies only to each Ethernet access network However, the 4K limit applies only to each Ethernet access network
skipping to change at page 22, line 22 skipping to change at page 22, line 7
more than one PE-rs, then a dedicated full-mesh of pseudowires is more than one PE-rs, then a dedicated full-mesh of pseudowires is
used among these PE-rs devices for carrying the SP BPDU packets for used among these PE-rs devices for carrying the SP BPDU packets for
that island. On a per P-VLAN basis, the MSTP will designate a single that island. On a per P-VLAN basis, the MSTP will designate a single
PE-rs to be used for carrying the traffic across the core. The loop- PE-rs to be used for carrying the traffic across the core. The loop-
free protection through the core is performed using split-horizon and free protection through the core is performed using split-horizon and
the failure protection in the core is performed through standard the failure protection in the core is performed through standard
IP/MPLS re-routing. IP/MPLS re-routing.
12. Significant Modifications 12. Significant Modifications
Between rev 00 and this one, these are the changes: Between rev 01 and this one, these are the changes:
o minor revisions of text o Addition of details for inter-domain connectivity
o briefly explains qualified learning and STP interaction o Addition of details to security section
13. Acknowledgments 13. Contributors
Loa Andersson, TLA
Ron Haberman, Masergy
Juha Heinanen, Song
Giles Heron, Packet Exchange
Sunil Khandekar, Alcatel
Luca Martini, Cisco
Pascal Menezes, Terabeam
Rob Nath, Riverstone
Eric Puetz, SBC
Vasile Radoaca, Nortel
Ali Sajassi, Cisco
Yetik Serbest, SBC
Nick Slabakov, Riverstone
Andrew Smith, Consultant
Tom Soon, SBC
Nick Tingle, Alcatel
14. Acknowledgments
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt
Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for
their valuable feedback. In addition, we would like to thank Rajiv their valuable feedback. In addition, we would like to thank Rajiv
Papneja (ISOCORE), Winston Liu (ISOCORE), and Charlie Hundall Papneja (ISOCORE), Winston Liu (ISOCORE), and Charlie Hundall
(Extreme) for identifying issues with the draft in the course of the (Extreme) for identifying issues with the draft in the course of the
interoperability tests. interoperability tests.
14. Security Considerations 15. Security Considerations
Security issues resulting from this draft will be discussed in . Data plane aspects
greater depth at a later point. It is recommended in [RFC3036] that o Traffic isolation between VPLS domains is guaranteed by
LDP security (authentication) methods be applied. This would the use of per VPLS L2 FIB table and the use of per VPLS
prevent unauthorized participation by a PE in a VPLS. Traffic pseudowires
separation for a VPLS is effected by using VC labels. However, for o The customer traffic, which consists of Ethernet frames,
additional levels of security, the customer MAY deploy end-to-end is carried unchanged over VPLS. If security is required,
security, which is out of the scope of this draft. In addition, the the customer traffic should be encrypted before entering
L2FRAME] document describes security issues in greater depth. the service provider network
o Preventing broadcast storms can be achieved by using
routers as CPE devices or by rate policing the amount of
broadcast traffic that customers can send.
. Control plane aspects
o It is recommended in [RFC3036] that LDP security
(authentication) methods be applied. This would prevent
unauthorized participation by a PE in a VPLS
o
. Denial of service attacks
o Means to limit the number of MAC addresses (per site per
VPLS) that a PE can learn should be available.
15. Intellectual Property Considerations 16. Intellectual Property Considerations
This document is being submitted for use in IETF standards This document is being submitted for use in IETF standards
discussions. discussions.
16. Full Copyright Statement 17. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
skipping to change at page 23, line 32 skipping to change at page 23, line 44
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
17. References 18. References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
02.txt, Work in progress, February 2003. 02.txt, Work in progress, February 2003.
[PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf- [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-
pwe3-control-protocol-02.txt, Work in progress, February 2003. pwe3-control-protocol-02.txt, Work in progress, February 2003.
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993 "MAC Bridges". 1993 "MAC Bridges".
skipping to change at page 24, line 39 skipping to change at page 24, line 50
[L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work [L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work
in Progress, February 2003. in Progress, February 2003.
[L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements- Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements-
00.txt, Work in Progress, May 2003. 00.txt, Work in Progress, May 2003.
[802.1ad] "IEEE standard for Provider Bridges", Work in Progress, [802.1ad] "IEEE standard for Provider Bridges", Work in Progress,
December 2002. December 2002.
18. Authors' Addresses 19. Authors' Addresses
Marc Lasserre Marc Lasserre
Riverstone Networks Riverstone Networks
Email: marc@riverstonenet.com Email: marc@riverstonenet.com
Vach Kompella Vach Kompella
TiMetra Networks Alcatel
274 Ferguson Dr.
Mountain View, CA 94043
Email: vkompella@timetra.com
Sunil Khandekar
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: sunil@timetra.com
Nick Tingle
TiMetra Networks
274 Ferguson Dr. 274 Ferguson Dr.
Mountain View, CA 94043 Mountain View, CA 94043
Email: nick@timetra.com Email: vach.kompella@alcatel.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Loa Andersson
Email: loa@pi.se
Pascal Menezes
Email: pascalm1@yahoo.com
Andrew Smith
Email: ah_smith@pacbell.net
Giles Heron
PacketExchange Ltd.
Email: giles@packetexchange.net
Juha Heinanen
TutPro
Email: jh@tutpro.com
Tom S. C. Soon
SBC Technology Resources Inc.
Email: sxsoon@tri.sbc.com
Yetik Serbest
SBC Communications
serbest@tri.sbc.com
Eric Puetz
SBC Communications
puetz@tri.sbc.com
Ron Haberman
Masergy Inc.
Email: ronh@masergy.com
Luca Martini
Level 3 Communications, LLC.
Email: luca@level3.net
Rob Nath
Riverstone Networks
Email: rnath@riverstonenet.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/