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 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]