idnits 2.17.1 draft-cai-l2vpn-evpn-vlan-aware-bundling-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 4 IANA Considerations' ) ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([EVPN-REQ]), 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 (June 28, 2012) is 4292 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'E-VPN' is mentioned on line 126, but not defined == Missing Reference: 'RFC2119' is mentioned on line 111, but not defined == Missing Reference: 'RFC4447' is mentioned on line 322, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC5036' is mentioned on line 308, but not defined == Missing Reference: 'RFC4448' is mentioned on line 282, but not defined == Missing Reference: 'NumberOfValues' is mentioned on line 299, but not defined == Missing Reference: 'RFC4762' is mentioned on line 324, but not defined == Missing Reference: 'RFC5561' is mentioned on line 340, but not defined == Unused Reference: 'KEYWORDS' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'EVPN' is defined on line 249, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-evpn-req-00 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-00 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Dennis Cai 3 Intended Status: Informational Track Sami Boutros 4 Samer Salam 5 Reshad Rahman 6 Expires: December 30, 2012 June 28, 2012 8 VLAN Aware EVPN services 9 draft-cai-l2vpn-evpn-vlan-aware-bundling-00.txt 11 Abstract 13 This document specifies E-VPN extensions to support the new VLAN 14 aware bundling service interface type defined in [EVPN-REQ]. The new 15 service interface type provides advantages in reducing provisioning 16 overhead as well as E-VPN instances scale in environments where a 17 large number of VLANs need to be extended over an MPLS/IP network, 18 while maintaining traffic segregation among those VLANs. The VLAN 19 aware bundling service interface can handle the high scale 20 requirements of today's Data Centers by bundling different VLANs over 21 a single WAN E-VPN instance used to interconnect those Data Center 22 sites. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2012 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 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. VLAN-aware-bundling E-VPN . . . . . . . . . . . . . . . . . . 3 64 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1 Packet forwarding, MAC learning, aging and flushing . . . . 5 66 3.2 Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 5 67 3.3 OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.4 VLAN translation . . . . . . . . . . . . . . . . . . . . . . 5 69 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 72 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 73 6 Appendix Vlan Aware VPLS . . . . . . . . . . . . . . . . . . . . 6 74 6.1 VLAN-aware-bundling PW . . . . . . . . . . . . . . . . . . . 7 75 6.2 PW VLAN Vector TLV . . . . . . . . . . . . . . . . . . . . . 7 76 6.3 LDP Capability Negotiation . . . . . . . . . . . . . . . . . 8 77 6.4 Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1 Introduction 82 The high scale requirements of Layer 2 data center interconnect 83 services mandate the signaling of a large number of WAN E-VPN 84 instances. As such, network operators are looking for solutions 85 whereby they can extend multiple Ethernet VLANs over a WAN using a 86 single E-VPN instance, while maintaining traffic segregation among 87 these VLANs in the data-plane. This gives rise to a requirement for a 88 new service interface types: the VLAN aware bundling service 89 interfaces. 91 These new VLAN aware bundling service interfaces MUST: - Provide the 92 ability to bundle multiple customer VLANs - Guarantee customer VLAN 93 transparency end-to-end.- Maintain data-plane separation between the 94 customer VLANs by creating a dedicated bridge-domain per VLAN.- 95 Support customer VLAN translation to handle the scenario where 96 different VLAN Identifiers (VIDs) are used on different sites to 97 designate the same customer VLAN. 99 As discussed in [EVPN-REQ], two new service interface types are 100 defined for VLAN aware bundling: with and without translation. The 101 new service interfaces maintain data-plane separation, per VLAN, 102 while sharing one L2VPN E-VPN instance. This document describes the 103 use of different E-VPN routes as defined in [E-VPN] for implementing 104 the VLAN-aware bundling service. 106 1.1 Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 MAC: Media Access Control 114 MPLS: Multi Protocol Label Switching. 116 OAM: Operations, Administration and Maintenance. 118 PE: Provide Edge Node. 120 CE: Customer Edge device e.g., host or router or switch. 122 EVI: E-VPN Instance. 124 2. VLAN-aware-bundling E-VPN 126 [E-VPN] uses a new BGP NLRI for advertising different route types for 127 E-VPN operation. 129 This document discusses how the Ethernet Tag field in the Ethernet 130 Auto-Discovery Route, Mac Advertisement route, and inclusive 131 multicast Ethernet tag route can be used to multiplex several VLANs 132 over the same EVI. 134 3. Operation 136 The following figure shows an example of how a VLAN aware Bundling 137 service type over E-VPN could be deployed. 139 +---------------------------------+ 140 | VLAN aware E-VPN PE1 | 141 | +---------------+ | 142 | | | | 143 | +------+ | | | 144 +--+ | | | | | | 145 |CE|-|---| BD ==== | | +------+ 146 +--+ | | | 1 | | | | | | 147 | | +------+ | VLAN aware | | | PE2 | +----+ 148 | | |E-VPN Instance ============| |---| CE | 149 | | | | | | | +----+ 150 | | +------+ | | | +------+ 151 +--+ | --| BD | | | | 152 |CE|-|---| 2 ==== | | 153 +--+ | | | | | | 154 | +------+ | | | 155 | +---------------+ | 156 | | 157 +---------------------------------+ 159 One E-VPN instance has been set up between two sites to extend 160 multiple customer VLANs. On each site, multiple CE devices could be 161 connected to the PE. The link between the CE and the PE could be C- 162 tag or S-tag interface per [802.1Q], carrying several VLANs.Only a 163 single E-VPN instance has been set up to carry customer VLANs between 164 the two sites. The use of two sites in the above figure is for 165 illustration; however, this could be extended to many sites. In order 166 to quantify the benefit of the approach, let's assume N data center 167 sites, with M customer VLANs. With the new VLAN aware service 168 interface type, the solution would require one E-VPN instance, 169 instead of M E-VPN instances. To maintain data-plane separation among 170 the customer VLANs, each PE will create a bridge-domain per customer 171 VLAN. As well, a customer VLAN on each CE port will represent a 172 unique bridge port in the customer bridge-domain. Only one E-VPN 173 instance would be signaled in the core and will be used to carry 174 multiple customer bridge-domains (or customer VLANs) as long as those 175 customer VLANs need to be extended to the same set of sites. On the 176 egress PE, the E-VPN label + the VLAN-tag would identify the 177 customer-bridge domain. 179 3.1 Packet forwarding, MAC learning, aging and flushing 181 Given the data-plane separation, packet forwarding in the scope of 182 one bridge-domain will remain unchanged. When sending traffic over 183 the E-VPN instance, a qualifying VLAN tag MUST be present on the 184 packet. This VLAN tag has global significance across all sites 185 connected to the E-VPN instance and is used to identify the customer 186 bridge domain in all sites. MAC learning, aging and flushing per 187 bridge-domain will remain un-changed. A mass withdraw for MAC routes 188 learned over the EVPN instance can be done by withdrawing the 189 Ethernet AD route with the tag ID corresponding to the bridge domain. 191 3.2 Multicast Pruning 193 Efficient multicast replication in the core can be achieved via the 194 use of the Inclusive Multicast Ethernet Tag Route, to prune the 195 flooding on a per VLAN basis. It is possible to only replicate 196 traffic to PEs that have advertised the Inclusive Multicast Ethernet 197 Tag Route with the Tag value set to the VLAN value. If VLAN value is 198 set to zero, then a single multicast LSM is setup to be used for all 199 VLAN traffic for that E-VPN instance. Multicast snooping protocols 200 such as IGMP and PIM MAY be used to further prune the replication 201 scope for a given multicast group in one customer bridge-domain. 203 3.3 OAM 205 Customer Ethernet OAM frames (e.g. CFM [802.1ag]) will be carried 206 transparently over the shared E-VPN instance by the customer's 207 bridge-domains. Current MPLS OAM mechanisms need to be extended to 208 verify connectivity in the E-VPN instance shared by the customer 209 bridge-domains, service level OAM monitoring should be performed 210 according to [RFC-6136], MPLS OAM extensions is out of scope of the 211 document. 213 3.4 VLAN translation 215 As mentioned above, the VLAN tag carried across the E-VPN instance 216 for the new VLAN aware bundling E-VPN instance MUST have network wide 217 significance within the scope of the E-VPN instance. As such, VLAN 218 translation may be performed at each PE attached to the E-VPN 219 instance to translate between the global VLAN tag identifying the 220 customer bridge-domain and the local VLAN tag used by the customer 221 bridge-domain on this PE. 223 4 Security Considerations 225 This document does not introduce any additional security constraints. 227 4 IANA Considerations 229 TBD 231 5 References 233 5.1 Normative References 235 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 239 1 1995. 241 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 242 April 1 1996. 244 5.2 Informative References 246 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 247 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 249 [EVPN] A. Sajassi, R. Aggarwal et. al., "BGP MPLS Based Ethernet 250 VPN", draft-ietf-l2vpn-evpn-00.txt. 252 [RFC-6136] Layer 2 Virtual Private Network (L2VPN) Operations, 253 Administration, and Maintenance (OAM) Requirements and 254 Framework. 256 6 Appendix Vlan Aware VPLS 258 It is possible to extend VPLS to support VLAN aware bundling type 259 service, a new PW VLAN Vector TLV to be included the LDP PW FEC label 260 mapping messages for the VPLS service, using the mechanisms specified 261 in RFC 4762, as well as a new LDP capability by which a PE can 262 specify its ability to support this new VLAN aware bundling service 263 interface type. The new PW VLAN Vector TLV would allow multiple VLANs 264 to share a single VPLS instance, while maintaining data plane 265 segregation among these VLANs. This document defines extension to the 266 PWE3 control protocol [RFC4447] to set up the new VLAN aware bundling 267 type service in MPLS networks. An extension to the MAC Withdrawal 268 mechanisms would allow per VLAN service MAC flushing for this new 269 VLAN aware bundling service. 271 6.1 VLAN-aware-bundling PW 273 [RFC4447] uses LDP Label Mapping message [RFC5036] for advertising 274 the FEC-to-PW Label binding. Two types of PW FEC, FEC-128 and FEC- 275 129, can be used for this purpose. Both types of PW FEC contain a PW 276 type Field. 278 PW type port or raw mode will be used for the VLAN aware bundling 279 interface type service. 281 Use of control word is optional and frame encapsulation follows the 282 same rules as in [RFC4448]. 284 A new PW VLAN vector TLV is defined, the new PW VLAN Vector TLV will 285 be included in LDP PW label mapping messages, as well it can be 286 included in the MAC flush message. 288 6.2 PW VLAN Vector TLV 290 The PW VLAN Vector TLV is described as below: 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |1|1| VLAN Vector(TBD)| Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |first VLAN Value |NumberOfValues | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 299 | VLANFlushBits[NumberOfValues] | 300 | " | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 The U and F bits are set to forward if unknown so that potential 304 intermediate VPLS PEs unaware of the new TLV can just propagate it 305 transparently. 307 The MAC Flush VLAN Vector TLV type is to be assigned by IANA from 308 the LDP standard [RFC5036] "TLV type name space", as described in 309 section 7. 311 The TLV value field is of variable length. The first 12 bits encode 312 the starting VLAN value. The second 12 bits contain the number of 313 values. The VLANFlushBits is an array of bits of length = 314 NumberOfValues, each bit in the array represents a VLAN flush state 315 starting from the 1st VLAN value. A bit value of 1 means flush and a 316 bit value of 0 means don't flush 318 A Starting VLAN value of 0, SHOULD mean include all VLANs, in this 319 case the NumberOfValues SHOULD be 0. 321 The PW VLAN Vector TLV SHOULD be placed after the PW FEC TLV in the 322 label mapping message as specified in [RFC4447], and SHOULD be placed 323 after the existing TLVs in MAC Flush message as specified in 324 [RFC4762]. 326 6.3 LDP Capability Negotiation 328 The capability of supporting VLAN Aware Bundling interface type 329 Service MUST be advertised to all LDP peers. This is achieved by 330 using the methods in [RFC5561] and advertising the LDP "VLAN aware 331 Bundling Capability" TLV. If an LDP peer supports the dynamic 332 capability advertisement, it can send a new Capability message with 333 the S bit set for the VLAN Aware Bundling capability TLV. If the peer 334 does not supports dynamic capability advertisement, then the VLAN 335 aware Bundling Capability TLV MUST be included in the LDP 336 Initialization message during the session establishment. An LSR 337 having VLAN Aware Bundling capability MUST recognize the new PW VLAN 338 Vector TLV in LDP label messages. 340 In line with requirements listed in [RFC5561], the following TLV is 341 defined to indicate the VLAN Aware Bundling capability: 342 0 1 2 3 343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |U|F| VLAN Aware Capability TBD | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |S| Reserved | Reserved | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Note: TLV number pending IANA allocation. 351 * U-bit: SHOULD be 1 (ignore if not understood). 353 * F-bit: SHOULD be 0 (don't forward if not understood). 355 * VLAN Aware Bundling Capability TLV Code Point: 357 The TLV type, which identifies a specific capability. The VLAN 358 Aware capability code point is requested in the IANA 359 allocation section below. 361 * S-bit: 363 The State Bit indicates whether the sender is advertising or 364 withdrawing the VLAN Aware capability. The State bit is used 365 as follows: 367 1 - The TLV is advertising the capability specified by the 368 TLV Code Point. 370 0 - The TLV is withdrawing the capability specified by the 371 TLV Code Point. 373 * Length: MUST be set to 2 (octet). 375 6.4 Multicast Pruning 377 Efficient multicast replication in the core can be achieved via the 378 use of the new VLAN vector TLV, to prune the flooding on a per VLAN 379 basis. It is possible to only replicate traffic to PEs that have 380 advertised a given VLAN in their Vector TLV. Multicast snooping 381 protocols such as IGMP and PIM MAY be used to further prune the 382 replication scope for a given multicast group in one customer bridge- 383 domain. 385 Authors' Addresses 387 Dennis Cai 388 Cisco Systems 390 EMail: dcai@cisco.com 392 Sami Boutros 393 Cisco Systems 395 EMail: sboutros@cisco.com 397 Samer Salam 398 Cisco Systems 400 EMail: ssalam@cisco.com 402 Reshad Rahman 403 Cisco Systems 405 EMail: rrahman@cisco.com