idnits 2.17.1 draft-zhang-l2vpn-vpls-bd-tagging-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2014) is 3538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Informational Bin Wang 4 Liang Xia 5 Huawei 6 Jie Hu 7 China Telecom 8 Expires: February 13, 2015 August 12, 2014 10 Tagging Customer Bridge Domains in VPLS 11 draft-zhang-l2vpn-vpls-bd-tagging-02.txt 13 Abstract 15 This document proposes to use Customer VLAN ID as an identifier for 16 traffic isolation in Virtual Private LAN Service (VPLS). In this way, 17 multiple bridge domains of customers can share a single VPLS instance 18 while their traffic are separated. With this proposal, Service 19 Providers can be relieved from the heavy provisioning overhead of 20 large number of pseudowires in the environment where a mass of bridge 21 domains need be connected. 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 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 63 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. PE Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Use Cases of U-tag Awareness in VPLS . . . . . . . . . . . . . 4 67 4.1. No Duplicated MAC Address . . . . . . . . . . . . . . . . . 4 68 4.2. Scalable Interconnection of L2 Sites . . . . . . . . . . . 5 69 4.3. BUM Traffic Scoped per BD . . . . . . . . . . . . . . . . . 5 70 4.3.1. Advertising Interested VLANs in LDP . . . . . . . . . . 5 71 4.3.2. Dynamic VLAN Registration with MVRP . . . . . . . . . . 5 72 4.4. Per C-VLAN MAC Withdraw . . . . . . . . . . . . . . . . . . 6 73 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 74 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 80 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 VPLS has been widely used to connect customers' bridge domains. 85 Traffic segregation for customers is performed on a per VPLS instance 86 basis. In the environment (e.g., Data Center Network) where a mass of 87 customers multiplied with a plenty of bridge domains are to be 88 connected, a large number of PWs need be maintained. Service 89 Providers are therefore suffering from scalability issue. 91 This proposal suggests the Customer VLAN ID (U-tag) is used as an 92 additional de-multiplexor for traffic segregation in VPLS. By doing 93 this, multiple BDs can share the same VPLS instance while their 94 traffic are isolated. This method can greatly reduce the number of 95 PWs therefore reduce the provisioning overhead for operators. Use 96 cases of this method are given in the document. 98 Two options arising from the industry are covered in the discussion. 99 The first one is proposed in [V-aware]. It extends the LDP control 100 plane for PEs to advertise supported VLANs. The second option makes 101 use of VLAN registration protocol, such as [MVRP], to exchange 102 supported C-VLANs between PEs. 104 2. Acronyms and Terminology 106 2.1. Acronyms 108 MVRP: Multiple VLAN Registration Protocol 109 BD: Bridge Domain/Broadcast Domain 110 PW: Pseudowire 111 VSI: Virtual Switch Instance 112 U-tag: Customer VLAN ID 113 C-VLAN: Customer VLAN 114 BUM: Broadcast, Unknown unicast and Multicast 115 VLL: Virtual Leased Line 117 2.2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. PE Model 124 ........................ 125 . +--------+ . 126 L2 +--------| BD1 +------------------ PW 127 L2 +--------| | . 128 L2 +---+ . +--------+ VSI. 129 | ........................ 130 | 131 | ........................ 132 | . +---+---+ . 133 | . +--------+ |100|PKT| . 134 +----| BD11 | +---+---+ . 135 L2 +--------|Utag=100+--------------+ 136 . +--------+ . | 137 . +---+---+ . | 138 . +--------+ |200|PKT| . | 139 L2 +--------| BD11 | +---+---+ . | 140 . |Utag=200+--------------+--- tagged PW 141 . +--------+ . | 142 . +---+---+ . | 143 . +--------+ |300|PKT| . | 144 L2 +--------| BD11 | +---+---+ . | 145 L2 +--------|Utag=300+--------------+ 146 . +--------+ . 147 . VSI. 148 ........................ 150 L2 +-----------VLL---------------------- PW 152 Figure 3.1: U-tag is used as the service de-multiplexor in tagged PW 154 In Figure 3.1, an example is used to shown that the Customer VLAN ID 155 (U-tag) is used as an finer grained de-multiplexor for traffic 156 segregation. Therefore, multiple customer BDs can be integrated into 157 one VSI while their traffic is isolated. 159 4. Use Cases of U-tag Awareness in VPLS 161 4.1. No Duplicated MAC Address 163 One MAC address might be used by multiple hosts in different customer 164 VLANs (C-VLAN). This is illegal but it is the headache reality for 165 providers. In the virtualization environment, Virtual Machines (VM) 166 are more likely to have duplicated MAC addresses. When these 167 hosts/VMs join in the same VSI of a PE, the PE will see MAC address 168 duplication. In order to overcome this issue, the PE has to adopt 169 qualified learning [RFC4762], i.e., the PE has to set up one VSI per 170 C-VLAN. This brings the scalability issue as discussed in Section 171 4.2. 173 If the PE uses U-tag as the de-multiplexor to isolate traffic of 174 customers' BDs, above MAC address duplication issue can be avoided. 176 4.2. Scalable Interconnection of L2 Sites 178 For the qualified learning, providers need set up one PW per C-VLAN. 179 When there is a large number of customers multiplied by C-VLANs 180 interconnected using VPLS, a mass of PWs need be maintained. It 181 brings heavy operating overhead to providers. 183 In this document, U-tag is used to distinguish BDs in VPLS. In this 184 way, traffic from multiple C-VLANs can be handled by a single VPLS. 185 As shown in Figure 3.1, one PW is set up for each VSI and this VSI 186 may be an integration of multiple BDs. Operating overhead of 187 operators can be greatly reduced. 189 4.3. BUM Traffic Scoped per BD 191 Traditional VPLS limits a broadcast domain scope per PW. Suppose a 192 customer has four sites in New York, Chicago, Atlanta and Dallas. BD1 193 = {New York, Chicago and Atlanta} while BD2 = {New York, Chicago and 194 Dallas}. If one VSI per PE is set up to interconnect these four 195 sites. BUM traffic of Atlanta site will be poured to Dallas site, and 196 vice versa. 198 When PEs are aware of the U-tag, the BUM traffic can be confined per 199 BD with multicast pruning. For above example, the operator need use 200 two U-tags to distinguish the two BDs. In this way, BUM traffic of 201 Atlanta site will be confined in BD1 and BUM traffic for Dallas site 202 will be confined in BD2. This increases the efficiency of the 203 bandwidth utilization of BUM traffic. 205 Two C-VLAN based multicast pruning techniques are listed below. (One 206 is give in [V-aware] the other has been implemented by vendors.) 208 4.3.1. Advertising Interested VLANs in LDP 210 With the PW VLAN Vector TLV defined in [V-aware], PEs can advertise 211 in LDP the interested C-VLANs for its interfaces. In this way, PEs 212 can prune the flooding on a per C-VLAN basis. 214 4.3.2. Dynamic VLAN Registration with MVRP 216 It requires Multiple VLAN Registration Protocol (MVRP) to be 217 supported by PEs for U-tag registration on the interfaces providing 218 VPLS. With the help of MVRP, operators need not manually configure C- 219 VLANs on PEs. 221 Only when a C-VLAN is registered in both directions of a PW, this PW 222 will not be eliminated for this C-VLAN. Otherwise, this PW will be 223 pruned for this C-VLAN. Multicast frames for a C-VLAN SHOULD only be 224 forwarded on PWs that are not pruned for this C-VLAN. 226 4.4. Per C-VLAN MAC Withdraw 228 With the awareness of U-tag, PEs can achieve a finer gained C-VLAN 229 scoped MAC withdraw. For example, with the VLAN Vector TLV defined in 230 [V-aware], a PE can specify VLANs that it wants their MAC address to 231 be flushed. 233 5. Backward Compatibility 235 Two PEs need negotiate their capability on supporting the awareness 236 of U-tag. Unless both PEs are aware of U-tag, the tagged PW cannot be 237 established. When a PE realizes the peering PE's interface is unaware 238 of U-tag, it MUST fall back to establish a raw PW with this 239 interface. 241 There are two ways to achieve the capability negotiation. 243 a) As defined in Section 4 of [V-aware], PEs can negotiate this 244 capability through LDP using the VLAN Aware Capability TLV. 246 b) A tagged PW is established between two interfaces if they both 247 enable MVRP. 249 For the tagged PW, PEs can achieve customer VLAN scoped MAC address 250 flushing [V-aware]. However, PEs may as well send out the old type 251 MAC withdraw message per Section 6.2 of [RFC4762]. The receiver PE 252 parses this kind of message as that the peering PE is flushing MAC 253 addresses across all customer VLANs supported by this PW. 255 6. Contributors 257 Xingjian He, Huawei 259 7. Security Considerations 261 This document raises no new security issues. For general security 262 considerations, refer to [RFC4761] and [RFC4762]. 264 8. IANA Considerations 266 This document requires no IANA actions. RFC Editor: please remove 267 this section before publication. 269 9. References 271 9.1. Normative References 273 [V-aware] D. Cai, S. Boutros, and et al, "VLAN Aware VPLS services", 274 draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt, working in 275 progress. 277 [MVRP] IEEE P802.1ak/D8.0, "IEEE Standard for Local and 278 Metropolitan Area Networks: Virtual Bridged Local Area 279 Networks -- Amendment 07: Multiple Registration Protocol", 280 November 29, 2006. 282 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 283 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 284 Signaling", RFC 4762, January 2007. 286 9.2. Informative References 288 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 289 LAN Service (VPLS) Using BGP for Auto-Discovery and 290 Signaling", RFC 4761, January 2007. 292 Author's Addresses 294 Mingui Zhang 295 Huawei Technologies 296 No. 156 Beiqing Rd. Haidian District, 297 Beijing 100095 298 P.R. China 300 EMail: zhangmingui@huawei.com 302 Bin Wang 303 Huawei Technologies 304 No. 156 Beiqing Rd. Haidian District, 305 Beijing 100095 306 P.R. China 308 EMail: zhangmingui@huawei.com 310 Liang Xia 311 Huawei Technologies 313 Email: frank.xialiang@huawei.com 315 Jie Hu 316 China Telecom 318 Email: hujie@ctbri.com.cn