draft-ietf-l2vpn-vpls-bgp-00.txt   draft-ietf-l2vpn-vpls-bgp-01.txt 
Network Working Group K. Kompella (Juniper) Network Working Group K. Kompella (Editor)
Internet Draft Y. Rekhter (Juniper) Internet Draft Y. Rekhter (Editor)
V. Kompella (TiMetra) Category: Standards Track Juniper Networks
Expires: November 2003 J. Achirica (Telefonica) Expires: July 2004 January 2004
draft-ietf-l2vpn-vpls-bgp-00.txt L. Andersson (Utfors) draft-ietf-l2vpn-vpls-bgp-01.txt
G. Heron (PacketExchange)
S. Khandekar (TiMetra)
M. Lasserre (Riverstone)
P. Lin (Yipes)
P. Menezes (Terabeam)
A. Moranganti (Appian)
H. Ould-Brahim (Nortel)
S. Yeong-il (Korea Tel)
Virtual Private LAN Service Virtual Private LAN Service
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
skipping to change at page 2, line 7 skipping to change at page 1, line 34
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful Service, and Virtual Private Switched Network service, is a useful
Service Provider offering. The service offered is a Layer 2 VPN; Service Provider offering. The service offered is a Layer 2 Virtual
however, in the case of VPLS, the customers in the VPN are connected Private Network (VPN); however, in the case of VPLS, the customers in
by a multipoint network, in contrast to the usual Layer 2 VPNs, which the VPN are connected by a multipoint network, in contrast to the
are point-to-point in nature. usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, and This document describes the functions required to offer VPLS, and
proposes a mechanism for signaling a VPLS, as well as for forwarding describes a mechanism for signaling a VPLS, as well as for forwarding
VPLS frames across a packet switched network. VPLS frames across a packet switched network.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC 2119 [1].
The terms P (Provider router, VPN-unaware), PE (Provider Edge
router), VE (VPLS Edge device), CE (Customer Edge device), etc. are
defined in [2].
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS), also known as Transparent LAN Virtual Private LAN Service (VPLS), also known as Transparent LAN
Service, and Virtual Private Switched Network service, is a useful Service, and Virtual Private Switched Network service, is a useful
service offering. A Virtual Private LAN appears in (almost) all service offering. A Virtual Private LAN appears in (almost) all
respects as a LAN to customers of a Service Provider. However, in a respects as a LAN to customers of a Service Provider. However, in a
VPLS, the customers are not all connected to a single LAN; the VPLS, the customers are not all connected to a single LAN; the
customers may be spread across a metro or wide area. In essence, a customers may be spread across a metro or wide area. In essence, a
VPLS glues several individual LANs across a metro area to appear and VPLS glues several individual LANs across a packet-switched network
function as a single LAN [3]. to appear and function as a single LAN [2].
This document describes the functions needed to offer VPLS, and goes This document describes the functions needed to offer VPLS, and goes
on to propose a mechanism for signaling a VPLS, as well as a on to describe a mechanism for signaling a VPLS, as well as a
mechanism for transport of VPLS frames over tunnels across a packet mechanism for transport of VPLS frames over tunnels across a packet
switched network. The signaling mechanism is taken from [4]; BGP is switched network. The signaling mechanism uses BGP as the control
used as the control plane protocol. This document also discusses plane protocol. This document also briefly discusses deployment
deployment options, in particular, the notion of decoupling functions options, in particular, the notion of decoupling functions across
across devices. devices.
Alternative approaches include: [4], which allows one to build a Alternative approaches include: [3], which allows one to build a
Layer 2 VPN with Ethernet as the interconnect; and [5], which allows Layer 2 VPN with Ethernet as the interconnect; and [4], which allows
one to set up an Ethernet connection across a packet switched one to set up an Ethernet connection across a packet-switched
network. Both of these, however, offer point-to-point Ethernet network. Both of these, however, offer point-to-point Ethernet
services. What distinguishes VPLS from the above two is that a VPLS services. What distinguishes VPLS from the above two is that a VPLS
offers a multipoint service. A mechanism for setting up pseudowires offers a multipoint service. A mechanism for setting up pseudowires
for VPLS using LDP is defined in [6]. for VPLS using the Label Distribution Protocol (LDP) is defined in
[5].
1.1. Scope of this Document 1.1. Scope of this Document
This document has four major parts: defining a VPLS functional model; This document has four major parts: defining a VPLS functional model;
defining a control plane for setting up VPLS; defining the data plane defining a control plane for setting up VPLS; defining the data plane
for VPLS (encapsulation and forwarding of data); and defining various for VPLS (encapsulation and forwarding of data); and defining various
deployment scenarios. deployment scenarios.
The functional model underlying VPLS is laid out in section 2. This The functional model underlying VPLS is laid out in section 2. This
describes the service being offered, the network components that describes the service being offered, the network components that
interact to provide the service, and at a high level their interact to provide the service, and at a high level their
interactions. interactions.
The control plane proposed here (section 3) uses BGP to establish The control plane described here (section 3) uses Multiprotocol BGP
VPLS service, i.e., for autodiscovery of VPLS members and for the [6] to establish VPLS service, i.e., for the autodiscovery of VPLS
setup and teardown of the pseudowires that constitute a given VPLS. members and for the setup and teardown of the pseudowires that
Section 3 also describes how a VPLS that spans Autonomous System constitute a given VPLS. Section 3 also describes how a VPLS that
boundaries is set up. Using BGP as the control plane for VPNs is not spans Autonomous System boundaries is set up, as well as how
new (see [4], [7] and [8]): what is described here is identical to multi-homing is handled. Using BGP as the control plane for VPNs is
what is in [4], which itself is based on the mechanisms proposed in not new (see [3], [7] and [8]): what is described here is based on
[7]. the mechanisms proposed in [7].
The forwarding plane and the actions that a participating PE must The forwarding plane and the actions that a participating PE must
take is described in section 4. take is described in section 4.
In section 5, the notion of 'decoupled' operation is defined, and the In section 5, the notion of 'decoupled' operation is defined, and the
interaction of decoupled and non-decoupled PEs is described. interaction of decoupled and non-decoupled PEs is described.
Decoupling allows for more flexible deployment of VPLS. Decoupling allows for more flexible deployment of VPLS.
2. Functional Model 2. Functional Model
skipping to change at page 4, line 32 skipping to change at page 3, line 46
|L2PE|--PE3 / \ / |L2PE|--PE3 / \ /
|----| -------- ------- |----| -------- -------
---- / | ---- ---- / | ----
/ \/ \ / \ CE = Customer Edge Device / \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router | A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ / L2PE = Layer 2 Aggregation \ / \ / L2PE = Layer 2 Aggregation
---- ---- ---- ----
2.1. Terminology 2.1. Terminology
(NOTE: the terminology here has not quite been fully harmonized with Terminology similar to that in [7] is used, with the addition of
the terminology in the VPN terminology document [2] or the PWE3 "L2PE", a Layer 2 PE device used for Layer 2 aggregation. An L2PE is
framework document; this will be done in a later version.) owned and operated by the Service Provider (as is the PE). PE and
L2PE devices are "VPLS-aware", which means that they know that a VPLS
The terminology of [4] is used, with the addition of "L2PE", a Layer service is being offered. We will call these VPLS edge devices,
2 PE device used for Layer 2 aggregation. An L2PE is owned and which could be either a PE or an L2PE, a VE.
operated by the Service Provider (as is the PE). PE and L2PE devices
are "VPLS-aware", which means that they know that a VPLS service is
being offered. We will call these VPLS edge devices, which could be
either a PE or an L2PE, a VE.
In contrast, the CE device (which may be owned and operated by either In contrast, the CE device (which may be owned and operated by either
the SP or the customer) is VPLS-unaware; as far as the CE is the SP or the customer) is VPLS-unaware; as far as the CE is
concerned, it is connected to the other CEs in the VPLS via a Layer 2 concerned, it is connected to the other CEs in the VPLS via a Layer 2
switched network. This means that there should be no changes to a CE switched network. This means that there should be no changes to a CE
device, either to the hardware or the software, in order to offer device, either to the hardware or the software, in order to offer
VPLS. VPLS.
A CE device may be connected to a PE or an L2PE via Layer 2 switches A CE device may be connected to a PE or an L2PE via Layer 2 switches
that are VPLS-unaware. From a VPLS point of view, such Layer 2 that are VPLS-unaware. From a VPLS point of view, such Layer 2
skipping to change at page 5, line 20 skipping to change at page 4, line 31
the ingress PE. In this document, the demultiplexor is an MPLS the ingress PE. In this document, the demultiplexor is an MPLS
label. label.
The term "VPLS" will refer to the service as well as a particular The term "VPLS" will refer to the service as well as a particular
instantiation of the service (i.e., an emulated LAN); it should be instantiation of the service (i.e., an emulated LAN); it should be
clear from the context which usage is intended. clear from the context which usage is intended.
2.2. Assumptions 2.2. Assumptions
The Service Provider Network is a packet switched network. The PEs The Service Provider Network is a packet switched network. The PEs
are assumed to be full meshed with tunnels over which packets that are assumed to be (logically) full-meshed with tunnels over which
belong to a service (such as VPLS) are encapsulated and forwarded. packets that belong to a service (such as VPLS) are encapsulated and
These tunnels can be IP tunnels, such as GRE, or MPLS tunnels, forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS
established by RSVP-TE or LDP. These tunnels are established tunnels, established by RSVP-TE or LDP. These tunnels are
independently of the services offered over them; the signaling and established independently of the services offered over them; the
establishment of these tunnels are not discussed in this document. signaling and establishment of these tunnels are not discussed in
this document.
"Flooding" and MAC address "learning" (see section 4) are an integral "Flooding" and MAC address "learning" (see section 4) are an integral
part of VPLS. However, these activities are private to an SP device, part of VPLS. However, these activities are private to an SP device,
i.e., in the VPLS described below, no SP device requests another SP i.e., in the VPLS described below, no SP device requests another SP
device to flood packets or learn MAC addresses on its behalf. device to flood packets or learn MAC addresses on its behalf.
All the PEs participating in a VPLS are assumed to be fully meshed, All the PEs participating in a VPLS are assumed to be fully meshed,
i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) i.e., every (ingress) PE can send a VPLS packet to the egress PE(s)
directly, without the need for an intermediate PE. This assumption directly, without the need for an intermediate PE (see the section
reduces (but does not eliminate) the need to run Spanning Tree below on "Split Horizon" Flooding). This assumption reduces (but
Protocol among the PEs. does not eliminate) the need to run Spanning Tree Protocol among the
PEs.
2.3. Interactions 2.3. Interactions
VPLS is a successful "LAN Service" if CE devices that belong to VPLS VPLS is a successful "LAN Service" if CE devices that belong to VPLS
V can interact through the SP network as if they were connected by a V can interact through the SP network as if they were connected by a
LAN. VPLS is "private" if CE devices that belong to different VPLSs LAN. VPLS is "private" if CE devices that belong to different VPLSs
cannot interact. VPLS is "virtual" if multiple VPLSs can be offered cannot interact. VPLS is "virtual" if multiple VPLSs can be offered
over a common packet switched network. over a common packet switched network.
PE devices interact to "discover" who all participate in the same PE devices interact to "discover" all the other PEs participating in
VPLS (i.e., are attached to CE devices that belong to the same VPLS), the same VPLS (i.e., that are attached to CE devices that belong to
and to exchange demultiplexors. These interactions are control- the same VPLS), and to exchange demultiplexors. These interactions
driven, not data-driven. are control-driven, not data-driven.
L2PEs interact with PEs to establish connections with remote PEs or L2PEs interact with PEs to establish connections with remote PEs or
L2PEs in the same VPLS. Again, this interaction is control-driven. L2PEs in the same VPLS. Again, this interaction is control-driven.
3. Control Plane 3. Control Plane
There are two primary functions of the VPLS control plane: There are two primary functions of the VPLS control plane:
autodiscovery, and setup and teardown of the pseudowires that autodiscovery, and setup and teardown of the pseudowires that
constitute the VPLS, often called signaling. The first two constitute the VPLS, often called signaling. The first two
subsections describe these functions. The last subsection describes subsections describe these functions. The next subsection describes
the setting up of pseudowires that span Autonomous Systems. the setting up of pseudowires that span Autonomous Systems. The last
subsection details how multi-homing is handled.
3.1. Autodiscovery 3.1. Autodiscovery
Autodiscovery refers to the process of finding all the PEs that Autodiscovery refers to the process of finding all the PEs that
participate in a given VPLS. A PE can either be configured with the participate in a given VPLS. A PE can either be configured with the
identities of all the other PEs in a given VPLS, or the PE can identities of all the other PEs in a given VPLS, or the PE can
autodiscover the other PEs. autodiscover the other PEs.
The former approach is fairly configuration-intensive, especially The former approach is fairly configuration-intensive, especially
since it is required (in this and other VPLS approaches) that the PEs since it is required (in this and other VPLS approaches) that the PEs
participating in a given VPLS are fully meshed (i.e., every pair of participating in a given VPLS are fully meshed (i.e., every pair of
PEs in a given VPLS establish pseudowires to each other). PEs in a given VPLS establish pseudowires to each other).
Furthermore, when the topology of a VPLS changes (i.e., a PE is added Furthermore, when the topology of a VPLS changes (i.e., a PE is added
to, or removed from the VPLS), the VPLS configuration on all PEs in to, or removed from the VPLS), the VPLS configuration on all PEs in
that VPLS must be changed. that VPLS must be changed.
In the autodiscovery approach, each PE "discovers" which other PEs In the autodiscovery approach, each PE "discovers" which other PEs
are part of a given VPLS by means of some protocol. In this are part of a given VPLS by means of some protocol, in this case BGP.
approach, each PE's configuration consists only of the identity of This allows each PE's configuration to consist only of the identity
the VPLS that each customer belongs to, not the identity of every of the VPLS that each customer belongs to, not the identity of every
other PE in that VPLS. Moreover, when the topology of a VPLS other PE in that VPLS. Moreover, when the topology of a VPLS
changes, only the affected PE's configuration changes; other PEs changes, only the affected PE's configuration changes; other PEs
automatically find out about the change and adapt. automatically find out about the change and adapt.
3.1.1. Functions 3.1.1. Functions
A PE that participates in a given VPLS V must be able to tell all A PE that participates in a given VPLS V must be able to tell all
other PEs in VPLS V that it is also a member of V. A PE must also other PEs in VPLS V that it is also a member of V. A PE must also
have a means of declaring that it no longer participates in a VPLS. have a means of declaring that it no longer participates in a VPLS.
To do both of these, the PE must have a means of identifying a VPLS To do both of these, the PE must have a means of identifying a VPLS
and a means by which to communicate to all other PEs. and a means by which to communicate to all other PEs.
L2PE devices also need to know what constitutes a given VPLS; L2PE devices also need to know what constitutes a given VPLS;
however, they don't need the same level of detail. The PE (or PEs) however, they don't need the same level of detail. The PE (or PEs)
to which an L2PE is connected gives the L2PE an abstraction of the to which an L2PE is connected gives the L2PE an abstraction of the
VPLS; this is described in section 5. One protocol mechanism to VPLS; this is described in section 5.
achieve this is described in [9].
3.1.2. Protocol Specification 3.1.2. Protocol Specification
The specific mechanism for autodiscovery described here, borrowed The specific mechanism for autodiscovery described here is based on
essentially unchanged from [4] and [7], uses BGP extended communities [3] and [7]; it uses BGP extended communities [9] to identify members
[10] to identify a VPLS. This mechanism is described more of a VPLS. A more generic autodiscovery mechanism is described in
generically in [8]. The specific extended community used is the [8]. The specific extended community used is the Route Target, whose
Route Target, whose format is described in [10]. The semantics of format is described in [9]. The semantics of the use of Route
the use of Route Targets is described in [7]; their use in VPLS is Targets is described in [7]; their use in VPLS is identical.
identical.
As it has been assumed that VPLSs are fully meshed, a single Route As it has been assumed that VPLSs are fully meshed, a single Route
Target RT suffices for a given VPLS V, and in effect that RT is the Target RT suffices for a given VPLS V, and in effect that RT is the
identifier for VPLS V. identifier for VPLS V.
A PE announces (typically via I-BGP) that it belongs to VPLS V by A PE announces (typically via I-BGP) that it belongs to VPLS V by
annotating its NLRIs for V (see next subsection) with Route Target annotating its NLRIs for V (see next subsection) with Route Target
RT, and acts on this by accepting NLRIs from other PEs that have RT, and acts on this by accepting NLRIs from other PEs that have
Route Target RT. A PE announces that it no longer participates in V Route Target RT. A PE announces that it no longer participates in V
by withdrawing all NLRIs that it had advertised with Route Target RT. by withdrawing all NLRIs that it had advertised with Route Target RT.
skipping to change at page 7, line 44 skipping to change at page 7, line 7
different streams of traffic carried over a tunnel, each stream different streams of traffic carried over a tunnel, each stream
possibly representing a different service. In the case of VPLS, the possibly representing a different service. In the case of VPLS, the
demultiplexor not only says to which specific VPLS a packet belongs, demultiplexor not only says to which specific VPLS a packet belongs,
but also identifies the ingress PE. The former information is used but also identifies the ingress PE. The former information is used
for forwarding the packet; the latter information is used for for forwarding the packet; the latter information is used for
learning MAC addresses. The demultiplexor described here is an MPLS learning MAC addresses. The demultiplexor described here is an MPLS
label, even though the PE-to-PE tunnels may not be MPLS tunnels. label, even though the PE-to-PE tunnels may not be MPLS tunnels.
3.2.1. Setup and Teardown 3.2.1. Setup and Teardown
A BGP NLRI, the VPLS NLRI, is used to exchange demultiplexors, using The VPLS BGP NLRI described below, with a new AFI and SAFI (see [6])
the mechanism described in [4]. is used to exchange demultiplexors.
A PE advertises a VPLS NLRI for each VPLS that it participates in. A PE advertises a VPLS NLRI for each VPLS that it participates in.
If the PE is doing learning and flooding, i.e., it is the VE, it If the PE is doing learning and flooding, i.e., it is the VE, it
announces a single set of VPLS NLRIs for each VPLS that it is in. If announces a single set of VPLS NLRIs for each VPLS that it is in. If
the PE is connected to several L2PEs, it announces one set of VPLS the PE is connected to several L2PEs, it announces one set of VPLS
NLRIs for each L2PE. A hybrid scheme is also possible, where the PE NLRIs for each L2PE. A hybrid scheme is also possible, where the PE
learns MAC addresses on some interfaces (over which it is directly learns MAC addresses on some interfaces (over which it is directly
connected to CEs) and delegates learning on other interfaces (over connected to CEs) and delegates learning on other interfaces (over
which it is connected to L2PEs). In this case, the PE would announce which it is connected to L2PEs). In this case, the PE would announce
one set of VPLS NLRIs for each L2PE that has customer ports in a one set of VPLS NLRIs for each L2PE that has customer ports in a
given VPLS, and one set for itself, if it has customer ports in that given VPLS, and one set for itself, if it has customer ports in that
VPLS. VPLS.
Each set of NLRIs defines the demultiplexors for a range of other PEs Each set of NLRIs defines the demultiplexors for a range of other PEs
in the VPLS. Ideally, a single NLRI suffices for all PEs in a VPLS; in the VPLS. Ideally, a single NLRI suffices to cover all PEs in a
however, there are cases (such as a newly added PE) where the pre- VPLS; however, there are cases (such as a newly added PE) where the
existing NLRI does not have enough labels. In such cases, pre-existing NLRI does not have enough labels. In such cases,
advertising an additional NLRI for the same VPLS serves to add labels advertising an additional NLRI for the same VPLS serves to add labels
for the new PEs without disrupting service to the pre-existing PEs. for the new PEs without disrupting service to the pre-existing PEs.
If service disruption is acceptable (or when the PE restarts its BGP If service disruption is acceptable (or when the PE restarts its BGP
process), a PE MAY consider coalescing all NLRIs for a VPLS into a process), a PE MAY consider coalescing all NLRIs for a VPLS into a
single NLRI. single NLRI.
If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE
Y that includes a demultiplexor that X can use, X sets up its ends of Y that includes a demultiplexor that X can use, X sets up its ends of
a pair of pseudowires between X and Y. X may also have to advertise a pair of pseudowires between X and Y. X may also have to advertise
a new NLRI for V that includes a demultiplexor that Y can use, if its a new NLRI for V that includes a demultiplexor that Y can use, if its
pre-existing NLRI for V did not include a demultiplexor for Y. pre-existing NLRI for V did not include a demultiplexor for Y.
If Y withdraws its NLRI for V that X was using, then X tears down its If Y's configuration is changed to remove it from VPLS V, or all its
links to CEs in V go down, then Y SHOULD withdraw all its NLRIs for
V.
If Y withdraws an NLRI for V that X was using, then X tears down its
ends of the pseudowires between X and Y. ends of the pseudowires between X and Y.
The format of the VPLS NLRI is given below; it is essentially The format of the VPLS NLRI is given below. The AFI and SAFI are the
identical to the L2 VPN NLRI [4]. The AFI and SAFI are the same as same as for the L2 VPN NLRI [3].
for the L2 VPN NLRI.
Figure 2: BGP NLRI for VPLS Information Figure 2: BGP NLRI for VPLS Information
+------------------------------------+ +------------------------------------+
| Length (2 octets) | | Length (2 octets) |
+------------------------------------+ +------------------------------------+
| Route Distinguisher (8 octets) | | Route Distinguisher (8 octets) |
+------------------------------------+ +------------------------------------+
| VE ID (2 octets) | | VE ID (2 octets) |
+------------------------------------+ +------------------------------------+
| Label-block Offset (2 octets) | | VE Block Offset (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Variable TLVs (0 to N octets) | | Label Base (3 octets) |
| ... |
+------------------------------------+ +------------------------------------+
3.2.2. Relearning MAC Addresses 3.2.2. Signaling PE Capabilities
Once a MAC address has been learned by VE A, VE A no longer needs to
flood packets destined to that MAC address; instead VE A can send
those packets directly to the VE "owning" that MAC address, say B.
However, it is possible that a CE "move" from VE B to VE C; one
example scenario is that the CE is dual-homed to VE B and C, and the
link over which the CE is attached to VE B goes down. In this case,
VE B may want to signal to other VEs in the VPLS that MAC addresses
that they learned from VE B (for the given VPLS) are no longer valid.
While aging timers will eventually enforce this, they may often be
too slow. The Relearn Sequence Number (RSN) TLV will help speed up
relearning.
The RSN TLV is an optional TLV with Type TBD, Length 4 and Value a 32
bit RSN, a monotonically increasing unsigned number. When an RSN TLV
is received, the RSN number is compared against the existing one for
that VPLS and PE. If the new number is higher than the previous one,
or no previous RSN exists, the PE SHOULD flush all existing MAC
address to VC bindings for that VPLS and PE.
3.2.3. Signaling PE Capabilities
The Encaps Type and Control Flags are encoded in an extended The Encaps Type and Control Flags are encoded in an extended
attribute, just as in [4]. The community type remains the same. attribute. The community type also is used in L2 VPNs [3].
There is a new Encaps Type for VPLS (TBD). There is a new Encaps Type for VPLS (TBD).
Figure 3: layer2-info extended community Figure 3: layer2-info extended community
+------------------------------------+ +------------------------------------+
| Extended community type (2 octets) | | Extended community type (2 octets) |
+------------------------------------+ +------------------------------------+
| Encaps Type (1 octet) | | Encaps Type (1 octet) |
+------------------------------------+ +------------------------------------+
skipping to change at page 10, line 13 skipping to change at page 9, line 12
that the PE will strip the outermost VLAN from the layer 2 customer that the PE will strip the outermost VLAN from the layer 2 customer
frame on ingress, and push a VLAN on egress. frame on ingress, and push a VLAN on egress.
Figure 4: Control Flags Bit Vector Figure 4: Control Flags Bit Vector
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |P|Q|F|C|S| (MBZ = MUST Be Zero) | MBZ |P|Q|F|C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
3.3. Inter-Provider VPLS 3.3. Multi-AS VPLS
As in [4] and [7], the above autodiscovery and signaling functions As in [3] and [7], the above autodiscovery and signaling functions
are typically announced via I-BGP. This assumes that all the sites are typically announced via I-BGP. This assumes that all the sites
in a VPLS are connected to PEs in a single Autonomous System (AS). in a VPLS are connected to PEs in a single Autonomous System (AS).
However, sites in a VPLS may occasionally connect to PEs in different However, sites in a VPLS may connect to PEs in different ASes. This
ASes. This leads to two issues: a) there would not be an I-BGP leads to two issues: 1) there would not be an I-BGP connection
connection between those PEs, so some means of signaling inter-AS is between those PEs, so some means of signaling across ASes may be
needed; and b) there may not be PE-to-PE tunnels between the ASes. needed; and 2) there may not be PE-to-PE tunnels between the ASes.
The former problem is solved in [7], Section 10. Three methods are A similar problem is solved in [7], Section 10. Three methods are
suggested; of these, the last two Just Work for Inter-Provider VPLS. suggested to address issue (1); all these methods have analogs in
Method (b) requires an I-BGP peering between the PEs in AS1 and ASBR1 multi-AS VPLS.
in AS1, an E-BGP peering between ASBR1 and ASBR2 in AS2, and I-BGP
peerings between ASBR2 and the PEs in AS2. Method (c) requires a
multi-hop E-BGP peering between the PEs (or preferably, a Route
Reflector) in AS1 and the PEs (or Route Reflector) in AS2.
The latter is easy if the PE-to-PE tunnels are IP. If the tunnels Here is a diagram for reference:
are MPLS, labeled IPv4 distribution of PE loopback addresses by ASBRs
(as described in part (c) of Section 10 of [7]) can be used to create __________ ____________ ____________ __________
PE-to-PE MPLS LSPs that traverses the ASes. / \ / \ / \ / \
\___/ AS 1 \ / AS 2 \___/
\ /
+-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+
___ / \ ___
/ \ / \ / \
\__________/ \____________/ \____________/ \__________/
a) VPLS-to-VPLS connections at the AS border routers.
In this method, an AS Border Router (ASBR1) acts as a PE for all
VPLSs that span AS1 and an AS to which ASBR1 is connected, such as
AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by
ASBR1 as a CE for the VPLSs that span AS1 and AS2; similarly,
ASBR2 acts as a PE for this VPLS from AS2's point of view, and
views ASBR1 as a CE.
This method does not require MPLS on the ASBR1-ASBR2 link, but
does require that this link carry Ethernet traffic, and that there
be a separate VLAN sub-interface for each VPLS traversing this
link. It further requires that ASBR1 does the PE operations
(discovery, signaling, MAC address learning, flooding,
encapsulation, etc.) for all VPLSs that traverse ASBR1. This
imposes a significant burden on ASBR1, both on the control plane
and the data plane, which limits the number of multi-AS VPLSs.
Note that in general, there will be multiple connections between a
pair of ASes, for redundancy. In this case, the Spanning Tree
Protocol must be run on each VPLS that spans these ASes, so that a
loop-free topology can be constructed in each VPLS. This imposes
a further burden on the ASBRs and PEs participating in those
VPLSs, as these devices would need to run the Spanning Tree
Protocol for each such VPLS..
b) EBGP redistribution of VPLS information between ASBRs.
This method requires I-BGP peerings between the PEs in AS1 and
ASBR1 in AS1 (perhaps via route reflectors), an E-BGP peering
between ASBR1 and ASBR2 in AS2, and I-BGP peerings between ASBR2
and the PEs in AS2. In the above example, PE1 sends a VPLS NLRI
to ASBR1 with a label block and itself as the BGP nexthop; ASBR1
sends the NLRI to ASBR2 with new labels and itself as the BGP
nexthop; and ASBR2 sends the NLRI to PE2 with new labels and
itself as the nexthop.
The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2
sends to PE2) is identical to the VPLS NLRI that PE1 sends to
ASBR1, except for the label block. To be precise, the Length, the
Route Distinguisher, the VE ID, the VE Block Offset, and the VE
Block Size MUST be the same; the Label Base may be different.
Furthermore, ASBR1 must also update its forwarding path as
follows: if the Label Base sent by PE1 is L1, the Label-block Size
is N, the Label Base sent by ASBR1 is L2, and the tunnel label
from ASBR1 to PE1 is T, then ASBR1 must install the following in
the forwarding path:
swap L2 with L1 and push T,
swap L2+1 with L1+1 and push T,
...
swap L2+N-1 with L1+N-1 and push T.
ASBR2 must act similarly, except that it may not need a tunnel
label if it is directly connected with ASBR1.
When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to
get the right VPLS label from ASBR2's label block for PE1, and
uses a tunnel label to reach ASBR2. ASBR2 swaps the VPLS label
with the label from ASBR1; ASBR1 then swaps the VPLS label with
the label from PE1, and pushes a tunnel label to reach PE1.
In this method, one needs MPLS on the ASBR1-ASBR2 interface, but
there is no requirement that the link layer be Ethernet.
Furthermore, the ASBRs take part in distributing VPLS information.
However, the data plane requirements of the ASBRs is much simpler
than in method (a), being limited to label operations. Finally,
the construction of loop-free VPLS topologies is done by routing
decisions, viz. BGP path and nexthop selection, so there is no
need to run the Spanning Tree Protocol on a per-VPLS basis. Thus,
this method is considerably more scalable than method (a).
c) Multi-hop EBGP redistribution of VPLS information between ASes.
In this method, there is a multi-hop E-BGP peering between the PEs
(or preferably, a Route Reflector) in AS1 and the PEs (or Route
Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop
self to PE2; if this is via route reflectors, the BGP nexthop is
not changed. This requires that there be a tunnel LSP from PE1 to
PE2. This tunnel LSP can be created exactly as in [7], section 10
(c), for example using E-BGP to exchange labeled IPv4 routes for
the PE loopbacks.
When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS
label corresponding to its own VE ID onto the packet. It then
pushes the tunnel label(s) to reach PE2.
This method requires no VPLS information (in either the control or
the data plane) on the ASBRs. The ASBRs only need to set up
PE-to-PE tunnel LSPs in the control plane, and do label operations
in the data plane. Again, as in the case of method (b), the
construction of loop-free VPLS topologies is done by routing
decisions, i.e., BGP path and nexthop selection, so there is no
need to run the Spanning Tree Protocol on a per-VPLS basis. This
option is likely to be the most scalable of the three methods
presented here.
In order to ease the allocation of VE IDs for a VPLS that spans
multiple ASes, one can allocate ranges for each AS. For example, AS1
uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If
there are 10 sites attached to AS1 and 20 to AS2, the allocated VE
IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS
NLRIs that are exchanged while ensuring that VE IDs are kept unique.
In the above example, if AS1 needed more than 100 sites, then another
range can be allocated to AS1. The only caveat is that there is no
overlap between VE ID ranges among ASes. The exception to this rule
is multi-homing, which is dealt with below.
3.4. Multi-homing and Path Selection
It is often desired to multi-home a VPLS site, i.e., to connect it to
multiple PEs, perhaps even in different ASes. In such a case, the
PEs connected to the same site can either be configured with the same
VE ID or with different VE IDs. In the latter case, it is mandatory
to run STP on the CE device, and possibly on the PEs, to construct a
loop-free VPLS topology.
In the case where the PEs connected to the same site are assigned the
same VE ID, a loop-free topology is constructed by routing
mechanisms, in particular, by BGP path selection. When a BGP speaker
receives two equivalent NLRIs (see below for the definition), it
applies standard path selection criteria such as Local Preference and
AS Path Length to determine which NLRI to choose; it MUST pick only
one. If the chosen NLRI is subsequently withdrawn, the BGP speaker
applies path selection to the remaining equivalent VPLS NLRIs to pick
another; if none remain, the forwarding information associated with
that NLRI is removed.
Two VPLS NLRIs are considered equivalent from a path selection point
of view if the Route Distinguisher, the VE ID and the VE Block Offset
are the same. If two PEs are assigned the same VE ID in a given
VPLS, they MUST use the same Route Distinguisher, and they MUST
announce the same VE Block Size for a given VE Offset.
4. Data Plane 4. Data Plane
This section discusses two aspects of the data plane for PEs and This section discusses two aspects of the data plane for PEs and
L2PEs implementing VPLS: encapsulation and forwarding. L2PEs implementing VPLS: encapsulation and forwarding.
4.1. Encapsulation 4.1. Encapsulation
Ethernet frames received from CE devices are encapsulated for Ethernet frames received from CE devices are encapsulated for
transmission over the packet switched network connecting the PEs. transmission over the packet switched network connecting the PEs.
The encapsulation is as in [11], with one change: a PE that sets the The encapsulation is as in [10], with one change: a PE that sets the
P bit in the Control Flags strips the outermost VLAN from an Ethernet P bit in the Control Flags strips the outermost VLAN from an Ethernet
frame received from a CE before encapsulating it, and pushes a VLAN frame received from a CE before encapsulating it, and pushes a VLAN
onto a decapsulated frame before sending it to a CE. onto a decapsulated frame before sending it to a CE.
4.2. Forwarding 4.2. Forwarding
Forwarding of VPLS packets is based on the interface over which the Forwarding of VPLS packets is based on the interface over which the
packet is received, which determines which VPLS the packet belongs packet is received, which determines which VPLS the packet belongs
to, and the destination MAC address. The former mapping is to, and the destination MAC address. The former mapping is
determined by configuration. The latter is the focus of this determined by configuration. The latter is the focus of this
section. section.
4.2.1. MAC address learning 4.2.1. MAC address learning
As was mentioned earlier, the key distinguishing feature of VPLS is As was mentioned earlier, the key distinguishing feature of VPLS is
that it is a multipoint service. This means that the entire Service that it is a multipoint service. This means that the entire Service
Provider network should appear as a single logical learning bridge Provider network should appear as a single logical learning bridge
for each VPLS that the SP network supports. The logical ports for for each VPLS that the SP network supports. The logical ports for
the SP "bridge" are the connections from the SP edge, be it a PE or the SP "bridge" are the connections from the SP edge, be it a PE or
an L2PE, to the CE. Just as a learning bridge learns MAC addresses an L2PE, to the CE. Just as a learning bridge learns MAC addresses
on its ports, the SP bridge must learn MAC addresses at its VEs [3]. on its ports, the SP bridge must learn MAC addresses at its VEs.
Learning consists of associating source MAC addresses of packets with Learning consists of associating source MAC addresses of packets with
the ports on which they arrive; call this association the Forwarding the ports on which they arrive; call this association the Forwarding
Information Base (FIB). The FIB is used for forwarding packets. For Information Base (FIB). The FIB is used for forwarding packets. For
example, suppose the bridge receives a packet with source MAC address example, suppose the bridge receives a packet with source MAC address
S on port P. If subsequently, the bridge receives a packet with S on port P. If subsequently, the bridge receives a packet with
destination MAC address S, it knows that it should send the packet destination MAC address S, it knows that it should send the packet
out on port P. out on port P.
There are two modes of learning: qualified and unqualified learning. There are two modes of learning: qualified and unqualified learning.
skipping to change at page 12, line 27 skipping to change at page 14, line 11
knew which CE "owned" that MAC address). knew which CE "owned" that MAC address).
On the other hand, if PE3 received the frame, it could delegate On the other hand, if PE3 received the frame, it could delegate
further flooding of the frame to its L2PE. If PE3 was connected to 2 further flooding of the frame to its L2PE. If PE3 was connected to 2
L2PEs, it would announce that it has two L2PEs. PE3 could either L2PEs, it would announce that it has two L2PEs. PE3 could either
announce that it is incapable of flooding, in which case it would announce that it is incapable of flooding, in which case it would
receive two frames, one for each L2PE, or it could announce that it receive two frames, one for each L2PE, or it could announce that it
is capable of flooding, in which case it would receive one copy of is capable of flooding, in which case it would receive one copy of
the frame, which it would then send to both L2PEs. the frame, which it would then send to both L2PEs.
4.2.3. "Split Horizon" Flooding
When a PE capable of flooding receives a broadcast Ethernet frame, or
one with an unknown destination MAC address, it must flood the frame.
If the frame arrived from an attached CE, the PE must send a copy of
the frame to every other attached CE, as well as to all PEs
participating in the VPLS. If the frame arrived from another PE,
however, the PE must only send a copy of the packet to attached CEs.
The PE MUST NOT send the frame to other PEs. This notion has been
termed "split horizon" flooding, and is a consequence of the PEs
being logically full-meshed -- if a broadcast frame is received from
PEx, then PEx would have sent a copy to all other PEs.
5. Deployment Scenarios 5. Deployment Scenarios
In deploying a network that supports VPLS, the SP must decide whether In deploying a network that supports VPLS, the SP must decide whether
the VPLS-aware device closest to the customer (the VE) is an L2PE or the VPLS-aware device closest to the customer (the VE) is an L2PE or
a PE. The default case described in this document is that the VE is a PE. The default case described in this document is that the VE is
a PE. However, there are a number of reasons that the VE might be an a PE. However, there are a number of reasons that the VE might be an
L2PE, i.e., a device that does layer 2 functions such as MAC address L2PE, i.e., a device that does layer 2 functions such as MAC address
learning and flooding, and some limited layer 3 functions such as learning and flooding, and some limited layer 3 functions such as
communicating to its PE, but doesn't do full-fledged discovery and communicating to its PE, but doesn't do full-fledged discovery and
PE-to-PE signaling [12]. PE-to-PE signaling.
As both of these cases have benefits, one would like to be able to As both of these cases have benefits, one would like to be able to
"mix and match" these scenarios. The signaling mechanism presented "mix and match" these scenarios. The signaling mechanism presented
here allows this. PE1 may be directly connected to CE devices; PE2 here allows this. PE1 may be directly connected to CE devices; PE2
may be connected to L2PEs that are connected to CEs; and PE3 may be may be connected to L2PEs that are connected to CEs; and PE3 may be
connected directly to a customer over some interfaces and to L2PEs connected directly to a customer over some interfaces and to L2PEs
over others. All these PEs do discovery and signaling in the same over others. All these PEs do discovery and signaling in the same
manner. How they do learning and forwarding depends on whether or manner. How they do learning and forwarding depends on whether or
not there is an L2PE; however, this is a local matter, and is not not there is an L2PE; however, this is a local matter, and is not
signaled. signaled.
6. Normative References 6. Normative References
[ 1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [ 1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
[ 2] Andersson, L. and T. Madsen, "PPVPN Terminology", work in [ 6] Bates, T., Rekhter, Y., Chandra, R., and Katz, D.,
progress. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000
[ 3] Andersson, L. (Editor), "PPVPN L2 Framework", work in progress. [ 7] Rosen, E., and Rekhter, Y., Editors, "BGP/MPLS VPNs", draft-
ietf-l3vpn-rfc2547bis-01.txt, work in progress.
[ 4] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in [ 9] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, work in
progress. progress.
[ 7] Rosen, E., et al, "BGP/MPLS VPNs", work in progress. [10] Martini, L., et al, "Encapsulation Methods for Transport of
Ethernet Frames Over IP/MPLS Networks", draft-ietf-
[10] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities pwe3-ethernet-encap-05.txt, work in progress.
Attribute", (work in progress).
[11] Martini, L., et al, "Encapsulation Methods for Transport of
Layer 2 Frames Over IP and MPLS Networks", work in progress.
[12] Kompella, K., et al, "Decoupled TLS", work in progress. [11] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC 2385, August 1998
7. Informative References 7. Informative References
[ 5] Martini, L., et al, "Transport of Layer 2 Frames Over MPLS", [ 2] Augustyn, W. (Editor), "Requirements for Virtual Private LAN
Services (VPLS)", draft-ietf-l2vpn-vpls-requirements-00.txt,
work in progress. work in progress.
[ 6] Kompella, V., et al, "Virtual Private Switched Network Services [ 3] Kompella, K., (Editor), "Layer 2 VPNs Over Tunnels", draft-
over an MPLS Network", work in progress. kompella-l2vpn-l2vpn-00.txt, work in progress.
[ 4] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP"
draft-ietf-pwe3-control-protocol-05.txt, work in progress.
[ 5] Kompella, V., et al, "Virtual Private LAN Services over MPLS",
draft-ietf-ppvpn-vpls-ldp-01.txt, work in progress.
[ 8] Ould-Brahim, H. et al, "Using BGP as an Auto-Discovery Mechanism [ 8] Ould-Brahim, H. et al, "Using BGP as an Auto-Discovery Mechanism
for Network-based VPNs", work in progress. for Network-based VPNs", work in progress.
[ 9] Shah, H. et al, "Signaling between PE and L2PE/MTU for Decoupled
VPLS and Hierarchical VPLS", work in progress.
Security Considerations Security Considerations
To be filled in in a later version. The focus in Virtual Private LAN Service is the privacy of data,
i.e., that data in a VPLS is only distributed to other nodes in that
IANA Considerations VPLS and not to any external agent or other VPLS. Note that VPLS
does not offer security or authentication: VPLS packets are sent in
To be filled in in a later version. the clear in the packet-switched network, and a man-in-the-middle can
eavesdrop, and may be able to inject packets into the data stream.
Acknowledgments If security is desired, the PE-to-PE tunnels can be IPsec tunnels.
For more security, the end systems in the VPLS sites can use
Thanks to Joe Regan and Alfred Nothaft for their contributions. appropriate means of encryption to secure their data even before it
enters the Service Provider network.
Authors' Addresses
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 There are two aspects to achieving data privacy in a VPLS: securing
Nortel Networks the control plane, and protecting the forwarding path. Compromise of
P O Box 3511 Station C the control plane could result in a PE sending data belonging to some
Ottawa ON K1Y 4H7 Canada VPLS to another VPLS, or blackholing VPLS data, or even sending it to
Phone: +1 (613) 765 3418 an eavesdropper, none of which are acceptable from a data privacy
Email: hbrahim@nortelnetworks.com point of view. Since all control plane exchanges are via BGP,
techniques such as in [11] help authenticate BGP messages, making it
harder to spoof updates (which can be used to divert VPLS traffic to
the wrong VPLS), or withdraws (denial of service attacks). In the
multi-AS options (b) and (c), this also means protecting the inter-AS
BGP sessions, between the ASBRs, the PEs or the Route Reflectors.
Note that [11] will not help in keeping VPLS labels private --
knowing the labels, one can eavesdrop on VPLS traffic. However, this
requires access to the data path within a Service Provider network.
Ashwin Moranganti Protecting the data plane requires ensuring that PE-to-PE tunnels are
Appian Communications well-behaved (this is outside the scope of this document), and that
email: amoranganti@appiancom.com VPLS labels are accepted only from valid interfaces. For a PE, valid
phone: 978 206-7248 interfaces comprise links from P routers. For an ASBR, a valid
interface is a link from an ASBR in an AS that is part of a given
VPLS. It is especially important in the case of multi-AS VPLSs that
one accept VPLS packets only from valid interfaces.
Pascal Menezes IANA Considerations
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
phone: (206) 686-2001
email: Pascal.Menezes@Terabeam.com
Pierre Lin IANA is asked to allocate an AFI for Layer 2 information (suggested
Yipes Communications, Inc. value: 25). IANA is also asked to register a SAFI for VPLS of 65
114 Sansome St. from the First-Come-First-Served space for SAFIs.
San Francisco CA 94104
email: pierre.lin@yipes.com
Marc Lasserre Contributors
Riverstone Networks
5200 Great America Parkway
Santa Clara CA 95054
marc@riverstonenet.com
Sunil Khandekar The following contributed to this document:
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Giles Heron Javier Achirica, Telefonica
PacketExchange Ltd. Loa Andersson, TLA
The Truman Brewery Chaitanya Kodeboyina, Juniper
91 Brick Lane Giles Heron, Consultant
LONDON E1 6QL Sunil Khandekar, Alcatel
United Kingdom Vach Kompella, Alcatel
Email: giles@packetexchange.net Marc Lasserre, Riverstone
Pierre Lin, Yipes
Pascal Menezes, Terabeam
Ashwin Moranganti, Appian
Hamid Ould-Brahim, Nortel
Seo Yeong-il, Korea Tel
Loa Andersson Acknowledgments
Utfors AB
Box 525, 169 29 Solna
Sweden
phone: +46 8 5270 5038
email: loa.andersson@utfors.se
Javier Achirica Thanks to Joe Regan and Alfred Nothaft for their contributions.
Telefonica Data
javier.achirica@telefonica-data.com
Vach Kompella Authors' Addresses
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: vkompella@timetra.com
Yakov Rekhter Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
yakov@juniper.net kireeti@juniper.net
Kireeti Kompella Yakov Rekhter
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
kireeti@juniper.net yakov@juniper.net
IPR Notice IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 16, line 30 skipping to change at page 18, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this 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
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
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 assignees.
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."
Acknowledgement Acknowledgement
 End of changes. 

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