Network Working Group Yuqun Cao Internet Draft Ruijie Networks Intended status: Standard Track April 15, 2011 Expires: October 2011 Extension to BGP-VPLS for E-Tree draft-cao-l2vpn-bgp-vpls-etree-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." Cao Expires October 15, 2011 [Page 1] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 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 October 15, 2011. Copyright 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. Abstract This document proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service using BGP for auto-discovery and signaling [RFC4761]. The proposed solution is characterized by breaking pseudowire between Leafs to fulfill the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility is also considered. Table of Contents 1. Introduction................................................3 2. Conventions used in this document............................4 3. Terminology.................................................4 4. Reference Model.............................................4 5. Extension to VPLS for E-Tree.................................6 5.1. Assumptions............................................6 5.2. AC type................................................7 5.3. PW setup Matrix.........................................7 5.4. VPLS BGP NLRI..........................................8 5.5. PW setup and teardown...................................9 5.5.1. Root endpoint......................................9 5.5.2. Leaf endpoint......................................9 5.6. Signaling PE Capabilities..............................10 5.7. Signaling PE Capabilities..............................10 5.8. Backward Compatibility.................................10 Cao Expires October 15, 2011 [Page 2] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 6. Extension to Data Plane for E-Tree..........................10 7. Compliance with Requirements................................10 8. Security Considerations.....................................11 9. References.................................................11 9.1. Normative References...................................11 9.2. Informative References.................................11 10. Acknowledgments...........................................11 1. Introduction A specific Rooted-multipoint service, Ethernet Tree(E-Tree), has been defined by Metro Ethernet Forum [MEF6.1]. Compared with MEF Ethernet LAN (E-LAN) service where there is no communication restriction between its attachment circuits, each attachment circuit of E-tree is designated as either a Root or a Leaf. A Root-AC can communicate with all other attachment circuit in an E-Tree, however a Leaf-AC can only communicate with Root-ACs but not Leafs. [Draft VPLS ETree Req] provides the functional requirements for MEF E-Tree support in VPLS. This document presents a minimal extension to the current VPLS standard [RFC4761] to break the "communication channel" between Leaf attachment circuits. Figure 1 below describes scenario for Leaf-to-Leaf communication restriction. |<----------E-Tree-------->| | | V V +-------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | | +---+ | +---+ |CE1+----AC1---+-+ | | | | +--+---AC3----+CE3| +---+ (Root AC)| | V | |Ethernet| | V | |(Root AC) +---+ | | S +-+---PW---+--+ S | | +---+ | | I | | | | I | | +---+ |CE2+----AC2---+-+ | | | | +--+---AC4----+CE4| +---+ (Leaf AC)| +---+ | | +---+ | (Leaf AC)+---+ +-------+ +---------+ Figure 1 Scenario for Leaf-to-Leaf Communication Restriction If PE2 receives one frame from PE1 over Ethernet PW, PE2 does NOT know the frame comes from Root AC or from Leaf AC, so it can not decide to forward the frame to AC4 (Leaf AC) or not with the current VPLS standards [RFC4761] [RFC4762]. Cao Expires October 15, 2011 [Page 3] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 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 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Terminology There are two solutions to restrict Leaf-to-Leaf communication, 1. Each frame carries additional information to indicate that it is originated from a Leaf endpoint or Root endpoint on the ingress PE, then egress PE can know forward behavior of the frame, if it comes from Leaf, it will NOT be forwarded to the local Leaf ACs. [Draft Ext VPLS for ETree] proposes this solution. 2. If a frame from local Leaf-AC, one PE in a VPLS will NOT forward it to its other local Leaf-ACs; if there is no PW between local Leaf-ACs and remote Leaf-ACs which are connected to remote PE, a frame from local Leafs also cannot be forwarded to remote Leafs. In this way, we also can restrict the communication between Leafs. The purposed solution in this document prefers to the second and two terms are introduced, o Root-endpoint. One endpoint which connects only Root-ACs, one or more Root-ACs. o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or more Leaf-ACs. There is no endpoint which connects both Root-ACs and Leaf-ACs in the second solution. 4. Reference Model Figure 2 below describes a typical reference model where Root ACs {AC1, AC5, AC6} can communicate with all other Ethernet ACs in the VSI, but Leaf ACs {AC2, AC3, AC4} only can communicate with Root ACs {AC1, AC5, AC6}, and can not communicate with each other. Cao Expires October 15, 2011 [Page 4] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 |<----------E-Tree------------>| | | V V +---------+ +---------+ | PE1 | | PE2 | /Leaf endpoint +---+ | +---+ | | +---+ | /\ +---+ |CE1+-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3| +---+ (Root AC)| | S +--+---PW12---+--+ S | | | |(Leaf AC) +---+ +---+ | | I | | | | I | | | | +---+ |CE2+----AC2----+--+ | | | | +--+-|------AC4----+CE4| +---+ (Leaf AC)| +-+-+ | | +-+-+ | \/ (Leaf AC) +---+ +---+-+---+ +----+----+ ^ | | | | | |PW13-2 |PW23 | | | | PW13-1| | +----+----+ /Root endpoint | | | | +-+-+ | /\ +---+ | | | | | v +--+-|--------AC5-+CE5| | | +--------------+--+ s | | | |(Root AC)+---+ | | | | I | | | | +---+ | +----------------+ | +--+-|------AC6---+CE6| | | +---+ | \/ (Root AC)+---+ | | PE3 | | +---------+ | ^ | <-----------E-Tree---------->| Figure 2 E-Tree typical Reference Model In most use cases, an E-Tree architecture has only a few Root ACs but many Leaf-ACs. On any PE in E-Tree, there are 3 cases, o Root-only ACs. All ACs connected to VSI are Root ACs, say AC5 and AC6 of PE 3 in Figure 2 and at least one VE ID which stands for one Root endpoint is assigned. o Leaf-only ACs. All ACs connected to VSI are Leaf ACs, say AC3 and AC4 of PE 2 in Figure 2 and at least one VE ID which stands for one Leaf endpoint is assigned. o Root-Leaf-Mixed ACs. Some connected to VSI are Root ACs and some are Leaf ACs, say AC1 and AC2 of PE 1 in Figure 2. Here network administrator should at least assign two VE IDs, one is called as Root-endpoint for Root ACs, and one is called as Leaf-endpoint for Leaf ACs. Within an E-Tree, Cao Expires October 15, 2011 [Page 5] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 o All Root-ACs of a Root endpoint can receive frame from and transmit frame to any other endpoints in an E-Tree. o A Root-AC of a Root endpoint can receive frame from and transmit frame to its other Root-ACs; o A Leaf endpoint can receive frame from and transmit frame to any Root endpoints in an E-Tree. o A Leaf endpoint cannot receive frame from and transmit frame to any other Leaf endpoints in the E-Tree. o A Leaf-AC of a Leaf endpoint cannot receive frame from and transmit frame to its other Leaf-ACs; For one VSI, PE 1 has both Root and Leaf ACs, so on PE 1, PE 1 establish one PW (PW12) for AC 1 (Root AC, also belongs to a Root endpoint) with PE 2 where remote ACs are Leaf-only, two PWs with PE 3 where PE 1 receives frames from or transmits frames to remote Root ACs for local Root AC(s) over PW13-1 and receives frames from or transmits frames to remote Root ACs for local Leaf ACs over PW13-2; PE 2 has Leaf-only ACs, so PE 2 establish one PW (PW12) with remote Root ACs on PE 1 and one PW (PW23) with remote Root ACs on PE3; PW3 which has Root-only ACs can establish PW with remote Leaf ACs and Root ACs, so PE 3 establish two PWs with PE 1 and one PW with PE2. However the ACs on PE 2 are Leaf, so any Ethernet frame which is received from AC 3 cannot be transmitted to other local Leaf ACs, say AC4, for example. PE 2 also can not transmit Ethernet frame to remote Leaf ACs since there is no PW for it. This applies to all traffic, including Unicast Known, Unicast Unknown, Broadcast or Multicast. 5. Extension to VPLS for E-Tree 5.1. Assumptions The PEs are assumed to be (logically) fully meshed with tunnels over which packets that belong to a service (such as VPLS or E-Tree) are encapsulated and forwarded. Any E-Tree endpoint comprises only one AC type. If a PE in a VPLS has both Root ACs and Leaf ACs, it SHOULD be configured with at least two endpoints, one is composed of Root ACs, and another is composed of Leaf ACs. It is illegal for any endpoint to have both at same time. Cao Expires October 15, 2011 [Page 6] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 5.2. AC type Each AC connected to an E-Tree on PE MUST have an AC attribute, Root AC or Leaf AC. For backward compatibility, the default AC type MUST be Root for current VPLS standard [RFC4761] [RFC4762]. o Root AC. It can communicate with all ACs in a VPLS or E-Tree and SHOULD belong to a Root endpoint. o Leaf AC. It only can communicate with all Root ACs in a VPLS or E- Tree, and SHOULD belong to a Leaf endpoint. 5.3. PW setup Matrix Just as mentioned in Section 3, there is no PW between Leaf-endpoints and Table 1 describes PW setup matrix, +---------------+-------+------+ | Endpoint type + Root + Leaf + +---------------+-------+------+ | Root + Setup + Setup+ +---------------+-------+------+ | Leaf + Setup + n/a + +---------------+-------+------+ Table 1 PW setup Matrix In the following cases PW may be established, o Local Root-Remote Root o Local Root-Remote Leaf or Local Leaf-Remote Root Foex example, between PE 1 and PE 2 in Figure 1, we have to setup 3 PWs, o PW 1: Communication between Root ACs, i.e., AC 1 and AC 3 in Figure 1. o PW 2: Communication between Root AC and Leaf AC, i.e., AC 1 and AC 4 in Figure 1. o PW 3: Communication between Root AC and Leaf AC, i.e., AC 2 and AC 3 in Figure 1. Cao Expires October 15, 2011 [Page 7] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 5.4. VPLS BGP NLRI Section 3.2.2 in [RFC 4761] defines VPLS BGP NLRI with a new AFI and SAFI to exchange VPLS membership and demultiplexors. +------------------------------------+ | Length (2 octets) | +------------------------------------+ | Route Distinguisher (8 octets) | +------------------------------------+ | VE ID (2 octets) | +------------------------------------+ | VE Block Offset (2 octets) | +------------------------------------+ | VE Block Size (2 octets) | +------------------------------------+ | Label Base (3 octets) | +------------------------------------+ Figure 3 BGP NLRI for VPLS Information A PE participating in a E-Tree must have at least one VE ID, but for a VSI on a PE which has both Root-ACs and Leaf-ACs, it must have at least two VE IDs, one is called as Root endpoint and one is called as Leaf endpoint. Here whole VE ID set is divided into two parts, one is Root VE ID set, and one is Leaf VE id set. L = {VBO, VBO+1, ......, VBO+LVBS-1}, R = { VBO+LVBS, VBO+LVBS +1,......, VBO+VBS-1}, Here VE ID, Leaf VE block Size (LVBS) and VE Block Size (VBO) are typically assigned by the network administrator. All Root VE IDs are in R set, and all Leaf VE IDs are in L set. If there are Root-only ACs on a PE, LVBS SHOULD be set as zero and L is NULL; if there are Leaf-only ACs, LVBS SHOULD be equal to VBS. The endpoint which is identified by VE ID in L set only can establish PW with the endpoint identified by VE ID in R set, but the endpoint identified by the VE ID in R set can establish PW with all VPLS endpoint identified by VE ID in RUL. Cao Expires October 15, 2011 [Page 8] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 5.5. PW setup and teardown Suppose PE-a is part of E-Tree foo and has both Root-ACs and Leaf-ACs. For Leaf ACs, it is assigned with VE ID l which is in Leaf VE ID set, VE block offset VBO+LVBS, VE Block Size LVBS, and label base lLB, For Root ACs, it is assigned with VE ID r which is in Root VE ID set, VE Block Offset VBO, VE Block Size VBS-LVBS, and label base rLB. If PE-b is also part of E-Tree foo with VE ID w (Root or Leaf) and gets NLRI advertisement from PE-a, it will do the following, 5.5.1. Root endpoint 1. Checks if w is part of PE-a's 'remote VE set': if VBO <= w < VBO+ VBS, then w is part of PE-a's remote VE set. If not, PE-b ignores this message, and skips the rest of this procedure. 2. Sets up a PW to PE-a: the demultiplexor label to send traffic from PE-b to PE-a is computed as (rLB + W - VBO). 3. Checks if r is part of any 'remote VE set' that PE-b announced, i.e., PE-b checks if r belongs to some remote VE set that PE-b announced, say with VE Block Offset VBO', VE Block Size VBS', and label base LB'. If not, PE-b MUST make a new announcement as described. 4. Sets up a PW from PE-a: the demultiplexor label over which PE-b should expect traffic from PE-a is computed as: (LB' + r - VBO'). If PE-a withdraws an NLRI for r that PE-b was using, then PE-b MUST tear down its ends of the pseudowire between PE-a and PE-b. 5.5.2. Leaf endpoint 1. Checks if w is part of PE-a's 'remote VE set': if VBO+LVBS <= w < VBO+ VBS, then w is part of PE-a's remote Root VE set. If not, PE-b ignores this message, and skips the rest of this procedure. 2. Sets up a PW to PE-a: the demultiplexor label to send traffic from PE-b to PE-a is computed as (LB + w - VBO). 3. Checks if l is part of any 'remote VE set' that PE-b announced, i.e., PE-b checks if l belongs to some remote VE set that PE-b announced, say with VE Block Offset VBO', VE Block Size VBS', and label base LB'. If not, PE-b MUST make a new announcement as described. Cao Expires October 15, 2011 [Page 9] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 4. Sets up a PW from PE-a: the demultiplexor label over which PE-b should expect traffic from PE-a is computed as: (LB' + l - VBO'). If PE-a withdraws an NLRI for l that PE-b was using, then PE-b MUST tear down its ends of the pseudowire between PE-a and PE-b. 5.6. Signaling PE Capabilities 5.7. Signaling PE Capabilities The extended attribute in Section [RFC4761] 3.2.4, the "Layer2 Info Extended Community", is used to signal control information about the pseudowires to be setup for a VPLS. It also can carry endpoint information. It will be extended in later version. 5.8. Backward Compatibility Root-ACs and Leaf-ACs are used only in cases where PEs support E-Tree and have no impact on VPLS PEs already in operation. In a case where a common VPLS is composed of both PEs supporting the solution and PEs not supporting it, ACs attached to PEs which don't support E-tree are taken as Root-ACs. The Leaf-to-Leaf communication restriction will be implemented within the scope of the compliant PEs. 6. Extension to Data Plane for E-Tree This will be added in later version. 7. Compliance with Requirements The proposed solution in this document meets the requirements mentioned in [Draft VPLS ETree Req] Section 5. The solution prohibits communication between any two Leaf ACs in a VPLS. The solution allows multiple Root ACs in a VPLS instance. The solution allows Root AC and Leaf AC of a VPLS instance co-exist on any PE. The solution is applicable to BGP-VPLS [RFC4761]. The solution is applicable to Case 1: Single technology "VPLS-only". Cao Expires October 15, 2011 [Page 10] Internet-Draft Extension to BGP-VPLS for E-Tree April 2011 8. Security Considerations This will be added in later version. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - Phase 2, April 2008 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, January 2007 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, January 2007 9.2. Informative References [Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree Support in VPLS, draft-key-l2vpn-vpls-etree-reqt- 02.txt,October 2010 [Draft Ext VPLS for ETree] Key, et al., Extension to VPLS for E-Tree, draft-key-l2vpn-vpls-etree-04.txt,October 2010 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yuqun Cao Ruijie Networks 618 Jinshan Road, Fuzhou 350002, China Email: yuqun.cao@gmail.com Cao Expires October 15, 2011 [Page 11]