idnits 2.17.1 draft-ietf-l2vpn-vpls-bridge-interop-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 860. 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 16) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 Cisco Systems 4 Intended Status: Informational 5 Dinesh Mohan, Ed. 6 Nortel 8 Expires: January 2009 10 VPLS Interoperability with CE Bridges 11 draft-ietf-l2vpn-vpls-bridge-interop-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 Abstract 38 One of the main motivations behind VPLS is its ability to provide 39 connectivity not only among customer routers and servers/hosts but 40 also among customer bridges. VPLS is expected to deliver the same 41 level of service that current enterprise users are accustomed to 42 from their own enterprise bridged networks today or the same level 43 of service that they receive from their Ethernet Service Providers 44 using IEEE bridged networks. 46 When CE devices are IEEE bridges, then there are certain issues and 47 challenges that need to be accounted for in a VPLS network. The 48 majority of these issues have currently been addressed in the IEEE 49 802.1ad standard for provider bridges and they need to be addressed 50 for VPLS networks. This draft discusses these issues and wherever 51 possible suggests areas to be explored in rectifying these issues. 53 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 55 Conventions 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC-2119]. 61 Table of Contents 63 1. Contributing Authors............................................2 64 2. Introduction....................................................2 65 3. Ethernet Service Instance.......................................3 66 4. VPLS-Capable PE Model with Bridge Module........................4 67 5. Mandatory Issues................................................7 68 5.1. Service Mapping...............................................7 69 5.2. CE Bridge Protocol Handling...................................9 70 5.3. Partial-mesh of Pseudowires..................................10 71 5.4. Multicast Traffic............................................11 72 6. Optional Issues................................................12 73 6.1. Customer Network Topology Changes............................12 74 6.2. Redundancy...................................................14 75 6.3. MAC Address Learning.........................................15 76 7. Interoperability with 802.1ad Networks.........................16 77 8. Acknowledgments................................................16 78 9. IANA Considerations............................................16 79 10. Security Considerations.......................................17 80 11. IPR Notice:...................................................17 81 12. Normative References..........................................17 82 13. Informative References........................................18 83 Authors' Addresses................................................18 84 Full Copyright Statement..........................................19 86 1. 87 Contributing Authors 89 This document is the combined effort of the following individuals 90 and others who have carefully reviewed this document and provided 91 the technical clarifications 93 Yetik Serbest SBC Communications 94 Frank Brockners Cisco Systems 96 2. 97 Introduction 99 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 101 Virtual Private LAN Service (VPLS) is a LAN emulation service 102 intended for providing connectivity between geographically dispersed 103 customer sites across MAN/WAN (over MPLS/IP) network(s), as if they 104 were connected using a LAN. One of the main motivations behind VPLS 105 is its ability to provide connectivity not only among customer 106 routers and servers/hosts but also among customer bridges. If only 107 connectivity among customer IP routers/hosts was desired, then an 108 IPLS solution [IPLS] could have been used. The strength of the VPLS 109 solution is that it can provide connectivity to both bridge and non- 110 bridge types of CE devices. VPLS is expected to deliver the same 111 level of service that current enterprise users are accustomed to 112 from their own enterprise bridged networks [802.1D/802.1Q] today or 113 the same level of service that they receive from their Ethernet 114 Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or 115 its predecessor, QinQ-based network). 117 When CE devices are IEEE bridges, then there are certain issues and 118 challenges that need to be accounted for in a VPLS network. The 119 majority of these issues have currently been addressed in the IEEE 120 802.1ad standard for provider bridges and they need to be addressed 121 for VPLS networks. This draft discusses these issues and wherever 122 possible suggests areas to be explored in rectifying these issues. 123 The detailed solution specification for these issues is outside of 124 the scope of this document. 126 It also discusses interoperability issues between VPLS and IEEE 127 802.1ad networks when the end-to-end service spans across both types 128 of networks, as outlined in [RFC-4762]. 130 This draft categorizes the CE-bridge issues into two groups: 1) 131 Mandatory and 2) Optional. The issues in group (1) need to be 132 addressed in order to ensure the proper operation of CE bridges. The 133 issues in group (2) would provide additional operational improvement 134 and efficiency and may not be required for interoperability with CE 135 bridges. Sections five and six discuss the mandatory and optional 136 issues respectively. 138 3. 139 Ethernet Service Instance 141 Before starting the discussion of bridging issues, it is important 142 to first clarify the Ethernet Service definition. The term VPLS has 143 different meanings in different contexts. In general, VPLS is used 144 in the following contexts [Eth-OAM]: a) as an end-to-end bridged-LAN 145 service over one or more network (one of which being MPLS/IP 146 network), b) as an MPLS/IP network supporting these bridged LAN 147 services, and c) as (V)LAN emulation. For better clarity, we 148 differentiate between its usage as network versus service by using 149 the terms VPLS network and VPLS instance respectively. Furthermore, 150 we confine VPLS (both network and service) to only the portion of 151 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 153 the end-to-end network that spans across an MPLS/IP network. For an 154 end-to-end service (among different sites of a given customer), we 155 use the term "Ethernet Service Instance" or ESI. 157 [MFA-Ether] defines the Ethernet Service Instance (ESI) as an 158 association of two or more Attachment Circuits (ACs) over which an 159 Ethernet service is offered to a given customer. An AC can be either 160 a UNI or a NNI; furthermore, it can be an Ethernet interface or a 161 VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface. 162 If an ESI is associated with more than two ACs, then it is a 163 multipoint ESI. In this document, where ever the keyword ESI is 164 used, it means multipoint ESI, unless it is stated otherwise. 166 An ESI can correspond to a VPLS instance if its associated ACs are 167 only connected to a VPLS network or an ESI can correspond to a 168 Service VLAN if its associated ACs are only connected to a Provider- 169 Bridged network [P802.1ad]. Furthermore, an ESI can be associated 170 with both a VPLS instance and a Service VLAN when considering an 171 end-to-end service that spans across both VPLS and Provider-Bridged 172 networks. An ESI can span across different networks (e.g., IEEE 173 802.1ad and VPLS) belonging to the same or different administrative 174 domains. 176 An ESI (either for a point-to-point or multipoint connectivity) is 177 associated with a forwarding path within the service provider's 178 network; whereas, an Ethernet Class of Service (CoS) is associated 179 with the frame Quality-of-Service treatment by each node along the 180 path defined by the ESI. An ESI can have one or more CoS associated 181 with it. 183 An ESI most often represents a customer or a specific service 184 requested by a customer. Since traffic isolation among different 185 customers (or their associated services) is of paramount importance 186 in service provider networks, its realization shall be done such 187 that it provides a separate MAC address domain and broadcast domain 188 per ESI. A separate MAC address domain is provided by using a 189 separate filtering database (e.g., FIB) per ESI (for both VPLS and 190 IEEE 802.1ad networks) and separate broadcast domain is provided by 191 using a full-mesh of PWs per ESI over the IP/MPLS core in a VPLS 192 network and/or a dedicated Service VLAN per ESI in an IEEE 802.1ad 193 network. 195 4. 196 VPLS-Capable PE Model with Bridge Module 198 [RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based 199 on the bridging functionality that needs to be supported by the PE. 200 If the CE devices can include both routers/hosts and IEEE bridges, 201 then the second model is the most suitable and adequate one and it 202 is consistent with IEEE standards for Provider Bridges [P802.1ad]. 203 We briefly describe the second model and then elaborate upon this 204 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 206 model to show its sub-components based on [P802.1ad] Provider Bridge 207 model. 209 As described in [RFC-4664], the second model for VPLS-PE contains a 210 single bridge module supporting all the VPLS instances on that PE 211 where each VPLS instance is represented by a unique VLAN inside that 212 bridge module (also known as Service VLAN or S-VLAN). The bridge 213 module has at least a single "Emulated LAN" interface over which 214 each VPLS instance is represented by a unique S-VLAN tag. Each VPLS 215 instance can consist of a set of PWs and its associated forwarder 216 corresponding to a single Virtual LAN (VLAN) as depicted in Figure 1 217 below. Thus, sometimes it is referred to as VLAN emulation. 219 +----------------------------------------+ 220 | VPLS-capable PE model | 221 | +---------------+ +------+ | 222 | | | |VPLS-1|------------ 223 | | |==========|Fwdr |------------ PWs 224 | | Bridge ------------ |------------ 225 | | | S-VLAN-1 +------+ | 226 | | Module | o | 227 | | | o | 228 | | (802.1ad | o | 229 | | bridge) | o | 230 | | | o | 231 | | | S-VLAN-n +------+ | 232 | | ------------VPLS-n|------------- 233 | | |==========| Fwdr |------------- PWs 234 | | | ^ | |------------- 235 | +---------------+ | +------+ | 236 | | | 237 +-------------------------|--------------+ 238 LAN emulation Interface 240 Figure 1. VPLS-capable PE Model 242 Customer frames associated with a given ESI, carry the S-VLAN ID for 243 that ESI over the LAN emulation interface. The S-VLAN ID is stripped 244 before transmitting the frames over the set of PWs associated with 245 that VPLS instance (assuming raw mode PWs are used as specified in 246 [RFC-4448]). 248 The bridge module can itself consist of one or two sub-components 249 depending on the functionality that it needs to perform. The 250 following Figure 2 depicts the model for the bridge module based on 251 [P802.1ad]. 253 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 255 +-------------------------------+ 256 | 802.1ad Bridge Module Model | 257 | | 258 +---+ | +------+ +-----------+ | 259 |CE |---------|C-VLAN|------| | | 260 +---+ | |bridge|------| | | 261 | +------+ | | | 262 | o | S-VLAN | | 263 | o | | | 264 | o | Bridge | | 265 +---+ | +------+ | | | 266 |CE |---------|C-VLAN|------| | | 267 +---+ | |bridge|------| | | 268 | +------+ +-----------+ | 269 +-------------------------------+ 271 Figure 2. The Model of 802.1ad Bridge Module 273 The S-VLAN bridge component is always required and it is responsible 274 for tagging customer frames with S-VLAN tags in the ingress 275 direction (from customer UNIs) and removing S-VLAN tags in the 276 egress direction (toward customer UNIs). It is also responsible for 277 running the provider's bridge protocol such as RSTP, MSTP, GVRP, 278 GMRP, etc. among provider bridges within a single administrative 279 domain. 281 The C-VLAN bridge component is required when the customer Attachment 282 Circuits are VLANs (aka C-VLANs). In such cases, the VPLS-capable PE 283 needs to participate in some of the customer's bridging protocol 284 such as RSTP and MSTP. The reason that such participation is 285 required is because a customer VLAN (C-VLAN) at one site can be 286 mapped into a different C-VLAN at a different site or in case of 287 asymmetric mapping, a customer Ethernet port at one site can be 288 mapped into a customer VLAN (or group of C-VLANs) at a different 289 site. 291 In scenarios where the C-VLAN bridge component is required, then 292 there will be one such component per customer UNI port in order to 293 avoid local switching within the C-VLAN bridge component and thus 294 limiting local switching among different UNIs for the same customer 295 to the S-VLAN bridge component. 297 The C-VLAN bridge component does service selection and 298 identification based on C-VLAN tags. Each frame from the customer 299 device is assigned to a C-VLAN and presented at one or more internal 300 port-based interfaces, each supporting a single service instance 301 that the customer desires to carry that C-VLAN. Similarly frames 302 from the provider network are assigned to an internal interface or 303 'LAN' (e.g, between C-VLAN and S-VLAN components) on the basis of 304 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 306 the S-VLAN tag. Since each internal interface supports a single 307 service instance, the S-VLAN tag can be, and is, removed at this 308 interface by the S-VLAN bridge component. If multiple C-VLANs are 309 supported by this service instance (e.g., VLAN bundling or port- 310 based), then the frames will have already been tagged with C-VLAN 311 tags. If a single C-VLAN is supported by this service instance 312 (e.g., VLAN-based), then the frames will not have been tagged with 313 C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one to 314 one mapping). The C-VLAN aware bridge component applies a port VLAN 315 ID (PVID) to untagged frames received on each internal 'LAN', 316 allowing full control over the delivery of frames for each C-VLAN 317 through the Customer UNI Port. 319 5. 320 Mandatory Issues 322 5.1. 323 Service Mapping 325 Different Ethernet AC types can be associated with a single Ethernet 326 Service Instance (ESI). For example, an ESI can be associated with 327 only physical Ethernet ports, VLANs, or a combination of the two 328 (e.g., one end of the service could be associated with physical 329 Ethernet ports and the other end could be associated with VLANs). In 330 [RFC-4762], unqualified and qualified learning are used to refer to 331 port-based and VLAN-based operation respectively and [RFC-4762] does 332 not describe the possible mappings between different types of 333 Ethernet ACs (e.g., 802.1D, 802.1Q or 802.1ad frames). In general, 334 the mapping of a customer port or VLAN to a given service instance 335 is a local function performed by the local PE and the service 336 provisioning shall accommodate it. In other words, there is no 337 reason to restrict and limit an ESI to have only port-based ACs or 338 to have only VLAN-based ACs. [P802.1ad] allows for each customer AC 339 (either a physical port, or a VLAN, or a group of VLANs) to be 340 mapped independently to an ESI which provides better service 341 offering to Enterprise customers. For better and more flexible 342 service offerings and for interoperability purposes between VPLS and 343 802.1ad networks, it is imperative that both networks offer the same 344 capabilities in terms of customer ACs mapping to the customer 345 service instance. 347 The following table lists possible mappings that can exist between 348 customer ACs and its associated ESI - this table is extracted from 349 [MFA-Ether]. As it can be seen, there are several possible ways to 350 perform such mapping. In the first scenario, it is assumed that an 351 Ethernet physical port only carries untagged traffic and all the 352 traffic is mapped to the corresponding service instance or ESI. This 353 is referred to as "port-based with untagged traffic". In the second 354 scenario, it is assumed that an Ethernet physical port carries both 355 tagged and untagged traffic and all that traffic is mapped to the 356 corresponding service instance or ESI. This is referred to as "port- 357 based with tagged and untagged traffic". In the third scenario, it 358 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 360 is assumed that only a single VLAN is mapped to the corresponding 361 service instance or ESI (referred to as VLAN-based). Finally, in the 362 fourth scenario, it is assumed that a group of VLANs from the 363 Ethernet physical interface is mapped to the corresponding service 364 instance or ESI. 366 =================================================================== 367 Ethernet I/F & Associated Service Instance(s) 368 ------------------------------------------------------------------- 369 Port-based Port-based VLAN-based VLAN 370 untagged tagged & bundling 371 untagged 372 ------------------------------------------------------------------- 373 Port-based Y N Y(Note-1) N 374 untagged 376 Port-based N Y Y(Note-2) Y 377 tagged & 378 untagged 380 VLAN-based Y(Note-1) Y(Note-2) Y Y(Note-3) 382 VLAN N Y Y(Note-3) Y 383 Bundling 384 =================================================================== 386 Note-1: In this asymmetric mapping scenario, it is assumed that the 387 CE device with "VLAN-based" AC is a device capable of supporting 388 [802.1Q] frame format. 390 Note-2: In this asymmetric mapping scenario, it is assumed that the 391 CE device with "VLAN-based" AC is a device that can support 392 [P802.1ad] frame format because it will receive Ethernet frames with 393 two tags; where the outer tag is S-VLAN and the inner tag is C-VLAN 394 received from "port-based" AC. One application example for such CE 395 device is in a BRAS for DSL aggregation over Metro Ethernet network. 397 Note-3: In this asymmetric mapping scenario, it is assumed that the 398 CE device with "VLAN-based" AC can support the [P802.1ad] frame 399 format because it will receive Ethernet frames with two tags; where 400 the outer tag is S-VLAN and the inner tag is C-VLAN received from 401 "VLAN bundling" AC. 403 If a PE uses an S-VLAN tag for a given ESI (either by adding an S- 404 VLAN tag to customer traffic or by replacing a C-VLAN tag with a S- 405 VLAN tag), then the frame format and EtherType for S-VLAN shall 406 adhere to [P802.1ad]. 408 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 410 As mentioned before, the mapping function between the customer AC 411 and its associated ESI is a local function and thus when the AC is a 412 single customer VLAN, it is possible to map different customer VLANs 413 at different sites to a single ESI without coordination among those 414 sites. 416 When a port-based mapping or a VLAN-bundling mapping is used, then 417 the PE may use an additional S-VLAN tag to mark the customer traffic 418 received over that AC as belonging to a given ESI. If the PE uses 419 the additional S-VLAN tag, then in the opposite direction the PE 420 shall strip the S-VLAN tag before sending the customer frames over 421 the same AC. However, when VLAN-mapping mode is used at an AC and if 422 the PE uses S-VLAN tag locally, then if the Ethernet interface is a 423 UNI, the tagged frames over this interface shall have a frame format 424 based on [802.1Q] and the PE shall translate the customer tag (C- 425 VLAN) into the provider tag (S-VLAN) upon receiving a frame from the 426 customer and in the opposite direction, the PE shall translate from 427 provider frame format (802.1ad) back to customer frame format 428 (802.1Q). 430 All the above asymmetric services can be supported via the PE model 431 with the bridge module depicted in Figure 2 (based on [802.1ad]). 433 5.2. 434 CE Bridge Protocol Handling 436 When a VPLS-capable PE is connected to a CE bridge, then depending 437 on the type of Attachment Circuit, different protocol handling may 438 be required by the bridge module of the PE. [P802.1ad] states that 439 when a PE is connected to a CE bridge, then the service offered by 440 the PE may appear to specific customer protocols running on the CE 441 in one of the four ways: 443 i) Transparent to the operation of the protocol among CEs of 444 different sites using the service provided, appearing as an 445 individual LAN without bridges; or, 446 ii) Discarding frames, acting as a non-participating barrier to the 447 operation of the protocol; or, 448 iii) Peering, with a local protocol entity at the point of provider 449 ingress and egress, participating in and terminating the 450 operation of the protocol; or, 451 iv) Participation in individual instances of customer protocols. 453 All the above CE bridge protocol handling can be supported via the 454 PE model with the bridge module depicted in figure-2 (based on 455 [802.1ad]). For example, when an Attachment Circuit is port-based, 456 then the bridge module of the PE can operate transparently with 457 respect to the CE's RSTP/MSTP protocols (and thus no C-VLAN 458 component is required for that customer UNI). However, when an 459 Attachment Circuit is VLAN-based (either VLAN-based or VLAN 460 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 462 bundling), then the bridge module of the PE needs to peer with the 463 RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge 464 component is required). In other words, when the AC is VLAN-based, 465 then protocol peering between CE and PE devices may be needed. There 466 are also protocols that require peering but are independent from the 467 type of Attachment Circuit. An example of such protocol is the link 468 aggregation protocol [802.3ad]; however, this is a media-dependent 469 protocol as its name implies. 471 [P802.1ad] reserves a block of 16 MAC addresses for the operation of 472 C-VLAN and S-VLAN bridge components and it shows which of these 473 reserved MAC addresses are only for C-VLAN bridge component and 474 which ones are only for S-VLAN bridge component and which ones apply 475 to both C-VLAN and S-VLAN components. 477 5.3. 478 Partial-mesh of Pseudowires 480 A PW failure results in creation of partial-mesh in a VPLS service 481 with adverse effects. If the CE devices belonging to an ESI are 482 routers running link state routing protocols that use LAN procedures 483 over that ESI, then a partial-mesh of PWs can result in "black 484 holing" traffic among the selected set of routers. And if the CE 485 devices belonging to an ESI are IEEE bridges, then a partial-mesh of 486 PWs can cause broadcast storms in the customer and provider 487 networks. Furthermore, it can cause multiple copies of a single 488 frame to be received by the CE and/or PE devices. Therefore, it is 489 of paramount importance to be able to detect PW failure and to take 490 corrective action to prevent creation of partial-mesh of PWs. 492 One can define a procedure for detection of partial mesh in which 493 each PE keeps track of the status of PW Endpoint Entities (EEs - 494 e.g., VPLS forwarders) for itself as well as the ones reported by 495 other PEs. Therefore, upon a PW failure, the PE that detects the 496 failure not only takes notice locally but it notifies other PEs 497 belonging to that service instance of such failure so that all the 498 participant PEs have a consistent view of the PW mesh. Such a 499 procedure is for the detection of partial mesh per service instance 500 and in turn it relies on additional procedure for PW failure 501 detection such as BFD or VCCV. Given that there can be tens (or even 502 hundreds) of thousands of PWs in a PE, the scalability aspects of 503 such procedure needs to be worked out. Furthermore, many of the 504 details regarding operational aspects of such procedure also need to 505 be worked out. 507 If the PE model, with a bridge module as depicted in Figure 2, is 508 used, then [P802.1ag] procedures could be used for detection of 509 partial-mesh of PWs. [p802.1ag] defines a set of procedures for 510 fault detection, verification, isolation, and notification per ESI. 512 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 514 The fault detection mechanism of [p8021.ag] can be used to perform 515 connectivity check among PEs belonging to a given VPLS instance. It 516 checks the integrity of a service instance end-to-end within an 517 administrative domain - e.g., from one AC at one end of the network 518 to another AC at the other end of the network. Therefore, its path 519 coverage includes bridge module within a PE and it is not limited to 520 just PWs. Furthermore, [P802.1ag] operates transparently over the 521 full-mesh of PWs for a given service instance since it operates at 522 the Ethernet level (and not at PW level). It should be noted that 523 [P802.1ag] assumes that the Ethernet links or LAN segments 524 connecting provider bridges are full-duplex and the failure in one 525 direction results in the failure of the whole link or LAN segment. 526 However, that is not the case for VPLS instance since a PW consists 527 of two uni-directional LSPs and one direction can fail independently 528 of the other causing an inconsistent view of the full-mesh by the 529 participating PEs till the detected failure in one side is 530 propagated to the other side. 532 5.4. 533 Multicast Traffic 535 VPLS follows a centralized model for multicast replication within an 536 ESI. VPLS relies on ingress replication. The ingress PE replicates 537 the multicast packet for each egress PE and sends it to the egress 538 PE using PtP PW over a unicast tunnel. VPLS operates on an overlay 539 topology formed by the full mesh of pseudo-wires. Thus, depending on 540 the underlying topology, the same datagram can be sent multiple 541 times down the same physical link. VPLS currently does not offer any 542 mechanisms to restrict the distribution of multicast or broadcast 543 traffic of an ESI throughout the network causing an additional 544 burden on the ingress PE through unnecessary packet replication, 545 causing additional load on the MPLS core network, and causing 546 additional processing at the receiving PE where extraneous multicast 547 packets are discarded. 549 One possible approach, to delivering multicast more efficiently over 550 a VPLS network, is to include the use of IGMP snooping in order to 551 send the packet only to the PEs that have receivers for that 552 traffic, rather than to all the PEs in the VPLS instance. If the 553 customer bridge or its network has dual-home connectivity, then for 554 proper operation of IGMP snooping, the PE must generate a "General 555 Query" over that customer's UNIs upon receiving a customer topology 556 change notification as described in Section 7 of [RFC-4541]. A 557 "General Query" by the PE results in proper registration of the 558 customer multicast MAC address(s) at the PE when there is customer 559 topology change. It should be noted that IGMP snooping provides a 560 solution for IP multicast packets and is not applicable to general 561 multicast data. 563 Using the IGMP-snooping as described, the ingress PE can select a 564 sub-set of PWs for packet replication; therefore, avoiding sending 565 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 567 multicast packets to the egress PEs that don't need them. However, 568 the replication is still performed by the ingress PE. In order to 569 avoid, replication at the ingress PE, one may want to use multicast 570 distribution trees (MDTs) in the provider core network; however, 571 this brings with it some potential pitfalls. If the MDT is used for 572 all multicast traffic of a given customer, then this results in 573 customer multicast and unicast traffic being forwarded on different 574 PWs and even on a different physical topology within the provider 575 network. This is a serious issue for customer bridges because 576 customer BPDUs, which are multicast data, can take a different path 577 through the network than the unicast data. Situations might arise 578 where either unicast OR multicast connectivity is lost. If unicast 579 connectivity is lost, but multicast forwarding continues to work, 580 the customer spanning tree would not take notice which results in 581 loss of its unicast traffic. Similarly, if multicast connectivity is 582 lost, but unicast is working, then the customer spanning tree will 583 activate the blocked port which may result in a loop within the 584 customer network. Therefore, the MDT cannot be used for both 585 customer multicast control and data traffic. If it is used, it 586 should only be limited to customer data traffic. However, there can 587 be a potential issue even when it is used for customer data traffic 588 since the MDT doesn't fit the PE model described in Figure 1 (it 589 operates independently from the full-mesh of PWs that correspond to 590 an S-VLAN). It is also not clear how CFM procedures (802.1ag) used 591 for ESI integrity check (e.g., per service instance) can be applied 592 to check the integrity of the customer multicast traffic over the 593 provider MDT. Because of these potential issues, the specific 594 applications of the provider MDT to customer multicast traffic shall 595 be documented and its limitations be clearly specified. 597 6. 598 Optional Issues 600 6.1. 601 Customer Network Topology Changes 603 A single CE or a customer network can be connected to a provider 604 network using more than one User-Network Interface (UNI). 605 Furthermore, a single CE or a customer network can be connected to 606 more than one provider network. [RFC-4665] provides some examples of 607 such customer network connectivity that are depicted in Figure 3 608 below. Such network topologies are designed to protect against the 609 failure or removal of network components from the customer network 610 and it is assumed that the customer leverages the spanning tree 611 protocol to protect against these cases. Therefore, in such 612 scenarios, it is important to flush customer MAC addresses in the 613 provider network upon the customer topology change to avoid black 614 holing of customer frames. 616 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 618 +----------- +--------------- 619 | | 620 +------+ +------+ +------+ +------+ 621 | CE |-----| PE | | CE |-----| PE | 622 |device| |device| |device| |device| SP network 623 +------+\ +------+ +------+\ +------+ 624 | \ | | \ | 625 |Back \ | |Back \ +--------------- 626 |door \ | SP network |door \ +--------------- 627 |link \ | |link \ | 628 +------+ +------+ +------+ +------+ 629 | CE | | PE | | CE | | PE | 630 |device|-----|device| |device|-----|device| SP network 631 +------+ +------+ +------+ +------+ 632 | | 633 +------------ +--------------- 634 (a) (b) 636 Figure 3. Combination of Dual-Homing and Backdoor Links for CE 637 Devices 639 The customer networks use their own instances of the spanning tree 640 protocol to configure and partition their active topology, so that 641 the provider connectivity doesn't result in a data loop. 642 Reconfiguration of a customer's active topology can result in the 643 apparent movement of customer end stations from the point of view of 644 the PEs. However, the requirement for mutual independence of the 645 distinct ESIs that can be supported by a single provider spanning 646 tree active topology does not permit either the direct receipt of 647 provider topology change notifications from the CEs or the use of 648 received customer spanning tree protocol topology change 649 notifications to stimulate topology change signaling on a provider 650 spanning tree. 652 To address this issue, [P802.1ad] requires that customer topology 653 change notification to be detected at the ingress of the S-VLAN 654 bridge component and the S-VLAN bridge transmits a Customer Change 655 Notification (CCN) message with the S-VLAN ID associated with that 656 service instance and a destination MAC address as specified in the 657 block of 16 reserved multicast MAC addresses. Upon receiving the 658 CCN, the provider bridge will flush all the customer MAC addresses 659 associated with that S-VLAN ID on all the provider bridge interfaces 660 except the one that the CCN message is received from. 662 Based on the provider bridge model depicted in Figure 1, there are 663 two methods of propagating the CCN message over the VPLS network. 664 The first method is to translate the in-band CCN message into an 665 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 667 out-of-band "MAC Address Withdrawal" message as specified in [RFC- 668 4762] and the second method is to treat the CCN message as customer 669 data and pass it transparently over the set of PWs associated with 670 that VPLS instance. The second method is recommended because of ease 671 of interoperability between the bridge and the LAN emulation modules 672 of the PE. 674 6.2. 675 Redundancy 677 [RFC-4762] talks about dual-homing of a given u-PE to two n-PEs over 678 a provider MPLS access network to provide protection against link 679 and node failure - e.g., in case the primary n-PE fails or the 680 connection to it fails, then the u-PE uses the backup PWs to reroute 681 the traffic to the backup n-PE. Furthermore, it discusses the 682 provision of redundancy when a provider Ethernet access network is 683 used and how any arbitrary access network topology (not just limited 684 to hub-and-spoke) can be supported using the provider's MSTP 685 protocol and how the provider MSTP for a given access network can be 686 confined to that access network and operate independently from MSTP 687 protocols running in other access networks. 689 In both types of redundancy mechanisms (Ethernet versus MPLS access 690 networks), only one n-PE is active for a given VPLS instance at any 691 time. In case of an Ethernet access network, core-facing PWs (for a 692 VPLS instance) at the n-PE are blocked by the MSTP protocol; 693 whereas, in case of a MPLS access network, the access-facing PW is 694 blocked at the u-PE for a given VPLS instance. 696 -------------------------+ Provider +------------------------- 697 . Core . 698 +------+ . . +------+ 699 | n-PE |======================| n-PE | 700 Provider | (P) |---------\ /-------| (P) | Provider 701 Access +------+ ._ \ / . +------+ Access 702 Network . \/ . Network 703 (1) +------+ . /\ . +------+ (2) 704 | n-PE |----------/ \--------| n-PE | 705 | (B) |----------------------| (B) |_ 706 +------+ . . +------+ 707 . . 708 ------------------------+ +------------------------- 710 Figure 4. Bridge Module Model 712 Figure 4 shows two provider access networks each with two n-PEs 713 where the n-PEs are connected via a full mesh of PWs for a given 714 VPLS instance. As shown in the figure, only one n-PE in each access 715 network is serving as a Primary PE (P) for that VPLS instance and 716 the other n-PE is serving as the backup PE (B). In this figure, each 717 primary PE has two active PWs originating from it. Therefore, when a 718 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 720 multicast, broadcast, and unknown unicast frame arrives at the 721 primary n-PE from the access network side, the n-PE replicates the 722 frame over both PWs in the core even though it only needs to send 723 the frames over a single PW (shown with "==" in Figure 4) to the 724 primary n-PE on the other side. This is an unnecessary replication 725 of the customer frames that consumes core-network bandwidth (half of 726 the frames get discarded at the receiving n-PE). This issue gets 727 aggravated when there are more than two n-PEs per provider access 728 network - e.g., if there are three n-PEs or four n-PEs per access 729 network, then 67% or 75% of core-BW for multicast, broadcast and 730 unknown unicast are respectively wasted. 732 Therefore, it is recommended to have a protocol among n-PEs that can 733 disseminate the status of PWs (active or blocked) among themselves 734 and furthermore to have it tied up with the redundancy mechanism 735 such that per VPLS instance the status of active/backup n-PE gets 736 reflected on the corresponding PWs emanating from that n-PE. 738 The above discussion was centered on the lack of efficiency with 739 regards to packet replication over MPLS core network for current 740 VPLS redundancy mechanism. Another important issue to consider is 741 the interaction between customer and service provider redundancy 742 mechanisms especially when customer devices are IEEE bridges. If CEs 743 are IEEE bridges, then they can run RSTP/MSTP protocols, RSTP 744 convergence and detection time is much faster than its predecessor 745 (IEEE 802.1D STP which is obsolete). Therefore, if the provider 746 network offers VPLS redundancy mechanism, then it should provide 747 transparency to the customer's network during a failure within its 748 network - e.g., the failure detection and recovery time within the 749 service provider network to be less than the one in the customer 750 network. If this is not the case, then a failure within the provider 751 network can result in unnecessary switch-over and temporary 752 flooding/loop within the customer's network that is dual homed. 754 6.3. 755 MAC Address Learning 757 When customer devices are routers, servers, or hosts, then the 758 number of MAC addresses per customer sites is very limited (most 759 often one MAC address per CE). However, when CEs are bridges, then 760 there can be many customer MAC addresses (e.g., hundreds of MAC 761 addresses) associated with each CE. 763 [P802.1ad] has devised a mechanism to alleviate MAC address learning 764 within provider Ethernet networks that can equally be applied to 765 VPLS networks. This mechanism calls for disabling MAC address 766 learning for an S-VLAN (or a service instance) within a provider 767 bridge (or PE) when there is only one ingress and one egress port 768 associated with that service instance on that PE. In such cases, 769 there is no need to learn customer MAC addresses on that PE since 770 the path through that PE for that service instance is fixed. For 771 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 773 example, if a service instance is associated with four CEs at four 774 different sites, then the maximum number of provider bridges (or 775 PEs), that need to participate in that customer MAC address 776 learning, is only three regardless of how many PEs are in the path 777 of that service instance. This mechanism can reduce the number of 778 MAC addresses learned in a H-VPLS with QinQ access configuration. 780 If the provider access network is of type Ethernet (e.g., IEEE 781 802.1ad-based network), then the MSTP protocol can be used to 782 partition the access network into several loop-free spanning tree 783 topologies where Ethernet service instances (S-VLANs) are 784 distributed among these tree topologies. Furthermore, GVRP can be 785 used to limit the scope of each service instance to a subset of its 786 associated tree topology (and thus limiting the scope of customer 787 MAC address learning to that sub-tree). Finally, the MAC address 788 disabling mechanism (described above) can be applied to that sub- 789 tree, to further limit the number of nodes (PEs) on that sub-tree 790 that need to learn customer MAC addresses for that service instance. 792 Furthermore, [p802.1ah] provides the capability of encapsulating 793 customers' MAC addresses within the provider MAC header. A u-PE 794 capable of this functionality can reduce the number of MAC addressed 795 learned significantly within the provider network for H-VPLS with 796 QinQ access as well as H-VPLS with MPLS access. 798 7. 799 Interoperability with 802.1ad Networks 801 [RFC-4762] discusses H-VPLS provider-network topologies with both 802 Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is 803 of paramount importance to ensure seamless interoperability between 804 these two types of networks. 806 Provider bridges as specified in [P802.1ad] are intended to operate 807 seamlessly with customer bridges and provide the required services. 808 Therefore, if a PE is modeled based on Figures 1&2 which includes a 809 [802.1ad] bridge module, then it should operate seamlessly with 810 Provider Bridges given that the issues discussed in this draft have 811 been taken into account. 813 8. 814 Acknowledgments 816 The authors would like to thank Norm Finn for his comments and 817 feedbacks. 819 9. 820 IANA Considerations 822 This document has no actions for IANA. 824 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 826 10. 827 Security Considerations 829 The security considerations in here are the same as the ones 830 described in [RFC-4762], and there are no additional security 831 aspects that need to be considered beyond the ones described in 832 [RFC-4762]. 834 11. 835 IPR Notice: 837 The IETF takes no position regarding the validity or scope of any 838 Intellectual Property Rights or other rights that might be claimed 839 to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use 850 of 851 such proprietary rights by implementers or users of this 852 specification can be obtained from the IETF on-line IPR repository 853 at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at ietf- 860 ipr@ietf.org. 862 12. 863 Normative References 865 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services 869 over MPLS", RFC 4762, January 2007 871 [P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area 872 Networks: Provider Bridges", Work in progress, September 2004 873 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 875 [P802.1ag] IEEE Draft P802.1ag/D0.1 "Virtual Bridge Local Area 876 Networks: Connectivity Fault Management", Work in Progress, October 877 2004 879 13. 880 Informative References 882 [RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2 883 Provider Provisioned Virtual Provider Networks", RFC 4665, September 884 2006 886 [RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual 887 Private Networks (L2VPNs)", RFC 4664, September 2006 889 [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS)", draft-ietf- 890 l2vpn-ipls-08.txt, work in progress, February 2008 892 [MFA-Ether] Sajassi, A. and et al, "Ethernet Service Interworking 893 Over MPLS", Work in Progress, September 2004 895 [RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames 896 Over IP/MPLS Networks", RFC 4448, April 2006 898 [802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC) 899 Bridges". 901 [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area 902 Networks". 904 [RFC-4541] Christensen, M. and et al, "Considerations for IGMP and 905 MLD Snooping Switches", Work in progress, May 2004 907 [Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM 908 Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-10.txt, 909 Work in progress, July 2008 911 Authors' Addresses 913 Ali Sajassi 914 Cisco Systems, Inc. 915 170 West Tasman Drive 916 San Jose, CA 95134 917 Email: sajassi@cisco.com 919 Yetik Serbest 920 SBC Labs 921 9505 Arboretum Blvd. 922 Austin, TX 78759 923 Email: yetik_serbest@labs.sbc.com 924 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 926 Frank Brockners 927 Cisco Systems, Inc. 928 Hansaallee 249 929 40549 Duesseldorf 930 Germany 931 Email: fbrockne@cisco.com 933 Dinesh Mohan 934 Nortel Networks 935 3500 Carling Ave 936 Ottawa, ON K2H8E9 937 Email: mohand@nortel.com 939 Full Copyright Statement 941 Copyright (C) The IETF Trust (2008). 943 This document is subject to the rights, licenses and restrictions 944 contained in BCP 78, and except as set forth therein, the authors 945 retain all their rights. 947 This document and the information contained herein are provided on 948 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 949 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 950 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 951 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 952 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 953 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 954 FOR A PARTICULAR PURPOSE.