Internet DRAFT - draft-henderickx-l2vpn-vpls-multihoming
draft-henderickx-l2vpn-vpls-multihoming
Network working group Wim Henderickx
Florin Balus
Internet Draft Alcatel-Lucent
Intended status: Standard track March 4, 2009
Expires: September 2009
BGP based Multi-homing in Virtual Private LAN Service
draft-henderickx-l2vpn-vpls-multihoming-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
<Henderickx> Expires September 4, 2009 [Page 1]
Internet-Draft BGP-based multihoming for VPLS March 2009
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo
shows how multi-homing can be offered in the context of LDP-based
VPLS using BGP-AD.
Table of Contents
1. Introduction...................................................2
1.1. General terminology.......................................3
1.2. Conventions used in this document.........................3
2. Background.....................................................3
2.1. Scenarios.................................................4
2.2. VPLS Multi-homing Considerations..........................5
3. BGP based Multi-homing procedures .............................6
3.1. Provisioning model........................................6
3.2. BGP-AD extensions.........................................6
3.3. Designated Forwarder Election.............................7
3.4. VPLS operation with BGP multi-homing......................8
3.4.1. Link failures........................................9
3.4.2. PE Failures..........................................9
4. Backwards compatibility with BGP-AD for LDP VPLS...............9
5. Inter-AS operation.............................................9
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. References....................................................10
8.1. Normative References.....................................10
8.2. Informative References...................................10
9. Acknowledgments...............................................10
1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing".
[RFC4762] explains how VPLS signaling is offered using LDP and
[L2VPN-Sig] explains how VPLS can be offered using BGP for auto-
discovery; section 3 of that document describes how multi-homing can
be achieved in this context. Implementation and deployment of multi-
homing in LDP-based VPLS was achieved through the use of local access
resiliency mechanisms, including active/standby Pseudowires
([RFC4762] section 10.2). This document provides a BGP based
Henderickx Expires September 4, 2009 [Page 2]
Internet-Draft BGP-based multihoming for VPLS March 2009
alternative for the selection of a designated forwarder between
redundant VSIs. Although the current version of the document makes
reference to the models described in [L2VPN-Sig], this solution is
independent of the signaling protocol used for the PW infrastructure,
being expandable to address multi-homing in BGP VPLS or a mix of BGP
and LDP VPLS domains.
Section 2 lays out some of the scenarios for multi-homing and some of
the expectations of VPLS multi-homing. Section 3 defines the
components of VPLS multi-homing, and the procedures required to
achieve this.
1.1. General terminology
Some general terminology is defined here; most is from [RFC4762].
Terminology specific to this memo is introduced as needed in later
sections.
A "Customer Edge" (CE) device, typically located on customer
premises, connects to a "Provider Edge" (PE) device, which is owned
and operated by the SP. A "Provider" (P) device is also owned and
operated by the SP, but has no direct customer connections. A "VPLS
Edge" (VE) device is a PE that offers VPLS services.
A VPLS domain represents a bridging domain per customer. An extended
community as described in [RFC4360] is typically used to identify all
the PE routers participating in a particular VPLS domain.
A VPLS Switching Instance (VSI) is a grouping of virtual ports on a
PE that belong to the same VPLS domain. VSIs 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 designated forwarder is a VSI that is elected to send traffic
to/from a given multi-homed CE.
1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
2. Background
This section describes various scenarios where multi-homing may be
required, and the implications thereof. It also describes some of
Henderickx Expires September 4, 2009 [Page 3]
Internet-Draft BGP-based multihoming for VPLS March 2009
the properties of VPLS multi-homing, and what that means from both an
operational point of view and an implementation point of view.
2.1. Scenarios
The most basic scenario is shown in figure 1. CE1 is a VPLS CE that
is dual-homed to both PE1 and PE2 for redundant connectivity.
...............
. . _-- CE3
---_PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \_--_CE4
\---_PE2 .
. .
...............
Figure 1 Scenario 1.
Another scenario that is envisioned is a scenario with 2 dual-homed
CE(s) to the same pair of PE(s). CE1 and CE2 are VPLS CE(s) that are
dual-homed to both PE1 and PE2 for redundant connectivity.
CE2 ----- ...............
\ \ . . _-- CE3
\ --_PE1 . /
\/ : PE3
_/\ : Service :
CE1 _ _ \ : Provider PE4
\ \ : : \_--_CE4
---_PE2 .
. .
...............
Figure 2 Scenario 2.
Figure 3 shows a scenario where CE1 is a VPLS CE that is dual-homed
to both PE1 and PE2 for redundant connectivity. However, CE2, which
is also in the same VPLS domain, is single-homed to just PE1.
Henderickx Expires September 4, 2009 [Page 4]
Internet-Draft BGP-based multihoming for VPLS March 2009
CE2 ----- ...............
\ . . _-- CE3
_---PE1 . /
/ : PE3
__/ : Service :
CE1 __ : Provider PE4
\ : : \-- CE4
\---PE2 .
. .
...............
Figure 3 Scenario 3.
2.2. VPLS Multi-homing Considerations
The first (perhaps obvious) fact about a multi-homed VPLS CE, such as
CE1 in Figure 1 is that if CE1 is an Ethernet switch or bridge, a
loop has been created in the customer VPLS. This is a dangerous
situation for an Ethernet network and the loop must be resolved
(broken). Even if CE1 is a router, it will get duplicate packets
every time a packet is flooded, which is clearly undesirable.
The next is that (unlike the case of IP-based multi-homing) only one
of PE1 and PE2 can be actively sending traffic, either towards CE1 or
into the SP cloud. All other PEs MUST choose the same designated
forwarder for a multi-homed site. Call the PE that is chosen to send
traffic to/from CE1 the "designated forwarder".
In Figure 3, CE1 and CE2 must be dealt with independently, since CE1
is dual-homed, but CE2 is not.
A multi-homing solution needs to address the following requirements:
. Address both PE and access link failure
. Provides fast convergence times
. Only the traffic transiting the affected network elements should
be impacted
. Minimize the traffic load on the network; ideally just the local
PEs should be involved in the selection process
. Re-use existing BGP procedures while minimizing the network
migration
Henderickx Expires September 4, 2009 [Page 5]
Internet-Draft BGP-based multihoming for VPLS March 2009
3. BGP based Multi-homing procedures
This section describes BGP based procedures for electing a designated
forwarder among the set of PEs that are multi-homed to a customer
site. Only the local PEs are actively participating in the selection
algorithm. The PE(s) remote from the dual homed CE are not required
to participate in the designated forwarding election for a remote
dual-homed CE.
3.1. Provisioning model
VPLS Multi-homing with BGP AD expands on the provisioning model as
defined in section 3.2 of [L2VPN-Sig]. Every multi-homed CE is
represented in the VPLS context through a Site-id, which is the same
on the local PEs. The Site-id is unique within the scope of a the
VPLS. It serves to differentiate between the dual-homed CEs connected
to the same VPLS instance (VSI).
In the example from figure 1, CE1 will be assigned the same Site-id
on both PE1 and PE2. The single-homed CEs, CE2 and CE3, are
represented by the base VSI-id and do not require allocation of a
site-id.
In figure 2 a different site-id is assigned on PE1 and PE2 for CE1
and CE2. However the same site id X MUST be assigned on PE1 and PE2
for CE1 and another site id Y MUST be assigned on PE1 and PE2 for
CE2.
Figure 3 shows two customer sites, CE1 and CE2, connected to PE1 and
CE1 multi-homed to PE1 and PE2. In such a case, the Site ID for CE1
on both PE1 and PE2 MUST be the same and no site ID is required for
CE2.
3.2. BGP-AD extensions
The information model described in the previous section requires
changes to the BGP-AD usage of the NLRI for VPLS.
The suggested extended MH VPLS NLRI structure is depicted below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Henderickx Expires September 4, 2009 [Page 6]
Internet-Draft BGP-based multihoming for VPLS March 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2B) (=14) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Route-distinguisher (RD) (8B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | VSI-ID (HO bits) (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSI-ID (LO bits) (2B) | Site ID (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 BGP MH-NLRI for VPLS multi-homing
The BGP AD NLRI described in [L2VPN-Sig] is extended with a 2 byte
site-ID. The last three bytes of the BGP AD NLRI assigned for the
Label Block in [RFC4761] are still not used.
After BGP AD and LDP signaling are building the PW infrastructure
between VSIs using the procedures described in [L2VPN-Sig], on
provisioning of a multi-homed CE BGP AD proceeds to advertise the
related Site-ids. Upon reception, the VPLS PE determines from the
Length field that this is an MH-NLRI identifying a Multi-homed site
that does not require signaling of a PW label through LDP. Only the
local multi-homed PEs, containing the multi-homed attachment circuits
will need to run the election algorithm to determine whether the
remote MH-NLRI should be preferred to his local one. The election
algorithm is described in detail in the next section. All the PEs but
the designated forwarder will keep their attachment circuits in
blocked status.
3.3. Designated Forwarder Election
BGP- based multi-homing for VPLS relies on VPLS path selection
performed at the local multi-homed PEs. By comparing BGP attributes
of the MH-NLRI(s) with the same Site ID as the local CE, the PE
elects whether he is the designated forwarder for a given multi-homed
site by comparing BGP attributes (normal BGP procedures) for the
received advertisements with its own, for example using LPREF
attribute or using extended communities (will be further detailed in
the next proposal). If the BGP attribute comparison results in a tie
the lowest VSI-ID is used as the tie-breaker. Based on these criteria
the PE decides if it is the designated forwarder for a given multi-
homed CE. When a given multi-homed PE is not elected for any of the
attached CE as designated forwarder, the PE MAY signal PW status "PW
forwarding standby" according to [PW status]. This ensures traffic
optimization in the SP network such that remote PE(s) do not send
traffic to this PE, e.g. in case of BUM traffic.
Henderickx Expires September 4, 2009 [Page 7]
Internet-Draft BGP-based multihoming for VPLS March 2009
3.4. VPLS operation with BGP multi-homing
This section describes the VPLS multi-homing operation using the
network diagram depicted in figure 6.
CE2 ----- ...............
\ \ . .
\ --_PE1 .
\/ : :
_/\ : Service PE3 -- CE3
CE1 _ _ \ : Provider :
\ \ : :
---_PE2 .
. .
...............
Figure 5 VPLS Multi-homing operation
VPLS NLRIs advertised by each PE:
PE1: Site ID=1, LPREF=200 (for site CE1)
Site ID=2, LPREF=200 (for site CE2)
PE2: Site ID=1, LPREF=100 (for site CE1)
Site ID=2, LPREF=100 (for site CE2)
PE3: No Site ID assigned, uses regular VSI-id(for site
CE3)
Henderickx Expires September 4, 2009 [Page 8]
Internet-Draft BGP-based multihoming for VPLS March 2009
PE1 is elected as designated forwarder for both CE1 and CE2. PE2 is
not elected for any connected CE as designated forwarder and as such
send PW status "PW forwarding standby" according [PW status].
3.4.1. Link failures
When a link failure is detected on a dual homed CE1 site the local
PE1, PE1 sends a MAC flush according to RFC4762 and withdraws in BGP
the MH VPLS NLRI with the local Site ID=1. The reception of the BGP
withdraw MH VPLS NLRI triggers a new designated forwarder election on
PE2. PE2 becomes the designated forwarder for CE1 and MUST change the
PW status to "Active" when it was signaling "Standby" before. This
allows traffic to be received/send from/to CE1. PE1 is designated
forwarder for CE2 and PE2 is designated forwarder for CE1 after this
failure.
This mechanism ensures no traffic impact is experienced on dual-homed
or non-dual homed CE(s) when a link to a dual homed CE fails on a
given PE.
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 MAC flush and NLRI withdraw messages so that excessive
flooding of such advertisements do not occur.
3.4.2. PE Failures
Failure of a PE participating in a multi-homing solution for CE1 will
automatically remove the NLRIs advertised by this PE and will
determine a new election process.
4. Backwards compatibility with BGP-AD for LDP VPLS
The BGP AD advertisements for the multi-homed sites can be limited to
PEs that understand the new NLRI format. In order to construct the
basic PW infrastructure between VSI, the existing procedures
described in [L2VPN-Sig] MAY be used in order to allow backwards
compatibility with the existing BGP-AD LDP VPLS operation.
5. Inter-AS operation
The procedures outlined in this memo do not change the inter-AS
operation of LDP VPLS with BGP-AD.
Henderickx Expires September 4, 2009 [Page 9]
Internet-Draft BGP-based multihoming for VPLS March 2009
6. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4762].
7. IANA Considerations
TBC
8. References
8.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",RFC
4761, January 2007.
[L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and
Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt,
May 2006 ( work in progress )
[PW status] P. Muley, et Al. "Preferential Forwarding Status bit
definition, draft-ietf-pwe3-redundancy-bit-01.txt
8.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
9. Acknowledgments
The authors would like to thank Devendra Raut, Nehal Bhau and
Himanshu SHAH for their insightful comments and probing questions.
Henderickx Expires September 4, 2009 [Page 10]
Internet-Draft BGP-based multihoming for VPLS March 2009
Authors' Addresses
Wim Henderickx
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp, Belgium
Email: wim.henderickx@alcatel-lucent.be
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Henderickx Expires September 4, 2009 [Page 11]
