One document matched: draft-kompella-l2vpn-vpls-multihoming-02.txt
Differences from draft-kompella-l2vpn-vpls-multihoming-01.txt
Network Working Group K. Kompella
Internet-Draft B. Kothari
Updates: 4761 (if approved) Juniper Networks
Intended status: Standards Track T. Spencer
Expires: May 7, 2009 AT&T
November 3, 2008
Multi-homing in BGP-based Virtual Private LAN Service
draft-kompella-l2vpn-vpls-multihoming-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009.
Kompella, et al. Expires May 7, 2009 [Page 1]
Internet-Draft BGP VPLS Multi-homing November 2008
Abstract
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo
shows how multi-homing can be offered in the context of BGP-based
VPLS.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 5
2.3. Using the Spanning Tree Protocol for Multi-homing . . . . 5
2.4. Active/Backup Links . . . . . . . . . . . . . . . . . . . 6
2.5. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 7
3.1. VE ID Assignment . . . . . . . . . . . . . . . . . . . . . 7
3.2. VE Preference . . . . . . . . . . . . . . . . . . . . . . 7
3.3. BGP Local Preference . . . . . . . . . . . . . . . . . . . 8
3.4. Designated Forwarder Election . . . . . . . . . . . . . . 8
3.4.1. BGP Path Selection . . . . . . . . . . . . . . . . . . 10
3.4.2. VPLS Path Selection . . . . . . . . . . . . . . . . . 11
4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Inter-AS Method (b): EBGP Redistribution of VPLS
Information between ASBRs . . . . . . . . . . . . . . . . 13
4.2. Method (c): Multi-Hop EBGP Redistribution of VPLS
Information between ASes . . . . . . . . . . . . . . . . . 15
5. VPLS Operation with multiple VE Identifiers . . . . . . . . . 16
5.1. Pseudowire Establishment . . . . . . . . . . . . . . . . . 17
5.2. Handling Link Failures . . . . . . . . . . . . . . . . . . 19
6. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 20
6.1. MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Kompella, et al. Expires May 7, 2009 [Page 2]
Internet-Draft BGP VPLS Multi-homing November 2008
1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing".
[RFC4761] explains how VPLS can be offered using BGP for auto-
discovery and signaling; section 3.5 of that document describes how
multi-homing can be achieved in this context. Implementation and
deployment of multi-homing in BGP-based VPLS has suggested some
refinement of the procedures described earlier; this memo details
these changes.
Section 2 lays out some of the scenarios for multi-homing, other ways
that this can be achieved, and some of the expectations of BGP-based
multi-homing. Section 3 defines the components of BGP-based multi-
homing, and the procedures required to achieve this. Section 7 may
someday discuss security considerations.
1.1. General Terminology
Some general terminology is defined here; most is from [RFC4761] or
[RFC4364]. Terminology specific to this memo is introduced as needed
in later sections.
A "Customer Edge" (CE) device, typically located on customer
premises, connects to a "Provider Edge" (PE) device, which is owned
and operated by the SP. A "Provider" (P) device is also owned and
operated by the SP, but has no direct customer connections. A "VPLS
Edge" (VE) device is a PE that offers VPLS services.
A VPLS domain represents a bridging domain per customer. A Route
Target community as described in [RFC4360] is typically used to
identify all the PE routers participating in a particular VPLS
domain. A VPLS site is a grouping of ports on a PE that belong to
the same VPLS domain. Sites are referred to as local or remote
depending on whether they are configured on the PE router in context
or on one of the remote PE routers (network peers).
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Kompella, et al. Expires May 7, 2009 [Page 3]
Internet-Draft BGP VPLS Multi-homing November 2008
2. Background
This section describes various scenarios where multi-homing may be
required, and the implications thereof. It also describes some of
the singular properties of VPLS multi-homing, and what that means
from both an operational point of view and an implementation point of
view. It describes briefly how the Spanning Tree Protocol can be
used to achieve multi-homing, and how that compares with BGP-based
multi-homing.
2.1. Scenarios
The most basic scenario is shown in Figure 1.
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
connectivity.
...............
. . ___ CE2
___ PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \___ CE3
\___ PE2 .
. .
...............
Figure 1: Scenario 1
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
connectivity. However, CE4, which is also in the same VPLS domain,
is single-homed to just PE1.
CE4 ------- ...............
\ . . ___ CE2
___ PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \___ CE3
\___ PE2 .
. .
...............
Figure 2: Scenario 2
Kompella, et al. Expires May 7, 2009 [Page 4]
Internet-Draft BGP VPLS Multi-homing November 2008
2.2. VPLS Multi-homing Considerations
The first (perhaps obvious) fact about a multi-homed VPLS CE, such as
CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a
loop has been created in the customer VPLS. This is a dangerous
situation for an Ethernet network, and the loop must be broken. Even
if CE1 is a router, it will get duplicates every time a packet is
flooded, which is clearly undesirable.
The next is that (unlike the case of IP-based multi-homing) only one
of PE1 and PE2 can be actively sending traffic, either towards CE1 or
into the SP cloud. That is to say, load balancing techniques will
not work. All other PEs MUST choose the same designated forwarder
for a multi-homed site. Call the PE that is chosen to send traffic
to/from CE1 the "designated forwarder".
In Figure 2, CE1 and CE4 must be dealt with independently, since CE1
is dual-homed, but CE4 is not.
2.3. Using the Spanning Tree Protocol for Multi-homing
It is quite common to have redundant links in Ethernet networks; here
too, redundancy leads to loops, but these can be broken by the use of
the Spanning Tree Protocol (STP). This technique can also be applied
in the case of multi-homed CEs in a VPLS domain. One approach is to
run STP on the multi-homed CE (say CE1 in Figure 1). CE1 would thus
detect a potential loop in the virtual LAN, and "block" either the
link to PE1 or to PE2, breaking the loop. Blocking the link to PE2
would effectively pick PE1 to be the designated forwarder, since (a)
PE2 will not get any traffic from CE1 to forward; (b) PE2's traffic
to CE1 will be ignored.
There are several operational disadvantages to the STP approach:
1. The SP has to trust the customer to run STP correctly and manage
changes carefully. If the customer makes a mistake, the SP will
pay for it by carrying the customer's "broadcast storm" across
the SP network.
2. The choice of whether PE1 or PE2 will be the "designated
forwarder" is made by the customer; however, the SP may feel that
they should make this choice, and in fact may be in a better
position to do so, as they know their network topology better.
3. STP has several characteristics that make it unsuitable for
carrier networks.
Another approach is to run STP on the PEs. However, the whole point
Kompella, et al. Expires May 7, 2009 [Page 5]
Internet-Draft BGP VPLS Multi-homing November 2008
of having a full mesh of PE-PE connections, and of "split horizon"
forwarding (Section 4.2.5 [RFC4761]; Section 4.4 [RFC4762]) is so
that STP is not needed on PEs. Furthermore, in Figure 2, PE1 must
not block the pseudowires to PE3 and PE4 in order to break the loop.
2.4. Active/Backup Links
Another approach is to define "active" and "backup" links from a
multi-homed CE to the PEs. For example, in Figure 1, CE1 could
define the link to PE1 as active and the link to PE2 as backup. If
the link to PE1, or PE1 itself, fails, the CE1 could detect this and
switch to the backup. However, again, the SP has to trust the
customer's staff to handle this correctly; also, the choice of
whether to use PE1 or PE2 remains with the customer.
2.5. Comparisons
One of the above methods may be acceptable in some cases. The
technique described in this memo is for those who are unsatisfied
with these methods. This technique relies on BGP mechanisms;
furthermore, the choice of "designated forwarder" is retained by the
SP. Finally, this technique can be used in conjunction with STP to
get further "insurance" against the possibility of loops.
Kompella, et al. Expires May 7, 2009 [Page 6]
Internet-Draft BGP VPLS Multi-homing November 2008
3. Multi-homing Operation
This section describes procedures for electing a designated forwarder
among the set of PEs that are multi-homed to a customer site. It is
imperative that all VPLS PEs elect the same designated forwarder
otherwise either a loop will be formed or traffic will be dropped.
Thus, procedures defined here MUST be supported by all BGP speakers
that are required to process VPLS NLRI advertisements.
3.1. VE ID Assignment
Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1
and PE2. In order for all VPLS PEs within the same VPLS domain to
elect one of the multi-homed PEs as the designated forwarder, an
indicator that the PEs are multi-homed is required. This is achieved
by assigning the same VE ID on PE1 and PE2 for CE1. When remote VPLS
PEs receive NLRI advertisement from PE1 and PE2 for CE1, the two NLRI
advertisements for CE1 are identified as candidates for designated
forwarder selection due to the same VE ID. Thus, same VE ID MUST be
assigned on all VPLS PEs that are multi-homed to the same customer
site.
Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 and
CE1 multi-homed to PE1 and PE2. In such a case, PE1 SHOULD assign
different VE IDs to CE1 and CE4, but the VE ID for CE1 on both PE1
and PE2 MUST be same.
Note that a VE ID = 0 is invalid.
3.2. VE Preference
When multiple PEs are assigned the same VE ID for multi-homing, it is
often desired to make a particular PE as the designated forwarder. A
VE preference is introduced in this document that can be used to
control the selection of the designated forwarder. A VE preference
indicates a degree of preference for a particular customer site.
Absence of this preference will still elect a designated forwarder
based on the algorithm explained in Section 3.4.
Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended
Community that carries control information about the pseudowires.
The last two octets that were reserved now carries VE preference as
shown in Figure 3.
Kompella, et al. Expires May 7, 2009 [Page 7]
Internet-Draft BGP VPLS Multi-homing November 2008
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| VE Preference (2 octets) |
+------------------------------------+
Figure 3: Layer2 Info Extended Community
A VE preference is a 2-octets unsigned integer. A value of zero
indicates absence of VE preference and is not a valid preference
value. This interpretation is required for backwards compatibility.
Implementations using Layer2 Info Extended Community as described in
(Section 3.2.4) [RFC4761] MUST set the last two octets as zero since
it was a reserved field.
3.3. BGP Local Preference
Section 3.5 in [RFC4761] describes the use of BGP Local Preference in
path selection to choose a particular NLRI, where Local Preference
indicates the degree of preference for a particular VE. The use of
Local Preference is inadequate when VPLS PEs are spread across
multiple ASes as Local Preference is not carried across AS boundary.
For backwards compatibility, if VE preference as described in
Section 3.2 is used, then BGP Local Preference MUST be set to the
value of VE preference. Note that a Local Preference value of zero
for a VE is not valid unless 'D' bit in the control flags is set (see
[I-D.kothari-l2vpn-auto-site-id]). In addition, Local Preference
value greater than or equal to 2^16 for VPLS advertisements is not
valid.
3.4. Designated Forwarder Election
BGP-based multi-homing for VPLS relies on BGP path selection and VPLS
path selection. BGP path selection as defined in this document for
VPLS NLRIs MUST be done by any BGP speaker that is required to
process VPLS NRLI advertisements. Thus, a Route Reflector,
[RFC4456], MUST support the procedures defined in this document for
BGP path selection for VPLS. Similarly, a BGP speaker that is also a
VPLS PE MUST also do BGP path selection for VPLS advertisements.
Kompella, et al. Expires May 7, 2009 [Page 8]
Internet-Draft BGP VPLS Multi-homing November 2008
VPLS path selection, however, is done only by a VPLS PE. The net
result of doing both BGP and VPLS path selection is that of electing
a single designated forwarder among the set of PEs to which a
customer site is multi-homed.
In order to explain how these two path selection algorithms work, one
must refer to the format of the VPLS NLRI. This NLRI contains:
<Route Distinguisher, VE ID, VE Block Offset, VE Block Size, Label
Base> (Section 3.2.2) [RFC4761]. These components are referred as
RD, VE-ID, VBO, VBS and LB, respectively. In addition, a VPLS
advertisement contains some attributes, among them the BGP nexthop
(BNH), control flags (CF), VE Preference (VP), and Local Preference
(LP). A VPLS advertisement might contain a Route Origin Attribute
(RO). Finally, the VPLS domain (DOM) is needed; this is not carried
explicitly in a VPLS advertisement, but is derived, typically from
BGP policies applied on Route Targets carried in the advertisement.
In addition to these fields in the advertisement, there are two
derived fields called PE-ID and PREF. The Table 1 shows how to set
the value of PREF based on VP and LP. The Table 2 shows how to set
the value of PE-ID based on RO and BNH.
+-------------+-------------+---------------+-----------------------+
| Valid | Valid | Valid values | Comment |
| values for | values for | for PREF | |
| VP | LP | | |
+-------------+-------------+---------------+-----------------------+
| 0 | 0 | 0 | malformed |
| | | | advertisement, unless |
| | | | CF:D=1 |
| | | | |
| 0 | 1 to | LP | backwards |
| | (2^16-1) | | compatibility |
| | | | |
| 0 | 2^16 to | (2^16-1) | backwards |
| | (2^32-1) | | compatibility |
| | | | |
| >0 | LP same as | VP | Implementation |
| | VP | | supports VP |
| | | | |
| >0 | LP != VP | 0 | malformed |
| | | | advertisement |
+-------------+-------------+---------------+-----------------------+
Table 1
Kompella, et al. Expires May 7, 2009 [Page 9]
Internet-Draft BGP VPLS Multi-homing November 2008
+----------+---------------------------+----------------------------+
| RO | PE-ID | Comment |
| Present | | |
+----------+---------------------------+----------------------------+
| Yes | Global Administrator | Source PE as specified in |
| | sub-field of RO | RO |
| | | |
| No | BNH | Source PE as specified by |
| | | BGP nexthop |
+----------+---------------------------+----------------------------+
Table 2
Taken all together, this yields:
<RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>
Both BGP and VPLS path selection algorithms are described in two
stages. For each algorithm, the first stage divides all received
VPLS advertisements into buckets of relevant and comparable
advertisements. In this stage, advertisements may be discarded as
not being relevant to path selection. The second stage picks a
single "winner" from each bucket by repeatedly applying a tie-
breaking algorithm on a pair of advertisements from that bucket. The
tie-breaking rules are such that the order in which advertisements
are picked from the bucket does not affect the final result. Note
that this is a conceptual description of the process; an
implementation MAY choose to realize this differently as long as the
semantics are preserved.
3.4.1. BGP Path Selection
3.4.1.1. Bucketization
An advertisement
AD = <RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>
is discarded if DOM is not of interest to the BGP speaker.
Otherwise, AD is put into the bucket for <RD, VE-ID, VBO>. In other
words, the prefix to use for comparison in BGP path selection
consists of <RD, VE-ID, VBO> and only advertisements with exact same
<RD, VE-ID, VBO> are candidates for path selection.
3.4.1.2. Tie-breaking Rules
Given two advertisements AD1 and AD2 as below, the following tie-
breaking rules MUST be applied in the given order (note that the RDs,
Kompella, et al. Expires May 7, 2009 [Page 10]
Internet-Draft BGP VPLS Multi-homing November 2008
VE-IDs and VBOs are the same):
AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, PE-ID1, CF1:D, PREF1>
AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, PE-ID2, CF2:D, PREF2>
where CF:D is the 'D' bit in the control flags and PREF is derived as
shown in Table 1
1. if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop
if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop
else continue
2. if (PREF1 > PREF2) AD1 wins; stop;
else if (PREF1 < PREF2) AD2 wins; stop;
else continue
3. if (PE-ID1 < PE-ID2) AD1 wins; stop;
else if (PE-ID1 > PE-ID2) AD2 wins; stop;
else AD1 and AD2 are equivalent; BGP will consider this as an
update
For VPLS advertisements, the above rules supercede the tie breaking
rules described in (Section 9.1.2.2) [RFC4271]
3.4.2. VPLS Path Selection
3.4.2.1. Bucketization
An advertisement
AD = <RD, VE-ID, VBO, VBS, LB; DOM, PE-ID, CF, PREF>
is discarded if DOM is not of interest to the VPLS PE. Otherwise, AD
is put into the bucket for <DOM, VE-ID>. In other words, all
advertisements for a particular VPLS domain that have the same VE-ID
are candidates for VPLS path selection.
3.4.2.2. Tie-breaking Rules
Given two advertisements AD1 and AD2 as below, the following tie-
breaking rules MUST be applied in the given order (note that VE-IDs
are same).
AD1 = <RD, VE-ID, VBO, VBS1, LB1; DOM, PE-ID1, CF1:D, PREF1>
AD2 = <RD, VE-ID, VBO, VBS2, LB2; DOM, PE-ID2, CF2:D, PREF2>
where CF:D is the 'D' bit in the control flags
Kompella, et al. Expires May 7, 2009 [Page 11]
Internet-Draft BGP VPLS Multi-homing November 2008
1. if (CF1:D != 1) AND (CF2:D == 1) AD1 wins; stop
if (CF1:D == 1) AND (CF2:D != 1) AD2 wins; stop
else continue
2. if (PREF1 > PREF2) AD1 wins; stop;
else if (PREF1 < PREF2) AD2 wins; stop;
else continue
3. if (PE-ID1 < PE-ID2) AD1 wins; stop;
else if (PE-ID1 > PE-ID2) AD2 wins; stop;
else AD1 and AD2 are from the same VPLS PE; AD1 and AD2 should
both be retained and an implementation MAY sort the
advertisements by other criteria such as VBO
If the final "winning" advertisement has VE-ID = 0 OR VBO = 0 OR VBS
= 0, it is discarded.
Kompella, et al. Expires May 7, 2009 [Page 12]
Internet-Draft BGP VPLS Multi-homing November 2008
4. Multi-AS VPLS
Section 3.4 in [RFC4761] describes three methods (a, b and c) to
connect sites in a VPLS to PEs that are across multiple AS. Since
VPLS advertisements in method (a) do not cross AS boundaries, multi-
homing operations for method (a) remain exactly the same as they are
within as AS. However, both for method (b) and (c), VPLS
advertisements do cross AS boundary. This section describes the VPLS
operations for method (b) and method (c). Consider Figure 4 for
inter-AS VPLS with multi-homed customer sites.
4.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information
between ASBRs
AS1 AS2
........ ........
CE2 _______ . . . .
___ PE1 . . PE3 --- CE3
/ : . . :
__/ : : : :
CE1 __ : ASBR1 --- ASBR2 :
\ : : : :
\___ PE2 . . PE4 ---- CE4
. . . .
........ ........
Assume VE IDs to be:
CE1: 1
CE2: 2
CE3: 3
CE4: 4
Figure 4: Inter-AS VPLS
A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed
to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and CE4 are
also single homed to PE3 and PE4 respectively in AS2. After running
path selection algorithm, all four VPLS PEs must elect the same set
of designated forwarder for all customer sites. Since BGP Local
Preference is not carried across AS boundary, VE preference as
described in Section 3.2 MUST be used for carrying site preference in
inter-AS VPLS operations.
As explained in (Section 3.4.2) [RFC4761], ASBR1 will send a VPLS
Kompella, et al. Expires May 7, 2009 [Page 13]
Internet-Draft BGP VPLS Multi-homing November 2008
NLRI received from PE1 to ASBR2 with new labels and itself as the BGP
nexthop. ASBR2 will send the received NLRI from ASBR1 to PE3 and PE4
with new labels and itself as the BGP nexthop. Since VPLS PEs use
BGP Local Preference in path selection, for backwards compatibility,
ASBR2 MUST set the Local Preference value in the VPLS advertisements
it sends to PE3 and PE4 to the VE preference value contained in the
VPLS advertisement it receives from ASBR1. ASBR1 MUST do the same
for the NLRIs it sends to PE1 and PE2. If ASBR1 receives a VPLS
advertisement without a valid VE preference from a PE within its AS,
then ASBR1 MUST set the VE preference in the advertisements to the
Local Preference value before sending it to ASBR2. Similarly, ASBR2
must do the same for advertisements without VE Preference it receives
from PEs within its AS. Thus, in method (b), ASBRs MUST update the
VE and Local Preference based on the advertisements they receive
either from a PE within their AS or an ASBR.
Since ASBR rewrites the BGP nexthop for VPLS advertisements it
receives from other ASes, the VPLS PEs no longer have the visibility
of the remote end PEs. In Figure 4, both PE3 and PE4 receives VPLS
NLRIs from ASBR2 for VE IDs 1 and 2, with BGP nexthop of ASBR2.
However, the VPLS PEs that originated the advertisements for VE IDs 1
and 2 are PE1 and PE2. Due to lack of information about the PEs that
originated the VPLS NLRIs, both PE3 and PE4 will only create one PW
to ASBR2 as to PE3 and PE4, the customer sites CE1 and CE2 appear
connected to ASBR2. However, two PWs are required in this case, one
for CE1 and another one for CE2. This can only be achieved if PE3
and PE4 know the originator PE for each advertisement received. For
this purpose, Route Origin Extended Community [RFC4360] is used to
carry the source PE's IP address.
To use Route Origin Extended Community for carrying the originator
VPLS PE's loopback address, the type field of the community MUST be
set to 0x01 and the Global Administrator sub-field MUST be set to the
PE's loopback IP address.
If a PE receives a VPLS NLRI with Route Origin Extended Community,
then the PE MUST use the IP address contained in the community as the
source PE. Otherwise, BGP nexthop for the VPLS advertisements MUST
be used as the source PE IP address. A VPLS PE MUST create one
active PW per remote PE. In Figure 4, PE1 will send the VPLS
advertisements with Route Origin Extended Community containing its
loopback address. PE2 will do the same. Even though PE3 receives
the VPLS advertisements for VE ID 1 and 2 from the same BGP nexthop,
ASBR2, the source PE address contained in the Route Origin Extended
Community is different for the CE1 and CE2 advertisements, and thus,
PE3 creates two PWs, one for CE1 (for VE ID 1) and another one for
CE2 (for VE ID 2).
Kompella, et al. Expires May 7, 2009 [Page 14]
Internet-Draft BGP VPLS Multi-homing November 2008
4.2. Method (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
Route Reflectors in AS1 and the PEs or Route Reflectors in AS2.
There is no VPLS state in either control or data plane on the ASBRs.
The multi-homing operations on the PEs in this method are exactly the
same as they are in intra-AS scenario. However, since Local
Preference is not carried across AS boundary, the translation of LP
to VP and vice versa MUST be done by RR, if RR is used to reflect
VPLS advertisements to other ASes. This is exactly the same as what
a ASBR does in case of method (b). A RR must set the VP to the LP
value in an advertisement before sending it to other ASes and must
set the LP to the VP value in an advertisement that it receives from
other ASes before sending to the PEs within the AS.
Kompella, et al. Expires May 7, 2009 [Page 15]
Internet-Draft BGP VPLS Multi-homing November 2008
5. VPLS Operation with multiple VE Identifiers
VE Identifiers uniquely identifies a particular customer site in a
VPLS domain. Even when multiple customer sites are attached to the
same VPLS PE as in Figure 5, a single VE ID is sufficient to
represent the two customer sites, A and B, as both are connected to
the same PE.
...............
... . .
| A | : Service :
--- \ : Provide : ...
\__ : VPLS PE2 --- | C |
___ PE1 Network : ---
... / : :
| B | . .
--- ...............
Figure 5: Multiple Customer sites with single VE ID
However, if sites of a customer are multi-homed to different set of
PEs, such as in Figure 6, and redundancy per site is desired, then
PEs MUST advertise a unique VE ID for each site that requires
redundancy.
...............
... . .
| B | : :
--- \ : : ...
\__ : Service PE2 --- | C |
___ PE1 : ---
... / : Provider :
| A | : :
--- \ : :
\__ PE3 :
: :
.................
Figure 6: Multiple Customer sites with different VE ID
In Figure 6, site A is multi-homed to PE1 and PE3, but site B is
single homed to PE1. Since redundancy for both A and B is desired,
PE1 and PE3 MUST assign the same VE ID for site A, and PE1 MUST
assign a different VE ID for B.
This section describes the VPLS operations, both for intra and inter
Kompella, et al. Expires May 7, 2009 [Page 16]
Internet-Draft BGP VPLS Multi-homing November 2008
AS scenarios, when there are multiple sites with different VE IDs, as
in Figure 6.
5.1. Pseudowire Establishment
This section explains how PWs are established between the PEs, when
more than one customer site with different VE ID is connected to the
same PE. Procedures described in this section are in context of one
VPLS domain. Route Target, as explained in [RFC4360], identifies a
VPLS domain.
When a PE receives VPLS NLRIs for multiple VE IDs for the same VPLS
instance from a remote PE, it MUST create an active PW by selecting
one of the VE IDs as primary and SHOULD create standby PWs for other
VE IDs. The setting up of PWs follow existing procedures defined in
RFC 4761. To select a site for setting up primary PW, an
advertisement with the lowest VE ID is selected.
In Figure 7,since VE preference of PE1 is better than PE3 for VE ID
1, PE1 wins the designated forwarder election based on Section 3.4.
Thus, PE1 is the designated forwarder for site A, and since site B is
single homed to PE1, PE1 will always be the forwarder for site B.
Kompella, et al. Expires May 7, 2009 [Page 17]
Internet-Draft BGP VPLS Multi-homing November 2008
...............
... . .
VE ID=2 | B | : :
--- \ : : ...
\__ : Service PE2 --- | C | VE ID=3
___ PE1 : ---
... / : Provider :
VE ID=1 | A | : :
--- \ : :
\__ PE3 :
: :
.................
VPLS NLRIs advertised by each PE:
PE1: VE_ID=1, LB=11, OFF=1, Pref=200 (for site A)
VE_ID=2, LB=11, OFF=1, Pref=100 (for site B)
PE2: VE_ID=3, LB=21, OFF=1 Pref=100 (for site B)
PE3: VE_ID=1, LB=101, OFF=1 Pref=100 (for site C)
where 'LB' is label base and 'OFF' is VE block offset
as carried in VPLS NLRI. 'Pref' is VE Preference as
carried in Layer2 Info Extended Community
Figure 7: Multiple Customer sites with different VE ID
PE2 MUST select VE ID of 1 for setting up active PW to PE1. Thus,
PE2 MUST use labels 21 and 22 to accept traffic from PE1, label 21
being the active PW and label 22 for standby PW. Note that PE2 MUST
associate MAC addresses from both PWs to remote PE, PE1, and should
not associate MAC addresses to individual PWs. In case the active PW
from PE1 to PE2 goes down, all MAC addresses learned from PE1 on PE2
will remain associated unless age out occurs or PE1 sends a FLUSH-
MESSAGE to PE2 [I-D.kothari-l2vpn-vpls-flush]. More details on
flushing of MAC addresses are explained in Section 6.
When a PE has multiple sites, it MUST advertise the same label base,
block offset and range for all its sites. In Figure 7, PE1 is
advertising label base of 11, block offset of 1 and block range of 8
for both sites A (VE ID 1) and B (VE ID 2). When PE1's
advertisements reach PE2, PE2 will always send traffic to PE1 with
label 13, irrespective of which site A or B is active. This
eliminates the need for PE2 to have multiple PWs to PE1.
Kompella, et al. Expires May 7, 2009 [Page 18]
Internet-Draft BGP VPLS Multi-homing November 2008
5.2. Handling Link Failures
In Figure 7, when link connectivity between site A and PE1 goes down,
PE1 MUST immediately send traffic to PE2 with label 22 instead of
label 21 that it was previously using. It MUST also send a BGP
update with 'D' bit set in the control flags. PE1 is no longer the
designated forwarder for site A.
Since PE2 has both labels, 21 and 22, there is no disruption of
traffic to PE2 when PE1 switches to label 22 from label 21. There
should be no MAC movement or re-learning on PE2 for traffic from PE1
for site B as a result of label switch by PE1. In addition, PE2 will
continue to use label 13 for traffic to PE1 and thus, connectivity
failure between A and PE1 has no impact on the traffic from PE2 to
PE1.
When PE3 receives the advertisement from PE1 with the 'D' bit set, it
MUST elect itself as the designated forwarder for site A based on the
multi-homing path selection rules. Similarly, PE2 elects PE3 as the
designated forwarder for the site A. PE3 creates PWs to PE2 using
normal procedures and starts using label advertised by PE2 to send
traffic to PE2. Due to the change in designated forwarder, MAC
addresses received on PE2 with label 21 are associated with PE3.
Note that if MAC addresses for site A were not flushed on PE2 when
link between A and PE1 went down, then PE2 can see MAC movement as it
is now learning site A's MAC addresses from PE3.
Instead of connectivity between site A and PE1, if link connectivity
between site B and PE1 goes down, there is no impact on traffic as
PE1 is already using label 21 for traffic to PE2. PE2 will continue
to use label 13 for traffic to PE1 with no change. Unless explicitly
flushed or age out occurs, MAC addresses for site B will remain as is
on PE2.
Kompella, et al. Expires May 7, 2009 [Page 19]
Internet-Draft BGP VPLS Multi-homing November 2008
6. MAC Flush Operations
In a service provider VPLS network, customer MAC learning is confined
to PE devices and any intermediate nodes, such as a Route Reflector,
do not have any for state for MAC addresses.
Topology changes either in the service provider's network or in
customer's network can result in the movement of MAC addresses from
one PE device to another. Such events can result into traffic being
dropped due to stale state of MAC addresses on the PE devices. Age
out timers that clear the stale state will resume the traffic
forwarding, but age out timers are typically in minutes, and
convergence of the order of minutes can severely impact customer's
service. To handle such events and expedite convergence of traffic,
flushing of affected MAC addresses is highly desirable.
A VPLS PE uses VPLS FLush Capability [I-D.kothari-l2vpn-vpls-flush]
to negotiate the use of VPLS-FLUSH message for MAC flush operations.
This section describes the scenarios where VPLS flush is desirable
and the specific VPLS Flush TLVs that provide capability to flush the
affected MAC addresses on the PE devices. All operations described
in this section are in context of a particular VPLS domain and not
across multiple VPLS domains.
6.1. MAC List FLush
If multiple customer sites are connected to the same PE, PE1 as shown
in Figure 7, and redundancy per site is desired when multi-homing
procedures described in this document are in affect, then it is
desired to flush just the relevant MAC addresses from a particular
site when the site connectivity is lost.
To flush particular set of MAC addresses, a PE SHOULD originate a
VPLS-FLUSH message with MAC list TLV (TLV type 0) that contains a
list of MAC addresses that needs to be flushed. In Figure 7, if
connectivity between A and PE1 goes down and if PE1 was the
designated forwarder for A, PE1 SHOULD send a list of MAC addresses
that belong to A to all its BGP peers.
If connectivity to both site A and B are down on PE1, then PE1 SHOULD
not send a VPLS-FLUSH message as the remote PEs will flush all MAC
addresses that belong to PE1, as described in Section 6.2.
If a single customer site is connected to a PE, and the connectivity
to the site is lost, then the PE SHOULD not send a VPLS-FLUSH message
as the remote PEs will flush all MAC addresses that they learned from
the source PE (see Section 6.2).
Kompella, et al. Expires May 7, 2009 [Page 20]
Internet-Draft BGP VPLS Multi-homing November 2008
It is RECOMMENDED that in case of excessive link flap of customer
attachment circuit in a short duration, a PE should have a means to
throttle advertisements of VPLS-FLUSH messages so that excessive
flooding of such advertisements do not occur.
6.2. Implicit MAC Flush
If a PE detects that all PWs from a source PE for a VPLS domain are
down, then the PE should flush all MAC addresses learned from that
source PE. Need for a VPLS-FLUSH message is only for cases when a
primary PW is torn down and standby PWs are in operational state.
Thus, a PE should not advertise VPLS-FLUSH message for cases when an
implicit flush due to loss of all PWs is sufficient.
When a connectivity to a customer site is lost, a PE either withdraws
the VPLS NLRI that it previously advertised for the site or it sends
a BGP update message for the site's VPLS NLRI with the 'D' bit set.
In either case, remote PEs learn that a particular site is no longer
reachable.
In Figure 7, if PE1 withdraws VPLS NLRIs for both site A and B or
sends BGP update with VPLS NLRIs for both A and B with 'D' bit set,
then PE2 SHOULD flush all MAC addresses that it learned from PE1.
PE1 should not send a VPLS-FLUSH message in this case.
If PE1 withdraws VPLS NLRIs for just site A or sends an update for
site A NLRIs with 'D' bit set, then PE2 SHOULD not flush MAC
addresses that it learned from PE1, unless PE2 has no standby PWs to
PE1.
Kompella, et al. Expires May 7, 2009 [Page 21]
Internet-Draft BGP VPLS Multi-homing November 2008
7. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4761].
Kompella, et al. Expires May 7, 2009 [Page 22]
Internet-Draft BGP VPLS Multi-homing November 2008
8. IANA Considerations
At this time, this memo includes no request to IANA.
Kompella, et al. Expires May 7, 2009 [Page 23]
Internet-Draft BGP VPLS Multi-homing November 2008
9. Acknowledgments
The authors would like to thank Chaitanya Kodeboyina, Yakov Rekhter,
Nischal Sheth and Amit Shukla for their insightful comments and
probing questions.
Kompella, et al. Expires May 7, 2009 [Page 24]
Internet-Draft BGP VPLS Multi-homing November 2008
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[I-D.kothari-l2vpn-auto-site-id]
Kothari, B., Kompella, K., and T. IV, "Automatic
Generation of Site IDs for Virtual Private LAN Service",
draft-kothari-l2vpn-auto-site-id-01 (work in progress),
October 2008.
[I-D.kothari-l2vpn-vpls-flush]
Kothari, B. and R. Fernando, "VPLS Flush in BGP-based
Virtual Private LAN Service",
draft-kothari-l2vpn-vpls-flush-00 (work in progress),
October 2008.
10.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
Kompella, et al. Expires May 7, 2009 [Page 25]
Internet-Draft BGP VPLS Multi-homing November 2008
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Bhupesh Kothari
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: bhupesh@juniper.net
Tom Spencer
AT&T
Email: tsiv@att.com
Kompella, et al. Expires May 7, 2009 [Page 26]
Internet-Draft BGP VPLS Multi-homing November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kompella, et al. Expires May 7, 2009 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-21 03:31:08 |