Network Working Group K. Kompella Internet-Draft B. Kothari Updates: 4761 (if approved) Juniper Networks Intended status: Standards Track T. Spencer Expires: May 15, 2008 at&t November 12, 2007 Multi-homing in BGP-based Virtual Private LAN Service draft-kompella-l2vpn-vpls-multihoming-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kompella, et al. Expires May 15, 2008 [Page 1] Internet-Draft BGP VPLS Multi-homing November 2007 Abstract 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 BGP-based VPLS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . . 5 2.3. Using the Spanning Tree Protocol for Multi-homing . . . . 5 2.4. Active/Backup Links . . . . . . . . . . . . . . . . . . . 6 2.5. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. BGP Path Selection . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Bucketization . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Tie-breaking Rules . . . . . . . . . . . . . . . . . . 8 3.2. VPLS Path Selection . . . . . . . . . . . . . . . . . . . 8 3.2.1. Bucketization . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Tie-breaking Rules . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Kompella, et al. Expires May 15, 2008 [Page 2] Internet-Draft BGP VPLS Multi-homing November 2007 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". [2] explains how VPLS can be offered using BGP for auto-discovery and signaling; section 3.5 of that document describes how multi-homing can be achieved in this context. Implementation and deployment of multi-homing in BGP-based VPLS has suggested some refinement of the procedures described earlier; this memo details these changes. Section 2 lays out some of the scenarios for multi-homing, other ways that this can be achieved, and some of the expectations of BGP-based multi-homing. Section 3 defines the components of BGP-based multi- homing, and the procedures required to achieve this. Section 4 may someday discuss security considerations. 1.1. General Terminology Some general terminology is defined here; most is from [2] or [4]. 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. A Route Target community as described in [3] is typically used to 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 the same VPLS domain. 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). 1.2. Conventions 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 [1]. Kompella, et al. Expires May 15, 2008 [Page 3] Internet-Draft BGP VPLS Multi-homing November 2007 2. Background This section describes various scenarios where multi-homing may be required, and the implications thereof. It also describes some of the singular properties of VPLS multi-homing, and what that means from both an operational point of view and an implementation point of view. It describes briefly how the Spanning Tree Protocol can be used to achieve multi-homing, and how that compares with BGP-based multi-homing. 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. ............... . . ___ CE2 ___ PE1 . / / : PE3 __/ : Service : CE1 __ : Provider PE4 \ : : \___ CE3 \___ PE2 . . . ............... Figure 1: Scenario 1 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, is single-homed to just PE1. CE4 ------- ............... \ . . ___ CE2 ___ PE1 . / / : PE3 __/ : Service : CE1 __ : Provider PE4 \ : : \___ CE3 \___ PE2 . . . ............... Figure 2: Scenario 2 Kompella, et al. Expires May 15, 2008 [Page 4] Internet-Draft BGP VPLS Multi-homing November 2007 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 broken. Even if CE1 is a router, it will get duplicates 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. That is to say, load balancing techniques will not work. 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 2, CE1 and CE4 must be dealt with independently, since CE1 is dual-homed, but CE4 is not. 2.3. Using the Spanning Tree Protocol for Multi-homing It is quite common to have redundant links in Ethernet networks; here too, redundancy leads to loops, but these can be broken by the use of the Spanning Tree Protocol (STP). This technique can also be applied in the case of multi-homed CEs in a VPLS domain. One approach is to run STP on the multi-homed CE (say CE1 in Figure 1). CE1 would thus detect a potential loop in the virtual LAN, and "block" either the link to PE1 or to PE2, breaking the loop. Blocking the link to PE2 would effectively pick PE1 to be the designated forwarder, since (a) PE2 will not get any traffic from CE1 to forward; (b) PE2's traffic to CE1 will be ignored. There are several operational disadvantages to the STP approach: 1. The SP has to trust the customer to run STP correctly and manage changes carefully. If the customer makes a mistake, the SP will pay for it by carrying the customer's "broadcast storm" across the SP network. 2. The choice of whether PE1 or PE2 will be the "designated forwarder" is made by the customer; however, the SP may feel that they should make this choice, and in fact may be in a better position to do so, as they know their network topology better. 3. STP has several characteristics that make it unsuitable for carrier networks. Another approach is to run STP on the PEs. However, the whole point Kompella, et al. Expires May 15, 2008 [Page 5] Internet-Draft BGP VPLS Multi-homing November 2007 of having a full mesh of PE-PE connections, and of "split horizon" forwarding (Section 4.2.5 [2]; Section 4.4 [6]) is so that STP is not needed on PEs. Furthermore, in Figure 2, PE1 must not block the pseudowires to PE3 and PE4 in order to break the loop. 2.4. Active/Backup Links Another approach is to define "active" and "backup" links from a multi-homed CE to the PEs. For example, in Figure 1, CE1 could define the link to PE1 as active and the link to PE2 as backup. If the link to PE1, or PE1 itself, fails, the CE1 could detect this and switch to the backup. However, again, the SP has to trust the customer's staff to handle this correctly; also, the choice of whether to use PE1 or PE2 remains with the customer. 2.5. Comparisons One of the above methods may be acceptable in some cases. The technique described in this memo is for those who are unsatisfied with these methods. This technique relies on BGP mechanisms; furthermore, the choice of "designated forwarder" is retained by the SP. Finally, this technique can be used in conjunction with STP to get further "insurance" against the possibility of loops. Kompella, et al. Expires May 15, 2008 [Page 6] Internet-Draft BGP VPLS Multi-homing November 2007 3. Procedures BGP-based multi-homing for VPLS relies on two things: BGP path selection and VPLS path selection. In this, it resembles BGP multi- homing for IP VPNs. BGP path selection can be done by any BGP speaker; a full understanding or parsing BGP VPLS advertisements is not required. A good example is a Route Reflector [5], which typically only has to do BGP path selection. A VPLS PE (i.e., a VE) MUST do both BGP and VPLS path selection. The net result of doing both BGP and VPLS path selection is that of electing a single Designated Forwarder among the set of VEs to which a customer site is multi-homed. In order to explain how these two path selection algorithms work, one must refer to the format of the VPLS NLRI. This NLRI contains: (Section 3.2.2 [2]). We'll refer to these components as RD, VE-ID, VBO, VBS and LB, respectively. In addition, a VPLS advertisement contains some attributes, among them the BGP nexthop (BNH), control flags (CF) and Local Preference (LP). Finally, the VPLS domain (DOM) is needed; this is not carried explicitly in a VPLS advertisement, but is derived, typically from BGP policies applied on Route Targets carried in the advertisement. Taken all together, this yields: Note that an advertisement with VE-ID = 0 is invalid. The path selection algorithms are described in two stages. The first stage divides all received VPLS advertisements into buckets of relevant and comparable advertisements. In this stage, advertisements may be discarded as not being relevant to path selection. The second stage picks a single "winner" from each bucket by repeatedly applying a tie-breaking algorithm on a pair of advertisements from that bucket. The tie-breaking rules are such that the order in which advertisements are picked from the bucket does not affect the final result. Note that this is a conceptual description of the process; an implementation MAY choose to realize this differently as long as the semantics are preserved. 3.1. BGP Path Selection 3.1.1. Bucketization An advertisement AD = Kompella, et al. Expires May 15, 2008 [Page 7] Internet-Draft BGP VPLS Multi-homing November 2007 is discarded if DOM is not of interest to the PE. Otherwise, AD is put into the bucket for . In other words, the prefix to use for comparison in BGP path selection consists of . 3.1.2. Tie-breaking Rules Given two advertisements AD1 and AD2 as below, the following tie- breaking rules MUST be applied in the given order (note that the RDs, VE-IDs and VBOs are the same): AD1 = AD2 = 1. if (LP1 > LP2) AD1 wins; stop; else if (LP2 > LP1) AD2 wins; stop; else continue 2. if (BNH1 < BNH2) AD1 wins; stop; else if (BNH2 < BNH1) AD2 wins; stop; else AD1 wins; stop 3.2. VPLS Path Selection 3.2.1. Bucketization An advertisement AD = is kept only if DOM is of interest to the PE, and the following is satisfied: VBO <= N < (VBO + VBS - 1) where N is one of the PE's VE IDs for VPLS DOM. If so, AD is put into the bucket for . Otherwise, AD is discarded. 3.2.2. Tie-breaking Rules Given two advertisements AD1 and AD2 as below, the following tie- breaking rules MUST be applied in the given order (note that the RDs, VE-IDs and VBOs are the same): AD1 = AD2 = where CF:D is the 'D' bit in the control flags (see Kompella, et al. Expires May 15, 2008 [Page 8] Internet-Draft BGP VPLS Multi-homing November 2007 [draft-kothari-l2vpn-auto-site-id]). AD1 = AD2 = 1. if (CF:D1 = 1) AD2 wins; stop; else if (CF:D2 = 1) AD1 wins; stop; else continue 2. if (LP1 > LP2) AD1 wins; stop; else if (LP2 > LP1) AD2 wins; stop; else continue 3. if (BNH1 < BNH2) AD1 wins; stop; else if (BNH2 < BNH1) AD2 wins; stop; else AD1 wins; stop If the final "winning" advertisement has CF:D = 1 or VE-ID = 0 or VBO = 0 or VBS = 0, it is discarded. Kompella, et al. Expires May 15, 2008 [Page 9] Internet-Draft BGP VPLS Multi-homing November 2007 4. Security Considerations Having security is a Good Thing. Kompella, et al. Expires May 15, 2008 [Page 10] Internet-Draft BGP VPLS Multi-homing November 2007 5. Acknowledgments The authors would like to thank Chaitanya Kodeboyina, Yakov Rekhter, Nischal Sheth and Amit Shukla for their insightful comments and probing questions. Kompella, et al. Expires May 15, 2008 [Page 11] Internet-Draft BGP VPLS Multi-homing November 2007 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. 6.2. Informative References [3] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [4] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [5] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [6] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. Kompella, et al. Expires May 15, 2008 [Page 12] Internet-Draft BGP VPLS Multi-homing November 2007 Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: kireeti@juniper.net Bhupesh Kothari Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: bhupesh@juniper.net Tom Spencer at&t Email: tsiv@att.com Kompella, et al. Expires May 15, 2008 [Page 13] Internet-Draft BGP VPLS Multi-homing November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kompella, et al. Expires May 15, 2008 [Page 14]