Internet Working Group Ali Sajassi Internet Draft Samer Salam Category: Standards Track Keyur Patel Cisco Expires: September 23, 2010 March 23, 2010 Routed VPLS using BGP draft-sajassi-l2vpn-rvpls-bgp-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 July 26, 2010. Copyright Notice Copyright (c) 2010 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. Sajassi, et. al. [Page 1] draft-sajassi-l2vpn-rvpls-00.txt March 2010 Abstract VPLS, as currently defined, has challenges pertaining to the areas of redundancy and multicast optimization. In particular, multi- homing with all-active forwarding cannot be supported and there's no easy way for leveraging MP2MP MDTs for optimizing the delivery of multi-destination frames. This document defines an evolution of the current VPLS solution, referred to as Routed VPLS (R-VPLS), to address these shortcomings. 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 RFC 2119 Table of Contents 1. Introduction.................................................... 3 2. Terminology..................................................... 3 3. Requirements.................................................... 4 3.1. All-Active Multi-homing....................................... 4 3.1.1. Flow-based Load Balancing................................... 4 3.1.2. Flow-based Multi-pathing.................................... 4 3.1.3. Geo-redundant PE Nodes...................................... 5 3.1.4. Optimal Traffic Forwarding.................................. 5 3.1.5. Flexible Redundancy Grouping Support........................ 5 3.1.6. Dual-homed Network.......................................... 6 3.2. Multicast Optimization with MP2MP MDT......................... 6 4. VPLS Issues..................................................... 6 4.1. Forwarding Loops.............................................. 7 4.2. Duplicate Frame Delivery...................................... 8 4.3. MAC Forwarding Table Instability.............................. 8 4.4. Identifying Source PE in MP2MP MDT............................ 8 5. Solution Overview: Routed VPLS (R-VPLS)......................... 9 6. R-VPLS Components............................................... 9 6.1. MAC Learning & Forwarding in Bridge Module................... 10 6.2. MAC Address Distribution in BGP.............................. 10 6.2.1. R-VPLS NLRI................................................ 11 6.2.2. L2VPN-MAC SAFI............................................. 12 6.2.3. BGP Route Targets.......................................... 12 6.3. Frame Forwarding over MPLS Core.............................. 12 6.3.1. Unicast.................................................... 12 6.3.2. Multicast/Broadcast........................................ 13 Sajassi, et al. [Page 2] draft-sajassi-l2vpn-rvpls-00.txt March 2010 6.4. Loop Avoidance and Duplicates Prevention..................... 13 6.4.1. Filtering Based on Multi-homing ID......................... 14 6.4.2. Defining a Designated Forwarder............................ 14 6.5. LACP State Synchronization................................... 14 7. Security Considerations........................................ 15 8. IANA Considerations............................................ 15 9. Intellectual Property Considerations........................... 15 10. Normative References.......................................... 16 11. Informative References........................................ 16 12. Authors' Addresses............................................ 16 1. Introduction VPLS, as defined in [RFC4664][RFC4761][RFC4762], is a proven and widely deployed technology. However, the existing solution has a number of challenges when it comes to redundancy and multicast optimization. In the area of redundancy, current VPLS can only support multi- homing with active/standby resiliency model, for e.g. as described in [VPLS-BGP-MH]. Flexible multi-homing with all-active ACs cannot be supported without adding considerable complexity to the VPLS data-path. In the area of multicast optimization, [VPLS-MCAST] describes how LSM MDTs can be used in conjunction with VPLS. However, this solution is limited to P2MP MDTs, as there's no easy way for leveraging MP2MP MDTs with VPLS. The lack of MP2MP support creates scalability issues for certain applications. This document defines an evolution of the current VPLS solution, to address the aforementioned shortcomings. The proposed solution is referred to as Routed VPLS (R-VPLS). Section 2 provides a summary of the terminology used. Section 3 discusses the requirements for all-active resiliency and multicast optimization. Section 4 described the issues associated with the current VPLS solution in addressing the requirements. Section 5 offers an overview of R-VPLS and then Section 6 goes into the details of its components. 2. Terminology CE: Customer Edge DHD: Dual-homed Device Sajassi, et al. [Page 3] draft-sajassi-l2vpn-rvpls-00.txt March 2010 DHN: Dual-homed Network LACP: Link Aggregation Control Protocol LSM: Label Switched Multicast MDT: Multicast Delivery Tree MP2MP: Multipoint to Multipoint P2MP: Point to Multipoint P2P: Point to Point PE: Provider Edge PoA: Point of Attachment PW: Pseudowire R-VPLS: Routed VPLS 3. Requirements This section describes the requirements for all-active multi-homing and MP2MP MDT support. 3.1. All-Active Multi-homing 3.1.1. Flow-based Load Balancing A customer network or a customer device can be multi-homed to a provider network using IEEE link aggregation standard -[802.1AX]. In [802.1AX], the load-balancing algorithms by which a CE distributes traffic over the Attachment Circuits connecting to the PEs are quite flexible. The only requirement is for the algorithm to ensure in-order frame delivery for a given traffic flow. In typical implementations, these algorithms involve selecting an outbound link within the bundle based on a hash function that identifies a flow based on one or more of the following fields: i) Layer 2: Source MAC Address, Destination MAC Address, VLAN i i) Layer 3: Source IP Address, Destination IP Address i i i) Layer 4: UDP or TCP Source Port, Destination Port iv) Combinations of the above. A key point to note here is that [802.1AX] does not define a standard load-balancing algorithm for Ethernet bundles, and as such different implementations behave differently. As a matter of fact, a bundle operates correctly even in the presence of asymmetric load- balancing over the links. This being the case, the first requirement for active/active VPLS dual-homing is the ability to accommodate flexible flow-based load-balancing from the CE node based on L2, L3 and/or L4 header fields. 3.1.2. Flow-based Multi-pathing [PWE3-FAT-PW] defines a mechanism that allows PE nodes to exploit equal-cost multi-paths (ECMPs) in the MPLS core network by Sajassi, et al. [Page 4] draft-sajassi-l2vpn-rvpls-00.txt March 2010 identifying traffic flows within a PW, and associating these flows with a Flow Label. The flows can be classified based on any arbitrary combination of L2, L3 and/or L4 headers. Any active/active VPLS dual-homing mechanism should seamlessly interoperate and leverage the mechanisms defined in [PWE3-FAT-PW]. 3.1.3. Geo-redundant PE Nodes The PE nodes offering dual-homed connectivity to a CE or access network may be situated in the same physical location (co-located), or may be spread geographically (e.g. in different COs or POPs). The latter is desirable when offering a geo-redundant solution that ensures business continuity for critical applications in the case of power outages, natural disasters, etc. An active/active VPLS dual- homing mechanism should support both co-located as well as geo- redundant PE placement. The latter scenario often means that requiring a dedicated link between the PEs, for the operation of the dual-homing mechanism, is not appealing from cost standpoint. Furthermore, the IGP cost from remote PEs to the pair of PEs in the dual-homed setup cannot be assumed to be the same when those latter PEs are geo-redundant. 3.1.4. Optimal Traffic Forwarding In a typical network, and considering a designated pair of PEs, it is common to find both single-homed as well as dual-homed CEs being connected to those PEs. An active/active VPLS dual-homing solution should support optimal forwarding of unicast traffic for all the following scenarios: i) single-homed CE to single-homed CE i i) single-homed CE to dual-homed CE i i i) dual-homed CE to single-homed CE iv) dual-homed CE to dual-homed CE This is especially important in the case of geo-redundant PEs, where having traffic forwarded from one PE to another within the same redundancy group introduces additional latency, on top of the inefficient use of the PE node's switching capacity. 3.1.5. Flexible Redundancy Grouping Support In order to simplify service provisioning and activation, the VPLS dual-homing mechanism should allow arbitrary grouping of PE nodes into redundancy groups. This is best explained with an example: consider three PE nodes - PE1, PE2 and PE3. The dual-homing mechanism must allow a given PE, say PE1, to be part of multiple redundancy groups concurrently. For example, there can be a group (PE1, PE2) and another group (PE1, PE3), where CEs could be dual- homed to any one of these two groups. Sajassi, et al. [Page 5] draft-sajassi-l2vpn-rvpls-00.txt March 2010 3.1.6. Dual-homed Network Supporting active/active dual-homing of an Ethernet network (a.k.a. Dual-homed Network or DHN) to a pair of VPLS PEs poses a number of challenges. First, some resiliency mechanism needs to be in place between the DHN and the PEs offering dual-homing, in order to prevent the formation of L2 forwarding loops. Two options are possible here: either the PEs participate in the control plane protocol of the DHN (e.g. MST or ITU-T G.8032), or some auxiliary mechanism needs to run between the CE nodes and the PEs. The latter must be complemented with an interworking function, at the CE, between the auxiliary mechanism and the DHN's native control protocol. However, unless the PEs participate directly in the control protocol of the DHN, fast control-plane re-convergence and fault recovery cannot be guaranteed. Secondly, all existing Ethernet network resiliency mechanisms operate at best at the granularity of VLANs. Hence, any load-balancing would be limited to L2 flows only. Depending on the applications at hand, this coarse flow granularity may not have enough entropy to provide proper link/node utilization distribution within the provider's network. Thirdly, an open issue remains with the handling of DHN partitioning: the PEs need to reliably detect the situation where the DHN has been segmented and each PE needs to handle inbound/outbound traffic for only those customers (or hosts) connected to the local partition. 3.2. Multicast Optimization with MP2MP MDT In certain applications, multiple multicast sources may exist for a given VPLS instance, and these sources are dispersed over the various PEs. For these applications, relying on P2MP MDTs for VPLS is neither efficient nor scalable. In the worst case, a selective MDT rooted on every PE may be required, thereby leading to an exponential growth in the amount of state that needs to be maintained in the MPLS core: the state required is O(N*V*M), where N is the average number of PEs per VPLS instance, V is the number of VPLS instances in the network and M is the average number of multicast groups per instance. By using MP2MP MDTs, it is possible to scale better by eliminating the number of PEs from the equation. Thus, the scalability of multicast becomes no longer a function of the number of sites. 4. VPLS Issues This section describes issues associated with the current VPLS solution in meeting the above requirements. The current solution for VPLS, as defined in [RFC4761]and [RFC4762], relies on establishing a full-mesh of pseudowires among participating PEs, and data-plane Sajassi, et al. [Page 6] draft-sajassi-l2vpn-rvpls-00.txt March 2010 learning for the purpose of building the MAC forwarding tables. This learning is performed on traffic received over both the attachment circuits as well as the pseudowires. Supporting an all-active multi-homing solution with current VPLS is subject to three fundamental problems: the formation of forwarding loops, duplicate delivery of flooded frames and MAC Forwarding Table instability. These problems will be described next in the context of the example network shown in figure 1 below. +--------------+ | | | | +----+ AC1 +----+ | | +----+ +----+ | CE1|-----|VPLS| | | |VPLS|---| CE2| +----+\ | PE1| | IP/MPLS | | PE3| +----+ \ +----+ | Network | +----+ \ | | AC2\ +----+ | | \|VPLS| | | | PE2| | | +----+ | | +--------------+ Figure 1: VPLS Multi-homed Network In the network of Figure 1, it is assumed that CE1 has both attachment circuits AC1 & AC2 active towards PE1 and PE2, respectively. This can be achieved, for example, by running a multi- chassis Ethernet link aggregation group from CE1 to the pair of PEs. 4.1. Forwarding Loops Consider the case where CE1 sends a unicast frame over AC1, destined to CE2. If PE1 doesn't have a forwarding entry in its MAC address table for CE2, it will flood the frame to all other PEs in the VPLS instance (namely PE3 & PE2) using either ingress replication over the full-mesh of pseudowires, or alternatively over an LSM tree [VPLS-MCAST]. When PE2 receives the flooded traffic, and assuming it doesn't know the destination port to CE2, it will flood the traffic over the ACs for the VFI in question, including AC2. Hence, a forwarding loop is created where CE1 receives its own traffic. Sajassi, et al. [Page 7] draft-sajassi-l2vpn-rvpls-00.txt March 2010 4.2. Duplicate Frame Delivery Examine the scenario where CE2 sends a multi-destination frame (unknown unicast, broadcast or multicast) to PE3. PE3 will then flood the frame to both PE1 & PE2, using either ingress replication over the pseudowire full-mesh or an LSM tree. Both PE1 and PE2 will receive copies of the frame, and both will forward the traffic on to CE1. Net result is that CE1 receives duplicate frames. 4.3. MAC Forwarding Table Instability Assume that both PE1 and PE2 have learnt that CE2 is reachable via PE3. Now, CE1 starts sending unicast traffic to CE2. Given that CE1 has its ACs configured in an Ethernet link aggregation group, it will forward traffic over both ACs using some load-balancing technique as described in section 3.1 above. Both PE1 and PE2 will forward frames from CE1 to PE3. Consequently, PE3 will see the same MAC address for CE1 constantly moving between its pseudowire to PE1 and its pseudowire to PE2. The MAC table entry for CE1 will keep flip-flopping indefinitely depending on traffic patterns. This MAC table instability on PE3 may lead to frame mis-ordering for traffic going from CE2 back to CE1. Shifting focus towards the requirement to support MP2MP MDT, the problem facing VPLS here is performing MAC learning over MP2MP MDT, as discussed next. 4.4. Identifying Source PE in MP2MP MDT In the solution described in [VPLS-MCAST], a PE must perform MAC learning on traffic received over an LSM MDT. To that end, the receiving PE must be able to identify the source PE transmitting the frame, in order to associate the MAC address with the p2p pseudowire leading back to the source. With P2MP MDT, the MDT label uniquely identifies the source PE. For inclusive trees, the MDT label also identifies the VFI; whereas, for aggregate inclusive trees, a second upstream-assigned label identifies the VFI. However, when it comes to MP2MP MDT, the MDT label identifies the root of the tree (which most likely is not the source PE), and the second label (if present) identifies the VFI. There is no easy solution to this problem since neither upstream nor downstream label assignment can work among the VPLS PEs. From the above, it should be clear that with the current VPLS solution it is not possible to support all-active multi-homing or MP2MP MDTs. In the sections that follow, we will explore a new solution that meets the requirements identified in section 3 and addresses the problems highlighted in this section. Sajassi, et al. [Page 8] draft-sajassi-l2vpn-rvpls-00.txt March 2010 5. Solution Overview: Routed VPLS (R-VPLS) This solution involves augmenting the current VPLS solution with control-plane based MAC learning over the MPLS core. A PE continues to perform data-plane based learning over its ACs, but performs no such learning on traffic received from the MPLS core. MAC addresses learnt by a PE over its ACs are advertised, using BGP, to all other PEs in the same VPLS instance. Remote PEs receiving these BGP NLRIs install forwarding entries, for the associated MAC addresses, in their VFIs pointing to the PE sending the advertisements. Multicast/broadcast traffic can be forwarded over the pseudowire full-mesh per current VPLS, or over an LSM tree leveraging the model described in [VPLS-MCAST]. Forwarding of unknown unicast traffic over the MPLS/IP core is optional and the default mode is not to forward it, but it is flooded over the local ACs per normal bridging operations. R-VPLS follows the same reference model for VPLS defined in [RFC4664]. In particular, the PE model defined in Figure 3 of said RFC applies, albeit with modifications to the functionality of the Bridge and the VPLS Forwarder modules. The details of the R-VPLS components are discussed in the next section. Auto-discovery in R-VPLS works exactly as before and after PEs belonging to a given VPLS instance discover each other, an inclusive MP2MP MDT is setup per [MPLS-MDT]. Optionally, a full-mesh of PWs per [RFC4761]/[RFC4762] or a set of P2MP MDTs per [VPLS-MCAST] can be setup. The purpose of the MP2MP MDT or the full-mesh of PWs, or the set of P2MP MDTs is for transporting customer multicast/ broadcast frames and optionally for customer unknown unicast frames. No MAC address learning is needed for frames received over the full- mesh of PWs or the MDT(s). The mapping of customer Ethernet frames to a VPLS instance (qualified learning versus unqualified learning) is also performed as before. Furthermore, the MAC learning over Attachment Circuits is done in the data-plane just as with current VPLS solution. The setup of any additional MDT per user multicast group or groups is also performed per [VPLS-MCAST]. 6. R-VPLS Components Figure 2 below shows the model of a PE participating in R-VPLS. The modules in this figure will be used to explain the components of R- VPLS. MPLS Core +-------------------------------+ | +-----------+ | R-VPLS PE | +---------| VPLS | | Sajassi, et al. [Page 9] draft-sajassi-l2vpn-rvpls-00.txt March 2010 | +----+ | Forwarder | | | |BGP | +-----------+ | | +----+ | LAN Emulation Interface | | +-----------+ | | +---------| Bridge | | | +-----------+ | +-----------------|---|---|-----+ AC1 AC2 ACn CEs Figure 2: R-VPLS PE Model 6.1. MAC Learning & Forwarding in Bridge Module The Bridge module within an R-VPLS PE performs basic bridging operations as before and is responsible for: i) Learning the source MAC address on all frames received over the ACs, and dynamically building the bridge forwarding database. i i) Forwarding known unicast frames to local ACs or the LAN Emulation interface for remote destinations. i i i) Flooding unknown unicast frames over the local ACs and optionally over the LAN Emulation interface. iv) Flooding multicast/broadcast frames to the local ACs and to the LAN Emulation interface. v) Informing the BGP module of all MAC addresses learnt over the local ACs. Also informing the BGP module when a MAC entry ages out, or is flushed due to a topology change. vi) Enforcing the filtering rules described in section 6.4. 6.2. MAC Address Distribution in BGP The BGP module within an R-VPLS PE is responsible for two main functions: First, advertising all MAC addresses learnt over the local ACs (by the Bridge module) to all remote PEs participating in the VPLS instance in question. This is done using a new L2VPN NLRI, to be defined. The BGP module should withdraw the advertised NLRIs for MAC addresses as they age out, or when the bridge table is flushed due to a topology change. Since no MAC address learning is performed for traffic received from the MPLS core, these BGP NLRI advertisements are used to build the forwarding entries for remote MAC addresses reachable over the MPLS network. This brings the discussion to the second function of the BGP module, namely: programming entries in the MAC forwarding table (in the VPLS Sajassi, et al. [Page 10] draft-sajassi-l2vpn-rvpls-00.txt March 2010 Forwarder module) using the information in the received BGP NLRIs. These entries will be used for forwarding traffic over the MPLS core to remotely reachable MAC addresses. Of course, the BGP module must remove the forwarding entries corresponding to withdrawn NLRIs. Note that these entries are not subject to timed aging (as they follow a control-plane learning paradigm rather than data-plane learning). BGP extensions are describe below. 6.2.1. R-VPLS NLRI A new BGP NRLI, called R-VPLS NLRI, is defined in this document as follow: +--------------------------------+ | RD (8 octets) | +--------------------------------+ | MPLS Label (4 octets) | +--------------------------------+ | MAC address (6 octets) | +--------------------------------+ Figure 1: R-VPLS NLRI Format RD: Route Distinguisher encoded as described in [RFC4364] MPLS Label: This is a downstream assigned MPLS label that identifies the VPLS instance on the downstream PE (this label can be considered analogous to L3VPN label associated with a given VRF). MAC: This is the customer source MAC learned by the PE and being advertised via BGP. In order for two BGP speakers to exchange R-VPLS NLRI, they must use BGP Capabilities Advertisement to ensure that they both are capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP) with an AFI of 25 and an SAFI of R-VPLS. Sajassi, et al. [Page 11] draft-sajassi-l2vpn-rvpls-00.txt March 2010 6.2.2. L2VPN-MAC SAFI The R-VPLS NLRI is carried in BGP using BGP Multiprotocol Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and a new SAFI known as BGP L2VPN-MAC SAFI pending IANA assignment. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the R-VPLS NLRI encoded as specified in the above. 6.2.3. BGP Route Targets Each BGP R-VPLS NLRI will have one or more route-target extended communities to associate a R-VPLS NLRI with a given VSI. These route-targets control distribution of the R-VPLS NLRI and thereby will control the formation of the overlay topology of the network that constitutes a particular VPN. 6.3. Frame Forwarding over MPLS Core The VPLS Forwarder module is responsible for handling frame transmission and reception over the MPLS core. The processing of the frame differs depending on whether the destination is a unicast or multicast/broadcast address. The two cases are discussed next. 6.3.1. Unicast For known unicast traffic, the VPLS Forwarder sends frames into the MPLS core using the forwarding information received by BGP from remote PEs. The frames are tagged with an LSP tunnel label and a pseudowire label as with current VPLS. The point of variation from current VPLS is in how the pseudowire label is determined and used. In current VPLS, the pseudowire label serves dual purpose: (1) to identify the source PE for data-plane learning, and (2) to identify the VPLS instance (and hence VFI). For R-VPLS, since the MAC learning is done in the control plane, there's no need for the pseudowire label to identify the source PE. Hence, it is possible to simplify the operation by using mp2p pseudowires, where a given PE advertises the same downstream PW label, for a given VPLS instance, to all peer PEs. This PW label can be advertised in the new L2VPN MAC NLRIs. For unknown unicast traffic, an R-VPLS PE can optionally forward these frames over MPLS core; however, the default is not to forward. If these frames are to be forwarded, then the same set of options used for forwarding multicast/broadcast frames (as described in next section) are also applicable here. Sajassi, et al. [Page 12] draft-sajassi-l2vpn-rvpls-00.txt March 2010 6.3.2. Multicast/Broadcast For multi-destination frames (multicast and broadcast) delivery, R- VPLS provides the flexibility of using a number of options: Option 1: the VPLS Forwarder can perform ingress replication over a full-mesh of p2p pseudowires, per current VPLS. Option 2: the VPLS Forwarder can use p2mp MDT per the procedures defined in [VPLS-MCAST]. Option 3: the VPLS Forwarder can use mp2mp MDT per the procedures described in section 6.4. This option is considered as default mode. 6.4. Loop Avoidance and Duplicates Prevention In the case where a set of VPLS PEs offer flexible multi-homing for a number of CEs, special considerations are required to prevent the creation of forwarding loops and delivery of duplicate frames when forwarding multi-destination frames. Consider the example network shown in figure 3 below. In this network, it is assumed that the ACs from all CEs to their corresponding PEs are active and forwarding, i.e. all-active redundancy model. +-----+ +--------------+ | | +-----------+ PE1 | | | +----+ | | | CE1 / +-----+ | | \ | CE2 \ +-----+ | \ +---+ | | +--------+ | MPLS Core | +-----+ PE2 | | / | | +---- CE3 +-----+ \ \ +-----+ +----+ | | PE3 | | | +-----+ Figure 3: VPLS with Flexible Multi-homing Take, for instance, the scenario where CE1 transmits a broadcast frame toward PE1. PE1 will attempt to flood the frame over all its local ACs and to all remote PEs (PE2 and PE3) in the same VPLS instance. The R-VPLS solution ensures that these broadcast frames do Sajassi, et al. [Page 13] draft-sajassi-l2vpn-rvpls-00.txt March 2010 not loop back to CE1 by way of PE2. The solution also ensures that CE2 and CE3 do not receive duplicates of the broadcast, via PE1/PE2 and PE2/PE3, respectively. This is achieved by enforcing the following behavior: 6.4.1. Filtering Based on Multi-homing ID Every R-VPLS PE is configured with a Multi-homing ID on the AC connecting to a multi-homed CE per [VPLS-BGP-DH]. The PE forwarding a multi-destination frame tags the flooded traffic with the multi- homing ID that identifies the originating AC, so that traffic from a multi-homed CE is not re-forwarded back to that CE upon receipt from the MPLS core. This tagging can be achieved by embedding a 'source label' as the end-of-stack label in the MPLS packets. The source label is set to the Multi-homing ID (MH-ID) as defined in [VPLS-BGP- DH]. This source label is matched against the MH-ID of a given AC, for traffic received from the MPLS core. If the source label matches the AC's own MH-ID, then traffic is filtered on that AC. If there's no match, then the traffic is allowed to egress that AC, as long as the Designated Forwarder rule (described below) is honored. 6.4.2. Defining a Designated Forwarder A Designated Forwarder (DF) PE is elected for handling all multi- destination frames received from the MPLS core towards a given multi-homed device. Only the DF PE is allowed to forward traffic received from the MPLS core (over the multipoint LSP or full-mesh of PWs) towards a given MHD. The DF is elected dynamically using the procedures in [VPLS-BGP-DH]. This resolves the issue of duplicate frame delivery. 6.5. LACP State Synchronization To support CE multi-homing with multi-chassis Ethernet bundles, the R-VPLS PEs connected to a given CE should synchronize [802.1AX] LACP state amongst each other. This includes at least the following LACP specific configuration parameters: - System Identifier (MAC Address): uniquely identifies a LACP speaker. - System Priority: determines which LACP speaker's port priorities are used in the Selection logic. - Aggregator Identifier: uniquely identifies a bundle within a LACP speaker. - Aggregator MAC Address: identifies the MAC address of the bundle. - Aggregator Key: used to determine which ports can join an Aggregator. - Port Number: uniquely identifies an interface within a LACP speaker. - Port Key: determines the set of ports that can be bundled. Sajassi, et al. [Page 14] draft-sajassi-l2vpn-rvpls-00.txt March 2010 - Port Priority: determines a port's precedence level to join a bundle in case the number of eligible ports exceeds the maximum number of links allowed in a bundle. The above information must be synchronized between the R-VPLS PEs wishing to form a multi-chassis bundle with a given CE, in order for the former to convey a single LACP peer to that CE. This is required for initial system bring-up and upon any configuration change. Furthermore, the PEs must also synchronize operational (run-time) data, in order for the LACP Selection logic state-machines to execute. This operational data includes the following LACP operational parameters, on a per port basis: - Partner System Identifier: this is the CE System MAC address. - Partner System Priority: the CE LACP System Priority - Partner Port Number: CE's AC port number. - Partner Port Priority: CE's AC Port Priority. - Partner Key: CE's key for this AC. - Partner State: CE's LACP State for the AC. - Actor State: PE's LACP State for the AC. - Port State: PE's AC port status. The above state needs to be communicated between R-VPLS PEs forming a multi-chassis bundle during LACP initial bringup, upon any configuration change and upon the occurrence of a failure. It should be noted that the above configuration and operational state is localized in scope and is only relevant to PEs within a given Redundancy Group, i.e. which connect to the same multi-homed CE over a given Ethernet bundle. Furthermore, the communication of state changes, upon failures, must occur with minimal latency, in order to minimize the switchover time and consequent service disruption. [PWE3-ICCP] defines a mechanism for synchronizing LACP state, using LDP, which can be leveraged for R-VPLS. The use of BGP for synchronization of LACP state is left for further study. 7. Security Considerations There are no additional security aspects beyond those of VPLS/H-VPLS that need to be discussed here. 8. IANA Considerations This document requires IANA to assign a new SAFI value for L2VPN_MAC SAFI. 9. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. Sajassi, et al. [Page 15] draft-sajassi-l2vpn-rvpls-00.txt March 2010 10. 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. [802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Computer Society, November, 2008. 11. 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. [PWE3-FAT-PW] Bryant et al., "Flow Aware Transport of Pseudowires over an MPLS PSN", draft-ietf-pwe3-fat-pw-03.txt, work in progress, January 2010. 12. Authors' Addresses Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Sajassi, et al. [Page 16] draft-sajassi-l2vpn-rvpls-00.txt March 2010 Keyur Patel Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: keyupate@cisco.com Sajassi, et al. [Page 17]