draft-ietf-l2vpn-vpls-bgp-01.txt   draft-ietf-l2vpn-vpls-bgp-02.txt 
Network Working Group K. Kompella (Editor) Network Working Group K. Kompella (Editor)
Internet Draft Y. Rekhter (Editor) Internet Draft Y. Rekhter (Editor)
Category: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: July 2004 January 2004 Expires: November 2004 May 2004
draft-ietf-l2vpn-vpls-bgp-01.txt draft-ietf-l2vpn-vpls-bgp-02.txt
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 44 skipping to change at page 2, line 44
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 the Label Distribution Protocol (LDP) is defined in for VPLS using the Label Distribution Protocol (LDP) is defined in
[5]. [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 options.
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 described here (section 3) uses Multiprotocol BGP The control plane described in this document uses Multiprotocol BGP
[6] to establish VPLS service, i.e., for the autodiscovery of VPLS [6] to establish VPLS service, i.e., for the autodiscovery of VPLS
members and for the setup and teardown of the pseudowires that members and for the setup and teardown of the pseudowires that
constitute a given VPLS. Section 3 also describes how a VPLS that constitute a given VPLS. Section 3 also describes how a VPLS that
spans Autonomous System boundaries is set up, as well as how spans Autonomous System boundaries is set up, as well as how
multi-homing is handled. Using BGP as the control plane for VPNs is multi-homing is handled. Using BGP as the control plane for VPNs is
not new (see [3], [7] and [8]): what is described here is based on not new (see [3], [7] and [8]): what is described here is based on
the mechanisms proposed in [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.
skipping to change at page 3, line 36 skipping to change at page 3, line 36
---- ____CE1 | ---- ____CE1 |
/ \ -------- -------- / | | / \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ ----- \ / \ / \___/ | \ -----
---- ---PE2 | \ ---- ---PE2 | \
| | \ ----- | | \ -----
| Service Provider Network | \ / \ | Service Provider Network | \ / \
| | CE5 A5 | | | CE5 A5 |
| ___ | / \ / | ___ | / \ /
|----| \ / \ PE4_/ ----- |----| \ / \ PE4_/ -----
|L2PE|--PE3 / \ / |u-PE|--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 \ / \ / u-PE = Layer 2 Aggregation
---- ---- ---- ---- A<n> = Customer site n
2.1. Terminology 2.1. Terminology
Terminology similar to that in [7] is used, with the addition of Terminology similar to that in [7] is used, with the addition of "u-
"L2PE", a Layer 2 PE device used for Layer 2 aggregation. An L2PE is PE", a Layer 2 PE device used for Layer 2 aggregation. A u-PE is
owned and operated by the Service Provider (as is the PE). PE and owned and operated by the Service Provider (as is the PE). PE and u-
L2PE devices are "VPLS-aware", which means that they know that a VPLS PE devices are "VPLS-aware", which means that they know that a VPLS
service is being offered. We will call these VPLS edge devices, service is being offered. We will call these VPLS edge devices,
which could be either a PE or an L2PE, a VE. which could be either a PE or an u-PE, 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 a u-PE 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
switches are invisible, and hence will not be discussed further. switches are invisible, and hence will not be discussed further.
Furthermore, an L2PE may be connected to a PE via Layer 2 and Layer 3 Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3
devices; this will be discussed further in a later section. devices; this will be discussed further in a later section.
The term "demultiplexor" refers to an identifier in a data packet The term "demultiplexor" refers to an identifier in a data packet
that identifies both the VPLS to which the packet belongs as well as that identifies both the VPLS to which the packet belongs as well as
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.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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" all the other PEs participating in PE devices interact to "discover" all the other PEs participating in
the same VPLS (i.e., that are attached to CE devices that belong to the same VPLS (i.e., that are attached to CE devices that belong to
the same VPLS), and to exchange demultiplexors. These interactions the same VPLS), and to exchange demultiplexors. These interactions
are control-driven, not data-driven. are control-driven, not data-driven.
L2PEs interact with PEs to establish connections with remote PEs or U-PEs interact with PEs to establish connections with remote PEs or
L2PEs in the same VPLS. Again, this interaction is control-driven. u-PEs 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 next subsection describes subsections describe these functions. The next subsection describes
the setting up of pseudowires that span Autonomous Systems. The last the setting up of pseudowires that span Autonomous Systems. The last
subsection details how multi-homing is handled. subsection details how multi-homing is handled.
3.1. Autodiscovery 3.1. Autodiscovery
Autodiscovery refers to the process of finding all the PEs that Discovery 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 use
autodiscover the other PEs. some protocol to discover the other PEs. The latter is called
autodiscovery.
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
skipping to change at page 6, line 13 skipping to change at page 6, line 14
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; U-PE 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 a u-PE is connected gives the u-PE an abstraction of the
VPLS; this is described in section 5. VPLS; this is described in section 5.
3.1.2. Protocol Specification 3.1.2. Protocol Specification
The specific mechanism for autodiscovery described here is based on The specific mechanism for autodiscovery described here is based on
[3] and [7]; it uses BGP extended communities [9] to identify members [3] and [7]; it uses BGP extended communities [9] to identify members
of a VPLS. A more generic autodiscovery mechanism is described in of a VPLS. A more generic autodiscovery mechanism is described in
[8]. The specific extended community used is the Route Target, whose [8]. The specific extended community used is the Route Target, whose
format is described in [9]. The semantics of the use of Route format is described in [9]. The semantics of the use of Route
Targets is described in [7]; their use in VPLS is identical. Targets is described in [7]; their use in VPLS is identical.
skipping to change at page 7, line 13 skipping to change at page 7, line 15
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
The VPLS BGP NLRI described below, with a new AFI and SAFI (see [6]) The VPLS BGP NLRI described below, with a new AFI and SAFI (see [6])
is used to exchange demultiplexors. 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 u-PEs, it announces one set of VPLS
NLRIs for each L2PE. A hybrid scheme is also possible, where the PE NLRIs for each u-PE. 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 u-PEs). 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 u-PE 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 to cover all PEs in a in the VPLS. Ideally, a single NLRI suffices to cover all PEs in a
VPLS; however, there are cases (such as a newly added PE) where the VPLS; however, there are cases (such as a newly added PE) where the
pre-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's configuration is changed to remove it from VPLS V, or all its If Y's configuration is changed to remove it from VPLS V, then Y MUST
links to CEs in V go down, then Y SHOULD withdraw all its NLRIs for withdraw all its NLRIs for V. If all Y's links to CEs in V go down,
V. then Y SHOULD either withdraw all its NLRIs for V, or let other PEs
in the VPLS V know in some way that Y is no longer connected to its
CEs.
If Y withdraws an NLRI for V that X was using, then X tears down its If Y withdraws an NLRI for V that X was using, then X MUST tear down
ends of the pseudowires between X and Y. its ends of the pseudowires between X and Y.
The format of the VPLS NLRI is given below. The AFI and SAFI are the The format of the VPLS NLRI is given below. The AFI and SAFI are the
same as for the L2 VPN NLRI [3]. same as for the L2 VPN NLRI [3].
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) |
skipping to change at page 8, line 26 skipping to change at page 8, line 26
| VE Block Size (2 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | Label Base (3 octets) |
+------------------------------------+ +------------------------------------+
3.2.2. Signaling PE Capabilities 3.2.2. 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. The community type also is used in L2 VPNs [3]. attribute. The community type also is used in L2 VPNs [3].
There is a new Encaps Type for VPLS (TBD). The Encaps Type for VPLS is 19.
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) |
+------------------------------------+ +------------------------------------+
| Control Flags (1 octet) | | Control Flags (1 octet) |
+------------------------------------+ +------------------------------------+
| Layer-2 MTU (2 octet) | | Layer-2 MTU (2 octet) |
+------------------------------------+ +------------------------------------+
| Reserved (2 octets) | | Reserved (2 octets) |
+------------------------------------+ +------------------------------------+
There are three new control flags, Q, F and P defined for VPLS. Q
says whether qualified learning occurs (1) or not (0); F which says
whether the PE is capable of flooding (1) or not (0). P indicates
that the PE will strip the outermost VLAN from the layer 2 customer
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)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
With reference to Figure 4, the following bits are defined; the MBZ
bits MUST be set to zero.
Name Meaning
P If set to 1, then the PE will strip the outermost VLAN
tag from the customer frame on ingress, and push a
VLAN tag on egress. If set to 0, the customer frame
is left unchanged.
Q Reserved.
F If set to 1 (0), the PE is (not) capable of flooding.
C If set to 1 (0), Control word is (not) required when
encapsulating Layer 2 frames [10].
S If set to 1 (0), Sequenced delivery of frames is (not)
required.
3.3. Multi-AS VPLS 3.3. Multi-AS VPLS
As in [3] 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 connect to PEs in different ASes. This However, sites in a VPLS may connect to PEs in different ASes. This
leads to two issues: 1) there would not be an I-BGP connection leads to two issues: 1) there would not be an I-BGP connection
between those PEs, so some means of signaling across ASes may be between those PEs, so some means of signaling across ASes may be
skipping to change at page 12, line 33 skipping to change at page 12, line 40
that NLRI is removed. that NLRI is removed.
Two VPLS NLRIs are considered equivalent from a path selection point 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 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 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 VPLS, they MUST use the same Route Distinguisher, and they MUST
announce the same VE Block Size for a given VE Offset. 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 u-
L2PEs implementing VPLS: encapsulation and forwarding. PEs 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 [10], 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.
skipping to change at page 13, line 11 skipping to change at page 13, line 19
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 a
an L2PE, to the CE. Just as a learning bridge learns MAC addresses u-PE, to the CE. Just as a learning bridge learns MAC addresses on
on its ports, the SP bridge must learn MAC addresses at its VEs. 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 (logical) ports on which they arrive; this association is the
Information Base (FIB). The FIB is used for forwarding packets. For Forwarding Information Base (FIB). The FIB is used for forwarding
example, suppose the bridge receives a packet with source MAC address packets. For example, suppose the bridge receives a packet with
S on port P. If subsequently, the bridge receives a packet with source MAC address S on (logical) port P. If subsequently, the
destination MAC address S, it knows that it should send the packet bridge receives a packet with destination MAC address S, it knows
out on port P. that it should send the packet out on port P.
There are two modes of learning: qualified and unqualified learning. There are two modes of learning: qualified and unqualified learning.
In qualified learning, the learning decisions at the VE are based on In qualified learning, the learning decisions at the VE are based on
the customer ethernet packet's MAC address and VLAN tag, if one the customer ethernet packet's MAC address and VLAN tag, if one
exists. If no VLAN tag exists, the default VLAN is assumed. exists. This VLAN is often called the "service delimiting VLAN".
Effectively, within one VPLS, there are multiple logical FIBs, one Each VLAN on a given port is mapped to a different service (VPLS, IP
for each customer VLAN tag identified in a customer packet. VPN, point-to-point Layer 2 VPN, etc.); each VLAN that is mapped to a
VPLS service has its own VPLS FIB.
In unqualified learning, learning is based on a customer ethernet In unqualified learning, learning is based on a customer ethernet
packet's MAC address only. In other words, at any VE, there is only packet's MAC address only. This is also called "port-mode VPLS".
one FIB per VPLS.
Every VE must have at least one FIB for each VPLS that it
participates in.
4.2.2. Flooding 4.2.2. Flooding
When a bridge receives a packet to a destination that is not in its When a bridge receives a packet to a destination that is not in its
FIB, it floods the packet on all the other ports. Similarly, a VE FIB, it floods the packet on all the other ports. Similarly, a VE
will flood packets to an unknown destination to all other VEs in the will flood packets to an unknown destination to all other VEs in the
VPLS. VPLS.
In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the
destination MAC address on the frame was not in PE2's FIB (for that destination MAC address on the frame was not in PE2's FIB (for that
VPLS), then PE2 would be responsible for flooding that frame to every VPLS), then PE2 would be responsible for flooding that frame to every
other PE in the same VPLS. On receiving that frame, PE1 would be other PE in the same VPLS. On receiving that frame, PE1 would be
responsible for further flooding the frame to CE1 and CE5 (unless PE1 responsible for further flooding the frame to CE1 and CE5 (unless PE1
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 u-PE. If PE3 was connected to 2
L2PEs, it would announce that it has two L2PEs. PE3 could either u-PEs, it would announce that it has two u-PEs. 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 u-PE, 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 u-PEs.
4.2.3. "Split Horizon" Flooding 4.2.3. "Split Horizon" Flooding
When a PE capable of flooding receives a broadcast Ethernet frame, or When a PE capable of flooding receives a broadcast Ethernet frame, or
one with an unknown destination MAC address, it must flood the frame. 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 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 the frame to every other attached CE, as well as to all PEs
participating in the VPLS. If the frame arrived from another PE, 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. 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 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 termed "split horizon" flooding, and is a consequence of the PEs
being logically full-meshed -- if a broadcast frame is received from being logically full-meshed -- if a broadcast frame is received from
PEx, then PEx would have sent a copy to all other PEs. PEx, then PEx would have sent a copy to all other PEs.
5. Deployment Scenarios 5. Deployment Options
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 a u-PE or a
a PE. The default case described in this document is that the VE is PE. The default case described in this document is that the VE is a
a PE. However, there are a number of reasons that the VE might be an PE. However, there are a number of reasons that the VE might be a u-
L2PE, i.e., a device that does layer 2 functions such as MAC address PE, 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. 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 u-PEs 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 u-PEs
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 a u-PE; 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
[ 6] Bates, T., Rekhter, Y., Chandra, R., and Katz, D., [ 6] Bates, T., Rekhter, Y., Chandra, R., and Katz, D.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000
[ 7] Rosen, E., and Rekhter, Y., Editors, "BGP/MPLS VPNs", draft-
ietf-l3vpn-rfc2547bis-01.txt, work in progress.
[ 9] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities [ 9] Sangli, S., D. Tappan, and Y. Rekhter, "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-06.txt, work in Attribute", draft-ietf-idr-bgp-ext-communities-07.txt (work in
progress. progress)
[10] Martini, L., et al, "Encapsulation Methods for Transport of [10] Martini, L., et al, "Encapsulation Methods for Transport of
Ethernet Frames Over IP/MPLS Networks", draft-ietf- Ethernet Frames Over IP/MPLS Networks", draft-ietf-
pwe3-ethernet-encap-05.txt, work in progress. pwe3-ethernet-encap-06.txt (work in progress)
[11] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [11] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC 2385, August 1998 Signature Option," RFC 2385, August 1998
7. Informative References 7. Informative References
[ 2] Augustyn, W. (Editor), "Requirements for Virtual Private LAN [ 2] Andersson, L., and Rosen, E., "Framework for Layer 2 Virtual
Services (VPLS)", draft-ietf-l2vpn-vpls-requirements-00.txt, Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-04.txt
work in progress. (work in progress)
[ 3] Kompella, K., (Editor), "Layer 2 VPNs Over Tunnels", draft- [ 3] Kompella, K., (Editor), "Layer 2 VPNs Over Tunnels", draft-
kompella-l2vpn-l2vpn-00.txt, work in progress. kompella-l2vpn-l2vpn-00.txt (work in progress)
[ 4] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP" [ 4] Martini, L., et al, "Pseudowire Setup and Maintenance using LDP"
draft-ietf-pwe3-control-protocol-05.txt, work in progress. draft-ietf-pwe3-control-protocol-06.txt (work in progress)
[ 5] Kompella, V., et al, "Virtual Private LAN Services over MPLS", [ 5] Kompella, V., et al, "Virtual Private LAN Services over MPLS",
draft-ietf-ppvpn-vpls-ldp-01.txt, work in progress. draft-ietf-ppvpn-vpls-ldp-03.txt (work in progress)
[ 8] Ould-Brahim, H. et al, "Using BGP as an Auto-Discovery Mechanism [ 7] Rosen, E., and Rekhter, Y., Editors, "BGP/MPLS VPNs", draft-
for Network-based VPNs", work in progress. ietf-l3vpn-rfc2547bis-01.txt (work in progress)
[ 8] Ould-Brahim, H., Rosen, E., and Rekhter, Y., "Using BGP as an
Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", draft-
ietf-l3vpn-bgpvpn-auto-04.txt (work in progress)
Security Considerations Security Considerations
The focus in Virtual Private LAN Service is the privacy of data, 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 i.e., that data in a VPLS is only distributed to other nodes in that
VPLS and not to any external agent or other VPLS. Note that VPLS VPLS and not to any external agent or other VPLS. Note that VPLS
does not offer security or authentication: VPLS packets are sent in does not offer security or authentication: VPLS packets are sent in
the clear in the packet-switched network, and a man-in-the-middle can 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. eavesdrop, and may be able to inject packets into the data stream.
If security is desired, the PE-to-PE tunnels can be IPsec tunnels. If security is desired, the PE-to-PE tunnels can be IPsec tunnels.
skipping to change at page 17, line 8 skipping to change at page 17, line 8
well-behaved (this is outside the scope of this document), and that well-behaved (this is outside the scope of this document), and that
VPLS labels are accepted only from valid interfaces. For a PE, valid VPLS labels are accepted only from valid interfaces. For a PE, valid
interfaces comprise links from P routers. For an ASBR, a valid 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 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 VPLS. It is especially important in the case of multi-AS VPLSs that
one accept VPLS packets only from valid interfaces. one accept VPLS packets only from valid interfaces.
IANA Considerations IANA Considerations
IANA is asked to allocate an AFI for Layer 2 information (suggested IANA is asked to allocate an AFI for Layer 2 information (suggested
value: 25). IANA is also asked to register a SAFI for VPLS of 65 value: 25).
from the First-Come-First-Served space for SAFIs.
Contributors Contributors
The following contributed to this document: The following contributed to this document:
Javier Achirica, Telefonica Javier Achirica, Telefonica
Loa Andersson, TLA Loa Andersson, TLA
Chaitanya Kodeboyina, Juniper Chaitanya Kodeboyina, Juniper
Giles Heron, Consultant Giles Heron, Consultant
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel
 End of changes. 

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