One document matched: draft-kothari-henderickx-l2vpn-vpls-multihoming-00.txt
Network Working Group B. Kothari
Internet-Draft K. Kompella
Updates: 4761 (if approved) Juniper Networks
Intended status: Standards Track W. Henderickx
Expires: January 7, 2010 F. Balus
Alcatel-Lucent
July 6, 2009
BGP based Multi-homing in Virtual Private LAN Service
draft-kothari-henderickx-l2vpn-vpls-multihoming-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Kothari, et al. Expires January 7, 2010 [Page 1]
Internet-Draft VPLS Multi-homing July 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kothari, et al. Expires January 7, 2010 [Page 2]
Internet-Draft VPLS Multi-homing July 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 6
3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 7
3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 7
3.2. Multi-homing NLRI . . . . . . . . . . . . . . . . . . . . 7
3.3. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 8
3.4. Designated Forwarder Election . . . . . . . . . . . . . . 8
3.4.1. BGP Advertisement for VPLS Multi-homing . . . . . . . 9
3.4.2. Tie-breaking Rules . . . . . . . . . . . . . . . . . . 12
3.4.3. DF Election on PEs . . . . . . . . . . . . . . . . . . 12
4. Use of Route Origin Extended Community . . . . . . . . . . . . 14
5. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. BGP Local Preference . . . . . . . . . . . . . . . . . . . 15
5.2. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Inter-AS Method (b): EBGP Redistribution of VPLS
Information between ASBRs . . . . . . . . . . . . . . 16
5.2.2. Method (c): Multi-Hop EBGP Redistribution of VPLS
Information between ASes . . . . . . . . . . . . . . . 17
6. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 18
6.1. MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 18
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 20
7.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . . 20
7.2. BGP Auto-discovery with LDP for signaling . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Kothari, et al. Expires January 7, 2010 [Page 3]
Internet-Draft VPLS Multi-homing July 2009
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.
[I-D.ietf-l2vpn-signaling] explains how VPLS can be offered using BGP
for auto-discovery and [RFC4762] explains how VPLS can be offered
using LDP for signaling. This document provides a VPLS multi-homing
solution when BGP is used for auto-discovery as described in either
[RFC4761] or [I-D.ietf-l2vpn-signaling].
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 8 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. A site is uniquely identified by a site ID,
also called as VE ID. 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].
Kothari, et al. Expires January 7, 2010 [Page 4]
Internet-Draft VPLS Multi-homing July 2009
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. There are other approaches for providing multi-homing such as
Spanning Tree Protocol, and this document specifies use of BGP for
multi-homing. Comprehensive comparison among the approaches is
outside the scope of this document.
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
Kothari, et al. Expires January 7, 2010 [Page 5]
Internet-Draft VPLS Multi-homing July 2009
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.
Kothari, et al. Expires January 7, 2010 [Page 6]
Internet-Draft VPLS Multi-homing July 2009
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. The
procedures described in this section are applicable to BGP based
VPLS, LDP based VPLS or a VPLS that contains a mix of both BGP and
LDP signaled PWs.
3.1. Provisioning Model
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 to the same customer site is
required. This is achieved by assigning the same multi-homed site ID
(MH-Site-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 MH-Site-ID. Thus, same
MH-Site-ID SHOULD be assigned on all VPLS PEs that are multi-homed to
the same customer site.
Note that a VE-ID=0 or MH-Site-ID=0 is invalid and a PE should only
discard such an advertisement.
3.2. Multi-homing NLRI
Section 3.2.2 in [RFC4761] describes the encoding of VPLS BGP NLRI.
For multi-homing operation, the same NLRI is used for identifying the
multi-homed customers sites. VE ID is part of the VPLS NLRI. In
addition, VE block offset, VE block size and label base are also
encoded in the NLRI. For multi-homing operation, MH-Site-ID is
encoded in the VE ID field of the NLRI. In addition, the NLRI for
the MH-Site-ID SHOULD have the block offset, block size and label
base as zero. Thus, the NLRI contains 2 octets indicating the
length, 8 octets for Route Distinguisher, 2 octets for MH-Site-ID and
7 octets padded with zero.
Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with
CE1 multi-homed to PE1 and PE2. CE4 does not require special
addressing being associated with the base VPLS instance identified by
the VSI-ID for LDP VPLS and VE-ID for BGP VPLS. However, CE1 which
is multi-homed to PE1 and PE2 requires configuration of MH-Site-ID
and both PE1 and PE2 SHOULD assign the same MH-Site-ID and the NLRI
SHOULD have the block offset, block size and label base as zero.
It is valid to have non-zero block offset, block size and label base
in the VPLS NLRI for a multi-homed site. However, multi-homing
Kothari, et al. Expires January 7, 2010 [Page 7]
Internet-Draft VPLS Multi-homing July 2009
operations in such a case are outside the scope of this document.
3.3. VPLS Preference
When multiple PEs are assigned the same site ID for multi-homing, it
is often desired to be able to control the selection of a particular
PE as the designated forwarder. A VE preference is introduced in
this document that can be used to accomplish this. 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.
+------------------------------------+
| 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.4. Designated Forwarder Election
BGP-based multi-homing for VPLS relies on BGP DF election and VPLS DF
election. The net result of doing both BGP and VPLS DF election is
that of electing a single designated forwarder (DF) among the set of
PEs to which a customer site is multi-homed. All the PEs that are
Kothari, et al. Expires January 7, 2010 [Page 8]
Internet-Draft VPLS Multi-homing July 2009
elected as non-designated forwarders MUST keep their attachment
circuit to the multi-homed CE in blocked status (no forwarding).
In order to explain how these two DF election algorithms work, one
must refer to the format of the VPLS NLRI. In addition to what is
carried in the NLRI, a VPLS advertisement contains some attributes,
such as Local Preference (LP) that are used in DF election algorithm.
A VPLS advertisement might contain a Route Origin Extended Community
(RO) (see section Section 4). 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 three derived fields called AC-Status, PE-ID
and PREF.
The following are the three entities that are used in DF tie-breaking
rules.
1. AC-Status (ACS): This indicates the attachment circuit status.
ACS = 1 indicates that attachment circuit is down and ACS = 0
indicates that attachment circuit is up.
2. PREF: This indicates the PE preference.
3. PE-ID: This indicates the loopback address of the PE that
originated the NLRI.
The following sections describe the formats of the VPLS NLRI and
specifies what constitutes a prefix for DF election algorithm. In
addition, the derivation of the three entities used in DF election
algorithm are described.
3.4.1. BGP Advertisement for VPLS Multi-homing
The VPLS NLRI as described in Section 3.2.2 in [RFC4761] contains
Route Distinguisher, VE-ID, VE Block Offset, VE Block Size, Label
Base. These components are referred as RD, VE-ID, VBO, VBS and LB,
respectively. In addition, a VPLS advertisement in case of BGP based
VPLS contains control flag (CF) and VE Preference (VP). 'D' bit in
the control flags is described in [I-D.kothari-l2vpn-auto-site-id]).
CF:D refers to the value of the 'D' bit in the control flags.
As explained in Section 3.2, MH-Site-ID is encoded as VE-ID.
However, for purposes of explaining path selection rules for VPLS
NLRIs, this section uses VE-ID to refer to site ID and does not
differentiate a MH NLRI from a non-MH NLRI that contains non-zero
block offset, block size and label base in the VPLS NLRI.
Kothari, et al. Expires January 7, 2010 [Page 9]
Internet-Draft VPLS Multi-homing July 2009
Table 1 shows how to set the value of ACS. Table 2 shows how to set
the value of PREF based on VP and LP. The Table 3 shows how to set
the value of PE-ID.
+--------------------+-----+
| Control Flags (CF) | ACS |
+--------------------+-----+
| CF:D = 1 | 1 |
| | |
| CF:D = 0 | 0 |
+--------------------+-----+
Table 1
+-------------+-------------+---------------+-----------------------+
| 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 2
Kothari, et al. Expires January 7, 2010 [Page 10]
Internet-Draft VPLS Multi-homing July 2009
+---------+---------------+-----------------------------------------+
| RO | PE-ID | Comment |
| Present | | |
+---------+---------------+-----------------------------------------+
| Yes | Global | Source PE as specified in RO |
| | Administrator | |
| | sub-field of | |
| | RO | |
| | | |
| No | BGP | Source PE as specified by BGP |
| | Identifier | Identifier. If a route carries the |
| | | ORIGINATOR_ID attribute, then the |
| | | ORIGINATOR_ID SHOULD be treated as the |
| | | BGP Identifier of the BGP speaker that |
| | | has advertised the route. |
+---------+---------------+-----------------------------------------+
Table 3
Taken all together, this yields:
<RD, VE-ID, VBO, VBS, LB; DOM, ACS, PE-ID, PREF>
3.4.1.1. BGP DF Election
An advertisement
ADV = <RD, VE-ID, VBO, VBS, LB; DOM, ACS, PE-ID, PREF>
is discarded if DOM is not of interest to the BGP speaker.
Otherwise, ADV is put into the bucket for <DOM, RD, VE-ID, VBO>. In
other words, the information in BGP DF election consists of <DOM, RD,
VE-ID, VBO> and only advertisements with exact same <DOM, RD, VE-ID,
VBO, DOM> are candidates for DF election.
3.4.1.2. VPLS DF Election
An advertisement
ADV = <RD, VE-ID, VBO, VBS, LB; DOM, ACS, PE-ID, PREF>
is discarded if DOM is not of interest to the VPLS PE. Otherwise,
ADV 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 DF election.
Kothari, et al. Expires January 7, 2010 [Page 11]
Internet-Draft VPLS Multi-homing July 2009
3.4.2. Tie-breaking Rules
This section describes the tie-breaking rules for both LDP based VPLS
using BGP-AD and BGP based VPLS. Both BGP and VPLS DF election
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 DF election.
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.
Given two advertisements ADV1 and ADV2, the following tie-breaking
rules MUST be applied in the given order.
1. if (ACS1 != 1) AND (ACS2 == 1) ADV1 wins; stop
if (ACS1 == 1) AND (ACS2 != 1) ADV2 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;
For BGP DF election, if there is no winner and AD1 and AD2 are from
the same PE, BGP DF election should simply consider this as an
update.
For VPLS DF election, if there is no winner and AD1 and AD2 are from
the same PE, a VPLS PE MUST retain both AD1 and AD2.
Note that if an advertisement has VE-ID = 0, it MUST be discarded.
For VPLS NLRIs, the above rules supercede the tie breaking rules
described in (Section 9.1.2.2) [RFC4271]
3.4.3. DF Election on PEs
DF election algorithm MUST be run by all multi-homed VPLS PEs. In
addition, egress PEs SHOULD also run the DF election algorithm. As a
result of the DF election, multi-homed PEs that lose the DF election
Kothari, et al. Expires January 7, 2010 [Page 12]
Internet-Draft VPLS Multi-homing July 2009
for a MH-Site-ID MUST put the ACs associated with the MH-Site-ID in
non-forwarding state.
DF election result on the egress PEs can be used in traffic
forwarding decision. Figure 2 shows two customer sites, CE1 and CE4,
connected to PE1 with CE1 multi-homed to PE1 and PE2. If PE1 is the
designated forwarder for CE1, based on the DF election result, PE3
can chose to not send unknown unicast and multicast traffic to PE2 as
PE2 is not the designated forwarder for any customer site and it has
no other single homed sites connected to it.
Kothari, et al. Expires January 7, 2010 [Page 13]
Internet-Draft VPLS Multi-homing July 2009
4. Use of Route Origin Extended Community
Due to lack of information about the PEs that originate the VPLS
NLRIs in inter-AS operations, 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.
Kothari, et al. Expires January 7, 2010 [Page 14]
Internet-Draft VPLS Multi-homing July 2009
5. BGP based VPLS
This section describes the VPLS operations that pertain to BGP VPLS
as described in [RFC4761].
5.1. 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.3 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.
5.2. 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.
Kothari, et al. Expires January 7, 2010 [Page 15]
Internet-Draft VPLS Multi-homing July 2009
5.2.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
DF election 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.3 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
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 DF election, 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
Kothari, et al. Expires January 7, 2010 [Page 16]
Internet-Draft VPLS Multi-homing July 2009
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 an ASBR or a PE within their AS.
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).
5.2.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.
Kothari, et al. Expires January 7, 2010 [Page 17]
Internet-Draft VPLS Multi-homing July 2009
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.
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. Mechanisms for MAC flush are described
in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762]
for LDP based VPLS.
6.1. MAC List FLush
If multiple customer sites are connected to the same PE, PE1 as shown
in Figure 2, 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
flush message with MAC list that contains a list of MAC addresses
that needs to be flushed. In Figure 2, if connectivity between CE1
and PE1 goes down and if PE1 was the designated forwarder for CE1,
PE1 SHOULD send a list of MAC addresses that belong to CE1 to all its
BGP peers.
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 flush messages so that excessive flooding
of such advertisements do not occur.
6.2. Implicit MAC Flush
When a connectivity to a customer site is lost, remote PEs learn that
a particular site is no longer reachable. In case of BGP based VPLS,
Kothari, et al. Expires January 7, 2010 [Page 18]
Internet-Draft VPLS Multi-homing July 2009
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 case of LDP based VPLS, a PE either
withdraws the PW label previously advertised or sends a PW Status TLV
with appropriate status bits.
If a remote PE detects that a multi-homed PE has transitioned from
being a DF to a non-DF, then the remote PE can choose to flush all
MAC addresses that it learned from the multi-homed PE.
Kothari, et al. Expires January 7, 2010 [Page 19]
Internet-Draft VPLS Multi-homing July 2009
7. Backwards Compatibility
No forwarding loops are formed when PEs or Route Reflectors that do
not support procedures defined in this section co exist in the
network with PEs or Route Reflectors that do support.
7.1. BGP based VPLS
As explained in this section, multi-homed PEs to the same customer
site MUST assign the same MH-Site-ID and SHOULD contain the block
offset, block size and label base as zero. Egress PEs that lack
support of multi-homing operations specified in this document will
fail to create any PWs for the multi-homed MH-Site-IDs due to the
label value of zero and thus, the multi-homing NLRI should have no
impact on the operation of egress VPLS PEs that lack support of
multi-homing operations specified in this document.
7.2. BGP Auto-discovery with LDP for signaling
TBD.
Kothari, et al. Expires January 7, 2010 [Page 20]
Internet-Draft VPLS Multi-homing July 2009
8. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4761].
Kothari, et al. Expires January 7, 2010 [Page 21]
Internet-Draft VPLS Multi-homing July 2009
9. IANA Considerations
At this time, this memo includes no request to IANA.
Kothari, et al. Expires January 7, 2010 [Page 22]
Internet-Draft VPLS Multi-homing July 2009
10. Acknowledgments
The authors would like to thank Yakov Rekhter, Nischal Sheth, and
Mitali Singh for their insightful comments and probing questions.
Kothari, et al. Expires January 7, 2010 [Page 23]
Internet-Draft VPLS Multi-homing July 2009
11. References
11.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.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[I-D.ietf-l2vpn-signaling]
Rosen, E., "Provisioning, Autodiscovery, and Signaling in
L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress),
May 2006.
[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.
[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.ietf-pwe3-redundancy-bit]
Muley, P., Bocci, M., and L. Martini, "Preferential
Forwarding Status bit definition",
draft-ietf-pwe3-redundancy-bit-01 (work in progress),
September 2008.
11.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.
Kothari, et al. Expires January 7, 2010 [Page 24]
Internet-Draft VPLS Multi-homing July 2009
[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.
Kothari, et al. Expires January 7, 2010 [Page 25]
Internet-Draft VPLS Multi-homing July 2009
Authors' Addresses
Bhupesh Kothari
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: bhupesh@juniper.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Wim Henderickx
Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be
Florin Balus
Alcatel-Lucent
Email: florin.balus@alcatel-lucent.com
Kothari, et al. Expires January 7, 2010 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 17:32:57 |