idnits 2.17.1 draft-jiang-l2vpn-etree-bgp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4761], [Vpls-etree]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 29, 2012) is 4439 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-jiang-l2vpn-vpls-pe-etree-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 L. Yong 3 Internet Draft Huawei 5 Intended status: Standards Track M. Paul 6 Deutsche Telekom 8 F. Jounay 9 Orange CH 11 F. Balus 12 W. Henderickx 13 Alcatel-Lucent 15 A. Sajassi 16 Cisco 18 Expires: August 2012 February 29, 2012 20 E-Tree Support in VPLS with BGP Signaling 21 draft-jiang-l2vpn-etree-bgp-00.txt 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on August 29, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Abstract 59 This document describes the extension to BGP signaling for the E-Tree 60 support in BGP VPLS when the dual-VLAN model is used as in [Vpls- 61 etree]. The BGP VPLS messages and their procedures remain almost the 62 same as in [RFC4761], only a new extended community for E-Tree is 63 proposed. 65 Table of Contents 67 1. Introduction .............................................. 2 68 2. Conventions used in this document ......................... 3 69 3. Terminology ............................................... 3 70 4. BGP Extensions for E-Tree Support ......................... 3 71 5. Security Considerations ................................... 5 72 6. IANA Considerations ....................................... 5 73 7. References ................................................ 5 74 7.1. Normative References ................................... 5 75 8. Acknowledgments ........................................... 6 76 Authors' Addresses ............................................. 7 78 1. Introduction 80 Dual-VLAN can be used to support generic E-Tree services both in the 81 Ethernet and in the VPLS. The solution proposed in [Vpls-etree] is 82 fully compatible with the IEEE bridge architecture and the IETF PWE3 83 technology, and VPLS scalability and simplicity is also well kept. 84 With this mechanism, it is also convenient to deploy a converged E- 85 Tree service across both Ethernet and MPLS networks. 87 LDP signaling of E-Tree support in a PW is specified in Section 6 of 88 [Vpls-etree], it can also be used together with BGP auto-discovery 89 [RFC6074]. 91 This document further describes the BGP signaling extension to BGP 92 VPLS for the E-Tree support and its processing procedures. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Terminology 102 E-Tree: a Rooted-Multipoint EVC service according to the definition 103 in MEF 105 Root VLAN, a VLAN ID used to indicate all the frames that are 106 originated at a root AC 108 Leaf VLAN, a VLAN ID used to indicate all the frames that are 109 originated at a leaf AC 111 4. BGP Extensions for E-Tree Support 113 In the dual-VLAN VPLS PE model per [Vpls-etree], the PEs need to 114 exchange their local VLANs when PW is set up by automatic signaling. 115 A new E-Tree extended community is proposed for E-Tree signaling in 116 BGP VPLS: 118 +------------------------------------+ 119 | Extended community type (2 octets) | 120 +------------------------------------+ 121 | Root VLAN (2 octets) | 122 +------------------------------------+ 123 | Leaf VLAN (2 octets) | 124 +------------------------------------+ 125 | Reserved |P| 126 +------------------------------------+ 128 Figure 1 E-Tree Extended Community 130 Where: 132 o Root VLAN ID is the value of the local root VLAN. 134 o Leaf VLAN ID is the value of the local leaf VLAN. 136 o Reserved, 15 bits MUST be set to zero on transmit and be ignored 137 on receive. 139 o P is a Leaf-only bit, it is set to 1 to indicate that the PE is 140 attached with only leaves, and set to 0 otherwise. 142 The PEs attached with both leaves and roots must support BGP E-Tree 143 signaling as described in this document, and must support VLAN 144 mapping in their data planes. The traditional PE attached with only 145 roots may also participate in an E-Tree. 147 In BGP VPLS signaling, besides attaching a Layer2 Info Extended 148 Community as detailed in [RFC4761], an E-Tree Extended Community MUST 149 be further attached if a PE wishes to set up an E-Tree service. The 150 PE MUST include its local root VLAN ID and leaf VLAN ID in the E-Tree 151 Extended Community. A PE attached with only leaves of an E-Tree 152 SHOULD set the P bit in the E-Tree Extended Community to 1. 154 A PE that receives a BGP UPDATE message with an E-Tree Extended 155 Community from its peer PE must process it as follows (a PE which 156 does not recognize this attribute will silently ignore it): 158 1) if the root and leaf VLAN ID in the E-Tree Extended Community 159 match the local root and leaf VLAN ID, then continue to 3); 161 2) else { 163 if the bit V is cleared, then it MUST set VLAN-Mapping-Mode to 164 TRUE; 166 else the PE with the minimum IP address MUST set VLAN-Mapping- 167 Mode to TRUE; 169 } 171 3) If the P bit is set, then the PE SHOULD set the Optimized-Mode to 172 TRUE. 174 If a PE has sent an E-Tree Extended Community but does not receive 175 any E-Tree Extended Community from its peer, then set the Compatible- 176 Mode to TRUE for the corresponding PW to the peer. 178 Data plane in the VPLS is the same as described in Section 4.2 of 179 [RFC4761], and data plane processing for a PW is the same as 180 described in the end of Section 6 of [Vpls-etree]. 182 5. Security Considerations 184 Besides security considerations as described in [RFC4448] and 185 [RFC4761], this solution prevents leaf to leaf communication in the 186 data plane of VPLS when its PEs are interconnected with PWs. In this 187 regard, security can be enhanced for customers with this solution. 189 6. IANA Considerations 191 IANA is requested to allocate a value for E-Tree in the registry of 192 BGP Extended Community. 194 Parameter ID Length Description 195 ======================================= 196 TBD 16 E-Tree 198 7. References 200 7.1. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997 205 [RFC4448] Martini, L., and et al, "Encapsulation Methods for 206 Transport of Ethernet over MPLS Networks", RFC 4448, April 207 2006 209 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 210 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 211 4761, January 2007 213 [RFC6074] Rosen, E., et al, "Provisioning, Auto-Discovery, and 214 Signaling in Layer 2 Virtual Private Networks (L2VPNs)", 215 RFC 6074, January 2011 217 [Vpls-etree] Jiang, et al., "VPLS PE Model for E-Tree Support", 218 draft-jiang-l2vpn-vpls-pe-etree-05 (work in progress), 219 October 2011 221 8. Acknowledgments 223 TBD. 225 Authors' Addresses 227 Yuanlong Jiang 228 Huawei Technologies Co., Ltd. 229 Bantian, Longgang district 230 Shenzhen 518129, China 231 Email: jiangyuanlong@huawei.com 233 Lucy Yong 234 Huawei USA 235 1700 Alma Dr. Suite 500 236 Plano, TX 75075, USA 237 Email: lucyyong@huawei.com 239 Manuel Paul 240 Deutsche Telekom 241 Goslarer Ufer 35 242 10589 Berlin, Germany 243 Email: manuel.paul@telekom.de 245 Frederic Jounay 246 Orange CH 247 4 rue caudray 1020 Renens, SwitzerlandEmail: 248 frederic.jounay@orange.ch 250 Florin Balus 251 Alcatel-Lucent 252 701 E. Middlefield Road 253 Mountain View, CA, USA 94043 254 Email: florin.balus@alcatel-lucent.com 256 Wim Henderickx 257 Alcatel-Lucent 258 Copernicuslaan 50 259 2018 Antwerp, Belgium 260 Email: wim.henderickx@alcatel-lucent.com 262 Ali Sajassi 263 Cisco 264 170 West Tasman Drive 265 San Jose, CA 95134, USA 266 Email: sajassi@cisco.com