draft-ietf-l2vpn-vpls-multihoming-05.txt   draft-ietf-l2vpn-vpls-multihoming-06.txt 
Network Working Group B. Kothari Network Working Group B. Kothari
Internet-Draft Cohere Networks Internet-Draft Gainspeed
Updates: 4761 (if approved) K. Kompella Updates: 4761 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: August 29, 2013 W. Henderickx Expires: January 16, 2014 W. Henderickx
F. Balus F. Balus
Alcatel-Lucent Alcatel-Lucent
J. Uttaro J. Uttaro
AT&T AT&T
S. Palislamovic S. Palislamovic
Alcatel-Lucent Alcatel-Lucent
W. Lin W. Lin
Juniper Networks Juniper Networks
February 25, 2013 July 15, 2013
BGP based Multi-homing in Virtual Private LAN Service BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-l2vpn-vpls-multihoming-05.txt draft-ietf-l2vpn-vpls-multihoming-06.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 redundant required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo connectivity to some sites, often called "multi-homing". This memo
shows how BGP-based multi-homing can be offered in the context of LDP shows how BGP-based multi-homing can be offered in the 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 7 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . 5
3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . . 8 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-homing NLRI . . . . . . . . . . . . . . . . . . . . 8 3.1. Customer Edge (CE) NLRI . . . . . . . . . . . . . . . . . 6
3.2. Provisioning Model . . . . . . . . . . . . . . . . . . . . 9 3.2. Provisioning Model . . . . . . . . . . . . . . . . . . . 7
3.3. Designated Forwarder Election . . . . . . . . . . . . . . 10 3.3. Designated Forwarder Election . . . . . . . . . . . . . . 8
3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . 9
3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 12 3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11
3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . . 14 3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . 13
4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Route Origin Extended Community . . . . . . . . . . . . . 15 4.1. Route Origin Extended Community . . . . . . . . . . . . . 13
4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 15 4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 13
4.3. Use of BGP-MH attributes in Inter-AS Methods . . . . . . . 16 4.3. Use of BGP attributes in Inter-AS Methods . . . . . . . . 14
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS
Information between ASBRs . . . . . . . . . . . . . . 16 Information between ASBRs . . . . . . . . . . . . . . 15
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of
of VPLS Information between ASes . . . . . . . . . . . 17 VPLS Information between ASes . . . . . . . . . 16
5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . . 19 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16
5.1. MAC List FLush . . . . . . . . . . . . . . . . . . . . . . 19 5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16
5.2. Implicit MAC Flush . . . . . . . . . . . . . . . . . . . . 19 5.2. Minimizing the effects of fast link transitions . . . . . 17
5.3. Minimizing the effects of fast link transitions . . . . . 20 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 21 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 18
6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . . 21 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18
6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 4, line 43 skipping to change at page 3, line 45
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 identified the same VPLS domain. The terms "VPLS instance" and "VPLS domain"
by a MH site ID (MH-ID). Sites are referred to as local or remote are used interchangeably in this document.
depending on whether they are configured on the PE router in context
or on one of the remote PE routers (network peers). The terms "VPLS A VPLS site connected to only one PE is called as single-homed VPLS
instance" and "VPLS domain" are used interchangeably in this site. The terms "VPLS site" and "CE site" are used interchangeably
document. in this document.
A VPLS site connected to multiple PEs is called as multi-homed site.
A BGP VPLS NLRI for the base VPLS instance that has non-zero VE block
offset, VE block size and label base is called as VE NLRI in this
document. Each VPLS instance is uniquely identified by a VE-ID. VE-
ID is carried in the BGP VPLS NLRI as specified in section 3.2.2 in
[RFC4761].
A VPLS NLRI with value zero for the VE block offset, VE block size
and label base is called as CE NLRI in this document.
Section Section 3.1 defines CE NLRI and provides more detail.
A Multi-homed (MH) site is uniquely identified by a CE-ID. Sites are
referred to as local or remote depending on whether they are
configured on the PE router in context or on one of the remote PE
routers (network peers). A single-homed site can also be assigned a
CE-ID, but it is not mandatory to configure a CE-ID for single-homed
sites. Section Section 3.1 provides detail on CE-ID.
1.2. Conventions 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
skipping to change at page 6, line 21 skipping to change at page 5, line 5
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
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, connectivity. However, CE4, which is also in the same 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 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
skipping to change at page 8, line 13 skipping to change at page 6, line 13
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. Multi-homing NLRI 3.1. Customer Edge (CE) NLRI
Section 3.2.2 in [RFC4761] specifies a NLRI to be used for BGP based Section 3.2.2 in [RFC4761] specifies a NLRI to be used for BGP based
VPLS (BGP VPLS NLRI). The format of the BGP VPLS NLRI is shown VPLS (BGP VPLS NLRI). The format of the BGP VPLS NLRI is shown
below. below.
+------------------------------------+ +------------------------------------+
| Length (2 octets) | | Length (2 octets) |
+------------------------------------+ +------------------------------------+
| Route Distinguisher (8 octets) | | Route Distinguisher (8 octets) |
+------------------------------------+ +------------------------------------+
| VE ID (2 octets) | | VE ID (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Offset (2 octets) | | VE Block Offset (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Size (2 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | Label Base (3 octets) |
+------------------------------------+ +------------------------------------+
BGP VPLS NLRI BGP VPLS NLRI
For multi-homing operation, a multi-homing NLRI (MH NLRI) is proposed For multi-homing operation, a customer-edge NLRI (CE NLRI) is
that uses BGP VPLS NLRI with the following fields set to zero: VE proposed that uses BGP VPLS NLRI with the following fields set to
Block Offset, VE Block Size and Label Base. In addition, the VE-ID zero: VE Block Offset, VE Block Size and Label Base. In addition,
field of the NLRI is set to MH-ID. Thus, the MH NLRI contains 2 the VE-ID field of the NLRI is set to CE-ID. Thus, the CE NLRI
octets indicating the length, 8 octets for Route Distinguisher, 2 contains 2 octets indicating the length, 8 octets for Route
octets for MH-ID and 7 octets with value zero. Distinguisher, 2 octets for CE-ID and 7 octets with value zero.
It is valid to have non-zero VE block offset, VE block size and label 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, 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 including multi-homing, in such a case are outside the scope of this
document. However, for interoperability with existing deployments document. However, for interoperability with existing deployments
that use non-zero VE block offset, VE block size and label base for that use non-zero VE block offset, VE block size and label base for
multi-homing operation, Section 6.1 provides more detail. multi-homing operation, Section 6.1 provides more detail.
Wherever VPLS NLRI is used in this document, context must be used to
infer if it is applicable for CE NLRI, VE NLRI or for both.
3.2. Provisioning Model 3.2. Provisioning Model
It is mandatory that each instance within a VPLS domain MUST be It is mandatory that each instance within a VPLS domain MUST be
provisioned with a unique Route Distinguisher value. Unique Route provisioned with a unique Route Distinguisher value. Unique Route
Distinguisher allows VPLS advertisements from different VPLS PEs to Distinguisher allows VPLS advertisements from different VPLS PEs to
be distinct even if the advertisements have the same VE-ID, which can be distinct even if the advertisements have the same VE-ID, which can
occur in case of multi-homing. This allows standard BGP path occur in case of multi-homing. This allows standard BGP path
selection rules to be applied to VPLS advertisements. selection rules to be applied to VPLS advertisements.
Each VPLS PE must advertise a unique VE-ID with non-zero VE Block 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 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 is associated with the base VPLS instance and the NLRI associated
with it must be used for creating PWs among VPLS PEs. Any single with it must be used for creating PWs among VPLS PEs. Any single-
homed customer sites connected to the VPLS instance do not require homed customer sites connected to the VPLS instance do not require
any special addressing. Any multi-homed customer sites connected to any special addressing. However, an administrator (SP operator) can
the VPLS instance require special addressing, which is achieved by chose to have a CE-ID for a single-homed site as well. Any multi-
use of MH-ID. A set of customer sites are distinguished as multi- homed customer sites connected to the VPLS instance require special
homed if they all have the same MH-ID. The following examples addressing, which is achieved by use of CE-ID. A set of customer
illustrate the use of VE-ID and MH-ID. sites are distinguished as multi-homed if they all have the same CE-
ID. The following examples illustrate the use of VE-ID and CE-ID.
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 to set up PWs to each other, each 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 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 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 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 forwarder, an indicator that the PEs are multi-homed to the same
customer site is required. This is achieved by assigning 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 VPLS site ID (CE-ID) on PE1 and PE2 for CE1. When remote VPLS PEs
PEs receive NLRI advertisement from PE1 and PE2 for CE1, the two NLRI 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 MUST be forwarder selection due to the same CE-ID. Thus, same CE-ID MUST be
assigned on all VPLS PEs that are multi-homed to the same customer assigned on all VPLS PEs that are multi-homed to the same customer
site. site.
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. Similar to Figure 1 provisioning 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 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. base VPLS instance. CE1 which is multi-homed to PE1 and PE2 requires
However, CE1 which is multi-homed to PE1 and PE2 requires configuration of CE-ID and both PE1 and PE2 MUST be provisioned with
configuration of MH-ID and both PE1 and PE2 MUST be provisioned with the same CE-ID for CE1. CE2, CE3 and CE4 are single-homed sites and
the same MH-ID for CE1. do not require special addressing. However, an operator can chose to
configure a CE-ID for CE4 on PE1. By doing so, remote PEs can
determine that PE1 has two VPLS sites, CE1 and CE4. If both CE1 and
CE4 connectivity to PE1 is down, remote PEs can chose not to send
multicast traffic to PE1 as there are no VPLS sites reachable via
PE1. If CE4 was not assigned a unique CE-ID, remote PEs have no way
to know if there are other VPLS sites attached and hence, would
always send multicast traffic to PE1. While CE2 and CE3 can also be
configured with unique CE-IDs, there is no advantage in doing so as
both PE3 and PE4 have exactly one VPLS site.
Note that a MH-ID=0 is invalid and a PE should discard such an Note that a CE-ID=0 is invalid and a PE should discard such an
advertisement. advertisement.
Use of multiple VE-IDs per VPLS instance for either multi-homing Use of multiple VE-IDs per VPLS instance for either multi-homing
operation or for any other purpose is outside the scope of this operation or for any other purpose is outside the scope of this
document. However, for interoperability with existing deployments document. However, for interoperability with existing deployments
that use multiple VE-IDs, Section 6.1 provides more detail. that use multiple VE-IDs, Section 6.1 provides more detail.
3.3. Designated Forwarder Election 3.3. Designated Forwarder Election
BGP-based multi-homing for VPLS relies on standard BGP path selection BGP-based multi-homing for VPLS relies on standard BGP path selection
and VPLS DF election. The net result of doing both BGP path and VPLS DF election. The net result of doing both BGP path
selection and VPLS DF election is that of electing a single selection and VPLS DF election is that of electing a single
designated forwarder (DF) among the set of PEs to which a customer designated forwarder (DF) among the set of PEs to which a customer
site is multi-homed. All the PEs that are elected as non-designated site is multi-homed. All the PEs that are elected as non-designated
forwarders MUST keep their attachment circuit to the multi-homed CE forwarders MUST keep their attachment circuit to the multi-homed CE
in blocked status (no 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. These election include both the NLRI and attached BGP attributes. These election
algorithms are applicable to all VPLS NLRIs, and not just to MH algorithms are applicable to all VPLS NLRIs, and not just to CE
NLRIs. In order to simplify the explanation of these algorithms, we NLRIs. In order to simplify the explanation of these algorithms, we
will use a number of variables derived from fields in the VPLS will use a number of variables derived from fields in the VPLS
advertisement. These variables are: RD, SITE-ID, VBO, DOM, ACS, PREF advertisement. These variables are: RD, SITE-ID, VBO, DOM, ACS, PREF
and PE-ID. The notation ADV -> <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 PE-ID> means that from a received VPLS advertisement ADV, the
respective variables were derived. The following sections describe respective variables were derived. The following sections describe
two attributes needed for DF election, then describe the variables two attributes needed for DF election, then describe the variables
and how they are derived from fields in VPLS advertisement ADV, and and how they are derived from fields in VPLS advertisement ADV, and
finally describe how DF election is done. finally describe how DF election is done.
skipping to change at page 10, line 45 skipping to change at page 9, line 7
The procedures also outline how to handle the case that either or The procedures also outline how to handle the case that either or
both are not present. both are not present.
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 as specified in [RFC4761]. Within this community are community as specified in [RFC4761]. Within this community are
various control flags. Two new control flags are proposed in this various control flags. Two new control flags are proposed in this
document. Figure 3 shows the position of the new 'D' and 'F' flags. document. Figure 3 shows the position of the new 'D' and 'F' flags.
Control Flags Bit Vector Control Flags Bit Vector
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero) |D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Figure 3
1. 'D' (Down): Indicates connectivity status between a CE site and a 1. 'D' (Down): Indicates connectivity status. In case of CE NLRI,
VPLS PE. The bit MUST be set to one if all the attachment the connectivity status is between a CE site and a VPLS PE. In
circuits connecting a CE site to a VPLS PE are down. case of VE NLRI, the connectivity status is for the VPLS
instance. In case of CE NLRI, the bit MUST be set to one if all
the attachment circuits connecting a CE site to a VPLS PE are
down. In case of VE NLRI, the bit must be set to one if the VPLS
instance is operationally down. Note that a VPLS instance that
has no connectivity to any of its sites must be considered as
operationally down.
2. 'F' (Flush): Indicates when to flush MAC state. A designated 2. 'F' (Flush): Indicates when to flush MAC state. A designated
forwarder must set the F bit and a non-designated forwarder must forwarder must set the F bit and a non-designated forwarder must
clear the F bit when sending BGP MH advertisements. A state clear the F bit when sending BGP CE NLRIs for multi-homed sites.
transition from one to zero for the F bit can be used by a remote A state transition from one to zero for the F bit can be used by
PE to flush all the MACs learned from the PE that is a remote PE to flush all the MACs learned from the PE that is
transitioning from designated forwarder to non-designated transitioning from designated forwarder to non-designated
forwarder. Refer to Section 5.2 for more details on the use forwarder. Refer to Section 5 for more details on the use case.
case. Note that F bit is only applicable to VE NLRI and is not
applicable to CE NLRI.
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. SITE-ID 3.3.2.2. SITE-ID
skipping to change at page 11, line 50 skipping to change at page 10, line 23
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.
ACS is set to the value of the 'D' bit in ADV that belongs to MH ACS is set to the value of the 'D' bit in ADV that belongs to CE
NLRI. If ADV belongs to base VPLS instance with non-zero label block NLRI. If ADV belongs to base VPLS instance (VE NLRI) with non-zero
values, no change must be made to ACS. label block values, no change must be made to ACS.
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 Value | LP Value | PREF Value | Comment |
| Value | | Value | | +------------+--------------+------------+--------------------------+
+---------+---------------+----------+------------------------------+ | 0 | 0 | 0 | malformed advertisement, |
| 0 | 0 | 0 | malformed advertisement, | | | | | unless ACS=1 |
| | | | unless ACS=1 | | | | | |
| | | | | | 0 | 1 to | LP | backwards compatibility |
| 0 | 1 to (2^16-1) | LP | backwards compatibility | | | (2^16-1) | | |
| | | | | | | | | |
| 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 | Implementation supports |
| | | | | | | VP | | 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 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.
skipping to change at page 13, line 10 skipping to change at page 12, line 9
VPLS advertisements. A concept of bucketization is introduced to VPLS advertisements. A concept of bucketization is introduced to
define route selection rules for VPLS advertisements. Note that this define route selection rules for VPLS advertisements. Note that this
is a conceptual description of the process; an implementation MAY is a conceptual description of the process; an implementation MAY
choose to realize this differently as long as the semantics are choose to realize this differently as long as the semantics are
preserved. preserved.
3.3.3.1. Bucketization for standard BGP path selection 3.3.3.1. Bucketization for standard BGP path selection
An advertisement An advertisement
ADV -> <RD, SITE-ID, VBO, ACS, PREF, PE-ID> ADV -> <RD, SITE-ID, VBO, ACS, PREF, PE-ID>
is put into the bucket for <RD, SITE-ID, VBO>. In other words, the is put into the bucket for <RD, SITE-ID, VBO>. In other words, the
information in BGP path selection consists of <RD, SITE-ID, VBO> and information in BGP path selection consists of <RD, SITE-ID, VBO> and
only advertisements with exact same <RD, SITE-ID, VBO> are candidates only advertisements with exact same <RD, SITE-ID, VBO> are candidates
for BGP path selection procedure as defined in [RFC4271]. for BGP path selection procedure as defined in [RFC4271].
3.3.3.2. Bucketization for VPLS DF Election 3.3.3.2. Bucketization for VPLS DF Election
An advertisement An advertisement
ADV -> <RD, SITE-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, SITE-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 advertisements for a particular VPLS domain that have the same SITE-
SITE-ID are candidates for VPLS DF election. ID 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 VPLS DF election. This section describes the tie-breaking rules for VPLS DF election.
Tie-breaking rules for VPLS DF election are applied to candidate Tie-breaking rules for VPLS DF election are applied to candidate
advertisements by all VPLS PEs and the actions taken by VPLS PEs advertisements by all VPLS PEs and the actions taken by VPLS PEs
based on the VPLS DF election result are described 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, SITE-ID1, VBO1, DOM1, ACS1, PREF1, PE-ID1> ADV1 -> <RD1, SITE-ID1, VBO1, DOM1, ACS1, PREF1, PE-ID1>
ADV2 -> <RD2, SITE-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2> ADV2 -> <RD2, SITE-ID2, VBO2, DOM2, ACS2, PREF2, PE-ID2>
Note that SITE-ID1 = SITE-ID2 and DOM1 = DOM2, since ADV1 and ADV2 Note that SITE-ID1 = SITE-ID2 and DOM1 = DOM2, since ADV1 and ADV2
came from the same bucket. Then the following tie-breaking rules came from the same bucket. Then the following tie-breaking rules
MUST be 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;
skipping to change at page 15, line 41 skipping to change at page 14, line 17
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 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. Community that carries control information about the pseudowires.
The 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 4. 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 4: 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 unless that a Local Preference value of zero for a CE-ID is not valid unless
'D' bit in the control flags is set (see 'D' bit in the control flags is set (see
[I-D.kothari-l2vpn-auto-site-id]). In addition, Local Preference [I-D.kothari-l2vpn-auto-site-id]). In addition, Local Preference
value greater than or equal to 2^16 for VPLS advertisements is not value greater than or equal to 2^16 for VPLS advertisements is not
valid. valid.
4.3. Use of BGP-MH attributes in Inter-AS Methods 4.3. Use of BGP 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 5 for inter-AS VPLS with multi-homed customer sites. Consider Figure 5 for inter-AS VPLS with multi-homed customer sites.
skipping to change at page 17, line 10 skipping to change at page 15, line 29
\ : : : : \ : : : :
\___ PE2 . . PE4 ---- CE4 \___ PE2 . . PE4 ---- CE4
. . . . . . . .
........ ........ ........ ........
Figure 5: Inter-AS VPLS Figure 5: 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), CE-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. VPLS PEs must elect the same designated forwarder for CE1 site.
Since 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 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, for nexthop. Since VPLS PEs use BGP Local Preference in DF election, for
skipping to change at page 19, line 21 skipping to change at page 16, line 50
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 5.1. MAC Flush Indicators
and the specific VPLS Flush TLVs that provide capability to flush the If 'D' bit in the control flags is set in a received VE NLRI, the
affected MAC addresses on the PE devices. All operations described receiving PE must flush all the MAC addresses learned from the PE
in this section are in context of a particular VPLS domain and not advertising the failure.
across multiple VPLS domains. Mechanisms for MAC flush are described
in [I-D.kothari-l2vpn-vpls-flush] for BGP based VPLS and in [RFC4762]
for LDP based VPLS.
5.1. MAC List FLush
If multiple customer sites are connected to the same PE, PE1 as shown
in Figure 2, and redundancy per site is desired when multi-homing
procedures described in this document are in effect, then it is
desirable to flush just the relevant MAC addresses from a particular
site when the site connectivity is lost.
To flush particular set of MAC addresses, a PE SHOULD originate a
flush message with MAC list that contains a list of MAC addresses
that needs to be flushed. In Figure 2, if connectivity between CE1
and PE1 goes down and if PE1 was the designated forwarder for CE1,
PE1 MAY send a list of MAC addresses that belong to CE1 to all its
BGP peers.
It is RECOMMENDED that in case of excessive link flap of customer
attachment circuit in a short duration, a PE should have a means to
throttle advertisements of flush messages so that excessive flooding
of such advertisements do not occur.
5.2. Implicit MAC Flush
Implicit MAC Flush refers to the use of BGP MH advertisements by the
PEs to flush the MAC addresses learned from the previous designated
forwarder.
In case of a failure, when connectivity to a customer site is lost, Anytime a designated forwarder change occurs, a remote PE must flush
remote PEs learn that a particular site is no longer reachable. The all the MAC addresses it learned from the PE that lost the DF
local PE either withdraws the VPLS NLRI that it previously advertised election (old designated forwarder). If multiple customer sites are
for the site or it sends a BGP update message for the site's VPLS connected to the same PE, PE1 as shown in Figure 2, and redundancy
NLRI with the 'D' bit set. In such cases, the remote PEs can flush per site is desired when multi-homing procedures described in this
all the MACs that were learned from the PE which reported the document are in effect, then it is desirable to flush just the
failure. relevant MAC addresses from a particular site when the site
connectivity is lost. However, procedures for flushing a limited set
of MAC addresses is beyond the scope of this document. Use of either
'D' or 'F' bit in control flags only allows to flush all MAC
addresses associated with a PE.
However, in cases when a designated forwarder change occurs in Designated forwarder change can occur in absence of failures, such as
absence of failures, such as when an attachment circuit comes up, the when an attachment circuit comes up. Consider the case in Figure 2
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 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 CE advertisement for CE1 to all it's peers. If PE3
the new designated forwarder for CE1 and as a result flushes all the performs the DF election before PE2, there is a chance that PE3 might
MACs learned from PE1 before PE2 elects itself as the non-designated learn MAC addresses from PE2 after it was done electing PE1. This
forwarder, there is a chance that PE3 might learn MAC addresses from can happen since PE2 has not yet processed the BGP CE advertisement
PE2 and as a result may black-hole traffic until those MAC addresses from PE1 and as a result continues to send traffic to PE3. This can
are deleted due to age out timers. cause traffic from PE3 to CE1 to black-hole until those MAC addresses
are deleted due to age out timers. Therefore, to avoid such race-
A designated forwarder must set the F bit and a non-designated conditions, a designated forwarder must set the F bit and a non-
forwarder must clear the F bit when sending BGP MH advertisements. A designated forwarder must clear the F bit when sending BGP CE
state transition from one to zero for the F bit can be used by a advertisements. A state transition from one to zero for the 'F' bit
remote PE to flush all the MACs learned from the PE that is can be used by a remote PE to flush all the MACs learned from the PE
transitioning from designated forwarder to non-designated forwarder. that is transitioning from designated forwarder to non-designated
forwarder.
5.3. Minimizing the effects of fast link transitions 5.2. 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 CE advertisements and LDP MAC Flush messages.
It is recommended that a timer to damp the link flaps be used for the 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 port towards the multi-homed CE to minimize the number of MAC Flush
events in the remote PEs and the occurrences of BGP state events in the remote PEs and the occurrences of BGP state compression
compressions for F bit transitions. A timer value more than the time for F bit transitions. A timer value more than the time it takes BGP
it takes BGP to converge in the network is recommended. 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 CE-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 CE-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.
For compatibility with PEs that use multiple VE-IDs with non-zero For compatibility with PEs that use multiple VE-IDs with non-zero
label block values for multi-homing operation, it is a requirement label block values for multi-homing operation, it is a requirement
that a PE receiving such advertisements must use the labels in the that a PE receiving such advertisements must use the labels in the
NLRIs associated with lowest VE-ID for PW creation. It is possible NLRIs associated with lowest VE-ID for PW creation. It is possible
that maintaining PW association with lowest VE-ID can result in PW that maintaining PW association with lowest VE-ID can result in PW
flap, and thus, traffic loss. However, it is necessary to maintain flap, and thus, traffic loss. However, it is necessary to maintain
the assocation of PW with the lowest VE-ID as it provides the association of PW with the lowest VE-ID as it provides
deterministic DF election among all the VPLS PEs. deterministic DF election among all the VPLS PEs.
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 CE 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 remote operation. MH PEs may use existing LDP MAC Flush to flush the remote
LDP VPLS PEs or may use the implicit MAC Flush procedure. LDP VPLS PEs or may use the MAC Flush procedures as described in
Section 5
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.
skipping to change at page 25, line 13 skipping to change at page 19, line 23
questions. questions.
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 Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
RFC 4761, January 2007. 4761, January 2007.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2 "Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074, Virtual Private Networks (L2VPNs)", RFC 6074, January
January 2011. 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-
draft-kothari-l2vpn-vpls-flush-00 (work in progress), 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",
draft-kothari-l2vpn-auto-site-id-01 (work in progress), draft-kothari-l2vpn-auto-site-id-01 (work in progress),
October 2008. October 2008.
[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.
skipping to change at page 26, line 8 skipping to change at page 20, line 15
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) 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 Gainspeed
295 Santa Ana Court 295 Santa Ana Court
Sunnyvale, CA 94085 Sunnyvale, CA 94085
US US
Email: bhupesh@cohere.net Email: bhupesh@gainspeed.com
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
Wim Henderickx Wim Henderickx
 End of changes. 53 change blocks. 
226 lines changed or deleted 239 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/