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