draft-ietf-l2vpn-vpls-multihoming-06.txt   draft-ietf-l2vpn-vpls-multihoming-07.txt 
Network Working Group B. Kothari Network Working Group B. Kothari
Internet-Draft Gainspeed 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: January 16, 2014 W. Henderickx Expires: January 4, 2015 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
July 15, 2013 July 3, 2014
BGP based Multi-homing in Virtual Private LAN Service BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-l2vpn-vpls-multihoming-06.txt draft-ietf-l2vpn-vpls-multihoming-07.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.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 16, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 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
skipping to change at page 2, line 27 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . 5 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . 5
3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . 6 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . 6
3.1. Customer Edge (CE) NLRI . . . . . . . . . . . . . . . . . 6 3.1. Customer Edge (CE) NLRI . . . . . . . . . . . . . . . . . 6
3.2. Provisioning Model . . . . . . . . . . . . . . . . . . . 7 3.2. Deployment Considerations . . . . . . . . . . . . . . . . 7
3.3. Designated Forwarder Election . . . . . . . . . . . . . . 8 3.3. Designated Forwarder Election . . . . . . . . . . . . . . 8
3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . 9 3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . 9
3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11 3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11
3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . 13 3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . 12
4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Route Origin Extended Community . . . . . . . . . . . . . 13 4.1. Route Origin Extended Community . . . . . . . . . . . . . 13
4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 13 4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 13
4.3. Use of BGP attributes in Inter-AS Methods . . . . . . . . 14 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 . . . . . . . . . . . . . . 15 Information between ASBRs . . . . . . . . . . . . . . 14
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of
VPLS Information between ASes . . . . . . . . . 16 VPLS Information between ASes . . . . . . . . . 16
5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16
5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16 5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16
5.2. Minimizing the effects of fast link transitions . . . . . 17 5.2. Minimizing the effects of fast link transitions . . . . . 17
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 18 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 18 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 17
6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 4, line 42 skipping to change at page 5, line 4
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 of from both an operational point of view and an implementation point of
view. There are other approaches for providing multi-homing such as view. There are other approaches for providing multi-homing such as
Spanning Tree Protocol, and this document specifies use of BGP for Spanning Tree Protocol, and this document specifies use of BGP for
multi-homing. Comprehensive comparison among the approaches is multi-homing. Comprehensive comparison among the approaches is
outside the scope of this document. outside the scope of this document.
2.1. Scenarios 2.1. Scenarios
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 6, line 19 skipping to change at page 6, line 22
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. Customer Edge (CE) 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 customer-edge NLRI (CE NLRI) is For multi-homing operation, a customer-edge NLRI (CE NLRI) is
proposed that uses BGP VPLS NLRI with the following fields set to proposed that uses BGP VPLS NLRI with the following fields set to
zero: VE Block Offset, VE Block Size and Label Base. In addition, zero: VE Block Offset, VE Block Size and Label Base. In addition,
the VE-ID field of the NLRI is set to CE-ID. Thus, the CE NLRI the VE-ID field of the NLRI is set to CE-ID. Thus, the CE NLRI
contains 2 octets indicating the length, 8 octets for Route contains 2 octets indicating the length, 8 octets for Route
Distinguisher, 2 octets for CE-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 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. infer if it is applicable for CE NLRI, VE NLRI or for both.
3.2. Provisioning Model 3.2. Deployment Considerations
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
skipping to change at page 9, line 7 skipping to change at page 9, line 12
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. In case of CE NLRI, 1. 'D' (Down): Indicates connectivity status. In case of CE NLRI,
the connectivity status is between a CE site and a VPLS PE. In the connectivity status is between a CE site and a VPLS PE. In
case of VE NLRI, the connectivity status is for the VPLS 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 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 the attachment circuits connecting a CE site to a VPLS PE are
skipping to change at page 9, line 31 skipping to change at page 9, line 36
has no connectivity to any of its sites must be considered as has no connectivity to any of its sites must be considered as
operationally down. 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 CE NLRIs for multi-homed sites. clear the F bit when sending BGP CE NLRIs for multi-homed sites.
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 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 for more details on the use case. forwarder. Refer to Section 5 for more details on the use 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 5 skipping to change at page 10, line 35
label block 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 Value | LP Value | PREF Value | Comment | | VP | LP Value | PREF | Comment |
+------------+--------------+------------+--------------------------+ | Value | | Value | |
| 0 | 0 | 0 | malformed advertisement, | +---------+---------------+----------+------------------------------+
| | | | unless ACS=1 | | 0 | 0 | 0 | malformed advertisement, |
| | | | | | | | | unless ACS=1 |
| 0 | 1 to | LP | backwards compatibility | | | | | |
| | (2^16-1) | | | | 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 | Implementation supports | | >0 | LP same as VP | VP | Implementation supports VP |
| | 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 12, line 9 skipping to change at page 11, line 32
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 SITE- advertisements for a particular VPLS domain that have the same 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 14, line 17 skipping to change at page 14, line 5
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.
skipping to change at page 15, line 11 skipping to change at page 15, line 4
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.
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information
between ASBRs between ASBRs
AS1 AS2
AS1 AS2 ........ ........
........ ........ CE2 _______ . . . .
CE2 _______ . . . . ___ PE1 . . PE3 --- CE3
___ PE1 . . PE3 --- CE3 / : . . :
/ : . . : __/ : : : :
__/ : : : : CE1 __ : ASBR1 --- ASBR2 :
CE1 __ : ASBR1 --- ASBR2 : \ : : : :
\ : : : : \___ PE2 . . PE4 ---- CE4
\___ PE2 . . PE4 ---- CE4 . . . .
. . . . ........ ........
........ ........
Figure 5: Inter-AS VPLS Figure 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), CE-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
skipping to change at page 17, line 4 skipping to change at page 16, line 40
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.
5.1. MAC Flush Indicators 5.1. MAC Flush Indicators
If 'D' bit in the control flags is set in a received VE NLRI, the If 'D' bit in the control flags is set in a received VE NLRI, the
receiving PE must flush all the MAC addresses learned from the PE receiving PE SHOULD flush all the MAC addresses learned from the PE
advertising the failure. advertising the failure.
Anytime a designated forwarder change occurs, a remote PE must flush Anytime a designated forwarder change occurs, a remote PE SHOULD
all the MAC addresses it learned from the PE that lost the DF flush all the MAC addresses it learned from the PE that lost the DF
election (old designated forwarder). If multiple customer sites are election (old designated forwarder). If multiple customer sites are
connected to the same PE, PE1 as shown in Figure 2, and redundancy connected to the same PE, PE1 as shown in Figure 2, and redundancy
per site is desired when multi-homing procedures described in this per site is desired when multi-homing procedures described in this
document are in effect, then it is desirable to flush just the document are in effect, then it is desirable to flush just the
relevant MAC addresses from a particular site when the site relevant MAC addresses from a particular site when the site
connectivity is lost. However, procedures for flushing a limited set connectivity is lost. However, procedures for flushing a limited set
of MAC addresses is beyond the scope of this document. Use of either 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 'D' or 'F' bit in control flags only allows to flush all MAC
addresses associated with a PE. addresses associated with a PE.
skipping to change at page 19, line 12 skipping to change at page 18, line 43
No new security issues are introduced beyond those that are described No new security issues are introduced beyond those that are described
in [RFC4761] and [RFC4762]. in [RFC4761] and [RFC4762].
8. IANA Considerations 8. IANA Considerations
At this time, this memo includes no request to IANA. At this time, this memo includes no request to IANA.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali
Singh and Ian Cowburn for their insightful comments and probing Singh, Ian Cowburn and Jonathan Hardwick for their insightful
questions. comments and probing 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", RFC (VPLS) Using BGP for Auto-Discovery and Signaling", 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,
 End of changes. 28 change blocks. 
102 lines changed or deleted 98 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/