idnits 2.17.00 (12 Aug 2021) /tmp/idnits43080/draft-cai-l2vpn-vpls-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 219 has weird spacing: '...used as follo...' -- The document date (October 13, 2012) is 3500 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) == Missing Reference: 'RFC4447' is mentioned on line 177, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Missing Reference: 'RFC5036' is mentioned on line 325, but not defined == Missing Reference: 'RFC4448' is mentioned on line 139, but not defined == Missing Reference: 'NumberOfValues' is mentioned on line 155, but not defined == Missing Reference: 'RFC4762' is mentioned on line 179, but not defined == Missing Reference: 'RFC6136' is mentioned on line 305, but not defined == Unused Reference: 'KEYWORDS' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC 4762' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC 5036' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC 4447' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC 4448' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC-6136' is defined on line 363, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1776 ** Downref: Normative reference to an Informational RFC: RFC 1925 (ref. 'TRUTHS') -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-l2vpn-evpn-req has been published as RFC 7209 Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Dennis Cai 3 Intended Status: Standard Track Sami Boutros 4 Samer Salam 5 Reshad Rahman 6 Expires: April 16, 2013 October 13, 2012 8 VLAN Aware VPLS services 9 draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt 11 Abstract 13 This document specifies VPLS extensions to support the new VLAN aware 14 bundling service interface type. The new service interface type 15 provides advantages in reducing the provisioning overhead, as well as 16 pseudowire scalability in environments where a large number of VLANs 17 need to be extended over an MPLS/IP network while maintaining traffic 18 segregation among those VLANs. 20 The VLAN aware bundling service interface can handle the high scale 21 requirements of today's Data Centers by bundling different VLANs over 22 a single WAN VPLS instance used to interconnect sites. Furthermore, 23 this document specifies an extension to the LDP MAC Withdrawal 24 mechanisms to allow per-VLAN MAC flushing for the new service 25 interface type. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. VLAN-aware-bundling PW . . . . . . . . . . . . . . . . . . . . 4 68 3. PW VLAN Vector TLV . . . . . . . . . . . . . . . . . . . . . . 4 69 4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 5 70 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Packet forwarding, MAC learning, aging and flushing . . . . 7 72 5.2. Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.4. VLAN translation . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 77 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 79 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1 Introduction 84 The high scale requirements of Layer 2 data center interconnect 85 services mandate the signaling of a large number of WAN VPLS 86 instances. As such, network operators are looking for solutions 87 whereby they can extend multiple Ethernet VLANs over a WAN using a 88 single VPLS instance, while maintaining traffic segregation among 89 these VLANs in the data-plane. This gives rise to a requirement for 90 new service interface types: the VLAN aware bundling service 91 interfaces. 93 These new VLAN aware bundling service interfaces MUST: 94 - Provide the ability to bundle multiple customer VLANs 95 - Guarantee customer VLAN transparency end-to-end. 96 - Maintain data-plane separation between the customer VLANs by 97 creating a dedicated bridge-domain per VLAN. 98 - Support customer VLAN translation to handle the scenario where 99 different VLAN Identifiers (VIDs) are used on different sites to 100 designate the same customer VLAN. 102 As discussed in [EVPN-REQ], two new service interface types are 103 defined for VLAN aware bundling: with and without translation. The 104 new service interfaces maintain data-plane separation, per VLAN, 105 while sharing one L2VPN VPN instance. In this document, we focus on 106 the scenario where VPLS is the L2VPN technology. This document 107 defines a new PW VLAN Vector TLV to be included in the LDP PW FEC 108 label mapping messages for the VPLS service, using the mechanisms 109 specified in RFC 4762, as well as a new LDP capability by which a PE 110 can specify its ability to support this new VLAN aware bundling 111 service interface type. Furthermore, This document defines extension 112 to the PWE3 control protocol [RFC4447] to set up the new VLAN aware 113 bundling type service in MPLS networks. The document specifies as 114 well an extension to the MAC Withdrawal mechanisms to allow per VLAN 115 service MAC flushing for this new VLAN aware bundling service. 117 1.1 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 LDP: Label Distribution Protocol. MAC: Media Access Control MPLS: 124 Multi Protocol Label Switching. OAM: Operations, Administration and 125 Maintenance. PE: Provide Edge Node. PW: PseudoWire. TLV: Type, 126 Length, and Value. VPLS: Virtual Private LAN Services. 128 2. VLAN-aware-bundling PW 130 [RFC4447] uses LDP Label Mapping message [RFC5036] for advertising 131 the FEC-to-PW Label binding. Two types of PW FEC, FEC-128 and FEC- 132 129, can be used for this purpose. Both types of PW FEC contain a PW 133 type Field. 135 PW type port or raw mode will be used for the VLAN aware bundling 136 interface type service. 138 Use of control word is optional and frame encapsulation follows the 139 same rules as in [RFC4448]. 141 A new PW VLAN vector TLV is defined, the new PW VLAN Vector TLV will 142 be included in LDP PW label mapping messages, as well it MAY be 143 included in the MAC flush message. 145 3. PW VLAN Vector TLV 147 The PW VLAN Vector TLV is described as below: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |1|1| VLAN Vector(TBD)| Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |first VLAN Value |NumberOfValues | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 155 | VLANFlushBits[NumberOfValues] | 156 | " | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The U and F bits are set to forward if unknown so that potential 159 intermediate VPLS PEs unaware of the new TLV can just propagate it 160 transparently. 162 The MAC Flush VLAN Vector TLV type is to be assigned by IANA from 163 the LDP standard [RFC5036] "TLV type name space", as described in 164 section 7. 166 The TLV value field is of variable length. The first 12 bits encode 167 the starting VLAN value. The second 12 bits contain the number of 168 values. The VLANFlushBits is an array of bits of length = 169 NumberOfValues, each bit in the array represents a VLAN flush state 170 starting from the 1st VLAN value. A bit value of 1 means flush and a 171 bit value of 0 means don't flush 173 A Starting VLAN value of 0, SHOULD mean include all VLANs, in this 174 case the NumberOfValues SHOULD be 0. 176 The PW VLAN Vector TLV SHOULD be placed after the PW FEC TLV in the 177 label mapping message as specified in [RFC4447], and SHOULD be placed 178 after the existing TLVs in MAC Flush message as specified in 179 [RFC4762]. 181 4. LDP Capability Negotiation 183 The capability of supporting VLAN Aware Bundling interface type 184 Service MUST be advertised to all LDP peers. This is achieved by 185 using the methods in [RFC5561] and advertising the LDP "VLAN aware 186 Bundling Capability" TLV. If an LDP peer supports the dynamic 187 capability advertisement, it can send a new Capability message with 188 the S bit set for the VLAN Aware Bundling capability TLV. If the peer 189 does not support dynamic capability advertisement, then the VLAN 190 aware Bundling Capability TLV MUST be included in the LDP 191 Initialization message during the session establishment. An LSR 192 having VLAN Aware Bundling capability MUST recognize the new PW VLAN 193 Vector TLV in LDP label messages. 195 In line with the requirements listed in [RFC5561], the following TLV 196 is defined to indicate the VLAN Aware Bundling capability: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |U|F| VLAN Aware Capability TBD | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |S| Reserved | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Note: TLV number pending IANA allocation. 208 * U-bit: SHOULD be 1 (ignore if not understood). 210 * F-bit: SHOULD be 0 (don't forward if not understood). 212 * VLAN Aware Bundling Capability TLV Code Point: The TLV type, 213 which identifies a specific capability. The VLAN Aware 214 capability code point is requested in the IANA allocation 215 section below. 217 * S-bit: The State Bit indicates whether the sender is 218 advertising or withdrawing the VLAN Aware capability. The State 219 bit is used as follows: 221 1 - The TLV is advertising the capability specified by the TLV 222 Code Point. 224 0 - The TLV is withdrawing the capability specified by the TLV 225 Code Point. 227 * Length: MUST be set to 2 (octet). 229 5. Operation 231 The following figure shows the VPLS PE model for supporting the VLAN 232 aware service interface. 234 +---------------------------------+ 235 | VLAN aware VPLS PE1 | 236 | +---------------+ | 237 | | | | 238 | +------+ | | | 239 +--+ | | | | | | 240 |CE|-|---| BD ==== | | +------+ 241 +--+ | | | 1 | | | | | | 242 | | +------+ | VLAN aware | | | PE2 | +----+ 243 | | | PW Fwdr ===== PW ===| |---| CE | 244 | | | | | | | +----+ 245 | | +------+ | | | +------+ 246 +--+ | --| BD | | | | 247 |CE|-|---| 2 ==== | | 248 +--+ | | | | | | 249 | +------+ | | | 250 | +---------------+ | 251 | | 252 +---------------------------------+ 253 One VPLS instance has been set up between two sites to extend 254 multiple customer VLANs. On each site, multiple CE devices could be 255 connected to the PE. The link between the CE and the PE could be 256 802.1q or 802.1ad, setup with multiple VLANs. Unlike a classic VPLS 257 solution that requires a dedicated VPLS instance for each customer 258 VLAN, only a single VPLS instance has been set up to carry customer 259 VLANs between the two sites. The use of two sites in the above figure 260 is for illustration; however, this could be extended to many sites. 261 In order to quantify the benefit of the approach, let's assume N data 262 center sites, with M customer VLANs. Classic VPLS full mesh solution 263 would require M VPLS instances and M*(N-1) PWs on each PE. While with 264 the new VLAN aware interface service type, the solution would require 265 one VPLS instance and will only require (N-1) PWs on each PE. To 266 maintain data-plane separation per customer VLAN, with the new VLAN 267 aware interface service, each PE will create a bridge-domain per 268 customer VLAN. As well, a customer VLAN on each CE port will 269 represent a unique bridge port in the customer bridge-domain. Only 270 one VPLS instance would be signaled in the core and will be used to 271 carry multiple customer bridge-domains (or customer VLANs) as long as 272 those customer VLANs need to be extended to the same set of sites. 273 Unlike classic VPLS, where the VPLS PW is presented as a bridge port, 274 the VFI and the customer VLAN would map to the customer bridge- 275 domain. 277 5.1. Packet forwarding, MAC learning, aging and flushing 279 Given the data-plane separation, packet forwarding in the scope of 280 one bridge-domain will remain unchanged. When sending traffic over 281 the PW, a qualifying VLAN tag MUST be present on the packet. This 282 VLAN tag has global significance across all sites connected to the 283 VPLS instance and is used to identify the customer bridge domain in 284 all sites. MAC learning, aging and flushing per bridge-domain will 285 remain un-changed. Extensions to MAC withdrawal mechanisms, as 286 described in section 4, would allow the MAC flushing to occur on a 287 subset of the customer bridge-domains. 289 5.2. Multicast Pruning 291 Efficient multicast replication in the core can be achieved via the 292 use of the new VLAN vector TLV, to prune the flooding on a per VLAN 293 basis. It is possible to only replicate traffic to PEs that have 294 advertised a given VLAN in their Vector TLV. Multicast snooping 295 protocols such as IGMP and PIM MAY be used to further prune the 296 replication scope for a given multicast group in one customer bridge- 297 domain. 299 5.3. OAM 301 Customer Ethernet OAM frames (e.g. CFM [802.1ag]) will be carried 302 transparently over the shared VPLS instance by the customers bridge- 303 domains. Current VCCV mechanisms can be used to verify PWs 304 connectivity in the VPLS instance shared by the customer bridge- 305 domains. VPLS OAM framework as defined in [RFC6136] applies to this 306 new service with no changes. 308 5.4. VLAN translation 310 As mentioned above, the VLAN tag carried across the PWs for the new 311 VLAN aware bundling VPLS instance MUST have network global 312 significance within the scope of the VPLS instance. As such, VLAN 313 translation can happen at each PE attached to the VPLS instance to 314 translate between the global VLAN tag identifying the customer 315 bridge-domain and the local VLAN tag used by the customer bridge- 316 domain on this PE. 318 6. Security Considerations 319 This document does not introduce any additional security constraints. 321 7. IANA Considerations 323 Two new types field for the VLAN Vector TLV type and VLAN aware 324 Bundling Capability TLV type are to be assigned by IANA from the LDP 325 standard [RFC5036] "TLV type name space". 327 8 References 329 8.1 Normative References 331 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 335 1 1995. 337 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 338 April 1 1996. 340 8.2 Informative References 342 [RFC 4762] Mark Lassere, et. al, "Virtual Private LAN Service (LAN) 343 Using Label Distribution Protocol (LDP) Signaling", 344 RFC4762, January 2007. 346 [RFC 5036] Andersson, L., et al. "LDP Specification", RFC5036, 347 October 2007. 349 [RFC 4447] Martini. and et al., "Pseudowire Setup and Maintenance 350 Using Label Distribution Protocol (LDP)", RFC 4447, April 351 2006. 353 [RFC 4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 354 "Encapsulation Methods for Transport of Ethernet over MPLS 355 Networks", RFC 4448, April 2006. 357 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 358 Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt. 360 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP 361 Capabilities", RFC 5561, July 2009. 363 [RFC-6136] Layer 2 Virtual Private Network (L2VPN) Operations, 364 Administration, and Maintenance (OAM) Requirements and 365 Framework. 367 Authors' Addresses 369 Dennis Cai 370 Cisco Systems 372 EMail: dcai@cisco.com 374 Sami Boutros 375 Cisco Systems 377 EMail: sboutros@cisco.com 379 Samer Salam 380 Cisco Systems 382 EMail: ssalam@cisco.com 384 Reshad Rahman 385 Cisco Systems 387 EMail: rrahman@cisco.com