draft-ietf-l2vpn-vpls-bgp-04.txt   draft-ietf-l2vpn-vpls-bgp-05.txt 
Network Working Group K. Kompella, Ed. Network Working Group K. Kompella, Ed.
Internet-Draft Y. Rekhter, Ed. Internet-Draft Y. Rekhter, Ed.
Expires: August 23, 2005 Juniper Networks Expires: October 10, 2005 Juniper Networks
February 19, 2005 April 8, 2005
Virtual Private LAN Service Virtual Private LAN Service
draft-ietf-l2vpn-vpls-bgp-04 draft-ietf-l2vpn-vpls-bgp-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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.
This Internet-Draft will expire on August 23, 2005. This Internet-Draft will expire on October 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 offers a Layer 2 Virtual Service Provider offering. The service offers a Layer 2 Virtual
skipping to change at page 2, line 14 skipping to change at page 2, line 12
This document describes the functions required to offer VPLS, a This document describes the functions required to offer VPLS, a
mechanism for signaling a VPLS, and rules for forwarding VPLS frames mechanism for signaling a VPLS, and rules for forwarding VPLS frames
across a packet switched network. across a packet switched network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.1 Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2 Conventions used in this document . . . . . . . . . . . . 4 1.2 Conventions used in this document . . . . . . . . . . . . 4
1.3 Changes from last version . . . . . . . . . . . . . . . . 4 1.3 Changes from version 04 to 05 . . . . . . . . . . . . . . 4
2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Changes from version 03 to 04 . . . . . . . . . . . . . . 5
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 8 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Protocol Specification . . . . . . . . . . . . . . . . 9 3.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Protocol Specification . . . . . . . . . . . . . . . . 10
3.2.1 Setup and Teardown . . . . . . . . . . . . . . . . . . 9 3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Signaling PE Capabilities . . . . . . . . . . . . . . 11 3.2.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 PW Setup and Teardown . . . . . . . . . . . . . . . . 11
3.3.1 a) VPLS-to-VPLS connections at the AS border 3.2.3 Signaling PE Capabilities . . . . . . . . . . . . . . 12
routers. . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 BGP VPLS Operation . . . . . . . . . . . . . . . . . . . . 13
3.3.2 b) EBGP redistribution of VPLS information between 3.4 Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 14
ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1 a) VPLS-to-VPLS connections at the AS border
3.3.3 c) Multi-hop EBGP redistribution of VPLS routers. . . . . . . . . . . . . . . . . . . . . . . . 15
information between ASes. . . . . . . . . . . . . . . 14 3.4.2 b) EBGP redistribution of VPLS information between
3.4 Multi-homing and Path Selection . . . . . . . . . . . . . 15 ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.3 c) Multi-hop EBGP redistribution of VPLS
4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 17 information between ASes. . . . . . . . . . . . . . . 16
4.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.4 Allocation of VE IDs Across Multiple ASes . . . . . . 17
4.2.1 MAC address learning . . . . . . . . . . . . . . . . . 17 3.5 Multi-homing and Path Selection . . . . . . . . . . . . . 17
4.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . 17 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3 "Split Horizon" Forwarding . . . . . . . . . . . . . . 18 4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 19
5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4.2.1 MAC address learning . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3 "Split Horizon" Forwarding . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . 22 5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 21
8.2 Informative References . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Normative References . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26 8.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28
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 packet-switched network VPLS glues several individual LANs across a packet-switched network
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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.
1.2 Conventions used in this document 1.2 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]).
1.3 Changes from last version 1.3 Changes from version 04 to 05
[NOTE to RFC Editor: this section is to be removed before
publication.]
Updated IANA section to reflect agreement with authors of [8] that
the two docs should use the same AFI for L2VPN information.
Addressed comments received from Alex Zinin. No technical changes,
but a more complete description to cover the issues that Alex raised:
1. encoding of BGP NEXT_HOP for the new AFI/SAFI is not described
2. VE ID, Block offset, Block size, Label base are not described
anywhere
3. no information on how the receiving PE choose the PW label
4. section 3.2.2 talks about PE capabilities all of a sudden and
introduces a L2 Info Community, whose fields and use are not
described
Changes to address these:
1. Broke up section 3.2.1 into "Concepts" and "PW Setup".
2. Expanded section on "Signaling PE Capabilities".
3. Added a new section 3.3 "BGP VPLS Operation".
4. Minor tweaking, e.g. to fix section number references.
1.4 Changes from version 03 to 04
[NOTE to RFC Editor: this section is to be removed before [NOTE to RFC Editor: this section is to be removed before
publication.] publication.]
Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina, Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina,
and Mike Loomis. Most changes are clarifications and rewording for and Mike Loomis. Most changes are clarifications and rewording for
better readability. The substantive changes are to remove several better readability. The substantive changes are to remove several
flags from the control field. flags from the control field.
2. Functional Model 2. Functional Model
skipping to change at page 8, line 9 skipping to change at page 9, line 9
Address Family Identifiers (AFI) and Subsequent Address Family Address Family Identifiers (AFI) and Subsequent Address Family
Identifiers (SAFI). Consequently, an implementation MUST maintain a Identifiers (SAFI). Consequently, an implementation MUST maintain a
separate routing storage for each service. However, multiple separate routing storage for each service. However, multiple
services can use the same underlying tunnels; the VPLS or VPN label services can use the same underlying tunnels; the VPLS or VPN label
is used to demultiplex the packets belonging to different services. is used to demultiplex the packets belonging to different services.
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. Section 3.1 and
subsections describe these functions. The third subsection describes Section 3.2 describe these functions. Both of these functions are
the setting up of pseudowires that span Autonomous Systems. The last accomplished with a single BGP Update advertisement; Section 3.3
subsection details how multi-homing is handled. describes how this is done by detailing BGP protocol operation for
VPLS. Section 3.4 describes the setting up of pseudowires that span
Autonomous Systems. Section 3.5 describes how multi-homing is
handled.
3.1 Autodiscovery 3.1 Autodiscovery
Discovery 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 use identities of all the other PEs in a given VPLS, or the PE can use
some protocol to discover the other PEs. The latter is called some protocol to discover the other PEs. The latter is called
autodiscovery. autodiscovery.
The former approach is fairly configuration-intensive, especially The former approach is fairly configuration-intensive, especially
skipping to change at page 9, line 29 skipping to change at page 10, line 30
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.
3.2 Signaling 3.2 Signaling
Once discovery is done, each pair of PEs in a VPLS must be able to Once discovery is done, each pair of PEs in a VPLS must be able to
establish (and tear down) pseudowires to each other, i.e., exchange establish (and tear down) pseudowires to each other, i.e., exchange
(and withdraw) demultiplexors. This process is known as signaling. (and withdraw) demultiplexors. This process is known as signaling.
Signaling is also used to transmit certain characteristics of the PE Signaling is also used to transmit certain characteristics of the
regarding a given VPLS. pseudowires that a PE sets up for a given VPLS.
Recall that a demultiplexor is used to distinguish among several Recall that a demultiplexor is used to distinguish among several
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. However, note that the PE-to-PE tunnels need not be MPLS
tunnels.
3.2.1 Setup and Teardown 3.2.1 Concepts
The VPLS BGP NLRI described below, with a new AFI and SAFI (see [3]) The VPLS BGP NLRI described below, with a new AFI and SAFI (see [3])
is used to exchange demultiplexors. is used to exchange VPLS membership and demultiplexors.
A PE advertises a VPLS NLRI for each VPLS that it participates in. A VPLS BGP NLRI has the following information elements: a VE ID, a VE
If the PE is doing learning and flooding, i.e., it is the VE, it Block Offset, a VE Block Size and a label base. The exact format is
announces a single set of VPLS NLRIs for each VPLS that it is in. If given below.
the PE is connected to several u-PEs, it announces one set of VPLS
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
connected to CEs) and delegates learning on other interfaces (over
which it is connected to u-PEs). In this case, the PE would announce
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
VPLS.
Each set of NLRIs defines the demultiplexors for a range of other PEs A PE participating in a VPLS must have at least one VE ID. If the PE
in the VPLS. Ideally, a single NLRI suffices to cover all PEs in a is the VE, it typically has one VE ID. If the PE is connected to
VPLS; however, there are cases (such as a newly added PE) where the several u-PEs, it has a distinct VE ID for each u-PE. It may
pre-existing NLRI does not have enough labels. In such cases, additionally have a VE ID for itself, if it itself acts as a VE for
advertising an additional NLRI for the same VPLS serves to add labels that VPLS. In what follows, we will call the PE announcing the VPLS
for the new PEs without disrupting service to the pre-existing PEs. NLRI PE-a, and we will assume that PE-a owns VE ID V (either
If service disruption is acceptable (or when the PE restarts its BGP belonging to PE-a itself, or to a u-PE connected to PE-a).
process), a PE MAY consider coalescing all NLRIs for a VPLS into a
single NLRI.
If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE VE IDs are typically assigned by the network administrator. Their
Y that includes a demultiplexor that X can use, X sets up its ends of scope is local to a VPLS. A given VE ID should belong to only one
a pseudowire between X and Y. X may also have to advertise a new PE, unless a CE is multi-homed (see Section 3.5).
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.
If Y's configuration is changed to remove it from VPLS V, then Y MUST A label block is a set of demultiplexor labels used to reach a given
withdraw all its NLRIs for V. If all Y's links to CEs in V go down, VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block
then Y SHOULD either withdraw all its NLRIs for V, or let other PEs Size VBS and label base LB implicitly announces
in the VPLS V know in some way that Y is no longer connected to its
CEs. label block for V: labels from LB to (LB + VBS - 1), and
remote VE set for V: from VBO to (VBO + VBS - 1).
There is a one-to-one correspondance between the remote VE set and
the label block: VE ID (VBO + n) corresponds to label (LB + n).
3.2.2 PW Setup and Teardown
Suppose PE-a is part of VPLS foo, and makes an announcement with VE
ID V, VE Block Offset VBO, VE Block Size VBS and label base LB. If
PE-b is also part of VPLS foo, and has VE ID W, PE-b does the
following:
1. is W part of PE-a's 'remote VE set': if VBO <= W < VBO + VBS,
then W is part of PE-a's remote VE set. If not, PE-b ignores
this message, and skips the rest of this procedure.
2. set up a PW to PE-a: the demultiplexor label to send traffic from
PE-b to PE-a is computed as (LB + W - VBO).
3. is V part of any 'remote VE set' that PE-b announced: PE-b checks
if V belongs to some remote VE set that PE-b announced, say with
VE Block Offset VBO', VE Block Size VBS' and label base LB'. If
not, PE-b MUST make a new announcement as described in
Section 3.3.
4. set up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + V - VBO').
If Y withdraws an NLRI for V that X was using, then X MUST tear down If Y withdraws an NLRI for V that X was using, then X MUST tear down
its ends of the pseudowire between X and Y. its ends of the pseudowire between X and Y.
The format of the VPLS NLRI is given below. The AFI is to be The format of the VPLS NLRI is given below. The AFI is the L2VPN AFI
assigned by IANA, and the SAFI is the VPLS SAFI (65). (to be assigned by IANA), and the SAFI is the VPLS SAFI (65).
+------------------------------------+ +------------------------------------+
| Length (2 octets) | | Length (2 octets) |
+------------------------------------+ +------------------------------------+
| Route Distinguisher (8 octets) | | Route Distinguisher (8 octets) |
+------------------------------------+ +------------------------------------+
| VE ID (2 octets) | | VE ID (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Offset (2 octets) | | VE Block Offset (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Size (2 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | Label Base (3 octets) |
+------------------------------------+ +------------------------------------+
Figure 2: BGP NLRI for VPLS Information Figure 2: BGP NLRI for VPLS Information
3.2.2 Signaling PE Capabilities 3.2.3 Signaling PE Capabilities
The Encaps Type and Control Flags are encoded in an extended The following extended attribute, the "Layer2 Info Extended
attribute. Community", is used to signal control information about the
pseudowires to be setup for a given VPLS. This information includes
the Encaps Type (type of encapsulation on the pseudowires), Control
Flags (control information regarding the pseudowires) and the Maximum
Transmission Unit (MTU) to be used on the pseudowires.
The Encaps Type for VPLS is 19. The Encaps Type for VPLS is 19.
+------------------------------------+ +------------------------------------+
| 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) |
+------------------------------------+ +------------------------------------+
skipping to change at page 12, line 11 skipping to change at page 13, line 11
+------------------------------------+ +------------------------------------+
Figure 3: Layer2 Info Extended Community Figure 3: Layer2 Info Extended Community
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero) | MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 4: Control Flags Bit Vector Figure 4: Control Flags Bit Vector
With reference to Figure 4, the following bits are defined; the MBZ With reference to Figure 4, the following bits in the Control Flags
bits MUST be set to zero. are defined; the remaining bits, designated MBZ, MUST be set to zero
when sending and MUST be ignored when receiving this community.
Name Meaning Name Meaning
C If set to 1 (0), Control word is (not) required when C If set to 1 (0), Control word MUST (NOT) be present when
encapsulating Layer 2 frames [10]. sending VPLS packets to this PE [10].
S If set to 1 (0), Sequenced delivery of frames is (not) S If set to 1 (0), Sequenced delivery of frames is (not)
required. required when sending VPLS packets to this PE.
3.3 Multi-AS VPLS 3.3 BGP VPLS Operation
To create a new VPLS, say VPLS foo, a network administrator must pick
a RT for VPLS foo, say RT-foo. This will be used by all PEs that
serve VPLS foo. To configure a given PE, say PE-a, to be part of
VPLS foo, the network administrator only has to choose a VE ID V for
PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with
more than one VE ID; in that case, the following is done for each VE
ID). The PE may also be configured with a Route Distinguisher (RD);
if not, it generates a unique RD for VPLS foo. Say the RD is
RD-foo-a. PE-a then generates an initial label block and a remote VE
set for V, defined by VE Block Offset VBO, VE Block Size VBS and
label base LB. These may be empty.
PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block
Offset VBO, VE Block Size VBS and label base LB. To this, it
attaches a Layer2 Info Extended Community and a RT, RT-foo. It sets
the BGP Next Hop for this NLRI as itself, and announces this NLRI to
its peers. The Network Layer protocol associated with the Network
Address of the Next Hop for the combination <AFI=L2VPN AFI, SAFI=VPLS
SAFI> is IP; this association is required by [3], Section 5. If the
value of the Length of the Next Hop field is 4, then the Next Hop
contains an IPv4 address. If this value is 16, then the Next Hop
contains an IPv6 address.
If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with
RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same
VPLS (auto-discovery). PE-a then has to set up its part of a VPLS
pseudowire between PE-a and PE-b, using the mechanisms in
Section 3.2. Similarly, PE-b will have discovered that PE-a is in
the same VPLS, and PE-b must set up its part of the VPLS pseudowire.
Thus, signaling and pseudowire setup is also achieved with the same
Update message.
If W is not in any remote VE set that PE-a announced for VE ID V in
VPLS foo, PE-b will not be able to set up its part of the pseudowire
to PE-a. To address this, PE-a can choose to withdraw the old
announcement(s) it made for VPLS foo, and announce a new Update with
a larger remote VE set and corresponding label block that covers all
VE IDs that are in VPLS foo. This however, may cause some service
disruption. An alternative for PE-a is to create a new remote VE set
and corresponding label block, and announce them in a new Update,
without withdrawing previous announcements.
If PE-a's configuration is changed to remove VE ID V from VPLS foo,
then PE-a MUST withdraw all its announcements for VPLS foo that
contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go
down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo, or
let other PEs in the VPLS foo know in some way that PE-a is no longer
connected to its CEs.
3.4 Multi-AS VPLS
As in [11] and [9], the above autodiscovery and signaling functions As in [11] and [9], 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
needed; and 2) 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.
skipping to change at page 13, line 20 skipping to change at page 15, line 20
\ / \ /
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
| PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 |
+-----+ +-------+ | +-------+ +-----+ +-----+ +-------+ | +-------+ +-----+
___ / \ ___ ___ / \ ___
/ \ / \ / \ / \ / \ / \
\__________/ \____________/ \____________/ \__________/ \__________/ \____________/ \____________/ \__________/
Figure 6: Inter-AS VPLS Figure 6: Inter-AS VPLS
3.3.1 a) VPLS-to-VPLS connections at the AS border routers. 3.4.1 a) VPLS-to-VPLS connections at the AS border routers.
In this method, an AS Border Router (ASBR1) acts as a PE for all 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 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 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 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. 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 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 require that this link carry Ethernet traffic, and that there be a
separate VLAN sub-interface for each VPLS traversing this link. It separate VLAN sub-interface for each VPLS traversing this link. It
skipping to change at page 13, line 47 skipping to change at page 15, line 47
Note that in general, there will be multiple connections between a Note that in general, there will be multiple connections between a
pair of ASes, for redundancy. In this case, the Spanning Tree pair of ASes, for redundancy. In this case, the Spanning Tree
Protocol (STP), or some other means of loop detection and prevention, Protocol (STP), or some other means of loop detection and prevention,
must be run on each VPLS that spans these ASes, so that a loop-free 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 topology can be constructed in each VPLS. This imposes a further
burden on the ASBRs and PEs participating in those VPLSs, as these burden on the ASBRs and PEs participating in those VPLSs, as these
devices would need to run a loop detection algorithm for each such devices would need to run a loop detection algorithm for each such
VPLS. How this may be achieved is outside the scope of this VPLS. How this may be achieved is outside the scope of this
document. document.
3.3.2 b) EBGP redistribution of VPLS information between ASBRs. 3.4.2 b) EBGP redistribution of VPLS information between ASBRs.
This method requires I-BGP peerings between the PEs in AS1 and ASBR1 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 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 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 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 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 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 NLRI to PE2 with new labels and itself as the nexthop.
The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2
skipping to change at page 14, line 41 skipping to change at page 16, line 44
In this method, one needs MPLS on the ASBR1-ASBR2 interface, but In this method, one needs MPLS on the ASBR1-ASBR2 interface, but
there is no requirement that the link layer be Ethernet. there is no requirement that the link layer be Ethernet.
Furthermore, the ASBRs take part in distributing VPLS information. Furthermore, the ASBRs take part in distributing VPLS information.
However, the data plane requirements of the ASBRs is much simpler However, the data plane requirements of the ASBRs is much simpler
than in method (a), being limited to label operations. Finally, the than in method (a), being limited to label operations. Finally, the
construction of loop-free VPLS topologies is done by routing construction of loop-free VPLS topologies is done by routing
decisions, viz. BGP path and nexthop selection, so there is no need 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 to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this
method is considerably more scalable than method (a). method is considerably more scalable than method (a).
3.3.3 c) Multi-hop EBGP redistribution of VPLS information between 3.4.3 c) Multi-hop EBGP redistribution of VPLS information between
ASes. ASes.
In this method, there is a multi-hop E-BGP peering between the PEs 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 (or preferably, a Route Reflector) in AS1 and the PEs (or Route
Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop 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 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. changed. This requires that there be a tunnel LSP from PE1 to PE2.
This tunnel LSP can be created exactly as in [9], section 10 (c), for This tunnel LSP can be created exactly as in [9], section 10 (c), for
example using E-BGP to exchange labeled IPv4 routes for the PE example using E-BGP to exchange labeled IPv4 routes for the PE
loopbacks. loopbacks.
When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label 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 corresponding to its own VE ID onto the packet. It then pushes the
tunnel label(s) to reach PE2. tunnel label(s) to reach PE2.
This method requires no VPLS information (in either the control or 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 the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE
skipping to change at page 15, line 18 skipping to change at page 17, line 22
This method requires no VPLS information (in either the control or 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 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 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 plane. Again, as in the case of method (b), the construction of
loop-free VPLS topologies is done by routing decisions, i.e., BGP 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 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 Tree Protocol on a per-VPLS basis. This option is likely to be the
most scalable of the three methods presented here. most scalable of the three methods presented here.
3.4.4 Allocation of VE IDs Across Multiple ASes
In order to ease the allocation of VE IDs for a VPLS that spans 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 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 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 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 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. 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 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 range can be allocated to AS1. The only caveat is that there be no
overlap between VE ID ranges among ASes. The exception to this rule overlap between VE ID ranges among ASes. The exception to this rule
is multi-homing, which is dealt with below. is multi-homing, which is dealt with below.
3.4 Multi-homing and Path Selection 3.5 Multi-homing and Path Selection
It is often desired to multi-home a VPLS site, i.e., to connect it to 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 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 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 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 to run STP on the CE device, and possibly on the PEs, to construct a
loop-free VPLS topology. How this can be accomplished is outside the loop-free VPLS topology. How this can be accomplished is outside the
scope of this document; however, the rest of this section will scope of this document; however, the rest of this section will
describe in some detail the former case. describe in some detail the former case.
skipping to change at page 17, line 42 skipping to change at page 19, line 42
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 customer ports on all of the VE on a given the SP "bridge" are the customer ports on all of the VE on a given
service. Just as a learning bridge learns MAC addresses on its service. Just as a learning bridge learns MAC addresses on its
ports, the SP bridge must learn MAC addresses at its VEs. 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 (logical) ports on which they arrive; this association is the the (logical) ports on which they arrive; this association is the
Forwarding Information Base (FIB). The FIB is used for forwarding Forwarding Information Base (FIB). The FIB is used for forwarding
packets. For example, suppose the bridge receives a packet with packets. For example, suppose the bridge receives a packet with
source MAC address S on (logical) port P. If subsequently, the source MAC address S on (logical) port P. If subsequently, the bridge
bridge receives a packet with destination MAC address S, it knows receives a packet with destination MAC address S, it knows that it
that it should send the packet out on port P. should send the packet out on port P.
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
skipping to change at page 19, line 13 skipping to change at page 21, line 13
it MUST NOT be sent to other PEs. it MUST NOT be sent to other PEs.
5. Deployment Options 5. Deployment Options
In deploying a network that supports VPLS, the SP must decide what In deploying a network that supports VPLS, the SP must decide what
functions the VPLS-aware device closest to the customer (the VE) functions the VPLS-aware device closest to the customer (the VE)
supports. The default case described in this document is that the VE supports. 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 is a PE. However, there are a number of reasons that the VE might be
a device that does all the Layer 2 functions (such as MAC address a device that does all the Layer 2 functions (such as MAC address
learning and flooding), and a limited set of Layer 3 functions (such learning and flooding), and a limited set of Layer 3 functions (such
as communicating to its PE), but, for example, doesn't do as communicating to its PE), but, for example, doesn't do full-
full-fledged discovery and PE-to-PE signaling. Such a device is fledged discovery and PE-to-PE signaling. Such a device is called a
called a "u-PE". "u-PE".
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. For example, in a given provider network, one PE here allows this. For example, in a given provider network, one PE
may be directly connected to CE devices; another may be connected to may be directly connected to CE devices; another may be connected to
u-PEs that are connected to CEs; and a third may be connected u-PEs that are connected to CEs; and a third may be connected
directly to a customer over some interfaces and to u-PEs over others. directly to a customer over some interfaces and to u-PEs over others.
All these PEs perform discovery and signaling in the same manner. All these PEs perform discovery and signaling in the same manner.
How they do learning and forwarding depends on whether or not there How they do learning and forwarding depends on whether or not there
is a u-PE; however, this is a local matter, and is not signaled. is a u-PE; however, this is a local matter, and is not signaled.
skipping to change at page 21, line 7 skipping to change at page 23, line 7
Protecting the data plane requires ensuring that PE-to-PE tunnels are Protecting the data plane requires ensuring that PE-to-PE tunnels are
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.
7. IANA Considerations 7. IANA Considerations
IANA is asked to allocate an AFI for Layer 2 information (suggested IANA is asked to allocate an AFI for L2VPN information (suggested
value: 25). value: 25). This should be the same as the AFI requested by [8].
8. References 8. References
8.1 Normative References 8.1 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] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[3] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000. Extensions for BGP-4", draft-ietf-idr-rfc2858bis-06 (work in
progress), May 2004.
[4] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities [4] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Attribute", Communities Attribute", draft-ietf-idr-bgp-ext-communities-08
Internet-Draft draft-ietf-idr-bgp-ext-communities-08, February (work in progress), February 2005.
2005.
[5] Martini, L., Rosen, E., El-Aawar, N. and G. Heron, [5] Martini, L., "Encapsulation Methods for Transport of Ethernet
"Encapsulation Methods for Transport of Ethernet Frames Over Frames Over MPLS Networks", draft-ietf-pwe3-ethernet-encap-09
IP/MPLS Networks", (work in progress), February 2005.
Internet-Draft draft-ietf-pwe3-ethernet-encap-08, September
2004.
8.2 Informative References 8.2 Informative References
[6] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [6] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05
Internet-Draft draft-ietf-l2vpn-l2-framework-05, June 2004. (work in progress), June 2004.
[7] Lasserre, M. and V. Kompella, "Virtual Private LAN Services [7] Lasserre, M. and V. Kompella, "Virtual Private LAN Services
over MPLS", Internet-Draft draft-ietf-l2vpn-vpls-ldp-05, over MPLS", draft-ietf-l2vpn-vpls-ldp-06 (work in progress),
September 2004. February 2005.
[8] Ould-Brahim, H., Rosen, E. and Y. Rekhter, "Using BGP as an [8] Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP as an
Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs",
Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-04, May 2004. draft-ietf-l3vpn-bgpvpn-auto-05 (work in progress),
February 2005.
[9] Rosen, E., "BGP/MPLS IP VPNs", [9] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03
Internet-Draft draft-ietf-l3vpn-rfc2547bis-03, October 2004. (work in progress), October 2004.
[10] Martini, L., "Pseudowire Setup and Maintenance using LDP", [10] Martini, L., "Pseudowire Setup and Maintenance using LDP",
Internet-Draft draft-ietf-pwe3-control-protocol-14, November draft-ietf-pwe3-control-protocol-16 (work in progress),
2004. March 2005.
[11] Kompella, K., "Layer 2 VPNs Over Tunnels", [11] Kompella, K., "Layer 2 VPNs Over Tunnels",
Internet-Draft draft-kompella-l2vpn-l2vpn-00, January 2004. draft-kompella-l2vpn-l2vpn-00 (work in progress), January 2004.
Authors' Addresses Authors' Addresses
Kireeti Kompella (editor) Kireeti Kompella (editor)
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti@juniper.net Email: kireeti@juniper.net
 End of changes. 

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