draft-ietf-l2vpn-vpls-multihoming-04.txt   draft-ietf-l2vpn-vpls-multihoming-05.txt 
Internet Engineering Task Force B. Kothari
Internet Draft Cohere Networks
Updates: 4761 (if approved)
Intended status: Standards Track K. Kompella
Expires: April 2013 Contrail Systems
W. Henderickx
F. Balus
S. Palislamovic
Alcatel-Lucent
J. Uttaro
AT&T
W. Lin
Juniper Networks
October 21, 2012 Network Working Group B. Kothari
Internet-Draft Cohere Networks
Updates: 4761 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks
Expires: August 29, 2013 W. Henderickx
F. Balus
Alcatel-Lucent
J. Uttaro
AT&T
S. Palislamovic
Alcatel-Lucent
W. Lin
Juniper Networks
February 25, 2013
BGP based Multi-homing in Virtual Private LAN Service BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-l2vpn-vpls-multihoming-04.txt draft-ietf-l2vpn-vpls-multihoming-05.txt
Abstract Abstract
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 the Service Provider (SP) to give the customer required for the Service Provider (SP) to give the customer redundant
redundant connectivity to some sites, often called "multi-homing". connectivity to some sites, often called "multi-homing". This memo
This memo shows how BGP-based multi-homing can be offered in the shows how BGP-based multi-homing can be offered in the context of LDP
context of LDP and BGP VPLS solutions. and BGP VPLS solutions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html 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."
This Internet-Draft will expire on April 21, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
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.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Terminology.......................................4 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document.........................5 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Background.....................................................6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scenarios.................................................6 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. VPLS Multi-homing Considerations..........................7 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 7
3. Multi-homing Operations........................................8 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 8
3.1. Provisioning Model........................................8 3.1. Multi-homing NLRI . . . . . . . . . . . . . . . . . . . . 8
3.2. Multi-homing NLRI.........................................8 3.2. Provisioning Model . . . . . . . . . . . . . . . . . . . . 9
3.3. Designated Forwarder Election.............................9 3.3. Designated Forwarder Election . . . . . . . . . . . . . . 10
3.3.1. Attributes...........................................9 3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Variables Used.......................................9 3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . . 11
3.3.2.1. RD.............................................10 3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 12
3.3.2.2. MH-ID..........................................10 3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . . 14
3.3.2.3. VBO............................................10 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2.4. DOM............................................10 4.1. Route Origin Extended Community . . . . . . . . . . . . . 15
3.3.2.5. ACS............................................10 4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 15
3.3.2.6. PREF...........................................11 4.3. Use of BGP-MH attributes in Inter-AS Methods . . . . . . . 16
3.3.2.7. PE-ID..........................................11 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS
3.4. VPLS DF Election on PEs..................................14 Information between ASBRs . . . . . . . . . . . . . . 16
3.5. Pseudowire binding and traffic forwarding rules..........14 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution
3.5.1. Site-ID Binding Properties..........................14 of VPLS Information between ASes . . . . . . . . . . . 17
3.5.2. Standby Pseudowire Properties.......................15 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 19
4. Multi-AS VPLS.................................................16 5.1. MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Route Origin Extended Community..........................16 5.2. Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 19
4.2. Preference...............................................16 5.3. Minimizing the effects of fast link transitions . . . . . 20
4.3. Use of BGP-MH attributes in Inter-AS Methods.............17 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 21
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . . 21
Information between ASBRs ......18 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . . 21
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
VPLS Information between ASes ..............19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5. MAC Flush Operations..........................................20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. MAC List FLush...........................................20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Implicit MAC Flush.......................................21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
5.3. Minimizing the effects of fast link transitions..........22 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
6. Backwards Compatibility.......................................23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. BGP based VPLS...........................................23
6.2. LDP VPLS with BGP Auto-discovery.........................23
7. Security Considerations.......................................24
8. IANA Considerations...........................................25
9. Acknowledgments...............................................26
10. References...................................................27
10.1. Normative References....................................27
10.2. Informative References..................................27
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. [RFC6074] explains how multi-homing can be achieved in this context. [RFC6074] explains how
VPLS can be offered using BGP for auto- discovery, (BGP-AD) and VPLS can be offered using BGP for auto-discovery (BGP-AD) and
[RFC4762] explains how VPLS can be offered using LDP for signaling. [RFC4762] explains how VPLS can be offered using LDP for signaling.
This document provides a BGP-based multi-homing solution applicable This document provides a BGP-based multi-homing solution applicable
to both BGP and LDP VPLS technologies. Note that BGP MH can be used to both BGP and LDP VPLS technologies. Note that BGP MH can be used
for LDP VPLS without the use of the BGP- AD solution. for LDP VPLS without the use of the BGP-AD solution.
Section 2 lays out some of the scenarios for multi-homing, other Section 2 lays out some of the scenarios for multi-homing, other ways
ways that this can be achieved, and some of the expectations of BGP- that this can be achieved, and some of the expectations of BGP-based
based multi-homing. Section 3 defines the components of BGP-based multi-homing. Section 3 defines the components of BGP-based multi-
multi-homing, and the procedures required to achieve this. Section homing, and the procedures required to achieve this. Section 7 may
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 domain. A VPLS site is a grouping of ports on a PE that belong to
the same VPLS domain. A Multi-homed (MH) site is uniquely the same VPLS domain. A Multi-homed (MH) site is uniquely identified
identified by a MH site ID (MH-ID). Sites are referred to as local by a MH site ID (MH-ID). Sites are referred to as local or remote
or remote depending on whether they are configured on the PE router depending on whether they are configured on the PE router in context
in context or on one of the remote PE routers (network peers). or on one of the remote PE routers (network peers). The terms "VPLS
instance" and "VPLS domain" are used interchangeably in this
document.
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 RFC-2119 [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 required, and the implications thereof. It also describes some of
the singular properties of VPLS multi-homing, and what that means the singular properties of VPLS multi-homing, and what that means
from both an operational point of view and an implementation point from both an operational point of view and an implementation point of
of view. There are other approaches for providing multi-homing such view. There are other approaches for providing multi-homing such as
as Spanning Tree Protocol, and this document specifies use of BGP Spanning Tree Protocol, and this document specifies use of BGP for
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
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
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 CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant
redundant connectivity. However, CE4, which is also in the same connectivity. However, CE4, which is also in the same VPLS domain,
VPLS domain, is 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 The first (perhaps obvious) fact about a multi-homed VPLS CE, such as
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. situation for an Ethernet network, and the loop must be broken. Even
Even if CE1 is a router, it will get duplicates every time a packet if CE1 is a router, it will get duplicates every time a packet is
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 of PE1 and PE2 can be actively sending traffic, either towards CE1 or
or into the SP cloud. That is to say, load balancing techniques into the SP cloud. That is to say, load balancing techniques will
will not work. All other PEs MUST choose the same designated not work. All other PEs MUST choose the same designated forwarder
forwarder for a multi-homed site. Call the PE that is chosen to for a multi-homed site. Call the PE that is chosen to send traffic
send traffic to/from 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 Operations 3. Multi-homing Operation
This section describes procedures for electing a designated This section describes procedures for electing a designated forwarder
forwarder among the set of PEs that are multi-homed to a customer among the set of PEs that are multi-homed to a customer site. The
site. The procedures described in this section are applicable to procedures described in this section are applicable to BGP based
BGP based VPLS, LDP based VPLS with BGP-AD or a VPLS that contains a VPLS, LDP based VPLS with BGP-AD or a VPLS that contains a mix of
mix of both BGP and LDP signaled PWs. both BGP and LDP signaled PWs.
3.1. Provisioning Model 3.1. Multi-homing NLRI
Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, Section 3.2.2 in [RFC4761] specifies a NLRI to be used for BGP based
PE1 and PE2. In order for all VPLS PEs within the same VPLS domain VPLS (BGP VPLS NLRI). The format of the BGP VPLS NLRI is shown
to elect one of the multi-homed PEs as the designated forwarder, an below.
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-ID) on PE1 and PE2 for CE1. When remote VPLS PEs receive | Length (2 octets) |
NLRI advertisement from PE1 and PE2 for CE1, the two NLRI +------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
BGP VPLS NLRI
For multi-homing operation, a multi-homing NLRI (MH NLRI) is proposed
that uses BGP VPLS NLRI with the following fields set to zero: VE
Block Offset, VE Block Size and Label Base. In addition, the VE-ID
field of the NLRI is set to MH-ID. Thus, the MH NLRI contains 2
octets indicating the length, 8 octets for Route Distinguisher, 2
octets for MH-ID and 7 octets with value zero.
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. VPLS operations,
including multi-homing, in such a case are outside the scope of this
document. However, for interoperability with existing deployments
that use non-zero VE block offset, VE block size and label base for
multi-homing operation, Section 6.1 provides more detail.
3.2. Provisioning Model
It is mandatory that each instance within a VPLS domain MUST be
provisioned with a unique Route Distinguisher value. Unique Route
Distinguisher allows VPLS advertisements from different VPLS PEs to
be distinct even if the advertisements have the same VE-ID, which can
occur in case of multi-homing. This allows standard BGP path
selection rules to be applied to VPLS advertisements.
Each VPLS PE must advertise a unique VE-ID with non-zero VE Block
Offset, VE Block Size and Label Base values in the BGP NLRI. VE-ID
is associated with the base VPLS instance and the NLRI associated
with it must be used for creating PWs among VPLS PEs. Any single
homed customer sites connected to the VPLS instance do not require
any special addressing. Any multi-homed customer sites connected to
the VPLS instance require special addressing, which is achieved by
use of MH-ID. A set of customer sites are distinguished as multi-
homed if they all have the same MH-ID. The following examples
illustrate the use of VE-ID and MH-ID.
Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1
and PE2. In order for all VPLS PEs to set up PWs to each other, each
VPLS PE must be configured with a unique VE-ID for its base VPLS
instance. In addition, 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-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 advertisements for CE1 are identified as candidates for designated
forwarder selection due to the same MH-ID. Thus, same MH-ID SHOULD forwarder selection due to the same MH-ID. Thus, same MH-ID MUST be
be assigned on all VPLS PEs that are multi-homed to the same assigned on all VPLS PEs that are multi-homed to the same customer
customer site. Note that a MH-ID=0 is invalid and a PE should site.
discard such an advertisement.
3.2. Multi-homing NLRI Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with
CE1 multi-homed to PE1 and PE2. Similar to Figure 1 provisioning
model, each VPLS PE must be configured with a unique VE-ID for it
base VPLS instance. CE4 does not require special addressing on PE1.
However, CE1 which is multi-homed to PE1 and PE2 requires
configuration of MH-ID and both PE1 and PE2 MUST be provisioned with
the same MH-ID for CE1.
Section 3.2.2 in [RFC4761] describes the encoding of the BGP VPLS Note that a MH-ID=0 is invalid and a PE should discard such an
NLRI with the following fields: VE-ID, VE block offset, VE block advertisement.
size and label base. While this NLRI MAY be used for multi-homing,
a modified version of it, as detailed in this paragraph, is used for
identifying the multi-homed customers sites. The VE-ID field in the
NLRI is set to MH-ID; the VE block offset, VE block size and label
base are set to zero. Thus, the NLRI contains 2 octets indicating
the length, 8 octets for Route Distinguisher, 2 octets for MH-ID and
7 octets with value zero.
Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 Use of multiple VE-IDs per VPLS instance for either multi-homing
with CE1 multi-homed to PE1 and PE2. CE4 does not require special operation or for any other purpose is outside the scope of this
addressing, being associated with the base VPLS instance identified document. However, for interoperability with existing deployments
by the VSI-ID for LDP VPLS and VE-ID for BGP VPLS. However, CE1 that use multiple VE-IDs, Section 6.1 provides more detail.
which is multi-homed to PE1 and PE2 requires configuration of MH-ID
and both PE1 and PE2 MUST be provisioned with the same MH-ID for
CE1. As stated above, to ensure backward capabilities, it is valid
to use BGP VPLS NLRI for multi-homing operations. As such, it is
valid to have non-zero VE block offset, VE block size and label base
in the VPLS NLRI for multi-homed site.
3.3. Designated Forwarder Election 3.3. Designated Forwarder Election
BGP-based multi-homing for VPLS relies on Standard BGP best path BGP-based multi-homing for VPLS relies on standard BGP path selection
selection and VPLS DF election. The net result of doing both and VPLS DF election. The net result of doing both BGP path
elections is that of electing a single designated forwarder (DF) selection and VPLS DF election is that of electing a single
among the set of PEs to which a customer site is multi-homed. All designated forwarder (DF) among the set of PEs to which a customer
the PEs that are elected as non-designated forwarders MUST keep site is multi-homed. All the PEs that are elected as non-designated
their attachment circuit to the multi-homed CE in blocked status (no forwarders MUST keep their attachment circuit to the multi-homed CE
forwarding). 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. Given that include both the NLRI and attached BGP attributes. These election
semantics of BGP VPLS NLRI does not necessarily follow a standard IP algorithms are applicable to all VPLS NLRIs, and not just to MH
Prefix form, a construct of advertisement (ADV) with the variables NLRIs. In order to simplify the explanation of these algorithms, we
of interest is defined. The variables of interest are: RD, MH-ID, will use a number of variables derived from fields in the VPLS
VBO, DOM, ACS, PREF and PE-ID, so the notation of: advertisement. These variables are: RD, SITE-ID, VBO, DOM, ACS, PREF
and PE-ID. The notation ADV -> <RD, SITE-ID, VBO, DOM, ACS, PREF,
PE-ID> means that from a received VPLS advertisement ADV, the
respective variables were derived. The following sections describe
two attributes needed for DF election, then describe the variables
and how they are derived from fields in VPLS advertisement ADV, and
finally describe how DF election is done.
ADV = <RD, MH-ID, VBO, DOM, ACS, PREF, PE-ID> 3.3.1. Attributes
The following sections describe two attributes needed for standard The procedures below refer to two attributes: the Route Origin
BGP best path selection and VPLS DF election, the variables derived community (see Section 4.1) and the L2-info community (see
from fields in VPLS advertisement ADV, and finally elaborate on the Section 4.2). These attributes are required for inter-AS operation;
selection processes. for generality, the procedures below show how they are to be used.
The procedures also outline how to handle the case that either or
both are not present.
3.3.1. Attributes For BGP-based Multi-homing, ADV MUST contain an L2-info extended
community as specified in [RFC4761]. Within this community are
various control flags. Two new control flags are proposed in this
document. Figure 3 shows the position of the new 'D' and 'F' flags.
The procedures below refer to two attributes: the Route Origin Control Flags Bit Vector
community (see Section 4.1) and the L2-info community (see Section
4.2). These attributes are required for inter-AS operation; for
generality, the procedures below show how they are to be used. The
procedures also outline how to handle the case that either or both
are not present.
3.3.2. Variables Used 0 1 2 3 4 5 6 7
3.3.2.1. RD +-+-+-+-+-+-+-+-+
|D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
RD is simply set to the Route Distinguisher field in the NLRI part Figure 3
of ADV. Actual process of assigning Route Distinguisher values must
guarantee its uniqueness per PE node. Therefore, two multi-homed
PEs offering the same VPLS service to a common set of CEs MUST
allocate different RD values for this site respectively.
3.3.2.2. MH-ID 1. 'D' (Down): Indicates connectivity status between a CE site and a
VPLS PE. The bit MUST be set to one if all the attachment
circuits connecting a CE site to a VPLS PE are down.
MH-ID is simply set to the VE-ID field in the NLRI part of ADV. The 2. 'F' (Flush): Indicates when to flush MAC state. A designated
same MH-ID MUST be assigned to all PEs that are connected to the forwarder must set the F bit and a non-designated forwarder must
same multi-homed site. 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. Refer to Section 5.2 for more details on the use
case.
3.3.2.3. VBO 3.3.2. Variables Used
3.3.2.1. RD
RD is simply set to the Route Distinguisher field in the NLRI part of
ADV.
3.3.2.2. SITE-ID
SITE-ID is simply set to the VE-ID field in the NLRI part of the ADV.
Note that no distinction is made whether VE-ID is for a multi-homed
site or not.
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.
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 VPLS. ACS = 1 if all attachment circuits for the site are down, and
0 otherwise. 0 otherwise.
For BGP-based Multi-homing, ADV MUST contain an L2-info extended ACS is set to the value of the 'D' bit in ADV that belongs to MH
community; within this community are control flags. One of these NLRI. If ADV belongs to base VPLS instance with non-zero label block
flags is the 'D' bit, described in [I-D.kothari-l2vpn-auto-site-id]. values, no change must be made to ACS.
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 community. If the Local Preference attribute is missing, LP is set
to 0; if the L2-info community is missing, VP is set to 0. The to 0; if the L2-info community is missing, VP is set to 0. The
following 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 |
+---------+---------------+----------+------------------------------+ +---------+---------------+----------+------------------------------+
Table 1 Table 1
3.3.2.7. PE-ID 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 type 0x01, then PE-ID is set to the Global Administrator sub-field of
of the RO. Otherwise, if ADV has an ORIGINATOR_ID attribute, then the RO. Otherwise, if ADV has an ORIGINATOR_ID attribute, then PE-ID
PE-ID is set to the ORIGINATOR_ID. Otherwise, PE-ID is set to the is set to the ORIGINATOR_ID. Otherwise, PE-ID is set to the BGP
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. Subset of these procedures documented in BGP VPLS and LDP VPLS. A distinction MUST NOT be made on whether the
standard BGP best path selection deals with general IP Prefix BGP NLRI is a multi-homing NLRI or not. Subset of these procedures
route selection processing as defined in RFC 4271 and RFC 4364. A documented in standard BGP best path selection deals with general IP
Prefix BGP route selection processing as defined in [RFC4271]. A
separate part of the algorithm defined under VPLS DF election is separate part of the algorithm defined under VPLS DF election is
very specific to designated forwarded election procedures performed specific to designated forwarded election procedures performed on
on per VPLS instance bases. Given that the notion of VPLS VPLS advertisements. A concept of bucketization is introduced to
advertisement is not commonly used destination IP Prefix, a concept define route selection rules for VPLS advertisements. Note that this
of bucketization is introduced. By bucketizing advertisements and is a conceptual description of the process; an implementation MAY
running them through two different sets of procedures based on choose to realize this differently as long as the semantics are
variables of interest, we are effectively adopting common sets of preserved.
route selection rules to the VPLS environment. A distinction MUST
NOT be made on whether the NLRI is a multi-homing NLRI or not. Note
that this is a conceptual description of the process; an
implementation MAY choose to realize this differently as long as the
semantics are preserved.
3.3.3.1. Bucketization and BGP Best Path Selection
From the advertisement
ADV -> <RD, MH-ID, VBO, ACS, PREF, PE-ID> 3.3.3.1. Bucketization for standard BGP path selection
we select variables of interest that satisfy a notion of the same An advertisement
route as it is applicable to BGP election. As such, advertisements
with the exact same RD, MH-ID and VBO are candidates for BGP
Selection and put into BGP election bucket.
ADV -> <RD, MH-ID, VBO> ADV -> <RD, SITE-ID, VBO, ACS, PREF, PE-ID>
A standard set of BGP path selection rules, as defined in RFC 4271 is put into the bucket for <RD, SITE-ID, VBO>. In other words, the
and 4264 is applied as tie-breaking mechanism. These tie-breaking information in BGP path selection consists of <RD, SITE-ID, VBO> and
rules are applied to candidate advertisements by a BGP speaker only advertisements with exact same <RD, SITE-ID, VBO> are candidates
responsible for processing and redistribution of BGP VPLS and MH for BGP path selection procedure as defined in [RFC4271].
NLRI. If there is no winner and both ADVs are from the same PE, BGP
path selection should simply consider this an update.
3.3.3.2. Bucketization and 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, SITE-ID, VBO, DOM, ACS, PREF, PE-ID>
is discarded if DOM is not of interest to the VPLS PE. Otherwise, is discarded if DOM is not of interest to the VPLS PE. Otherwise,
ADV is put into the bucket for <DOM, MH-ID>. In other words, all ADV is put into the bucket for <DOM, SITE-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
and common DOM are candidates for VPLS DF election. Tie breaking SITE-ID are candidates for VPLS DF election.
rules for VPLS DF election are different from standard BGP best path
selection. As outlined in 3.3, the main reason for that is the fact 3.3.3.3. Tie-breaking Rules
that only single VPLS PE can be a designated forwarder for a given
site. Tie-breaking rules for VPLS DF election are applied to This section describes the tie-breaking rules for VPLS DF election.
candidate advertisements by all VPLS PEs and the actions taken by Tie-breaking rules for VPLS DF election are applied to candidate
VPLS PEs based on the VPLS DF election result are described advertisements by all VPLS PEs and the actions taken by VPLS PEs
in Section 3.4. based on the VPLS DF election result are described 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, SITE-ID1, VBO1, DOM1, ACS1, PREF1, PE-ID1>
ADV2 -> <RD2, MH-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2> ADV2 -> <RD2, SITE-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2>
Note that MH-ID1 = MH-ID2 and DOM1 = DOM2, since ADV1 and ADV2 came Note that SITE-ID1 = SITE-ID2 and DOM1 = DOM2, since ADV1 and ADV2
from the same bucket. Then the following tie-breaking rules MUST be came from the same bucket. Then the following tie-breaking rules
applied in the given order. MUST be 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
If there is no winner and ADV1 and ADV2 are from the same PE, a VPLS If there is no winner and ADV1 and ADV2 are from the same PE, a VPLS
PE MUST retain both ADV1 and ADV2. PE MUST retain both ADV1 and ADV2.
3.4. VPLS 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. addition, all other PEs SHOULD also run the DF election algorithm.
As a result of the DF election, multi-homed PEs that lose 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 SITE-ID MUST put the ACs associated with the SITE-ID
non-forwarding state. DF election result on the egress PEs can be in non-forwarding state.
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.
3.5. Pseudowire binding and traffic forwarding rules
3.5.1. Site-ID Binding Properties
For the use case where a single PE provides connectivity to a set of
CEs from which some on multi-homed and others are not, only single
pseudowire MAY be established. For example, if PE1 provides VPLS
service to CE1 and CE4 which are both part of the same VPLS domain,
but different sites, and CE1 is multi-homed, but CE4 is not (as
described in figure 2), PE3 would establish only single pseudowire
toward PE1. A design needs to ensure that regardless of PE1's
forwarding state in respect to DF or non-DF for multi-homed CE1,
PE3s access to CE4 is established. Since label allocation and
pseudowire established is tied to site-ID, we need to ensure that
proper pseudowire bindings are established.
For set of given advertisements with the common DOM but with
different Site-ID values, a VPLS PE speaker SHOULD instantiate and
bind the pseudowire based on advertisement with the lowest Site-ID
value. Otherwise, binding would be completely random and during DF
changes for multi-homed site, non-multi-homed CE might suffer
traffic loss.
3.5.2. Standby Pseudowire Properties
As the notion of the convergence is addressed for transport plane by DF election result on the egress PEs can be used in traffic
use of RSVP FRR and LDP LFA, it is evident that similar solution is forwarding decision. Figure 2 shows two customer sites, CE1 and CE4,
required at the service level plane as well. This is most evident connected to PE1 with CE1 multi-homed to PE1 and PE2. If PE1 is the
in large-scale deployments as it takes quite long time to converge. designated forwarder for CE1, based on the DF election result, PE3
Ingress PE usually has to handle multiple relatively larger tasks can chose to not send unknown unicast and multicast traffic to PE2 as
and re-signal all pseudowires affected by egress PE or AC failure. PE2 is not the designated forwarder for any customer site and it has
Therefore, an implementation MAY choose to optimize the convergence no other single homed sites connected to it.
by pre-signaling the second, standby, pseudowire toward non-DF end
point for every active VPLS in 1:1 fashion. This greatly improves
the convergence times. However, details of such implementation are
still under research.
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 set to 0x01 and the Global Administrator sub-field MUST be set to the
the PE's loopback IP address. PE's loopback IP address.
4.2. 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 accomplish this. VPLS preference indicates a degree of preference
for a particular customer site. VPLS preference is not mandatory for a particular customer site. VPLS preference is not mandatory for
for intra-AS operation; the algorithm explained in Section 3.3 will intra-AS operation; the algorithm explained in Section 3.3 will work
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. Community that carries control information about the pseudowires.
The last two octets that were reserved now carries VPLS preference The last two octets that were reserved now carries VPLS preference as
as shown in Figure 3. shown in Figure 4.
+------------------------------------+ +------------------------------------+
| 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 3: Layer2 Info Extended Community Figure 4: 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 VPLS preference is used, then BGP For backwards compatibility, if VPLS preference is used, then BGP
Local Preference MUST be set to the value of VPLS preference. Note Local Preference MUST be set to the value of VPLS preference. Note
that a Local Preference value of zero for a MH-ID is not valid nless that a Local Preference value of zero for a MH-ID is not valid unless
'D' bit in the control flags is set (see [I-D.kothari-l2vpn-auto- 'D' bit in the control flags is set (see
site-id]). In addition, Local Preference value greater than or [I-D.kothari-l2vpn-auto-site-id]). In addition, Local Preference
equal to 2^16 for VPLS 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 [RFC6074] describe three Section 3.4 in [RFC4761] and section 4 in [RFC6074] describe three
methods (a, b and c) to connect sites in a VPLS to PEs that are 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 across multiple AS. Since VPLS advertisements in method (a) do not
cross AS boundaries, multi-homing operations for method (a) remain cross AS boundaries, multi-homing operations for method (a) remain
exactly the same as they are within as AS. However, for method (b) exactly the same as they are within as AS. However, for method (b)
and (c), VPLS advertisements do cross AS boundary. This section and (c), VPLS advertisements do cross AS boundary. This section
describes the VPLS operations for method (b) and method (c). describes the VPLS operations for method (b) and method (c).
Consider Figure 4 for inter-AS VPLS with multi-homed customer sites. Consider Figure 5 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 4: Inter-AS VPLS Figure 5: Inter-AS VPLS
A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi- A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed
homed to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and CE4 are
CE4 are also single homed to PE3 and PE4 respectively in AS2. also single homed to PE3 and PE4 respectively in AS2. Assume that in
Assume that in addition to the base LDP/BGP VPLS addressing (VSI- addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), MH ID
IDs/VE-IDs), MH ID 1 is assigned for CE1. After running DF election 1 is assigned for CE1. After running DF election algorithm, all four
algorithm, all four VPLS PEs must elect the same designated VPLS PEs must elect the same designated forwarder for CE1 site.
forwarder for CE1 site. Since BGP Local Preference is not carried Since BGP Local Preference is not carried across AS boundary, VPLS
across AS boundary, VPLS preference as described in Section 4.2 MUST preference as described in Section 4.2 MUST be used for carrying site
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 For Inter-AS method (b) ASBR1 will send a VPLS NLRI received from PE1
PE1 to ASBR2 with itself as the BGP nexthop. ASBR2 will send the to ASBR2 with itself as the BGP nexthop. ASBR2 will send the
received NLRI from ASBR1 to PE3 and PE4 with itself as the BGP received NLRI from ASBR1 to PE3 and PE4 with itself as the BGP
nexthop. Since VPLS PEs use BGP Local Preference in DF election, nexthop. Since VPLS PEs use BGP Local Preference in DF election, for
for backwards compatibility, ASBR2 MUST set the Local Preference backwards compatibility, ASBR2 MUST set the Local Preference value in
value in the VPLS advertisements it sends to PE3 and PE4 to the VPLS the VPLS advertisements it sends to PE3 and PE4 to the VPLS
preference value contained in the VPLS advertisement it receives preference value contained in the VPLS advertisement it receives from
from ASBR1. ASBR1 MUST do the same for the NLRIs it sends to PE1 ASBR1. ASBR1 MUST do the same for the NLRIs it sends to PE1 and PE2.
and PE2. If ASBR1 receives a VPLS advertisement without a valid If ASBR1 receives a VPLS advertisement without a valid VPLS
VPLS preference from a PE within its AS, then ASBR1 MUST set the preference from a PE within its AS, then ASBR1 MUST set the VPLS
VPLS preference in the advertisements to the Local Preference value preference in the advertisements to the Local Preference value before
before sending it to ASBR2. Similarly, ASBR2 must do the same for sending it to ASBR2. Similarly, ASBR2 must do the same for
advertisements without VPLS Preference it receives from PEs within advertisements without VPLS Preference it receives from PEs within
its AS. Thus, in method (b), ASBRs MUST update the VPLS and Local its AS. Thus, in method (b), ASBRs MUST update the VPLS and Local
Preference based on the advertisements they receive either from an Preference based on the advertisements they receive either from an
ASBR or a PE within their AS. ASBR or a PE within their AS.
In Figure 4, PE1 will send the VPLS advertisements with Route Origin In Figure 5, PE1 will send the VPLS advertisements with Route Origin
Extended Community containing its loopback address. PE2 will do the Extended Community containing its loopback address. PE2 will do the
same. Even though PE3 receives the VPLS advertisements for VE-ID 1 same. Even though PE3 receives the VPLS advertisements for VE-ID 1
and 2 from the same BGP nexthop, ASBR2, the source PE address and 2 from the same BGP nexthop, ASBR2, the source PE address
contained in the Route Origin Extended Community is different for contained in the Route Origin Extended Community is different for the
the CE1 and CE2 advertisements, and thus, PE3 creates two PWs, one CE1 and CE2 advertisements, and thus, PE3 creates two PWs, one for
for CE1 (for VE-ID 1) and another one for CE2 (for VE-ID 2). CE1 (for VE-ID 1) and another one for CE2 (for VE-ID 2).
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 In this method, there is a multi-hop E-BGP peering between the PEs or
or Route Reflectors in AS1 and the PEs or Route Reflectors in AS2. 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. 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 multi-homing operations on the PEs in this method are exactly the
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 VPLS advertisements to other ASes. This is exactly the same as what
an ASBR does in case of method (b). A RR must set the VP to the LP 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 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 set the LP to the VP value in an advertisement that it receives from
other 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 In a service provider VPLS network, customer MAC learning is confined
confined to PE devices and any intermediate nodes, such as a Route to PE devices and any intermediate nodes, such as a Route Reflector,
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 and the specific VPLS Flush TLVs that provide capability to flush the
the affected MAC addresses on the PE devices. All operations affected MAC addresses on the PE devices. All operations described
described in this section are in context of a particular VPLS domain in this section are in context of a particular VPLS domain and not
and not across multiple VPLS domains. Mechanisms for MAC flush are across multiple VPLS domains. Mechanisms for MAC flush are described
described in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762]
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 If multiple customer sites are connected to the same PE, PE1 as shown
shown in Figure 2, and redundancy per site is desired when multi- in Figure 2, and redundancy per site is desired when multi-homing
homing procedures described in this document are in effect, then it procedures described in this document are in effect, then it is
is desirable to flush just the relevant MAC addresses from a desirable to flush just the relevant MAC addresses from a particular
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 MAY 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
Implicit MAC Flush refers to the use of BGP MH advertisements by the Implicit MAC Flush refers to the use of BGP MH advertisements by the
PEs to flush the MAC addresses learned from the previous designated PEs to flush the MAC addresses learned from the previous designated
forwarder. forwarder.
In case of a failure, when connectivity to a customer site is lost, In case of a failure, when connectivity to a customer site is lost,
remote PEs learn that a particular site is no longer reachable. The remote PEs learn that a particular site is no longer reachable. The
local PE either withdraws the VPLS NLRI that it previously local PE either withdraws the VPLS NLRI that it previously advertised
advertised for the site or it sends a BGP update message for the for the site or it sends a BGP update message for the site's VPLS
site's VPLS NLRI with the 'D' bit set. In such cases, the remote NLRI with the 'D' bit set. In such cases, the remote PEs can flush
PEs can flush all the MACs that were learned from the PE which all the MACs that were learned from the PE which reported the
reported the failure. failure.
However, in cases when a designated forwarder change occurs in However, in cases when a designated forwarder change occurs in
absence of failures, such as when an attachment circuit comes up, absence of failures, such as when an attachment circuit comes up, the
the BGP MH advertisement from the PE reporting the change is not BGP MH advertisement from the PE reporting the change is not
sufficient for MAC flush procedures. Consider the case in Figure 2 sufficient for MAC flush procedures. Consider the case in Figure 2
where PE1-CE1 link is non-operational and PE2 is the designated where PE1-CE1 link is non-operational and PE2 is the designated
forwarder for CE1. Also assume that Local Preference of PE1 is forwarder for CE1. Also assume that Local Preference of PE1 is
higher than PE2. When PE1-CE1 link becomes operational, PE1 will 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 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 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 MACs learned from PE1 before PE2 elects itself as the non-designated
forwarder, there is a chance that PE3 might learn MAC addresses from 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 PE2 and as a result may black-hole traffic until those MAC addresses
are deleted due to age out timers. 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 designated forwarder must set the F bit and a non-designated A designated forwarder must set the F bit and a non-designated
forwarder must clear the F bit when sending BGP MH advertisements. forwarder must clear the F bit when sending BGP MH advertisements. A
A state transition from one to zero for the F bit can be used by 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 remote PE to flush all the MACs learned from the PE that is
transitioning from designated forwarder to non-designated forwarder. transitioning from designated forwarder to non-designated forwarder.
5.3. Minimizing the effects of fast link transitions 5.3. Minimizing the effects of fast link transitions
Certain failure scenarios may result in fast transitions of the link Certain failure scenarios may result in fast transitions of the link
towards the multi-homing CE which in turn will generate fast status towards the multi-homing CE which in turn will generate fast status
transitions of one or multiple multi-homed sites reflected through transitions of one or multiple multi-homed sites reflected through
multiple BGP MH advertisements and LDP MAC Flush messages. multiple BGP MH advertisements and LDP MAC Flush messages.
It is recommended that a timer to damp the link flaps be used for It is recommended that a timer to damp the link flaps be used for the
the port towards the multi-homed CE to minimize the number of MAC port towards the multi-homed CE to minimize the number of MAC Flush
Flush events in the remote PEs and the occurrences of BGP state events in the remote PEs and the occurrences of BGP state
compressions for F bit transitions. A timer value more than the compressions for F bit transitions. A timer value more than the time
time it takes BGP to converge in the network is recommended. it takes BGP to converge in the network is recommended.
6. Backwards Compatibility 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 block offset, block size and label base as zero. Remote PEs that
lack support of multi-homing operations specified in this document lack support of multi-homing operations specified in this document
will fail to create any PWs for the multi-homed MH-IDs due to the will fail to create any PWs for the multi-homed MH-IDs due to the
label value of zero and thus, the multi-homing NLRI should have no label value of zero and thus, the multi-homing NLRI should have no
impact on the operation of Remote PEs that lack support of multi- impact on the operation of Remote PEs that lack support of multi-
homing operations specified in this document. homing operations specified in this document.
6.2. LDP VPLS with BGP Auto-discovery For compatibility with PEs that use multiple VE-IDs with non-zero
label block values for multi-homing operation, it is a requirement
that a PE receiving such advertisements must use the labels in the
NLRIs associated with lowest VE-ID for PW creation. It is possible
that maintaining PW association with lowest VE-ID can result in PW
flap, and thus, traffic loss. However, it is necessary to maintain
the assocation of PW with the lowest VE-ID as it provides
deterministic DF election among all the VPLS PEs.
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. MH PEs may use existing LDP MAC Flush to flush the operation. MH PEs may use existing LDP MAC Flush to flush the remote
remote LDP VPLS PEs or may use the implicit MAC Flush procedure. 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 No new security issues are introduced beyond those that are described
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. Acknowledgments 9. Acknowledgments
The authors would like to thank Ian Cowburn, Yakov Rekhter, Nischal The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali
Sheth, and Mitali Singh for their insightful comments and probing Singh and Ian Cowburn for their insightful comments and probing
questions. questions.
This document was prepared using 2-Word-v2.0.template.dot. 10. References
10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
Service (VPLS) Using BGP for Auto-Discovery and (VPLS) Using BGP for Auto-Discovery and Signaling",
Signaling", RFC 4761, January 2007. RFC 4761, January 2007.
[RFC6074] Rosen, E., "Provisioning, Autodiscovery, and Signaling [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
in L2VPNs", RFC 6074, January 2011. "Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074,
January 2011.
10.2. Informative References 10.2. Informative References
[I-D.kothari-l2vpn-vpls-flush] [I-D.kothari-l2vpn-vpls-flush]
Kothari, B. and R. Fernando, "VPLS Flush in BGP-based Kothari, B. and R. Fernando, "VPLS Flush in BGP-based
Virtual Private LAN Service", Virtual Private LAN Service",
draft-kothari-l2vpn-vpls-flush-00 (work in progress), draft-kothari-l2vpn-vpls-flush-00 (work in progress),
October 2008. October 2008.
[I-D.kothari-l2vpn-auto-site-id] [I-D.kothari-l2vpn-auto-site-id]
Kothari, B., Kompella, K., and T. IV, "Automatic Kothari, B., Kompella, K., and T. IV, "Automatic
Generation of Site IDs for Virtual Private LAN Service", Generation of Site IDs for Virtual Private LAN Service",
skipping to change at page 28, line 5 skipping to change at page 25, line 45
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006. (IBGP)", RFC 4456, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
Service (VPLS) Using Label Distribution Protocol (LDP) (VPLS) Using Label Distribution Protocol (LDP) Signaling",
Signaling", RFC 4762, January 2007. RFC 4762, January 2007.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
Authors' Addresses Authors' Addresses
Bhupesh Kothari Bhupesh Kothari
Cohere Networks Cohere Networks
295 Santa Ana Court
Sunnyvale, CA 94085
US
Email: bhupesh@cohere.net Email: bhupesh@cohere.net
Kireeti Kompella Kireeti Kompella
Contrail Systems Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@alcatel-lucent.be
Florin Balus Florin Balus
Alcatel-Lucent Alcatel-Lucent
Email: florin.balus@alcatel-lucent.com
Senad Palislamovic Email: florin.balus@alcatel-lucent.com
Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748, US Middletown, NJ 07748
US
Email: uttaro@att.com Email: uttaro@att.com
Senad Palislamovic
Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
 End of changes. 134 change blocks. 
508 lines changed or deleted 513 lines changed or added

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