INTERNET-DRAFT Sami Boutros Clarence Filsfils Samer Salam Intended Status: Standards Track (Cisco) Expires: September 1, 2011 February 28, 2011 VPLS Active/Active Multi-homing draft-boutros-l2vpn-vpls-active-active-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Boutros et al. Expires September 1, 2011 [Page 1] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 Boutros et al. Expires September 1, 2011 [Page 2] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 Abstract This document defines VPLS extensions to support per-flow load- balancing among multiple active attachment circuits connected to the same multi-homed site, fast convergence upon redundant link or node failure, flexible PE location, shortest-path routing, and policy support such as E-TREE. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Active-Active Extensions to VPLS . . . . . . . . . . . . . . . . 7 3.1 SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Modified VPLS Label Stack . . . . . . . . . . . . . . . . . 7 3.3 Forwarding Rules - Active/Active . . . . . . . . . . . . . . 8 3.3.1 A frame is received from a local AC . . . . . . . . . . 8 3.3.2 A packet is received from the backbone . . . . . . . . 9 3.3.3 EIBGP Multipath Behavior . . . . . . . . . . . . . . . 9 3.3.4 Active Standby . . . . . . . . . . . . . . . . . . . 10 3.3.5 MH Site label usage . . . . . . . . . . . . . . . . . 10 3.3.6 MAC Learning Logic Extensions . . . . . . . . . . . . 10 3.3.7 MAC Flush Logic Extensions . . . . . . . . . . . . . 10 4 Fast convergence . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 PE Node Failure . . . . . . . . . . . . . . . . . . . . . 11 4.2 AC Failure . . . . . . . . . . . . . . . . . . . . . . . . 11 5 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6 Control Plane Signaling Extension Requirements . . . . . . . . 11 6.1 VPLS BGP NLRI Extensions . . . . . . . . . . . . . . . . . 11 6.2 LDP TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Eliminating Duplicate Frames: DF Election Requirement . . . . . 12 8 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Active/Active Redundancy Scenarios . . . . . . . . . . . . 12 8.1.1 Flooded traffic from/to MH Sites . . . . . . . . . . 12 8.1.2 Unicast traffic from MH Site M3 to SH Site M5 . . . . 13 8.1.3 Unicast traffic from MH Site M3 to MH Site M1 . . . . 13 8.1.4 Unicast traffic from SH Site M2 to MH Site M1 (AC10 Failure) . . . . . . . . . . . . . . . . . . . . . . 14 8.1.5 Multicast traffic from MH Site M3 to MH Site M1 (AC1 Failure) . . . . . . . . . . . . . . . . . . . . . . 14 8.1.6 Unicast traffic from SH Site M2 to MH Site M1 (PE1 failure) . . . . . . . . . . . . . . . . . . . . . . 15 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 10.2 Informative References . . . . . . . . . . . . . . . . . 16 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Boutros et al. Expires September 1, 2011 [Page 3] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 Boutros et al. Expires September 1, 2011 [Page 4] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 1 Introduction VPLS currently supports multi-homing with active/standby redundancy, for e.g. as discussed in draft-ietf-l2vpn-vpls-multihoming. While this redundancy model is sufficient for certain deployments, there are evolving network applications that require support for active/active redundancy with per flow load-balancing. VPLS support for active/active multi-homing is applicable only when the access network Layer 2 redundancy mechanism supports it. For example mLACP, as defined in [ICCP], can support active/active redundancy. It is worth noting that active/active multi-homing can be achieved using a virtual switch solution, and that approach has its own set of advantages and drawbacks that are outside the scope of this document. Consider the simple network topology that follows: +-----PE1 +--------+ CE1 | VPLS | PE3 -- CE3 +-----PE2 +--------+ CE1 is dual homed to PE1 and PE2. PE1, PE2 and PE3 are connected to the same VPLS instance with a full mesh of PWs. If both of the ACs connecting CE1 to PE1 and PE2 are active, the following issues would arise in the network, if it were running current VPLS: 1- Unknown unicast, multicast and broadcast traffic originating from CE1 on the active AC towards PE1 may be looped back to CE1 from PE2 on the other active AC. 2- Unknown unicast, multicast and broadcast traffic originating from CE3 and flooded by PE3, would arrive to PE1 and PE2, and duplicate packets will be delivered to CE1. 3- Traffic with a particular source MAC address (M1) originating from CE1 towards the core, and load-balanced to both PE1 and PE2, will cause MAC address table instability on PE3. The latter will see M1 flip-flopping between the 2 PWs originating from PE1 and PE2, respectively. This document describes a flexible multi-homing solution with all-active ACs using VPLS data-path extensions. In the sections that follow, we will describe: (1) The VPLS data-path forwarding extensions to support all-active multi-homing. (2) The mechanism to achieve optimum forwarding for both unicast and multicast flows between single-homed and multi-homed sites connected to the same VPLS domain. (3) The mechanism to achieve fast convergence on port, link or node failures. (4) The requirements for the control plane signaling extensions as they apply to the VPLS signaling procedures defined in [rfc4761] and [rfc4762]. (5) The DF election mechanism requirements for eliminating frame duplication in the case of flooded multi-destination traffic. (6) The support of E-TREE service restrictions The fundamental idea behind this proposal is as follows: when a PE (PEr) receives a frame from the MPLS backbone, it needs to know 1) from which source site it is coming (this is known as SSID, the source site ID. Each site has a Boutros et al. Expires September 1, 2011 [Page 5] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 unique site ID) and the 'cast status of the frame' (whether the source PE (PEs) sent the frame to one single PE or to several PE's). Once this information is available, the receiving PEr can:- ensure to not send the frame back into the source site (PEr filters any local AC which has the same SSID as the source site)- if the frame needs to be flooded, decide whether the frame can be flooded on a local multi- homed AC (if the cast status is unicast, yes it can be flooded; if the cast status is flooded, then PEr can only flood on the local MH AC if PEr is DF for that MH AC). The encoding of these two pieces of information within a packet is performed with an additional upstream label pushed after the classical VPLS PW label. A source PE signals (BGP or LDP) such upstream label beforehand and binds two pieces of semantics to each upstream label: the SSID of the source site and the cast status of the frame. At minimum, two upstream labels are required per connected site at a PE: one for each cast status. If a specific deployment uses P2M LSP for flooding multicast, broadcast and unknown unicast, then the cast status can be derived from the top label (p2p PW vs P2M LSP) and one single upstream label is required per PE per site. 1.1 Terminology 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 [RFC2119]. 2 Definitions CE: Customer Edge DHD: Dual-homed Device SHD: Single-homed Device DHN: Dual-homed Network LACP: Link Aggregation Control Protocol LSM: Label Switched Multicast MDT: Multicast Delivery Tree P2MP: Point to Multipoint P2P: Point to Point PE: Provider Edge Boutros et al. Expires September 1, 2011 [Page 6] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 PoA: Point of Attachment PW: Pseudowire MH-ID: Multi-home Identifier. SH-ID: Single-home Identifier. MH: Multi-Home. SH: Single-Home. SSID: source site ID 3 Active-Active Extensions to VPLS 3.1 SSID A site connected to a PE is either singled-home (SH) (one single AC between that site and any PE of the VPLS domain) or multi-homed (MH) (multiple AC's between that site and multiple PE's). A MH site has a globally unique site ID. A SH site has a unique site ID in the context of the PE advertising it. When a PE advertises connectivity to a site, it indicates the site nature (SH or MH), its site ID, two upstream labels bound to the site and the VPLS instances associated with the site. A PE connected to 5 SH sites can either advertise one single SH site route for all the 5 SH sites or advertise 5 individual SH site routes. At least 2 upstream labels are required to identify the site: one upstream label is used for known unicast traffic originating from the site (the PE which sent the frame sent it to one single remote PE), and another upstream label is used for multi- destination traffic from the site (the PE which sent the frame sent it to multiple remote PE's either via ingress replication or P2MP LSP). The use of different upstream labels will be described in more details in sections below. We call 'Cast status' whether the source PE unicast the frame to one single PE or to multiple remote PE's. This is an important piece of information to let a remote PE connected to a multi-homed site know whether it should flood the packet to the multi-homed site or not. MH-Site labels are withdrawn by a PE when the site gets disconnected from the PE, e.g. due to link failures. 3.2 Modified VPLS Label Stack When a PE connected to a MH-Site floods traffic originating from that site over a P2MP LSP, it MUST use the following label stack: 1- Using a P2MP aggregate inclusive tree: Boutros et al. Expires September 1, 2011 [Page 7] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 [P2MP Label] [Identify Source PE] [VSI Label] [Identify VPLS instance] [Source site Label] [Identify SH/MH site, Cast Status] 2- Using a P2MP inclusive tree: [P2MP Label] [Identify Source PE] [Source site Label] [Identify SH/MH site, cast status] The source site label is the upstream label advertised by the PE connected to the site and corresponding to the advertised MH-ID or SH-ID. When a PE connected to a MH-Site forwards unicast traffic originating from that site over a P2P PW, it MUST use the following label stack: [PW Label] [Identify Source PE + and VPLS instance] [Source site Label][Identify SH/MH site, cast stat] The source site label is the upstream label advertised by the PE connected to the site and corresponding to the advertised MH-ID or SH-ID. The same label stack can be used to flood multi-destination traffic originating from the MH-Site, using P2P PWs, in case of ingress replication. 3.3 Forwarding Rules - Active/Active 3.3.1 A frame is received from a local AC The PE associates a SSID with the packet (the SSID of the source AC). The PE performs a MAC lookup in the VPLS instance associated with the source AC. A. a match is found A.1 the match is a local AC The behavior is the same as when a packet is received from the core and a MAC lookup gives a match on a local AC. See later section C. A.2 the match is a remote SHID The packet is sent to the remote PE. The label encapsulation is as described in section 3.1 (specifically, the upstream label identifies the source site ID and the cast status as unicast) A.3 the match is a remote MHID A hash is computed on L2/L3/L4 flow-defining fields and a single PE connected to the remote MHID site is selected. The packet is sent to this remote PE with the label stack as described in section 3.1 (specifically, the upstream label identifies the source site ID and the cast status as unicast) B. No match is found The packet is flooded on local ACs and all the remote PEs within the Boutros et al. Expires September 1, 2011 [Page 8] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 VPLS instance. Some specific filtering is required for flooding on local ACs. This behavior is similar to the one performed when a packet is received from the MPLS backbone and the MAC lookup gives no match. See section D for specific details. The label encapsulation for packets flooded to remote PEs is as described in section 3.1 (specifically, the upstream label identifies the source site ID and the cast status as flooded). 3.3.2 A packet is received from the backbone When a packet P is received from the backbone, the receiving PE (PEr) will determine the four following pieces of information: from which remote site ID the packet is coming, what is the cast status of packet P and what is its VPLS instance. PEr first learns that the SMAC of packet P is reachable via the source site ID (learning is done to a site ID, not to a PE). If the source site is MH, then the SMAC is in fact learned against a load- balancing data-structure of 2 or more PEs. Second PEr performs a MAC destination address lookup in the VPLS instance. C. A match is found on a local AC - PEr forwards on the local AC only if [the site ID of the local AC is <> from the source site ID] D. No match is found The packet is flooded on all local AC's which meet ALL the following properties: - The local AC site ID is <> from the source site ID - If P's cast status is flooded, then PEr can flood on a local AC part of a multi-homed site if PEr is the DF for that MH site Note: in case D, note that if the cast status of the packet is unicast, then P should be flooded on all local MH AC's whether PEr is DF or not. Indeed, the packet was unicast to PEr by the source PE and hence there is no need to apply DF filtering to avoid duplication between several PEs connected to the same MH site. Note: Core split horizon rule MUST be enforced as per classic VPLS: a frame received from PW cannot be flooded back onto PWs 3.3.3 EIBGP Multipath Behavior When a frame is received from a local AC, and the MAC lookup gives a match on a MHID site which has a local AC and a remote PE, this revision specifies that the local AC should be preferred. A later revision might support the load-balancing of traffic between the Boutros et al. Expires September 1, 2011 [Page 9] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 local path and the remote path. Such a behavior is commonly known as EIBGP multipath in L3VPN. 3.3.4 Active Standby The only difference occurs in step A3. No hashing is required: the packet is always sent to the primary PE within the load-balancing structure. Note: In Active/Standby mode, the standby PE MAY configure the blocking behavior in both directions for the MH-Site. 3.3.5 MH Site label usage When a PE PEr advertises a label L bound to a local MHID, the local and remote PEs will install the label differently in their forwarding table. PEr, the local PE, will install L as a downstream label. Any packet received with this label is cross-connected (a la VPWS) onto an AC leading to the MHID site. This forwarding entry is key to deliver sub-50msec protection upon AC failure (see later). A remote PEt installs L in a context table indexed by 'PEr'. More specifically, when PEt receives a frame from PEr, a first label will identify 'PEr', the source PE and then the next label will be L. PEt will look up L into the context table related to PEr and will deduce what is the source MHID of the packet and what is the cast status of the packet. 3.3.6 MAC Learning Logic Extensions MAC learning for packet coming from the backbone is performed against the source site ID. In the case of a MH source site ID, this is very important as the MAC address is learned to the MHID and hence traffic later sent to this MAC address can be load-balanced to all the PEs connected to that MHID site. In the case of a SH source site ID, as a single PE is connected to such site, the MAC learning is in fact similar to classic VPLS. 3.3.7 MAC Flush Logic Extensions When one of the SH site ACs goes down, existing mechanisms for MAC flush for the VPLS instances associated with this AC MUST be used. Allocating a distinct SSID to each SH AC allows a PE to limit the flush to the minimum set of impacted MAC addresses. When a PE attached to the MH site goes down, remote PEs MUST remove the failed PE from the ECMP of PWs associated with the MH Site with no MAC flushing. When the AC attached to a MH-Site goes down, the PE MUST send a withdrawal for the MH Site ID and associated label. Remote PEs MUST then remove the PE from the ECMP of PWs associated with the MH Site without MAC flushing. MAC entries learnt via MH site on a given VPLS instance must be flushed only when all PEs withdraw their Boutros et al. Expires September 1, 2011 [Page 10] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 advertisements for that MH Site. 4 Fast convergence 4.1 PE Node Failure When a PE attached to a MH site goes down, remote PEs can detect the PE failure using existing fast detection mechanisms and update their load-balancing structure for the MHID site by removing the failed PE's PW from the load-balancing path-list. 4.2 AC Failure Two PEs PE1 and PE2 are connected to the same MH site S with respective ACs AC1 and AC2. PE1 advertises a label L bound to site S hence PE1 cross-connects any packet received with label L onto AC1 (a la VPWS). PE2 pre-computes and pre-installs a backup structure for AC2: any traffic that should be sent on AC2, would be backed up on an LSP to PE1 with an extra label L being pushed. Upon AC2 failure, this backup structure is immediately enabled and the traffic is rerouted to PE1 which reroutes it onto AC1 and hence towards the resilient site S. 5 Policy Detailed procedures on support of forwarding policies, such as those mandated by E-TREE service will be described in the next revision of this document. 6 Control Plane Signaling Extension Requirements Each PE MUST signal (1) a MH-ID advertisement for each MH site it is connected to and a set of one or more associated upstream label(s) to identify the MH site, (2) an SH-ID advertisement (0) for all single homed sites it is connected to and a set of one or more associated upstream non null label(s) and (3) the list of VPLS instances associated with the MH and SH site advertisements. The upstream labels that identify the source SH or MH site are used to distinguish whether the traffic is being unicast or flooded over the core. This is to allow the disposition PE to decide whether it needs to enforce the AC split-horizon and DF filtering. 6.1 VPLS BGP NLRI Extensions TBD 6.2 LDP TLVs Boutros et al. Expires September 1, 2011 [Page 11] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 TBD 7 Eliminating Duplicate Frames: DF Election Requirement Designated Forwarder (DF) election is needed to eliminate duplicates for flooded traffic coming from core to the MH site. Only the PE that is elected as the DF MUST forward the flooded traffic. The mechanisms of DF election are outside the scope of this document. 8 Operation 8.1 Active/Active Redundancy Scenarios 8.1.1 Flooded traffic from/to MH Sites M3 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 - Assume PE3 and PE30 signaled the MH-Site-ID3 and upstream labels. - Assume PE3 and PE1 are DF for Site 3 and Site 1 and PE3 is DF for site10 1. Mcast Packet with src MAC M3 arrives at PE3. 2. PE3 floods packet to AC40 and AC13. 3. PE3 encap packet with upstream label (Cast= flood) and flood over PWs or over p2mp LSP to PE1, 2, 10, 30. 4. On PE1,2,10,30 learning of M3 will be against MHID3 load-balancing structure. 5. PE1, floods packet to AC4 and AC1 (DF for Site1). 6. PE10 floods only to AC5 and PE2 to AC2. 7. On PE30, learning will be against MHID3 load-balancing structure. 8. PE30, floods packet to AC300. Boutros et al. Expires September 1, 2011 [Page 12] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 8.1.2 Unicast traffic from MH Site M3 to SH Site M5 M3 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 Assume PE3 and PE1 are DF for Site 3 and Site 1. 1. Packet with src MAC M3 arrives at PE30. 2. PE30 has a match for M5 via SHID at PE10. PE30 encap packet with upstream label (Cast=Unicast Packet) and send packet over PW to PE10. 3. On PE10 learning of M3 will be against MHID3. 4. PE10 sends packet to M5 over AC5. 8.1.3 Unicast traffic from MH Site M3 to MH Site M1 M3 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 Boutros et al. Expires September 1, 2011 [Page 13] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 Assume PE3 and PE1 are DF for Site 3 and Site 1. 1. Packet with src MAC M3 arrives at PE3. 2. PE3 has a match for M1 via MHID1. PE3 hashes and selects PE1 out of the load-balancing structure for MHID1. PE3 encapsulates packet with upstream label (Cast=Unicast Packet) and send packet over PW to PE1.. 3. PE1 receives packet and learns M3 is behind MHID3. 4. PE1 sends packet to AC1. 8.1.4 Unicast traffic from SH Site M2 to MH Site M1 (AC10 Failure) M3 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 Assume PE3 and PE1 are DF for Site 3 and Site 1. 1. Packet with src MAC M2 arrives at PE2. 2. PE2 encap packet with SH Site upstream label (Unicast packet). 3. PE2 matches M1 behind MHID1. It hashes and picks PE1. PE2 sends the packet over PW to PE10 with upstream label identifying SHID at PE2 and cast status=unicast. 4. PE10 receives packet over PE2 PW, does mac learning against SHID at PE2 (basically PE2). 5. Once PE10 detects AC10 failure, it sends packet to PE1 encaping the packet with the PE1 advertised upstream label (unicast) for MH Site-1. 6. PE1 receives packet and PE1 pop the label, and sends packet to AC1 with no mac learning. 7. PE10 sends a withdraw for the MH Site1 route to all PEs, all PEs would remove the PE10 PW from the ECMP. 8.1.5 Multicast traffic from MH Site M3 to MH Site M1 (AC1 Failure) M3 Boutros et al. Expires September 1, 2011 [Page 14] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 Assume PE3 and PE1 are DF for Site 3 and Site 1. 1. Mcast Packet with src MAC M3 arrives at PE3. 2. PE3 floods packet to AC40 and AC13. 3. PE3 encap packet with upstream label (Cast status = Flood ) and flood over PWs or over p2mp LSP to PE1, 2, 10, 30. 4. On PE1,2,10,30 learning of M3 will be against MHID3. 5. PE10 floods only to AC5 and PE2 to AC2. 6. On PE30, learning will be against MHID3. 7. PE30, floods packet to AC300. 8. PE1, floods packet to AC4, but since AC1 is down, PE1 encap the packet with PE10 MH-Site-1 upstream label (unicast) and sends packet to PE10. 9. PE10 received packet from PE1, pops the label and sends the packet to AC10 with no mac learning. 10. PE1 informs PE10 to become the DF. 8.1.6 Unicast traffic from SH Site M2 to MH Site M1 (PE1 failure) M3 +-----+ |Site3| +-----+ AC3/ \AC30 +------+ +----+ +----+ +-----+ M33|Site33|-AC40-| PE3| |PE30| -AC300- |Site6| M30 +------+ +----+ +----+ +-----+ / +----+ AC13 | PE2| +-----+ +------+ / +----+ \AC2- |Site2| M2 M10|Site10| +-----+ +------+ \AC11 Boutros et al. Expires September 1, 2011 [Page 15] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 \ +-----+ +----+ +----+ +-----+ M4 |Site4| -AC4-| PE1| |PE10|-AC5- |Site5| M5 +-----+ +----+ +----+ +-----+ AC1 \ /AC10 +-----+ |Site1| +-----+ M1 Assume PE3 and PE1 are DF for Site 3 and Site 1. 1. PE2 detects PE1 failure, remove PE1 from the load-balancing structure related to site MHID1. 2. Packet with src MAC M2 arrives at PE2. 3. PE2 has a match for M1 via MHID1. As there is a single PE left in the related load-balancing structure, the packet is forwarded to PE10. 4. PE10 receives packet over PE2 PW and learns that M2 is behind a SH site behind PE2. 5. PE10 sends packet to AC10. 9 IANA Considerations To be added in future revisions. 10 References 10.1 Normative References [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC4664, September 2006. [RFC4761] "Virtual Private LAN Service (VPLS) Using BGP for Auto- discovery and Signaling", January 2007. [RFC4762] "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007. 10.2 Informative References [VPLS-BGP-MH] Kothari et al., "BGP based Multi-homing in Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 00, work in progress, November, 2009. [VPLS-MCAST] Aggarwal et al., "Multicast in VPLS", draft-ietf-l2vpn vpls-mcast-06.txt, work in progress, March, 2010 [PWE3-ICCP] Martini et al., "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-02.txt, work in progress, Octoer, 2009 Boutros et al. Expires September 1, 2011 [Page 16] INTERNET DRAFT VPLS Active/Active Multi-homing February 28, 2011 Author's Addresses Sami Boutros Cisco Systems, Inc. Email: sboutros@cisco.com Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com Samer Salam Cisco Systems, Inc. Email: ssalam@cisco.com Boutros et al. Expires September 1, 2011 [Page 17]