idnits 2.17.1 draft-ietf-l2vpn-vpls-bridge-interop-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 17) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC-4664], [RFC-2119]), 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2010) is 4925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-ipls-09 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-oam-req-frmk-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group Ali Sajassi, Ed. 3 Internet Draft Frank Brockners 4 Category: Informational Cisco Systems 6 Dinesh Mohan, Ed. 8 Yetik Serbest 10 Expires: April 24, 2010 October 24, 2010 12 VPLS Interoperability with CE Bridges 13 draft-ietf-l2vpn-vpls-bridge-interop-06.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright and License Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Abstract 65 One of the main motivations behind VPLS is its ability to provide 66 connectivity not only among customer routers and servers/hosts but 67 also among customer IEEE bridges. VPLS is expected to deliver the 68 same level of service that current enterprise users are accustomed 69 to from their own enterprise bridged networks or their Ethernet 70 Service Providers. 72 When CE devices are IEEE bridges, then there are certain issues and 73 challenges that need to be accounted for in a VPLS network. The 74 majority of these issues have been addressed in the IEEE 802.1ad 75 standard for provider bridges and they can be leveraged for VPLS 76 networks. This draft extends the PE model described in [RFC-4664] 77 based on IEEE 802.1ad bridge module, and illustrates a clear 78 demarcation between the IEEE bridge module and IETF LAN emulation 79 module. By doing so, it shows that the majority of interoperability 80 issues with CE bridges can be delegated to the 802.1ad bridge 81 module, thus removing the burden on the IETF LAN emulation module 82 within a VPLS PE. 84 Conventions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC-2119]. 90 Table of Contents 92 1. Introduction.................................................... 3 93 2. Ethernet Service Instance....................................... 4 94 3. VPLS-Capable PE Model with Bridge Module........................ 5 95 4. Mandatory Issues................................................ 7 96 4.1. Service Mapping............................................... 7 97 4.2. CE Bridge Protocol Handling................................... 9 98 4.3. Partial-mesh of Pseudowires.................................. 10 99 4.4. Multicast Traffic............................................ 11 100 5. Optional Issues................................................ 12 101 5.1. Customer Network Topology Changes............................ 13 102 5.2. Redundancy................................................... 14 103 5.3. MAC Address Learning......................................... 16 104 6. Interoperability with 802.1ad Networks......................... 17 105 7. Acknowledgments................................................ 17 106 8. IANA Considerations............................................ 17 107 9. Security Considerations........................................ 17 108 10. Normative References.......................................... 18 109 11. Informative References........................................ 18 110 Authors' Addresses................................................ 19 112 1. 113 Introduction 115 Virtual Private LAN Service (VPLS) is a LAN emulation service 116 intended for providing connectivity between geographically dispersed 117 customer sites across MAN/WAN (over MPLS/IP) network(s), as if they 118 were connected using a LAN. One of the main motivations behind VPLS 119 is its ability to provide connectivity not only among customer 120 routers and servers/hosts but also among IEEE customer bridges. If 121 only connectivity among customer IP routers/hosts was desired, then 122 an IPLS solution [IPLS] could have been used. The strength of the 123 VPLS solution is that it can provide connectivity to both bridge and 124 non-bridge types of CE devices. VPLS is expected to deliver the same 125 level of service that current enterprise users are accustomed to 126 from their own enterprise bridged networks [802.1D/802.1Q] today or 127 the same level of service that they receive from their Ethernet 128 Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or 129 its predecessor, QinQ-based network). 131 When CE devices are IEEE bridges, then there are certain issues and 132 challenges that need to be accounted for in a VPLS network. The 133 majority of these issues have been addressed in the IEEE 802.1ad 134 standard for provider bridges and they can be leveraged for VPLS 135 networks. This draft extends the PE model described in [RFC-4664] 136 based on IEEE 802.1ad bridge module and illustrates a clear 137 demarcation between IEEE bridge module and IETF LAN emulation 138 module. By doing so, it describes that the majority of 139 interoperability issues with CE bridges can be delegated to 802.1ad 140 bridge module, thus removing the burden on IETF LAN emulation module 141 within a VPLS PE. This document discusses these issues and wherever 142 possible suggests areas to be explored in rectifying these issues. 143 The detailed solution specification for these issues is outside of 144 the scope of this document. 146 It also discusses interoperability issues between VPLS and IEEE 147 802.1ad networks when the end-to-end service spans across both types 148 of networks, as outlined in [RFC-4762]. 150 This draft categorizes the CE-bridge issues into two groups: 1) 151 Mandatory and 2) Optional. The issues in group (1) need to be 152 addressed in order to ensure the proper operation of CE bridges. The 153 issues in group (2) would provide additional operational improvement 154 and efficiency and may not be required for interoperability with CE 155 bridges. Sections five and six discuss the mandatory and optional 156 issues respectively. 158 2. 159 Ethernet Service Instance 161 Before starting the discussion of bridging issues, it is important 162 to clarify the Ethernet Service definition. The term VPLS has 163 different meanings in different contexts. In general, VPLS is used 164 in the following contexts [Eth-OAM]: a) as an end-to-end bridged-LAN 165 service over one or more network (one of which being MPLS/IP 166 network), b) as an MPLS/IP network supporting these bridged LAN 167 services, and c) as (V)LAN emulation. For better clarity, we 168 differentiate between its usage as network versus service by using 169 the terms VPLS network and VPLS instance respectively. Furthermore, 170 we confine VPLS (both network and service) to only the portion of 171 the end-to-end network that spans across an MPLS/IP network. For an 172 end-to-end service (among different sites of a given customer), we 173 use the term "Ethernet Service Instance" or ESI. 175 [MFA-Ether] defines the Ethernet Service Instance (ESI) as an 176 association of two or more Attachment Circuits (ACs) over which an 177 Ethernet service is offered to a given customer. An AC can be either 178 a UNI or a NNI; furthermore, it can be an Ethernet interface or a 179 VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface. 180 If an ESI is associated with more than two ACs, then it is a 181 multipoint ESI. In this document, where ever the keyword ESI is 182 used, it means multipoint ESI, unless it is stated otherwise. 184 An ESI can correspond to a VPLS instance if its associated ACs are 185 only connected to a VPLS network or an ESI can correspond to a 186 Service VLAN if its associated ACs are only connected to a Provider- 187 Bridged network [P802.1ad]. Furthermore, an ESI can be associated 188 with both a VPLS instance and a Service VLAN when considering an 189 end-to-end service that spans across both VPLS and Provider-Bridged 190 networks. An ESI can span across different networks (e.g., IEEE 191 802.1ad and VPLS) belonging to the same or different administrative 192 domains. 194 An ESI most often represents a customer or a specific service 195 requested by a customer. Since traffic isolation among different 196 customers (or their associated services) is of paramount importance 197 in service provider networks, its realization shall be done such 198 that it provides a separate MAC address domain and broadcast domain 199 per ESI. A separate MAC address domain is provided by using a 200 separate MAC forwarding table (e.g., FIB - also known as filtering 201 database [IEEE 802.1D]) per ESI (for both VPLS and IEEE 802.1ad 202 networks) and separate broadcast domain is provided by using a full- 203 mesh of pseudowires per ESI over the IP/MPLS core in a VPLS network 204 and/or a dedicated Service VLAN per ESI in an IEEE 802.1ad network. 206 3. 207 VPLS-Capable PE Model with Bridge Module 209 [RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based 210 on the bridging functionality that needs to be supported by the PE. 211 If the CE devices can be routers/hosts or IEEE bridges, the second 212 model from [RFC-4664] is the most suitable, and it is both adequate 213 to provide the VPLS level of service and consistent with the IEEE 214 standards for Provider Bridges [P802.1ad]. We briefly describe the 215 second model and then expand upon this model to show its sub- 216 components based on [P802.1ad] Provider Bridge model. 218 As described in [RFC-4664], the second model for VPLS-PE contains a 219 single bridge module supporting all the VPLS instances on that PE 220 where each VPLS instance is represented by a unique VLAN inside that 221 bridge module (also known as Service VLAN or S-VLAN). The bridge 222 module has a single "Emulated LAN" interface over which it 223 communicates with all VPLS forwarders and each VPLS instance is 224 represented by a unique S-VLAN tag. Each VPLS instance can consist 225 of a set of pseudowires and its associated forwarder corresponding 226 to a single Virtual LAN (VLAN) as depicted in Figure 1 below. Thus, 227 sometimes it is referred to as VLAN emulation. 229 +----------------------------------------+ 230 | VPLS-capable PE model | 231 | +---------------+ +------+ | 232 | | | |VPLS-1|------------ 233 | | |=======+ |Fwdr |------------ PWs 234 | | Bridge --------|--- |------------ 235 | | | SVID-1| +------+ | 236 | | Module | | o | 237 | | | | o | 238 | | (802.1ad | | o | 239 | | bridge) | | o | 240 | | | | o | 241 | | | SVID-n| +------+ | 242 | | --------|---VPLS-n|------------- 243 | | |=======+ | Fwdr |------------- PWs 244 | | | ^ | |------------- 245 | +---------------+ | +------+ | 246 | | | 247 +-----------------------|----------------+ 248 | 249 LAN emulation (multi-access) Interface 251 Figure 1. VPLS-capable PE Model 253 Customer frames associated with a given ESI, carry the S-VLAN ID for 254 that ESI over the LAN emulation interface. The S-VLAN ID is stripped 255 before transmitting the frames over the set of pseudowires 256 associated with that VPLS instance (assuming raw mode PWs are used 257 as specified in [RFC-4448]). 259 The bridge module can itself consist of one or two sub-components 260 depending on the functionality that it needs to perform. The 261 following Figure 2 depicts the model for the bridge module based on 262 [P802.1ad]. 264 +-------------------------------+ 265 | 802.1ad Bridge Module Model | 266 | | 267 +---+ AC | +------+ +-----------+ | 268 |CE |---------|C-VLAN|------| | | 269 +---+ | |bridge|------| | | 270 | +------+ | | | 271 | o | S-VLAN | | 272 | o | | | ---> to VPLS Fwdr 273 | o | Bridge | | 274 +---+ AC | +------+ | | | 275 |CE |---------|C-VLAN|------| | | 276 +---+ | |bridge|------| | | 277 | +------+ | | | 278 +---+ AC | | | | 279 |CE |-----------------------| | | 280 +---+ | +-----------+ | 281 +-------------------------------+ 283 Figure 2. The Model of 802.1ad Bridge Module 285 The S-VLAN bridge component is always required and it is responsible 286 for tagging customer frames with S-VLAN tags in the ingress 287 direction (from customer UNIs) and removing S-VLAN tags in the 288 egress direction (toward customer UNIs). It is also responsible for 289 running the provider's bridge protocol such as RSTP, MSTP, GVRP, 290 GMRP, etc. among provider bridges within a single administrative 291 domain. 293 The C-VLAN bridge component is required when the customer Attachment 294 Circuits are VLANs (aka C-VLANs). In such cases, the VPLS-capable PE 295 needs to participate in some of the customer's bridging protocol 296 such as RSTP and MSTP. The reason that such participation is 297 required is because a customer VLAN (C-VLAN) at one site can be 298 mapped into a different C-VLAN at a different site or in case of 299 asymmetric mapping, a customer Ethernet port at one site can be 300 mapped into a customer VLAN (or group of C-VLANs) at a different 301 site. 303 The C-VLAN bridge component does service selection and 304 identification based on C-VLAN tags. Each frame from the customer 305 device is assigned to a C-VLAN and presented at one or more internal 306 port-based interfaces, each supporting a single service instance 307 that the customer desires to carry that C-VLAN. Similarly frames 308 from the provider network are assigned to an internal interface or 309 'LAN' (e.g, between C-VLAN and S-VLAN components) on the basis of 310 the S-VLAN tag. Since each internal interface supports a single 311 service instance, the S-VLAN tag can be, and is, removed at this 312 interface by the S-VLAN bridge component. If multiple C-VLANs are 313 supported by this service instance (e.g., VLAN bundling or port- 314 based), then the frames will have already been tagged with C-VLAN 315 tags. If a single C-VLAN is supported by this service instance 316 (e.g., VLAN-based), then the frames will not have been tagged with a 317 C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one to 318 one mapping). The C-VLAN aware bridge component applies a port VLAN 319 ID (PVID) to untagged frames received on each internal 'LAN', 320 allowing full control over the delivery of frames for each C-VLAN 321 through the Customer UNI Port. 323 4. 324 Mandatory Issues 326 4.1. 327 Service Mapping 329 Different Ethernet AC types can be associated with a single Ethernet 330 Service Instance (ESI). For example, an ESI can be associated with 331 only physical Ethernet ports, VLANs, or a combination of the two 332 (e.g., one end of the service could be associated with physical 333 Ethernet ports and the other end could be associated with VLANs). In 334 [RFC-4762], unqualified and qualified learning are used to refer to 335 port-based and VLAN-based operation respectively and [RFC-4762] does 336 not describe the possible mappings between different types of 337 Ethernet ACs (e.g., 802.1D, 802.1Q or 802.1ad frames). In general, 338 the mapping of a customer port or VLAN to a given service instance 339 is a local function performed by the local PE and the service 340 provisioning shall accommodate it. In other words, there is no 341 reason to restrict and limit an ESI to have only port-based ACs or 342 to have only VLAN-based ACs. [P802.1ad] allows for each customer AC 343 (either a physical port, or a VLAN, or a group of VLANs) to be 344 mapped independently to an ESI which provides better service 345 offering to Enterprise customers. For better and more flexible 346 service offerings and for interoperability purposes between VPLS and 347 802.1ad networks, it is imperative that both networks offer the same 348 capabilities in terms of customer ACs mapping to the customer 349 service instance. 351 The following table lists possible mappings that can exist between 352 customer ACs and its associated ESI - this table is extracted from 353 [MFA-Ether]. As it can be seen, there are several possible ways to 354 perform such mapping. In the first scenario, it is assumed that an 355 Ethernet physical port only carries untagged traffic and all the 356 traffic is mapped to the corresponding service instance or ESI. This 357 is referred to as "port-based with untagged traffic". In the second 358 scenario, it is assumed that an Ethernet physical port carries both 359 tagged and untagged traffic and all that traffic is mapped to the 360 corresponding service instance or ESI. This is referred to as "port- 361 based with tagged and untagged traffic". In the third scenario, it 362 is assumed that only a single VLAN is mapped to the corresponding 363 service instance or ESI (referred to as VLAN-based). Finally, in the 364 fourth scenario, it is assumed that a group of VLANs from the 365 Ethernet physical interface is mapped to the corresponding service 366 instance or ESI. 368 =================================================================== 369 Ethernet I/F & Associated Service Instance(s) 370 ------------------------------------------------------------------- 371 Port-based Port-based VLAN-based VLAN 372 untagged tagged & bundling 373 untagged 374 ------------------------------------------------------------------- 375 Port-based Y N Y(Note-1) N 376 untagged 378 Port-based N Y Y(Note-2) Y 379 tagged & 380 untagged 382 VLAN-based Y(Note-1) Y(Note-2) Y Y(Note-3) 384 VLAN N Y Y(Note-3) Y 385 Bundling 386 =================================================================== 388 Note-1: In this asymmetric mapping scenario, it is assumed that the 389 CE device with "VLAN-based" AC is a device capable of supporting 390 [802.1Q] frame format. 392 Note-2: In this asymmetric mapping scenario, it is assumed that the 393 CE device with "VLAN-based" AC is a device that can support 395 [P802.1ad] frame format because it will receive Ethernet frames with 396 two tags; where the outer tag is S-VLAN and the inner tag is C-VLAN 397 received from "port-based" AC. One application example for such CE 398 device is in a BRAS for DSL aggregation over Metro Ethernet network. 400 Note-3: In this asymmetric mapping scenario, it is assumed that the 401 CE device with "VLAN-based" AC can support the [P802.1ad] frame 402 format because it will receive Ethernet frames with two tags; where 403 the outer tag is S-VLAN and the inner tag is C-VLAN received from 404 "VLAN bundling" AC. 406 If a PE uses an S-VLAN tag for a given ESI (either by adding an S- 407 VLAN tag to customer traffic or by replacing a C-VLAN tag with a S- 408 VLAN tag), then the frame format and EtherType for S-VLAN SHALL 409 adhere to [P802.1ad]. 411 As mentioned before, the mapping function between the customer AC 412 and its associated ESI is a local function and thus when the AC is a 413 single customer VLAN, it is possible to map different customer VLANs 414 at different sites to a single ESI without coordination among those 415 sites. 417 When a port-based mapping or a VLAN-bundling mapping is used, then 418 the PE may use an additional S-VLAN tag to mark the customer traffic 419 received over that AC as belonging to a given ESI. If the PE uses 420 the additional S-VLAN tag, then in the opposite direction the PE 421 SHALL strip the S-VLAN tag before sending the customer frames over 422 the same AC. However, when VLAN-mapping mode is used at an AC and if 423 the PE uses S-VLAN tag locally, then if the Ethernet interface is a 424 UNI, the tagged frames over this interface SHALL have a frame format 425 based on [802.1Q] and the PE SHALL translate the customer tag (C- 426 VLAN) into the provider tag (S-VLAN) upon receiving a frame from the 427 customer and in the opposite direction, the PE shall translate from 428 provider frame format (802.1ad) back to customer frame format 429 (802.1Q). 431 All the above asymmetric services can be supported via the PE model 432 with the bridge module depicted in Figure 2 (based on [802.1ad]). 434 4.2. 435 CE Bridge Protocol Handling 437 When a VPLS-capable PE is connected to a CE bridge, then depending 438 on the type of Attachment Circuit, different protocol handling may 439 be required by the bridge module of the PE. [P802.1ad] states that 440 when a PE is connected to a CE bridge, then the service offered by 441 the PE may appear to specific customer protocols running on the CE 442 in one of the four ways: 444 a) Transparent to the operation of the protocol among CEs of 445 different sites using the service provided, appearing as an 446 individual LAN without bridges; or, 447 b) Discarding frames, acting as a non-participating barrier to the 448 operation of the protocol; or, 449 c) Peering, with a local protocol entity at the point of provider 450 ingress and egress, participating in and terminating the 451 operation of the protocol; or, 452 d) Participation in individual instances of customer protocols. 454 All the above CE bridge protocol handling can be supported via the 455 PE model with the bridge module depicted in figure-2 (based on 456 [802.1ad]). For example, when an Attachment Circuit is port-based, 457 then the bridge module of the PE can operate transparently with 458 respect to the CE's RSTP/MSTP protocols (and thus no C-VLAN 459 component is required for that customer UNI). However, when an 460 Attachment Circuit is VLAN-based (either VLAN-based or VLAN 461 bundling), then the bridge module of the PE needs to peer with the 462 RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge 463 component is required). In other words, when the AC is VLAN-based, 464 then protocol peering between CE and PE devices may be needed. There 465 are also protocols that require peering but are independent from the 466 type of Attachment Circuit. An example of such protocol is the link 467 aggregation protocol [802.3ad]; however, this is a media-dependent 468 protocol as its name implies. 470 [P802.1ad] reserves a block of 16 MAC addresses for the operation of 471 C-VLAN and S-VLAN bridge components and it shows which of these 472 reserved MAC addresses are only for C-VLAN bridge component and 473 which ones are only for S-VLAN bridge component and which ones apply 474 to both C-VLAN and S-VLAN components. 476 4.3. 477 Partial-mesh of Pseudowires 479 A VPLS service depends on a full mesh of pseudowires, so a 480 pseudowire failure reduces the underlying connectivity to a partial 481 mesh and this can have adverse effects on the VPLS service. If the 482 CE devices belonging to an ESI are routers running link state 483 routing protocols that use LAN procedures over that ESI, then a 484 partial-mesh of PWs can result in "black holing" traffic among the 485 selected set of routers. And if the CE devices belonging to an ESI 486 are IEEE bridges, then a partial-mesh of PWs can cause broadcast 487 storms in the customer and provider networks. Furthermore, it can 488 cause multiple copies of a single frame to be received by the CE 489 and/or PE devices. Therefore, it is of paramount importance to be 490 able to detect PW failure and to take corrective action to prevent 491 creation of partial-mesh of PWs. 493 When the PE model depicted in Figure 2 is used, then [P802.1ag] 494 procedures could be used for detection of partial-mesh of PWs. 495 [p802.1ag] defines a set of procedures for fault detection, 496 verification, isolation, and notification per ESI. 498 The fault detection mechanism of [p8021.ag] can be used to perform 499 connectivity check among PEs belonging to a given VPLS instance. It 500 checks the integrity of a service instance end-to-end within an 501 administrative domain - e.g., from one AC at one end of the network 502 to another AC at the other end of the network. Therefore, its path 503 coverage includes bridge module within a PE and it is not limited to 504 just PWs. Furthermore, [P802.1ag] operates transparently over the 505 full-mesh of PWs for a given service instance since it operates at 506 the Ethernet level (and not at PW level). It should be noted that 507 since a PW consists of two uni-directional LSPs, then one direction 508 can fail independently of the other. Even in this case, the 509 procedures of [p802.1ag] can provide a consistent view of the full- 510 mesh to the participating PEs by relying on remote defect indication 511 (RDI). 513 Another, less preferred, option is to define a procedure for 514 detection of partial mesh in which each PE keeps track of the status 515 of PW Endpoint Entities (EEs - e.g., VPLS forwarders) for itself as 516 well as the ones reported by other PEs. Therefore, upon a PW 517 failure, the PE that detects the failure not only takes notice 518 locally but it notifies other PEs belonging to that service instance 519 of such failure so that all the participant PEs have a consistent 520 view of the PW mesh. Such a procedure is for the detection of 521 partial mesh per service instance and in turn it relies on 522 additional procedure for PW failure detection such as BFD or VCCV. 523 Given that there can be tens (or even hundreds) of thousands of PWs 524 in a PE, there can be scalability issues with such fault 525 detection/notification procedures. 527 4.4. 528 Multicast Traffic 530 VPLS follows a centralized model for multicast replication within an 531 ESI. VPLS relies on ingress replication. The ingress PE replicates 532 the multicast packet for each egress PE and sends it to the egress 533 PE using PtP PW over a unicast tunnel. VPLS operates on an overlay 534 topology formed by the full mesh of pseudo-wires. Thus, depending on 535 the underlying topology, the same datagram can be sent multiple 536 times down the same physical link. VPLS currently does not offer any 537 mechanisms to restrict the distribution of multicast or broadcast 538 traffic of an ESI throughout the network causing an additional 539 burden on the ingress PE through unnecessary packet replication, 540 causing additional load on the MPLS core network, and causing 541 additional processing at the receiving PE where extraneous multicast 542 packets are discarded. 544 One possible approach, to delivering multicast more efficiently over 545 a VPLS network, is to include the use of IGMP snooping in order to 546 send the packet only to the PEs that have receivers for that 547 traffic, rather than to all the PEs in the VPLS instance. If the 548 customer bridge or its network has dual-home connectivity, then for 549 proper operation of IGMP snooping, the PE must generate a "General 550 Query" over that customer's UNIs upon receiving a customer topology 551 change notification as described in Section 7 of [RFC-4541]. A 552 "General Query" by the PE results in proper registration of the 553 customer multicast MAC address(s) at the PE when there is customer 554 topology change. It should be noted that IGMP snooping provides a 555 solution for IP multicast packets and is not applicable to general 556 multicast data. 558 Using the IGMP-snooping as described, the ingress PE can select a 559 sub-set of PWs for packet replication; therefore, avoiding sending 560 multicast packets to the egress PEs that don't need them. However, 561 the replication is still performed by the ingress PE. In order to 562 avoid, replication at the ingress PE, one may want to use multicast 563 distribution trees (MDTs) in the provider core network; however, 564 this brings with it some potential pitfalls. If the MDT is used for 565 all multicast traffic of a given customer, then this results in 566 customer multicast and unicast traffic being forwarded on different 567 PWs and even on a different physical topology within the provider 568 network. This is a serious issue for customer bridges because 569 customer BPDUs, which are multicast data, can take a different path 570 through the network than the unicast data. Situations might arise 571 where either unicast OR multicast connectivity is lost. If unicast 572 connectivity is lost, but multicast forwarding continues to work, 573 the customer spanning tree would not take notice which results in 574 loss of its unicast traffic. Similarly, if multicast connectivity is 575 lost, but unicast is working, then the customer spanning tree will 576 activate the blocked port which may result in a loop within the 577 customer network. Therefore, the MDT cannot be used for both 578 customer multicast control and data traffic. If it is used, it 579 should only be limited to customer data traffic. However, there can 580 be a potential issue even when it is used for customer data traffic 581 since the MDT doesn't fit the PE model described in Figure 1 (it 582 operates independently from the full-mesh of PWs that correspond to 583 an S-VLAN). It is also not clear how CFM procedures (802.1ag) used 584 for ESI integrity check (e.g., per service instance) can be applied 585 to check the integrity of the customer multicast traffic over the 586 provider MDT. Because of these potential issues, the specific 587 applications of the provider MDT to customer multicast traffic shall 588 be documented and its limitations be clearly specified. 590 5. 591 Optional Issues 593 5.1. 594 Customer Network Topology Changes 596 A single CE or a customer network can be connected to a provider 597 network using more than one User-Network Interface (UNI). 598 Furthermore, a single CE or a customer network can be connected to 599 more than one provider network. [RFC-4665] provides some examples of 600 such customer network connectivity that are depicted in Figure 3 601 below. Such network topologies are designed to protect against the 602 failure or removal of network components from the customer network 603 and it is assumed that the customer leverages the spanning tree 604 protocol to protect against these cases. Therefore, in such 605 scenarios, it is important to flush customer MAC addresses in the 606 provider network upon the customer topology change to avoid black 607 holing of customer frames. 609 +----------- +--------------- 610 | | 611 +------+ +------+ +------+ +------+ 612 | CE |-----| PE | | CE |-----| PE | 613 |device| |device| |device| |device| SP network 614 +------+\ +------+ +------+\ +------+ 615 | \ | | \ | 616 |Back \ | |Back \ +--------------- 617 |door \ | SP network |door \ +--------------- 618 |link \ | |link \ | 619 +------+ +------+ +------+ +------+ 620 | CE | | PE | | CE | | PE | 621 |device|-----|device| |device|-----|device| SP network 622 +------+ +------+ +------+ +------+ 623 | | 624 +------------ +--------------- 625 (a) (b) 627 Figure 3. Combination of Dual-Homing and Backdoor Links for CE 628 Devices 630 The customer networks use their own instances of the spanning tree 631 protocol to configure and partition their active topology, so that 632 the provider connectivity doesn't result in a data loop. 633 Reconfiguration of a customer's active topology can result in the 634 apparent movement of customer end stations from the point of view of 635 the PEs. However, the requirement for mutual independence of the 636 distinct ESIs that can be supported by a single provider spanning 637 tree active topology does not permit either the direct receipt of 638 provider topology change notifications from the CEs or the use of 639 received customer spanning tree protocol topology change 640 notifications to stimulate topology change signaling on a provider 641 spanning tree. 643 To address this issue, [P802.1ad] requires that customer topology 644 change notification to be detected at the ingress of the S-VLAN 645 bridge component and the S-VLAN bridge transmits a Customer Change 646 Notification (CCN) message with the S-VLAN ID associated with that 647 service instance and a destination MAC address as specified in the 648 block of 16 reserved multicast MAC addresses. Upon receiving the 649 CCN, the provider bridge will flush all the customer MAC addresses 650 associated with that S-VLAN ID on all the provider bridge interfaces 651 except the one that the CCN message is received from. 653 Based on the provider bridge model depicted in Figure 1, there are 654 two methods of propagating the CCN message over the VPLS network. 655 The first method is to translate the in-band CCN message into an 656 out-of-band "MAC Address Withdrawal" message as specified in [RFC- 657 4762] and the second method is to treat the CCN message as customer 658 data and pass it transparently over the set of PWs associated with 659 that VPLS instance. The second method is recommended because of ease 660 of interoperability between the bridge and the LAN emulation modules 661 of the PE. 663 5.2. 664 Redundancy 666 [RFC-4762] talks about dual-homing of a given u-PE to two n-PEs over 667 a provider MPLS access network to provide protection against link 668 and node failure - e.g., in case the primary n-PE fails or the 669 connection to it fails, then the u-PE uses the backup PWs to reroute 670 the traffic to the backup n-PE. Furthermore, it discusses the 671 provision of redundancy when a provider Ethernet access network is 672 used and how any arbitrary access network topology (not just limited 673 to hub-and-spoke) can be supported using the provider's MSTP 674 protocol and how the provider MSTP for a given access network can be 675 confined to that access network and operate independently from MSTP 676 protocols running in other access networks. 678 In both types of redundancy mechanism (Ethernet versus MPLS access 679 networks), only one n-PE is active for a given VPLS instance at any 680 time. In case of an Ethernet access network, core-facing PWs (for a 681 VPLS instance) at the n-PE are blocked by the MSTP protocol; 682 whereas, in case of a MPLS access network, the access-facing PW is 683 blocked at the u-PE for a given VPLS instance. 685 -------------------------+ Provider +----------------------- 686 . Core . 687 +------+ . . +------+ 688 | n-PE |======================| n-PE | 689 Provider | (P) |---------\ /-------| (P) | Provider 690 Access +------+ ._ \ / . +------+ Access 691 Network . \/ . Network 692 (1) +------+ . /\ . +------+ (2) 693 | n-PE |----------/ \--------| n-PE | 694 | (B) |----------------------| (B) |_ 695 +------+ . . +------+ 696 . . 697 ------------------------+ +----------------------- 699 Figure 4. Bridge Module Model 701 Figure 4 shows two provider access networks each with two n-PEs 702 where the n-PEs are connected via a full mesh of PWs for a given 703 VPLS instance. As shown in the figure, only one n-PE in each access 704 network is serving as a Primary PE (P) for that VPLS instance and 705 the other n-PE is serving as the backup PE (B). In this figure, each 706 primary PE has two active PWs originating from it. Therefore, when a 707 multicast, broadcast, and unknown unicast frame arrives at the 708 primary n-PE from the access network side, the n-PE replicates the 709 frame over both PWs in the core even though it only needs to send 710 the frames over a single PW (shown with "==" in Figure 4) to the 711 primary n-PE on the other side. This is an unnecessary replication 712 of the customer frames that consumes core-network bandwidth (half of 713 the frames get discarded at the receiving n-PE). This issue gets 714 aggravated when there are more than two n-PEs per provider access 715 network - e.g., if there are three n-PEs or four n-PEs per access 716 network, then 67% or 75% of core-BW for multicast, broadcast and 717 unknown unicast are respectively wasted. 719 Therefore, it is recommended to have a protocol among n-PEs that can 720 disseminate the status of PWs (active or blocked) among themselves 721 and furthermore to have it tied up with the redundancy mechanism 722 such that per VPLS instance the status of active/backup n-PE gets 723 reflected on the corresponding PWs emanating from that n-PE. 725 The above discussion was centered on the lack of efficiency with 726 regards to packet replication over MPLS core network for current 727 VPLS redundancy mechanism. Another important issue to consider is 728 the interaction between customer and service provider redundancy 729 mechanisms especially when customer devices are IEEE bridges. If CEs 730 are IEEE bridges, then they can run RSTP/MSTP protocols, RSTP 731 convergence and detection time is much faster than its predecessor 732 (IEEE 802.1D STP which is obsolete). Therefore, if the provider 733 network offers VPLS redundancy mechanism, then it should provide 734 transparency to the customer's network during a failure within its 735 network - e.g., the failure detection and recovery time within the 736 service provider network to be less than the one in the customer 737 network. If this is not the case, then a failure within the provider 738 network can result in unnecessary switch-over and temporary 739 flooding/loop within the customer's network that is dual homed. 741 5.3. 742 MAC Address Learning 744 When customer devices are routers, servers, or hosts, then the 745 number of MAC addresses per customer sites is very limited (most 746 often one MAC address per CE). However, when CEs are bridges, then 747 there can be many customer MAC addresses (e.g., hundreds of MAC 748 addresses) associated with each CE. 750 [P802.1ad] has devised a mechanism to alleviate MAC address learning 751 within provider Ethernet networks that can equally be applied to 752 VPLS networks. This mechanism calls for disabling MAC address 753 learning for an S-VLAN (or a service instance) within a provider 754 bridge (or PE) when there is only one ingress and one egress port 755 associated with that service instance on that PE. In such cases, 756 there is no need to learn customer MAC addresses on that PE since 757 the path through that PE for that service instance is fixed. For 758 example, if a service instance is associated with four CEs at four 759 different sites, then the maximum number of provider bridges (or 760 PEs), that need to participate in that customer MAC address 761 learning, is only three regardless of how many PEs are in the path 762 of that service instance. This mechanism can reduce the number of 763 MAC addresses learned in a H-VPLS with QinQ access configuration. 765 If the provider access network is of type Ethernet (e.g., IEEE 766 802.1ad-based network), then the MSTP protocol can be used to 767 partition the access network into several loop-free spanning tree 768 topologies where Ethernet service instances (S-VLANs) are 769 distributed among these tree topologies. Furthermore, GVRP can be 770 used to limit the scope of each service instance to a subset of its 771 associated tree topology (and thus limiting the scope of customer 772 MAC address learning to that sub-tree). Finally, the MAC address 773 disabling mechanism (described above) can be applied to that sub- 774 tree, to further limit the number of nodes (PEs) on that sub-tree 775 that need to learn customer MAC addresses for that service instance. 777 Furthermore, [p802.1ah] provides the capability of encapsulating 778 customers' MAC addresses within the provider MAC header. A u-PE 779 capable of this functionality can reduce the number of MAC addressed 780 learned significantly within the provider network for H-VPLS with 781 QinQ access as well as H-VPLS with MPLS access. 783 6. 784 Interoperability with 802.1ad Networks 786 [RFC-4762] discusses H-VPLS provider-network topologies with both 787 Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is 788 important to ensure seamless interoperability between these two types 789 of networks. 791 Provider bridges as specified in [P802.1ad] are intended to operate 792 seamlessly with customer bridges and provide the required services. 793 Therefore, if a PE is modeled based on Figures 1 and 2 which includes 794 a [802.1ad] bridge module, then it should operate seamlessly with 795 Provider Bridges given that the issues discussed in this draft have 796 been taken into account. 798 7. 799 Acknowledgments 801 The authors would like to thank Norm Finn and Samer Salam for their 802 comments and valuable feedbacks. 804 8. 805 IANA Considerations 807 This document has no actions for IANA. 809 9. 810 Security Considerations 812 In addition to the security issues described in [RFC-4762], the 813 following considerations apply: 815 - When a CE that is a customer bridge is connected to the VPLS 816 network, it may be desirable to secure the end-to-end communication 817 between the customer bridge nodes across the VPLS network. This can 818 be accomplished by running [802.1AE] MAC Security between the C-VLAN 819 components of the customer bridges. In this case, the VPLS PEs must 820 ensure transparent delivery of the encryption/security protocol 821 datagrams using the Bridge Group Address [802.1ad]. 823 - When a CE that is a customer bridge is connected to the VPLS 824 network, it may be desirable to secure the communication between the 825 customer bridge and its directly connected PE. If the PE is modeled 826 to include a [802.1ad] bridge module, then this can be achieved by 827 running MAC Security between the customer bridge and the S-VLAN 828 Component of the VPLS PE as described in section 7.7.2 of [802.1AX]. 830 - When and 802.1ad network is connected to a VPLS network, it is 831 possible to secure the NNI between the two networks using the 832 procedures of [802.1AE] and [802.1AX] between the S-VLAN Components 833 of the Provider Edge Bridge and the VPLS PE connecting to it, as 834 long as the PE is modeled to include a [802.1ad] bridge module. 836 10. 837 Normative References 839 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, March 1997. 842 [RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services 843 over MPLS", RFC 4762, January 2007 845 [P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area 846 Networks: Provider Bridges", Work in progress, September 2004 848 [P802.1ag] IEEE Draft P802.1ag/D0.1 "Virtual Bridge Local Area 849 Networks: Connectivity Fault Management", Work in Progress, October 850 2004 852 11. 853 Informative References 855 [RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2 856 Provider Provisioned Virtual Provider Networks", RFC 4665, September 857 2006 859 [RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual 860 Private Networks (L2VPNs)", RFC 4664, September 2006 862 [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS)", draft-ietf- 863 l2vpn-ipls-09.txt, work in progress, February 2009 865 [MFA-Ether] Sajassi, A. and et al, "Ethernet Service Interworking 866 Over MPLS", Work in Progress, September 2004 868 [RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames 869 Over IP/MPLS Networks", RFC 4448, April 2006 871 [802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC) 872 Bridges". 874 [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area 875 Networks". 877 [RFC-4541] Christensen, M. and et al, "Considerations for IGMP and 878 MLD Snooping Switches", Work in progress, May 2004 880 [Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM 881 Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-10.txt, 882 Work in progress, November 2010 884 Authors' Addresses 886 Ali Sajassi 887 Cisco Systems, Inc. 888 170 West Tasman Drive 889 San Jose, CA 95134 890 Email: sajassi@cisco.com 892 Yetik Serbest 893 SBC Labs 894 9505 Arboretum Blvd. 895 Austin, TX 78759 896 Email: yetik_serbest@labs.sbc.com 898 Frank Brockners 899 Cisco Systems, Inc. 900 Hansaallee 249 901 40549 Duesseldorf 902 Germany 903 Email: fbrockne@cisco.com 905 Dinesh Mohan 906 Nortel Networks 907 3500 Carling Ave 908 Ottawa, ON K2H8E9 909 Email: mohand@nortel.com