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