Internet Working Group Y. Jiang L. Yong Internet Draft Huawei Intended status: Standards Track M. Paul Deutsche Telekom F. Jounay Orange CH F. Balus W. Henderickx Alcatel-Lucent A. Sajassi Cisco Expires: August 2012 February 29, 2012 E-Tree Support in VPLS with BGP Signaling draft-jiang-l2vpn-etree-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 August 29, 2012. Jiang, et al Expires August 29, 2012 [Page 1] Internet-Draft E-Tree in BGP February 2012 Copyright Notice Copyright (c) 2012 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 describes the extension to BGP signaling for the E-Tree support in BGP VPLS when the dual-VLAN model is used as in [Vpls- etree]. The BGP VPLS messages and their procedures remain almost the same as in [RFC4761], only a new extended community for E-Tree is proposed. Table of Contents 1. Introduction .............................................. 2 2. Conventions used in this document ......................... 3 3. Terminology ............................................... 3 4. BGP Extensions for E-Tree Support ......................... 3 5. Security Considerations ................................... 5 6. IANA Considerations ....................................... 5 7. References ................................................ 5 7.1. Normative References ................................... 5 8. Acknowledgments ........................................... 6 Authors' Addresses ............................................. 7 1. Introduction Dual-VLAN can be used to support generic E-Tree services both in the Ethernet and in the VPLS. The solution proposed in [Vpls-etree] is fully compatible with the IEEE bridge architecture and the IETF PWE3 technology, and VPLS scalability and simplicity is also well kept. With this mechanism, it is also convenient to deploy a converged E- Tree service across both Ethernet and MPLS networks. LDP signaling of E-Tree support in a PW is specified in Section 6 of [Vpls-etree], it can also be used together with BGP auto-discovery [RFC6074]. Jiang, et al Expires August 29, 2012 [Page 2] Internet-Draft E-Tree in BGP February 2012 This document further describes the BGP signaling extension to BGP VPLS for the E-Tree support and its processing procedures. 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 [RFC2119]. 3. Terminology E-Tree: a Rooted-Multipoint EVC service according to the definition in MEF Root VLAN, a VLAN ID used to indicate all the frames that are originated at a root AC Leaf VLAN, a VLAN ID used to indicate all the frames that are originated at a leaf AC 4. BGP Extensions for E-Tree Support In the dual-VLAN VPLS PE model per [Vpls-etree], the PEs need to exchange their local VLANs when PW is set up by automatic signaling. A new E-Tree extended community is proposed for E-Tree signaling in BGP VPLS: +------------------------------------+ | Extended community type (2 octets) | +------------------------------------+ | Root VLAN (2 octets) | +------------------------------------+ | Leaf VLAN (2 octets) | +------------------------------------+ | Reserved |P| +------------------------------------+ Figure 1 E-Tree Extended Community Jiang, et al Expires August 29, 2012 [Page 3] Internet-Draft E-Tree in BGP February 2012 Where: o Root VLAN ID is the value of the local root VLAN. o Leaf VLAN ID is the value of the local leaf VLAN. o Reserved, 15 bits MUST be set to zero on transmit and be ignored on receive. o P is a Leaf-only bit, it is set to 1 to indicate that the PE is attached with only leaves, and set to 0 otherwise. The PEs attached with both leaves and roots must support BGP E-Tree signaling as described in this document, and must support VLAN mapping in their data planes. The traditional PE attached with only roots may also participate in an E-Tree. In BGP VPLS signaling, besides attaching a Layer2 Info Extended Community as detailed in [RFC4761], an E-Tree Extended Community MUST be further attached if a PE wishes to set up an E-Tree service. The PE MUST include its local root VLAN ID and leaf VLAN ID in the E-Tree Extended Community. A PE attached with only leaves of an E-Tree SHOULD set the P bit in the E-Tree Extended Community to 1. A PE that receives a BGP UPDATE message with an E-Tree Extended Community from its peer PE must process it as follows (a PE which does not recognize this attribute will silently ignore it): 1) if the root and leaf VLAN ID in the E-Tree Extended Community match the local root and leaf VLAN ID, then continue to 3); 2) else { if the bit V is cleared, then it MUST set VLAN-Mapping-Mode to TRUE; else the PE with the minimum IP address MUST set VLAN-Mapping- Mode to TRUE; } 3) If the P bit is set, then the PE SHOULD set the Optimized-Mode to TRUE. Jiang, et al Expires August 29, 2012 [Page 4] Internet-Draft E-Tree in BGP February 2012 If a PE has sent an E-Tree Extended Community but does not receive any E-Tree Extended Community from its peer, then set the Compatible- Mode to TRUE for the corresponding PW to the peer. Data plane in the VPLS is the same as described in Section 4.2 of [RFC4761], and data plane processing for a PW is the same as described in the end of Section 6 of [Vpls-etree]. 5. Security Considerations Besides security considerations as described in [RFC4448] and [RFC4761], this solution prevents leaf to leaf communication in the data plane of VPLS when its PEs are interconnected with PWs. In this regard, security can be enhanced for customers with this solution. 6. IANA Considerations IANA is requested to allocate a value for E-Tree in the registry of BGP Extended Community. Parameter ID Length Description ======================================= TBD 16 E-Tree 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC4448] Martini, L., and et al, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007 [RFC6074] Rosen, E., et al, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011 [Vpls-etree] Jiang, et al., "VPLS PE Model for E-Tree Support", draft-jiang-l2vpn-vpls-pe-etree-05 (work in progress), October 2011 Jiang, et al Expires August 29, 2012 [Page 5] Internet-Draft E-Tree in BGP February 2012 8. Acknowledgments TBD. Jiang, et al Expires August 29, 2012 [Page 6] Internet-Draft E-Tree in BGP February 2012 Authors' Addresses Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: jiangyuanlong@huawei.com Lucy Yong Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075, USA Email: lucyyong@huawei.com Manuel Paul Deutsche Telekom Goslarer Ufer 35 10589 Berlin, Germany Email: manuel.paul@telekom.de Frederic Jounay Orange CH 4 rue caudray 1020 Renens, SwitzerlandEmail: frederic.jounay@orange.ch Florin Balus Alcatel-Lucent 701 E. Middlefield Road Mountain View, CA, USA 94043 Email: florin.balus@alcatel-lucent.com Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium Email: wim.henderickx@alcatel-lucent.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, USA Email: sajassi@cisco.com Jiang, et al Expires August 29, 2012 [Page 7]