draft-ietf-l2vpn-vpls-multihoming-01.txt   draft-ietf-l2vpn-vpls-multihoming-02.txt 
L2VPN Working Group B. Kothari
Internet Draft K. Kompella
Intended status: Standards Track Juniper Networks
Expires: January 2011 W. Henderickx
F. Balus
Alcatel-Lucent
J. Uttaro
AT&T
July 12, 2010
BGP based Multi-homing in Virtual Private LAN Service Network Working Group B. Kothari
draft-ietf-l2vpn-vpls-multihoming-01 Internet-Draft Cisco Systems
Updates: 4761 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks
Expires: April 28, 2011 W. Henderickx
F. Balus
Alcatel-Lucent
J. Uttaro
AT&T
October 25, 2010
BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-l2vpn-vpls-multihoming-02.txt
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 BGP-based multi-homing can be offered in the context of LDP
and BGP VPLS solutions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on April 28, 2011.
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 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private 10, 2008. The person(s) controlling the copyright in some of this
Network (VPN) that gives its customers the appearance that their material may not have granted the IETF Trust the right to allow
sites are connected via a Local Area Network (LAN). It is often modifications of such material outside the IETF Standards Process.
required for the Service Provider (SP) to give the customer redundant Without obtaining an adequate license from the person(s) controlling
connectivity to some sites, often called "multi-homing". This memo the copyright in such materials, this document may not be modified
shows how BGP-based multi-homing can be offered in the context of LDP outside the IETF Standards Process, and derivative works of it may
and BGP VPLS solutions. 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.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Terminology.......................................4 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document.........................4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background.....................................................4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scenarios.................................................4 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. VPLS Multi-homing Considerations..........................5 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 7
3. Multi-homing Operation.........................................6 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 8
3.1. Provisioning Model........................................6 3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 8
3.2. Multi-homing NLRI.........................................6 3.2. Multi-homing NLRI . . . . . . . . . . . . . . . . . . . . 8
3.3. Designated Forwarder Election.............................7 3.3. Designated Forwarder Election . . . . . . . . . . . . . . 9
3.3.1. Attributes...........................................7 3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Variables Used.......................................8 3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . . 9
3.3.2.1. RD..............................................8 3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11
3.3.2.2. MH-ID...........................................8 3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . . 13
3.3.2.3. VBO.............................................8 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2.4. DOM.............................................8 4.1. Route Origin Extended Community . . . . . . . . . . . . . 14
3.3.2.5. ACS.............................................8 4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 14
3.3.2.6. PREF............................................8 4.3. Use of BGP-MH attributes in Inter-AS Methods . . . . . . . 15
3.3.2.7. PE-ID...........................................9 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS
Information between ASBRs . . . . . . . . . . . . . . 15
3.3.3. Election Procedures..................................9 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution
3.3.3.1. Bucketization for BGP DF Election..............10 of VPLS Information between ASes . . . . . . . . . . . 16
3.3.3.2. Bucketization for VPLS DF Election.............10 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 18
3.3.3.3. Tie-breaking Rules.............................10 5.1. MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 18
3.4. DF Election on PEs.......................................11 5.2. Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 18
4. Multi-AS VPLS.................................................12 5.3. Minimizing the effects of fast link transitions . . . . . 20
4.1. Route Origin Extended Community..........................12 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 21
4.2. VPLS Preference..........................................12 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Use of BGP-MH attributes in Inter-AS Methods.............13 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . . 21
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Information between ASBRs..................................14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
VPLS Information between ASes..............................15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5. MAC Flush Operations..........................................15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
5.1. MAC List Flush...........................................16 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
5.2. Implicit MAC Flush.......................................16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Backwards Compatibility.......................................16
6.1. BGP based VPLS...........................................17
6.2. LDP VPLS with BGP Auto-discovery.........................17
7. Security Considerations.......................................17
8. IANA Considerations...........................................17
9. References....................................................17
9.1. Normative References.....................................17
9.2. Informative References...................................18
10. Acknowledgments..............................................18
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing". connectivity to one or more sites, often called "multi-homing".
[RFC4761] explains how VPLS can be offered using BGP for auto- [RFC4761] explains how VPLS can be offered using BGP for auto-
discovery and signaling; section 3.5 of that document describes how discovery and signaling; section 3.5 of that document describes how
multi-homing can be achieved in this context. [I-D.ietf-l2vpn- multi-homing can be achieved in this context.
signaling] explains how VPLS can be offered using BGP for auto- [I-D.ietf-l2vpn-signaling] explains how VPLS can be offered using BGP
discovery (BGP-AD) and [RFC4762] explains how VPLS can be offered for auto- discovery (BGP-AD) and [RFC4762] explains how VPLS can be
using LDP for signaling. This document provides a BGP-based multi- offered using LDP for signaling. This document provides a BGP-based
homing solution applicable to both BGP and LDP VPLS technologies. multi-homing solution applicable to both BGP and LDP VPLS
Note that BGP MH can be used for LDP VPLS without the use of the BGP- technologies. Note that BGP MH can be used for LDP VPLS without the
AD solution. use of the BGP- AD solution.
Section 2 lays out some of the scenarios for multi-homing, other ways 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 that this can be achieved, and some of the expectations of BGP-based
multi-homing. Section 3 defines the components of BGP-based multi- multi-homing. Section 3 defines the components of BGP-based multi-
homing, and the procedures required to achieve this. Section 7 may homing, and the procedures required to achieve this. Section 7 may
someday discuss security considerations. someday discuss security considerations.
1.1. General Terminology 1.1. General Terminology
Some general terminology is defined here; most is from [RFC4761], Some general terminology is defined here; most is from [RFC4761],
[RFC4762] or [RFC4364]. Terminology specific to this memo is [RFC4762] or [RFC4364]. Terminology specific to this memo is
introduced as needed in later sections. introduced as needed in later sections.
A "Customer Edge" (CE) device, typically located on customer A "Customer Edge" (CE) device, typically located on customer
premises, connects to a "Provider Edge" (PE) device, which is owned premises, connects to a "Provider Edge" (PE) device, which is owned
and operated by the SP. A "Provider" (P) device is also owned and 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 operated by the SP, but has no direct customer connections. A "VPLS
Edge" (VE) device is a PE that offers VPLS services. Edge" (VE) device is a PE that offers VPLS services.
A VPLS domain represents a bridging domain per customer. A Route A VPLS domain represents a bridging domain per customer. A Route
Target community as described in [RFC4360] is typically used to Target community as described in [RFC4360] is typically used to
identify all the PE routers participating in a particular VPLS 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 domain. A VPLS site is a grouping of ports on a PE that belong to
same VPLS domain. A Multi-homed (MH) site is uniquely identified by a the same VPLS domain. A Multi-homed (MH) site is uniquely identified
MH site ID (MH-ID). Sites are referred to as local or remote by a MH site ID (MH-ID). Sites are referred to as local or remote
depending on whether they are configured on the PE router in context depending on whether they are configured on the PE router in context
or on one of the remote PE routers (network peers). or on one of the remote PE routers (network peers).
1.2. Conventions used in this document 1.2. Conventions
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
This section describes various scenarios where multi-homing may be This section describes various scenarios where multi-homing may be
required, and the implications thereof. It also describes some of the required, and the implications thereof. It also describes some of
singular properties of VPLS multi-homing, and what that means from the singular properties of VPLS multi-homing, and what that means
both an operational point of view and an implementation point of from both an operational point of view and an implementation point of
view. There are other approaches for providing multi-homing such as view. There are other approaches for providing multi-homing such as
Spanning Tree Protocol, and this document specifies use of BGP for Spanning Tree Protocol, and this document specifies use of BGP for
multi-homing. Comprehensive comparison among the approaches is multi-homing. Comprehensive comparison among the approaches is
outside the scope of this document. outside the scope of this document.
2.1. Scenarios 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 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
connectivity. connectivity.
............... ...............
. . ___ CE2 . . ___ CE2
___ PE1 . / ___ PE1 . /
/ : PE3 / : PE3
__/ : Service : __/ : Service :
CE1 __ : Provider PE4 CE1 __ : Provider PE4
\ : : \___ CE3 \ : : \___ CE3
\___ PE2 . \___ PE2 .
. . . .
............... ...............
Figure 1 Scenario 1 Figure 1: Scenario 1
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant 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 connectivity. However, CE4, which is also in the same VPLS domain,
single-homed to just PE1. is single-homed to just PE1.
CE4 ------- ............... CE4 ------- ...............
\ . . ___ CE2 \ . . ___ CE2
___ PE1 . / ___ PE1 . /
/ : PE3 / : PE3
__/ : Service : __/ : Service :
CE1 __ : Provider PE4 CE1 __ : Provider PE4
\ : : \___ CE3 \ : : \___ CE3
\___ PE2 . \___ PE2 .
. . . .
............... ...............
Figure 2 Scenario 2 Figure 2: Scenario 2
2.2. VPLS Multi-homing Considerations 2.2. VPLS Multi-homing Considerations
The first (perhaps obvious) fact about a multi-homed VPLS CE, such as 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 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 loop has been created in the customer VPLS. This is a dangerous
situation for an Ethernet network, and the loop must be broken. Even 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 if CE1 is a router, it will get duplicates every time a packet is
flooded, which is clearly undesirable. flooded, which is clearly undesirable.
The next is that (unlike the case of IP-based multi-homing) only one 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 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 into the SP cloud. That is to say, load balancing techniques will
work. All other PEs MUST choose the same designated forwarder for a not work. All other PEs MUST choose the same designated forwarder
multi-homed site. Call the PE that is chosen to send traffic to/from for a multi-homed site. Call the PE that is chosen to send traffic
CE1 the "designated forwarder". to/from CE1 the "designated forwarder".
In Figure 2, CE1 and CE4 must be dealt with independently, since CE1 In Figure 2, CE1 and CE4 must be dealt with independently, since CE1
is dual-homed, but CE4 is not. is dual-homed, but CE4 is not.
3. Multi-homing Operation 3. Multi-homing Operation
This section describes procedures for electing a designated forwarder This section describes procedures for electing a designated forwarder
among the set of PEs that are multi-homed to a customer site. The among the set of PEs that are multi-homed to a customer site. The
procedures described in this section are applicable to BGP based procedures described in this section are applicable to BGP based
VPLS, LDP based VPLS with BGP-AD or a VPLS that contains a mix of VPLS, LDP based VPLS with BGP-AD or a VPLS that contains a mix of
both BGP and LDP signaled PWs. both BGP and LDP signaled PWs.
3.1. Provisioning Model 3.1. Provisioning Model
Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1 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 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 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 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 required. This is achieved by assigning the same multi-homed site ID
(MH-ID) on PE1 and PE2 for CE1. When remote VPLS PEs receive NLRI (MH-ID) on PE1 and PE2 for CE1. When remote VPLS PEs receive NLRI
advertisement from PE1 and PE2 for CE1, the two NLRI advertisements advertisement from PE1 and PE2 for CE1, the two NLRI advertisements
for CE1 are identified as candidates for designated forwarder for CE1 are identified as candidates for designated forwarder
selection due to the same MH-ID. Thus, same MH-ID SHOULD be assigned selection due to the same MH-ID. Thus, same MH-ID SHOULD be assigned
on all VPLS PEs that are multi-homed to the same customer site. Note on all VPLS PEs that are multi-homed to the same customer site.
that a MH-ID=0 is invalid and a PE should discard such an
Note that a MH-ID=0 is invalid and a PE should discard such an
advertisement. advertisement.
3.2. Multi-homing NLRI 3.2. Multi-homing NLRI
Section 3.2.2 in [RFC4761] describes the encoding of the BGP VPLS Section 3.2.2 in [RFC4761] describes the encoding of the BGP VPLS
NLRI. This NLRI contains fields VE-ID, VE block offset, VE block size NLRI. This NLRI contains fields VE-ID, VE block offset, VE block
and label base. For multi-homing operation, the same NLRI is used for size and label base. For multi-homing operation, the same NLRI is
identifying the multi-homed customers sites. The VE-ID field in the used for identifying the multi-homed customers sites. The VE-ID
NLRI is set to MH-ID; the VE block offset, VE block size and label field in the NLRI is set to MH-ID; the VE block offset, VE block size
base are set to zero. Thus, the NLRI contains 2 octets indicating the and label base are set to zero. Thus, the NLRI contains 2 octets
length, 8 octets for Route Distinguisher, 2 octets for MH-ID and 7 indicating the length, 8 octets for Route Distinguisher, 2 octets for
octets with value zero. MH-ID and 7 octets with value zero.
Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with 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 CE1 multi-homed to PE1 and PE2. CE4 does not require special
addressing, being associated with the base VPLS instance identified 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 by the VSI-ID for LDP VPLS and VE-ID for BGP VPLS. However, CE1
is multi-homed to PE1 and PE2 requires configuration of MH-ID and which is multi-homed to PE1 and PE2 requires configuration of MH-ID
both PE1 and PE2 MUST be provisioned with the same MH-ID for CE1. It and both PE1 and PE2 MUST be provisioned with the same MH-ID for CE1.
is valid to have non-zero VE block offset, VE block size and label
base in the VPLS NLRI for a multi-homed site. However, multi-homing It is valid to have non-zero VE block offset, VE block size and label
base in the VPLS NLRI for a multi-homed site. However, multi-homing
operations in such a case are outside the scope of this document. operations in such a case are outside the scope of this document.
3.3. Designated Forwarder Election 3.3. Designated Forwarder Election
BGP-based multi-homing for VPLS relies on BGP DF election and VPLS DF 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 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 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 PEs to which a customer site is multi-homed. All the PEs that are
elected as non-designated forwarders MUST keep their attachment elected as non-designated forwarders MUST keep their attachment
circuit to the multi-homed CE in blocked status (no forwarding). circuit to the multi-homed CE in blocked status (no forwarding).
These election algorithms operate on VPLS advertisements, which These election algorithms operate on VPLS advertisements, which
include both the NLRI and attached BGP attributes. In order to include both the NLRI and attached BGP attributes. In order to
simplify the explanation of these algorithms, we will use a number of simplify the explanation of these algorithms, we will use a number of
variables derived from fields in the VPLS advertisement. These variables derived from fields in the VPLS advertisement. These
variables are: RD, MH-ID, VBO, DOM, ACS, PREF and PE-ID. The notation variables are: RD, MH-ID, VBO, DOM, ACS, PREF and PE-ID. The
ADV -> <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID> means that from a notation ADV -> <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID> means that
received VPLS advertisement ADV, the respective variables were from a received VPLS advertisement ADV, the respective variables were
derived. The following sections describe two attributes needed for DF derived. The following sections describe two attributes needed for
election, then describe the variables and how they are derived from DF election, then describe the variables and how they are derived
fields in VPLS advertisement ADV, and finally describe how DF from fields in VPLS advertisement ADV, and finally describe how DF
election is done. election is done.
3.3.1. Attributes 3.3.1. Attributes
The procedures below refer to two attributes: the Route Origin The procedures below refer to two attributes: the Route Origin
community (see Section 4.1) and the L2-info community (see Section community (see Section 4.1) and the L2-info community (see
4.2.1). These attributes are required for inter-AS operation; for Section 4.2). These attributes are required for inter-AS operation;
generality, the procedures below show how they are to be used. The for generality, the procedures below show how they are to be used.
procedures also say how to handle the case that either or both are The procedures also say how to handle the case that either or both
not present. are not present.
3.3.2. Variables Used 3.3.2. Variables Used
3.3.2.1. RD 3.3.2.1. RD
RD is simply set to the Route Distinguisher field in the NLRI part of RD is simply set to the Route Distinguisher field in the NLRI part of
ADV. ADV.
3.3.2.2. MH-ID 3.3.2.2. MH-ID
MH-ID is simply set to the VE-ID field in the NLRI part of ADV. MH-ID is simply set to the VE-ID field in the NLRI part of ADV.
3.3.2.3. VBO 3.3.2.3. VBO
VBO is simply set to the VE Block Offset field in the NLRI part of VBO is simply set to the VE Block Offset field in the NLRI part of
ADV. This field will typically be zero. ADV. This field will typically be zero.
3.3.2.4. DOM 3.3.2.4. DOM
This variable, indicating the VPLS domain to which ADV belongs, is This variable, indicating the VPLS domain to which ADV belongs, is
derived by applying BGP policy to the Route Target extended derived by applying BGP policy to the Route Target extended
communities in ADV. The details of how this is done are outside the communities in ADV. The details of how this is done are outside the
scope of this document. scope of this document.
3.3.2.5. ACS 3.3.2.5. ACS
ACS is the status of the attachment circuits for a given site of a ACS is the status of the attachment circuits for a given site of a
VPLS. ACS = 1 if all attachment circuits for the site are down, and 0 VPLS. ACS = 1 if all attachment circuits for the site are down, and
otherwise. 0 otherwise.
For BGP-based Multi-homing, ADV MUST contain an L2-info extended For BGP-based Multi-homing, ADV MUST contain an L2-info extended
community; within this community are control flags. One of these community; within this community are control flags. One of these
flags is the 'D' bit, described in [I-D.kothari-l2vpn-auto-site-id]. flags is the 'D' bit, described in [I-D.kothari-l2vpn-auto-site-id].
ACS is set to the value of the 'D' bit in ADV. ACS is set to the value of the 'D' bit in ADV.
3.3.2.6. PREF 3.3.2.6. PREF
PREF is derived from the Local Preference (LP) attribute in ADV as PREF is derived from the Local Preference (LP) attribute in ADV as
well as the VPLS Preference field (VP) in the L2-info extended well as the VPLS Preference field (VP) in the L2-info extended
community. If the Local Preference attribute is missing, LP is set to community. If the Local Preference attribute is missing, LP is set
0; if the L2-info community is missing, VP is set to 0. The following to 0; if the L2-info community is missing, VP is set to 0. The
table shows how PREF is computed from LP and VP. following table shows how PREF is computed from LP and VP.
+---------+---------------+----------+------------------------------+ +---------+---------------+----------+------------------------------+
| VP | LP Value | PREF | Comment | | VP | LP Value | PREF | Comment |
| Value | | Value | | | Value | | Value | |
+---------+---------------+----------+------------------------------+ +---------+---------------+----------+------------------------------+
| 0 | 0 | 0 | malformed advertisement, | | 0 | 0 | 0 | malformed advertisement, |
| | | | unless ACS=1 | | | | | unless ACS=1 |
| | | | | | | | | |
| 0 | 1 to (2^16-1) | LP | backwards compatibility | | 0 | 1 to (2^16-1) | LP | backwards compatibility |
| | | | | | | | | |
| 0 | 2^16 to | (2^16-1) | backwards compatibility | | 0 | 2^16 to | (2^16-1) | backwards compatibility |
| | (2^32-1) | | | | | (2^32-1) | | |
| | | | | | | | | |
| >0 | LP same as VP | VP | Implementation supports VP | | >0 | LP same as VP | VP | Implementation supports VP |
| | | | | | | | | |
| >0 | LP != VP | 0 | malformed advertisement | | >0 | LP != VP | 0 | malformed advertisement |
+---------+---------------+----------+------------------------------+ +---------+---------------+----------+------------------------------+
Figure 3 PREF table
3.3.2.7. PE-ID Table 1
3.3.2.7. PE-ID
If ADV contains a Route Origin (RO) community (see Section 4.1) with If ADV contains a Route Origin (RO) community (see Section 4.1) with
type 0x01, then PE-ID is set to the Global Administrator sub-field of type 0x01, then PE-ID is set to the Global Administrator sub-field of
the RO. Otherwise, if ADV has an ORIGINATOR_ID attribute, then PE-ID the RO. Otherwise, if ADV has an ORIGINATOR_ID attribute, then PE-ID
is set to the ORIGINATOR_ID. Otherwise, PE-ID is set to the BGP is set to the ORIGINATOR_ID. Otherwise, PE-ID is set to the BGP
Identifier. Identifier.
3.3.3. Election Procedures 3.3.3. Election Procedures
The election procedures described in this section apply equally to The election procedures described in this section apply equally to
BGP VPLS and LDP VPLS. BGP VPLS and LDP VPLS.
Election occurs in two stages. The first stage divides all received Election occurs in two stages. The first stage divides all received
VPLS advertisements into buckets of relevant and comparable VPLS advertisements into buckets of relevant and comparable
advertisements. Distinction MUST NOT be made on whether the NLRI is a advertisements. Distinction MUST NOT be made on whether the NLRI is
multi-homing NLRI or not. In this stage, advertisements may be a multi-homing NLRI or not. In this stage, advertisements may be
discarded as not being relevant to DF election. The second stage discarded as not being relevant to DF election. The second stage
picks a single "winner" from each bucket by repeatedly applying a picks a single "winner" from each bucket by repeatedly applying a
tie-breaking algorithm on a pair of advertisements from that bucket. tie-breaking algorithm on a pair of advertisements from that bucket.
The tie-breaking rules are such that the order in which The tie-breaking rules are such that the order in which
advertisements are picked from the bucket does not affect the final advertisements are picked from the bucket does not affect the final
result. Note that this is a conceptual description of the process; an result. Note that this is a conceptual description of the process;
implementation MAY choose to realize this differently as long as the an implementation MAY choose to realize this differently as long as
semantics are preserved. the semantics are preserved.
Note: these procedures supersede the tie breaking rules described in Note: these procedures supersede the tie breaking rules described in
(Section 9.1.2.2) [RFC4271] (Section 9.1.2.2) [RFC4271]
3.3.3.1. Bucketization for BGP DF Election 3.3.3.1. Bucketization for BGP DF Election
An advertisement An advertisement
ADV -> <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID> ADV -> <RD, MH-ID, VBO, ACS, PREF, PE-ID>
is discarded if DOM is not of interest to the BGP speaker. Otherwise, is put into the bucket for <RD, MH-ID, VBO>. In other words, the
ADV is put into the bucket for <DOM, RD, MH-ID, VBO>. In other words, information in BGP DF election consists of <RD, MH-ID, VBO> and only
the information in BGP DF election consists of <DOM, RD, MH-ID, VBO> advertisements with exact same <RD, MH-ID, VBO> are candidates for DF
and only advertisements with exact same <DOM, RD, MH-ID, VBO, DOM> election.
are candidates for DF election.
3.3.3.2. Bucketization for VPLS DF Election 3.3.3.2. Bucketization for VPLS DF Election
An advertisement An advertisement
ADV -> <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID> ADV -> <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID>
is discarded if DOM is not of interest to the VPLS PE. Otherwise, ADV is discarded if DOM is not of interest to the VPLS PE. Otherwise,
is put into the bucket for <DOM, MH-ID>. In other words, all ADV is put into the bucket for <DOM, MH-ID>. In other words, all
advertisements for a particular VPLS domain that have the same MH-ID advertisements for a particular VPLS domain that have the same MH-ID
are candidates for VPLS DF election. are candidates for VPLS DF election.
3.3.3.3. Tie-breaking Rules 3.3.3.3. Tie-breaking Rules
This section describes the tie-breaking rules for both BGP and VPLS This section describes the tie-breaking rules for both BGP and VPLS
DF election. Tie-breaking rules for BGP DF election are applied to DF election. Tie-breaking rules for BGP DF election are applied to
candidate advertisements by any BGP speaker. Since RD must be same candidate advertisements by any BGP speaker. Since RD must be same
for advertisements to be candidates for BGP DF election, use of for advertisements to be candidates for BGP DF election, use of
unique RDs will result in no candidate advertisements for BGP tie- unique RDs will result in no candidate advertisements for BGP tie-
breaking rules and thus, a BGP speaker in such a case will simply not breaking rules and thus, a BGP speaker in such a case will simply not
do BGP DF election. Tie-breaking rules for VPLS DF election are do BGP DF election. Tie-breaking rules for VPLS DF election are
applied to candidate advertisements by all VPLS PEs and the actions applied to candidate advertisements by all VPLS PEs and the actions
taken by VPLS PEs based on the VPLS DF election result are described taken by VPLS PEs based on the VPLS DF election result are described
in Section 3.4. in Section 3.4.
Given two advertisements ADV1 and ADV2 from a given bucket, first Given two advertisements ADV1 and ADV2 from a given bucket, first
compute the variables needed for DF election: compute the variables needed for DF election:
ADV1 -> <RD1, MH-ID1, VBO1, DOM1, ACS1, PREF1, PE-ID1> ADV1 -> <RD1, MH-ID1, VBO1, DOM1, ACS1, PREF1, PE-ID1>
ADV2 -> <RD2, MH-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2>
ADV2 -> <RD2, MH-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2>
Note that MH-ID1 = MH-ID2 and DOM1 = DOM2, since ADV1 and ADV2 came Note that MH-ID1 = MH-ID2 and DOM1 = DOM2, since ADV1 and ADV2 came
from the same bucket. If this is for BGP DF election, RD1 = RD2 and from the same bucket. If this is for BGP DF election, RD1 = RD2 and
VBO1 = VBO2 as well. Then the following tie-breaking rules MUST be VBO1 = VBO2 as well. Then the following tie-breaking rules MUST be
applied in the given order. applied in the given order.
1. if (ACS1 != 1) AND (ACS2 == 1) ADV1 wins; stop 1. if (ACS1 != 1) AND (ACS2 == 1) ADV1 wins; stop
if (ACS1 == 1) AND (ACS2 != 1) ADV2 wins; stop if (ACS1 == 1) AND (ACS2 != 1) ADV2 wins; stop
else continue else continue
2. if (PREF1 > PREF2) ADV1 wins; stop; 2. if (PREF1 > PREF2) ADV1 wins; stop;
else if (PREF1 < PREF2) ADV2 wins; stop; else if (PREF1 < PREF2) ADV2 wins; stop;
else continue else continue
3. if (PE-ID1 < PE-ID2) ADV1 wins; stop; 3. if (PE-ID1 < PE-ID2) ADV1 wins; stop;
else if (PE-ID1 > PE-ID2) ADV2 wins; stop; else if (PE-ID1 > PE-ID2) ADV2 wins; stop;
else ADV1 and ADV2 are from the same VPLS PE else ADV1 and ADV2 are from the same VPLS PE
For BGP DF election, if there is no winner and ADV1 and ADV2 are from For BGP DF election, if there is no winner and ADV1 and ADV2 are from
the same PE, BGP DF election should simply consider this as an the same PE, BGP DF election should simply consider this as an
update. update.
For VPLS DF election, if there is no winner and ADV1 and ADV2 are For VPLS DF election, if there is no winner and ADV1 and ADV2 are
from the same PE, a VPLS PE MUST retain both ADV1 and ADV2. from the same PE, a VPLS PE MUST retain both ADV1 and ADV2.
3.4. DF Election on PEs 3.4. DF Election on PEs
DF election algorithm MUST be run by all multi-homed VPLS PEs. In DF election algorithm MUST be run by all multi-homed VPLS PEs. In
addition, all other PEs SHOULD also run the DF election algorithm. As addition, all other PEs SHOULD also run the DF election algorithm.
a result of the DF election, multi-homed PEs that loose the DF As a result of the DF election, multi-homed PEs that lose the DF
election for a MH-ID MUST put the ACs associated with the MH-ID in election for a MH-ID MUST put the ACs associated with the MH-ID in
non-forwarding state. non-forwarding state.
DF election result on the egress PEs can be used in traffic DF election result on the egress PEs can be used in traffic
forwarding decision. Figure 2 shows two customer sites, CE1 and CE4, 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 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 designated forwarder for CE1, based on the DF election result, PE3
can chose to not send unknown unicast and multicast traffic to PE2 as 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 PE2 is not the designated forwarder for any customer site and it has
no other single homed sites connected to it. no other single homed sites connected to it.
4. Multi-AS VPLS 4. Multi-AS VPLS
This section describes multi-homing in an inter-AS context. This section describes multi-homing in an inter-AS context.
4.1. Route Origin Extended Community 4.1. Route Origin Extended Community
Due to lack of information about the PEs that originate the VPLS Due to lack of information about the PEs that originate the VPLS
NLRIs in inter-AS operations, Route Origin Extended Community NLRIs in inter-AS operations, Route Origin Extended Community
[RFC4360] is used to carry the source PE's IP address. [RFC4360] is used to carry the source PE's IP address.
To use Route Origin Extended Community for carrying the originator To use Route Origin Extended Community for carrying the originator
VPLS PE's loopback address, the type field of the community MUST be 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 set to 0x01 and the Global Administrator sub-field MUST be set to the
PE's loopback IP address. PE's loopback IP address.
4.2. VPLS Preference 4.2. VPLS Preference
When multiple PEs are assigned the same site ID for multi-homing, it 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 is often desired to be able to control the selection of a particular
PE as the designated forwarder. Section 3.5 in [RFC4761] describes PE as the designated forwarder. Section 3.5 in [RFC4761] describes
the use of BGP Local Preference in path selection to choose a the use of BGP Local Preference in path selection to choose a
particular NLRI, where Local Preference indicates the degree of particular NLRI, where Local Preference indicates the degree of
preference for a particular VE. The use of Local Preference is preference for a particular VE. The use of Local Preference is
inadequate when VPLS PEs are spread across multiple ASes as Local inadequate when VPLS PEs are spread across multiple ASes as Local
Preference is not carried across AS boundary. A new field, VPLS Preference is not carried across AS boundary. A new field, VPLS
preference (VP), is introduced in this document that can be used to preference (VP), is introduced in this document that can be used to
accomplish this. VPLS preference indicates a degree of preference for accomplish this. VPLS preference indicates a degree of preference
a particular customer site. VPLS preference is not mandatory for for a particular customer site. VPLS preference is not mandatory for
intra-AS operation; the algorithm explained in Section 3.3 will work intra-AS operation; the algorithm explained in Section 3.3 will work
with or without the presence of VPLS preference. with or without the presence of VPLS preference.
Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended
Community that carries control information about the pseudowires. The Community that carries control information about the pseudowires.
last two octets that were reserved now carries VPLS preference as The last two octets that were reserved now carries VPLS preference as
shown in Figure 3. shown in Figure 3.
+------------------------------------+ +------------------------------------+
| Extended community type (2 octets) | | Extended community type (2 octets) |
+------------------------------------+ +------------------------------------+
| Encaps Type (1 octet) | | Encaps Type (1 octet) |
+------------------------------------+ +------------------------------------+
| Control Flags (1 octet) | | Control Flags (1 octet) |
+------------------------------------+ +------------------------------------+
| Layer-2 MTU (2 octet) | | Layer-2 MTU (2 octet) |
+------------------------------------+ +------------------------------------+
| VPLS Preference (2 octets) | | VPLS Preference (2 octets) |
+------------------------------------+ +------------------------------------+
Figure 4 Layer 2 Info Extended Community Figure 3: Layer2 Info Extended Community
A VPLS preference is a 2-octets unsigned integer. A value of zero A VPLS preference is a 2-octets unsigned integer. A value of zero
indicates absence of a VP and is not a valid preference value. This indicates absence of a VP and is not a valid preference value. This
interpretation is required for backwards compatibility. interpretation is required for backwards compatibility.
Implementations using Layer2 Info Extended Community as described in Implementations using Layer2 Info Extended Community as described in
(Section 3.2.4) [RFC4761] MUST set the last two octets as zero since (Section 3.2.4) [RFC4761] MUST set the last two octets as zero since
it was a reserved field. it was a reserved field.
For backwards compatibility, if VP is used, then BGP Local Preference For backwards compatibility, if VPLS preference is used, then BGP
MUST be set to the value of VP. Note that a Local Preference value of Local Preference MUST be set to the value of VPLS preference. Note
zero for a MH-Site is not valid unless 'D' bit in the control flags that a Local Preference value of zero for a MH-ID is not valid unless
is set (see [I-D.kothari-l2vpn-auto-site-id]). In addition, Local 'D' bit in the control flags is set (see
Preference value greater than or equal to 2^16 for VPLS [I-D.kothari-l2vpn-auto-site-id]). In addition, Local Preference
advertisements is not valid. value greater than or equal to 2^16 for VPLS advertisements is not
valid.
4.3. Use of BGP-MH attributes in Inter-AS Methods 4.3. Use of BGP-MH attributes in Inter-AS Methods
Section 3.4 in [RFC4761] and section 4 in [I-D.ietf-l2vpn-signaling] Section 3.4 in [RFC4761] and section 4 in [I-D.ietf-l2vpn-signaling]
describe three methods (a, b and c) to connect sites in a VPLS to PEs describe 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) that are across multiple AS. Since VPLS advertisements in method (a)
do not cross AS boundaries, multi-homing operations for method (a) do not cross AS boundaries, multi-homing operations for method (a)
remain exactly the same as they are within as AS. However, for method remain exactly the same as they are within as AS. However, for
(b) and (c), VPLS advertisements do cross AS boundary. This section method (b) and (c), VPLS advertisements do cross AS boundary. This
describes the VPLS operations for method (b) and method (c). Consider section describes the VPLS operations for method (b) and method (c).
Figure 5 for inter-AS VPLS with multi-homed customer sites. Consider Figure 4 for inter-AS VPLS with multi-homed customer sites.
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information
between ASBRs between ASBRs
AS1 AS2 AS1 AS2
........ ........ ........ ........
CE2 _______ . . . . CE2 _______ . . . .
___ PE1 . . PE3 --- CE3 ___ PE1 . . PE3 --- CE3
/ : . . : / : . . :
__/ : : : : __/ : : : :
CE1 __ : ASBR1 --- ASBR2 : CE1 __ : ASBR1 --- ASBR2 :
\ : : : : \ : : : :
\___ PE2 . . PE4 ---- CE4 \___ PE2 . . PE4 ---- CE4
. . . . . . . .
........ ........ ........ ........
Figure 5 Inter-AS VPLS Figure 4: Inter-AS VPLS
A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed 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 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. Assume that in also single homed to PE3 and PE4 respectively in AS2. Assume that in
addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), MH ID addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), MH ID
1 is assigned for CE1. After running DF election algorithm, all four 1 is assigned for CE1. After running DF election algorithm, all four
VPLS PEs must elect the same designated forwarder for CE1 site. Since VPLS PEs must elect the same designated forwarder for CE1 site.
BGP Local Preference is not carried across AS boundary, VPLS Since BGP Local Preference is not carried across AS boundary, VPLS
preference as described in Section 4.2 MUST be used for carrying site preference as described in Section 4.2 MUST be used for carrying site
preference in inter-AS VPLS operations. preference in inter-AS VPLS operations.
For Inter-AS method (b) ASBR1 will send a VPLS NLRI received from PE1 For Inter-AS method (b) ASBR1 will send a VPLS NLRI received from PE1
to ASBR2 with itself as the BGP nexthop. ASBR2 will send the received to ASBR2 with itself as the BGP nexthop. ASBR2 will send the
NLRI from ASBR1 to PE3 and PE4 with itself as the BGP nexthop. Since received NLRI from ASBR1 to PE3 and PE4 with itself as the BGP
VPLS PEs use BGP Local Preference in DF election, for backwards nexthop. Since VPLS PEs use BGP Local Preference in DF election, for
compatibility, ASBR2 MUST set the Local Preference value in the VPLS backwards compatibility, ASBR2 MUST set the Local Preference value in
advertisements it sends to PE3 and PE4 to the VPLS preference value the VPLS advertisements it sends to PE3 and PE4 to the VPLS
contained in the VPLS advertisement it receives from ASBR1. ASBR1 preference value contained in the VPLS advertisement it receives from
MUST do the same for the NLRIs it sends to PE1 and PE2. If ASBR1 ASBR1. ASBR1 MUST do the same for the NLRIs it sends to PE1 and PE2.
receives a VPLS advertisement without a valid VPLS preference from a If ASBR1 receives a VPLS advertisement without a valid VPLS
PE within its AS, then ASBR1 MUST set the VPLS preference in the preference from a PE within its AS, then ASBR1 MUST set the VPLS
advertisements to the Local Preference value before sending it to preference in the advertisements to the Local Preference value before
ASBR2. Similarly, ASBR2 must do the same for advertisements without sending it to ASBR2. Similarly, ASBR2 must do the same for
VPLS Preference it receives from PEs within its AS. Thus, in method advertisements without VPLS Preference it receives from PEs within
(b), ASBRs MUST update the VPLS and Local Preference based on the its AS. Thus, in method (b), ASBRs MUST update the VPLS and Local
advertisements they receive either from an ASBR or a PE within their Preference based on the advertisements they receive either from an
AS. ASBR or a PE within their AS.
In Figure 5, PE1 will send the VPLS advertisements, including the In Figure 4, PE1 will send the VPLS advertisements with Route Origin
ones for MH site CE1, with Route Origin Extended Community containing Extended Community containing its loopback address. PE2 will do the
its loopback address. PE2 will do the same. Even though PE3 receives same. Even though PE3 receives the VPLS advertisements for VE-ID 1
the VPLS advertisements from the same BGP nexthop, ASBR2, the source and 2 from the same BGP nexthop, ASBR2, the source PE address
PE address contained in the Route Origin Extended Community is contained in the Route Origin Extended Community is different for the
different for the VPLS advertisements received from PE1 and PE2, and CE1 and CE2 advertisements, and thus, PE3 creates two PWs, one for
thus, PE3 can apply correctly the DF Election algorithm as the CE1 (for VE-ID 1) and another one for CE2 (for VE-ID 2).
resulting PE-IDs are different.
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of VPLS 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of VPLS
Information between ASes Information between ASes
In this method, there is a multi-hop E-BGP peering between the PEs or 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 Route Reflectors in AS1 and the PEs or Route Reflectors in AS2.
is no VPLS state in either control or data plane on the ASBRs. 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 The multi-homing operations on the PEs in this method are exactly the
same as they are in intra-AS scenario. However, since Local same as they are in intra-AS scenario. However, since Local
Preference is not carried across AS boundary, the translation of LP 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 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 VPLS advertisements to other ASes. This is exactly the same as what
ASBR does in case of method (b). A RR must set the VP to the LP value a ASBR does in case of method (b). A RR must set the VP to the LP
in an advertisement before sending it to other ASes and must set the value in an advertisement before sending it to other ASes and must
LP to the VP value in an advertisement that it receives from other set the LP to the VP value in an advertisement that it receives from
ASes before sending to the PEs within the AS. other ASes before sending to the PEs within the AS.
5. MAC Flush Operations 5. MAC Flush Operations
In a service provider VPLS network, customer MAC learning is confined In a service provider VPLS network, customer MAC learning is confined
to PE devices and any intermediate nodes, such as a Route Reflector, to PE devices and any intermediate nodes, such as a Route Reflector,
do not have any state for MAC addresses. do not have any state for MAC addresses.
Topology changes either in the service provider's network or in Topology changes either in the service provider's network or in
customer's network can result in the movement of MAC addresses from customer's network can result in the movement of MAC addresses from
one PE device to another. Such events can result into traffic being 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 dropped due to stale state of MAC addresses on the PE devices. Age
out timers that clear the stale state will resume the traffic out timers that clear the stale state will resume the traffic
forwarding, but age out timers are typically in minutes, and forwarding, but age out timers are typically in minutes, and
convergence of the order of minutes can severely impact customer's convergence of the order of minutes can severely impact customer's
service. To handle such events and expedite convergence of traffic, service. To handle such events and expedite convergence of traffic,
flushing of affected MAC addresses is highly desirable. flushing of affected MAC addresses is highly desirable.
This section describes the scenarios where VPLS flush is desirable This section describes the scenarios where VPLS flush is desirable
and the specific VPLS Flush TLVs that provide capability to flush the and the specific VPLS Flush TLVs that provide capability to flush the
affected MAC addresses on the PE devices. All operations described in affected MAC addresses on the PE devices. All operations described
this section are in context of a particular VPLS domain and not in this section are in context of a particular VPLS domain and not
across multiple VPLS domains. Mechanisms for MAC flush are described across multiple VPLS domains. Mechanisms for MAC flush are described
in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762] in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762]
for LDP based VPLS. for LDP based VPLS.
5.1. MAC List Flush 5.1. MAC List FLush
If multiple customer sites are connected to the same PE, PE1 as shown 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 in Figure 2, and redundancy per site is desired when multi-homing
procedures described in this document are in effect, then it is procedures described in this document are in effect, then it is
desirable to flush just the relevant MAC addresses from a particular desirable to flush just the relevant MAC addresses from a particular
site when the site connectivity is lost. site when the site connectivity is lost.
To flush particular set of MAC addresses, a PE SHOULD originate a To flush particular set of MAC addresses, a PE SHOULD originate a
flush message with MAC list that contains a list of MAC addresses flush message with MAC list that contains a list of MAC addresses
that needs to be flushed. In Figure 2, if connectivity between CE1 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, 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 PE1 MAY send a list of MAC addresses that belong to CE1 to all its
BGP peers. BGP peers.
It is RECOMMENDED that in case of excessive link flap of customer 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 attachment circuit in a short duration, a PE should have a means to
throttle advertisements of flush messages so that excessive flooding throttle advertisements of flush messages so that excessive flooding
of such advertisements do not occur. of such advertisements do not occur.
5.2. Implicit MAC Flush 5.2. Implicit MAC Flush
When connectivity to a customer site is lost, remote PEs learn that a Implicit MAC Flush refers to the use of BGP MH advertisements by the
particular site is no longer reachable. The local PE either withdraws PEs to flush the MAC addresses learned from the previous designated
the VPLS NLRI that it previously advertised for the site or it sends forwarder.
a BGP update message for the site's VPLS NLRI with the 'D' bit set.
If a remote PE detects that a multi-homed PE has transitioned from In case of a failure, when connectivity to a customer site is lost,
being a DF to a non-DF, then the remote PE can choose to flush all remote PEs learn that a particular site is no longer reachable. The
MAC addresses that it learned from the multi-homed PE transitioning local PE either withdraws the VPLS NLRI that it previously advertised
from DF to non-DF. Alternatively the remote PE may chose to react for the site or it sends a BGP update message for the site's VPLS
when detecting the non-DF to DF transition for a multi-homed PE by NLRI with the 'D' bit set. In such cases, the remote PEs can flush
flushing in the related VPLS context all the MACs learned with the all the MACs that were learned from the PE which reported the
exception of the MACs associated with the new DF PE. failure.
6. Backwards Compatibility However, in cases when a designated forwarder change occurs in
absence of failures, such as when an attachment circuit comes up, the
BGP MH advertisement from the PE reporting the change is not
sufficient for MAC flush procedures. Consider the case in Figure 2
where PE1-CE1 link is non-operational and PE2 is the designated
forwarder for CE1. Also assume that Local Preference of PE1 is
higher than PE2. When PE1-CE1 link becomes operational, PE1 will
send a BGP MH advertisement to all it's peers. If PE3 elects PE1 as
the new designated forwarder for CE1 and as a result flushes all the
MACs learned from PE1 before PE2 elects itself as the non-designated
forwarder, there is a chance that PE3 might learn MAC addresses from
PE2 and as a result may black-hole traffic until those MAC addresses
are deleted due to age out timers.
A new flag 'F' is introduced in the Control Flags Bit Vector as a
deterministic way to indicate when to flush.
Control Flags Bit Vector
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|A|F|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 5
A designatd forwarder must set the F bit and a non-designated
forwarder must clear the F bit when sending BGP MH advertisements. A
state transition from one to zero for the F bit can be used by a
remote PE to flush all the MACs learned from the PE that is
transitioning from designated forwarder to non-designated forwarder.
5.3. Minimizing the effects of fast link transitions
Certain failure scenarios may result in fast transitions of the link
towards the multi-homing CE which in turn will generate fast status
transitions of one or multiple multi-homed sites reflected through
multiple BGP MH advertisements and LDP MAC Flush messages.
It is recommended that a timer to damp the link flaps be used for the
port towards the multi-homed CE to minimize the number of MAC Flush
events in the remote PEs and the occurrences of BGP state
compressions for F bit transitions. A timer value more than the time
it takes BGP to converge in the network is recommended.
6. Backwards Compatibility
No forwarding loops are formed when PEs or Route Reflectors that do No forwarding loops are formed when PEs or Route Reflectors that do
not support procedures defined in this section co exist in the not support procedures defined in this section co exist in the
network with PEs or Route Reflectors that do support. network with PEs or Route Reflectors that do support.
6.1. BGP based VPLS 6.1. BGP based VPLS
As explained in this section, multi-homed PEs to the same customer As explained in this section, multi-homed PEs to the same customer
site MUST assign the same MH-ID and related NLRI SHOULD contain the site MUST assign the same MH-ID and related NLRI SHOULD contain the
block offset, block size and label base as zero. Remote PEs that lack block offset, block size and label base as zero. Remote PEs that
support of multi-homing operations specified in this document will lack support of multi-homing operations specified in this document
fail to create any PWs for the multi-homed MH-IDs due to the label will fail to create any PWs for the multi-homed MH-IDs due to the
value of zero and thus, the multi-homing NLRI should have no impact label value of zero and thus, the multi-homing NLRI should have no
on the operation of Remote PEs that lack support of multi-homing impact on the operation of Remote PEs that lack support of multi-
operations specified in this document. homing operations specified in this document.
6.2. LDP VPLS with BGP Auto-discovery 6.2. LDP VPLS with BGP Auto-discovery
The BGP-AD NLRI has a prefix length of 12 containing only a 8 bytes The BGP-AD NLRI has a prefix length of 12 containing only a 8 bytes
RD and a 4 bytes VSI-ID. If a LDP VPLS PEs running BGP AD lacks RD and a 4 bytes VSI-ID. If a LDP VPLS PEs running BGP AD lacks
support of multi-homing operations specified in this document, it support of multi-homing operations specified in this document, it
SHOULD ignore a MH NLRI with the length field of 17. As a result it SHOULD ignore a MH NLRI with the length field of 17. As a result it
will not ask LDP to create any PWs for the multi-homed Site-ID and will not ask LDP to create any PWs for the multi-homed Site-ID and
thus, the multi-homing NLRI should have no impact on LDP VPLS thus, the multi-homing NLRI should have no impact on LDP VPLS
operation. operation. MH PEs may use existing LDP MAC Flush to flush the remote
LDP VPLS PEs or may use the implicit MAC Flush procedure.
7. Security Considerations 7. Security Considerations
No new security issues are introduced beyond those that are described No new security issues are introduced beyond those that are described
in [RFC4761] and [RFC4762]. in [RFC4761] and [RFC4762].
8. IANA Considerations 8. IANA Considerations
At this time, this memo includes no request to IANA. At this time, this memo includes no request to IANA.
9. References 9. Acknowledgments
9.1. Normative References The authors would like to thank Yakov Rekhter, Nischal Sheth, and
Mitali Singh for their insightful comments and probing questions.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10. References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 10.1. Normative References
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Heron, "Pseudowire Setup and Maintenance Using the Label Requirement Levels", BCP 14, RFC 2119, March 1997.
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
Emulation (PWE3)", BCP 116, RFC 4446, April 2006. (VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[I-D.ietf-l2vpn-signaling] Rosen, E., "Provisioning, Autodiscovery, [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08 Heron, "Pseudowire Setup and Maintenance Using the Label
(work in progress), May 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
[I-D.kothari-l2vpn-vpls-flush] Kothari, B. and R. Fernando, "VPLS [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Flush in BGP-based Virtual Private LAN Service", draft- Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
kothari-l2vpn-vpls-flush-00 (work in progress), October
2008.
[I-D.kothari-l2vpn-auto-site-id] Kothari, B., Kompella, K., and T. [I-D.ietf-l2vpn-signaling]
IV, "Automatic Generation of Site IDs for Virtual Private Rosen, E., "Provisioning, Autodiscovery, and Signaling in
LAN Service", draft-kothari-l2vpn-auto-site-id-01 (work in L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress),
progress), October 2008. May 2006.
[I-D.ietf-pwe3-redundancy-bit] Muley, P., Bocci, M., and L. Martini, [I-D.kothari-l2vpn-vpls-flush]
"Preferential Forwarding Status bit definition", draft- Kothari, B. and R. Fernando, "VPLS Flush in BGP-based
ietf-pwe3-redundancy-bit-01 (work in progress), September Virtual Private LAN Service",
2008. draft-kothari-l2vpn-vpls-flush-00 (work in progress),
October 2008.
9.2. Informative References [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.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [I-D.ietf-pwe3-redundancy-bit]
Communities Attribute", RFC 4360, February 2006. Muley, P., "May 14, 2010 Pseudowire Preferential
Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-03
(work in progress), May 2010.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 10.2. Informative References
Networks (VPNs)", RFC 4364, February 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, Communities Attribute", RFC 4360, February 2006.
April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
(VPLS) Using Label Distribution Protocol (LDP) Signaling", Networks (VPNs)", RFC 4364, February 2006.
RFC 4762, January 2007.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Protocol 4 (BGP-4)", RFC 4271, January 2006. Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
10. Acknowledgments [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Singh, Deven Raut and Nehal Bhau for their insightful comments and Protocol 4 (BGP-4)", RFC 4271, January 2006.
probing questions.
Authors' Addresses Authors' Addresses
Bhupesh Kothari Bhupesh Kothari
Juniper Networks Cisco Systems
1194 N. Mathilda Ave. 3750 Cisco Way
Sunnyvale, CA 94089 US San Jose, CA 95134
US
Email: bhupesh@juniper.net Email: bhupesh@cisco.com
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 US Sunnyvale, CA 94089
US
Email: kireeti@juniper.net Email: kireeti@juniper.net
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp, Belgium
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.be
Florin Balus Florin Balus
Alcatel-Lucent Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com Email: florin.balus@alcatel-lucent.com
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA US
Email: uttaro@att.com Email: uttaro@att.com
 End of changes. 152 change blocks. 
405 lines changed or deleted 432 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/