idnits 2.17.1 draft-sajassi-l2vpn-vpls-bridge-interop-03.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 -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(653): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(708): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(836): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(849): 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 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 923. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 891), 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. 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 51 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 (-02) exists of draft-rosen-l2vpn-mesh-failure-01 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-01 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 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: December 2006 15 VPLS Interoperability with CE Bridges 16 draft-sajassi-l2vpn-vpls-bridge-interop-03.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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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 (as describe in the previous section), a customer 282 Ethernet port at one site can be mapped into a customer VLAN (or 283 group of C-VLANs) at a different 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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 may PE 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-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 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 [Rosen-Mesh] defines a procedure for detection of partial mesh in 484 which 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. The 490 procedure defined in [Rosen-Mesh] is for detection of partial mesh 491 per service instance and in turn it relies on additional procedure 492 for PW failure detection such as BFD or VCCV. Given that there can 493 be ten (or even hundreds) of thousands of PWs in a PE, the 494 scalability aspects of this procedure needs to be worked out. Also 495 [Rosen-Mesh] acknowledges that many of the details regarding 496 operational aspects of such procedure are missing and need to be 497 worked out. 499 If the PE model, with bridge module as depicted in figure-2, is 500 used, then [P802.1ag] procedures could be used for detection of 501 partial-mesh of PWs. [p802.1ag] defines a set of procedures for 502 fault detection, verification, isolation, and notification per ESI. 504 Fault detection mechanism of [p8021.ag] can be used to perform 505 connectivity check among PEs belonging to a given VPLS instance. It 506 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 508 checks the integrity of a service instance end-to-end within an 509 administrative domain � e.g., from one AC at one end of the network 510 to another AC at the other end of the network. Therefore, its path 511 coverage includes bridge module within a PE and it is not limited to 512 just PWs. Furthermore, [P802.1ag] operates transparently over the 513 full-mesh of PWs for a given service instance since it operates at 514 the Ethernet level (and not at PW level). It should be noted that 515 [P802.1ag] assumes that the Ethernet links or LAN segments 516 connecting provider bridges are full-duplex and the failure in one 517 direction results in the failure of the whole link or LAN segment. 518 However, that is not the case for VPLS instance since a PW consists 519 of two uni-directional LSPs and one direction can fail independent 520 from the other causing inconsistent view of the full-mesh by the 521 participating PEs till the detected failure in one side is 522 propagated to the other side. 524 4.4. Multicast Traffic 526 VPLS follows a centralized model for multicast replication within an 527 ESI. VPLS relies on ingress replication. The ingress PE replicates 528 the multicast packet for each egress PE and sends it to the egress 529 PE using PtP PW over a unicast tunnel. VPLS operates on an overlay 530 topology formed by the full mesh of pseudo-wires. Thus, depending on 531 the underlying topology, the same datagram can be sent multiple 532 times down the same physical link. VPLS currently does not offer any 533 mechanisms to restrict the distribution of multicast or broadcast 534 traffic of an ESI throughout the network causing additional burden 535 on the ingress PE for unnecessary packet replication, causing 536 additional load on the MPLS core network, and causing additional 537 processing at the receiving PE where multicast packet is discarded. 539 One possible approach, to deliver multicast more efficiently over 540 VPLS network, is to include the use of IGMP snooping in order to 541 send the packet only to the PEs that have receivers for that 542 traffic, rather than to all the PEs in the VPLS instance. If the 543 customer bridge or its network has dual-home connectivity as 544 described in section 7, then for proper operation of IGMP snooping, 545 the PE must generate a �General Query� over that customer UNIs upon 546 receiving a customer topology change notification as described in 547 [IGMP-SNOOP]. A �General Query� by the PE results in proper 548 registration of the customer multicast MAC address(s) at the PE when 549 there is customer topology change. It should be noted that IGMP 550 snooping provides a solution for IP multicast packets and is not 551 applicable to general multicast data. 553 Using the IGMP-snooping as described, the ingress PE can select a 554 sub-set of PWs for packet replication; therefore, avoiding sending 555 multicast packets to the egress PEs that don�t need them. However, 556 the replication is still performed by the ingress PE. In order to 557 avoid, replication at ingress PE, one may want to use multicast 558 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 560 distribution trees (MDTs) in the provider core network; however, 561 this comes with its potential pitfalls. If the MDT is used for all 562 multicast traffic of a given customer, then this results in customer 563 multicast and unicast traffic to be forwarded on different PWs and 564 even on a different physical topology within the provider network. 565 This is a serious issue for customer bridges because customer BPDUs, 566 which are multicast data, can take a different path through the 567 network than the unicast data. Situations might arise where either 568 unicast OR multicast connectivity is lost. If unicast connectivity 569 is lost, but multicast forwarding continues to work, the customer 570 spanning tree would not take notice which results in loss of its 571 unicast traffic. Similarly, if multicast connectivity is lost, but 572 unicast is working, then the customer spanning tree will activate 573 the blocked port which may result in loop within the customer 574 network. Therefore, the MDT cannot be used for both customer 575 multicast control and data traffic. If it is used, it should only be 576 limited to customer data traffic. However, there can be potential 577 issue even when it is used for customer data traffic since the MDT 578 doesn�t fit the PE model described in Figure-1 (it operates 579 independently from the full-mesh of PWs that correspond to an S- 580 VLAN). It is also not clear how CFM procedures (802.1ag) used for 581 ESI integrity check (e.g., per service instance) can be applied to 582 check the integrity of the customer multicast traffic over the 583 provider MDT. Because of these potential issues, the specific 584 applications of the provider MDT to customer multicast traffic shall 585 be documented and its limitations be clearly specified. 587 5. Optional Issues 589 5.1. Customer Network Topology Changes 591 A single CE or a customer network can be connected to a provider 592 network using more than one User-Network Interface (UNI). 593 Furthermore, a single CE or a customer network can be connected to 594 more than one provider network. [L2VPN-REQ] provides some examples 595 of such customer network connectivity that are depicted in the 596 figure below. Such network topologies are designed to protect 597 against the failure or removal of network components with the 598 customer network and it is assumed that the customer leverages the 599 spanning tree protocol to protect against these cases. Therefore, in 600 such scenarios, it is important to flush customer MAC addresses in 601 the provider network upon the customer topology change to avoid 602 black holing of customer frames. 604 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 606 +----------- +--------------- 607 | | 608 +------+ +------+ +------+ +------+ 609 | CE |-----| PE | | CE |-----| PE | 610 |device| |device| |device| |device| SP network 611 +------+\ +------+ +------+\ +------+ 612 | \ | | \ | 613 |Back \ | |Back \ +--------------- 614 |door \ | SP network |door \ +--------------- 615 |link \ | |link \ | 616 +------+ +------+ +------+ +------+ 617 | CE | | PE | | CE | | PE | 618 |device|-----|device| |device|-----|device| SP network 619 +------+ +------+ +------+ +------+ 620 | | 621 +------------ +--------------- 622 (a) (b) 624 Figure 3. Combination of Dual-Homing and Backdoor Links for CE 625 Devices 627 The customer networks use their own instances of spanning tree 628 protocol to configure and partition their active topology, so that 629 the provider connectivity doesn�t result in data loop. 630 Reconfiguration of a customer�s active topology can result in the 631 apparent movement of customer end stations from the point of view of 632 the PEs. However, the requirement for mutual independence of the 633 distinct ESIs that can be supported by a single provider spanning 634 tree active topology does not permit either the direct receipt of 635 provider topology change notifications from the CEs or the use of 636 received customer spanning tree protocol topology change 637 notifications to stimulate topology change signaling on a provider 638 spanning tree. 640 To address this issue, [P802.1ad] requires that customer topology 641 change notification to be detected at the ingress of the S-VLAN 642 bridge component and the S-VLAN bridge transmits a Customer Change 643 Notification (CCN) BPDU tagged with the S-VLAN ID associated with 644 that service instance and a destination MAC address as specified in 645 the block of 16 reserved multicast MAC addresses. Upon receiving the 646 CCN, the provider bridge will flush all the customer MAC addresses 647 associated with that S-VLAN ID on all the provider bridge interfaces 648 except the one that the CCN message is received from. 650 Based on the provider bridge model depicted in figure (1), there are 651 two methods of propagating the CCN message over the VPLS network. 652 The first method is to translate the in-band CCN message into an 653 out-of-band �MAC Address Withdrawal� message as specified in [VPLS- 654 LDP] and the second method is to treat the CCN message as customer 655 data and pass it transparently over the set of PWs associated with 656 that VPLS instance. The second method is recommended because of ease 657 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 659 of interoperability between the bridge and the LAN emulation modules 660 of the PE. 662 5.2. Redundancy 664 [VPLS-LDP] talks about dual-homing of a given u-PE to two n-PEs over 665 a provider MPLS access network to provide protection against link 666 and node failure � e.g., in case the primary n-PE fails or the 667 connection to it fails, then the u-PE uses the backup PWs to reroute 668 the traffic to the backup n-PE. Furthermore, it discusses the 669 provision of redundancy when a provider Ethernet access network is 670 used and how any arbitrary access network topology (not just limited 671 to hub-and-spoke) can be supported using the provider�s MSTP 672 protocol and how the provider MSTP for a given access network can be 673 confined to that access network and operate independently from MSTP 674 protocols running in other access networks. 676 In both types of redundancy mechanisms (Ethernet versus MPLS access 677 networks), only one n-PE is active for a given VPLS instance at any 678 time. In case of an Ethernet access network, core-facing PWs (for a 679 VPLS instance) at the n-PE are blocked by the MSTP protocol; 680 whereas, in case of a MPLS access network, the access-facing PW is 681 blocked at the u-PE for a given VPLS instance. 683 -------------------------+ Provider +------------------------- 684 . Core . 685 +------+ . . +------+ 686 | n-PE |======================| n-PE | 687 Provider | (P) |---------\ /-------| (P) | Provider 688 Access +------+ ._ \ / . +------+ Access 689 Network . \/ . Network 690 (1) +------+ . /\ . +------+ (2) 691 | n-PE |----------/ \--------| n-PE | 692 | (B) |----------------------| (B) |_ 693 +------+ . . +------+ 694 . . 695 ------------------------+ +------------------------- 697 Figure 4. Bridge Module Model 699 Figure-4 shows two provider access networks each with two n-PEs 700 where the n-PEs are connected via a full mesh of PWs for a given 701 VPLS instance. As shown in the figure, only one n-PE in each access 702 network is serving as a Primary PE (P) for that VPLS instance and 703 the other n-PE is serving as the backup PE (B). In this figure, each 704 primary PE has two active PWs originating from it. Therefore, when a 705 multicast, broadcast, and unknown unicast frame arrives at the 706 primary n-PE from the access network side, the n-PE replicates the 707 frame over both PWs in the core even though it only needs to send 708 the frames over a single PW (shown with �==� in the figure) to the 709 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 711 primary n-PE on the other side. This is an unnecessary replication 712 of the customer frames that consumes core-network bandwidth (half of 713 the frames get discarded at the receiving n-PE). This issue gets 714 aggravated when there are more than two n-PEs per provider access 715 network � e.g., if there are three n-PEs or four n-PEs per access 716 network, then 67% or 75% of core-BW for multicast, broadcast and 717 unknown unicast are respectively wasted. 719 Therefore, it is recommended to have a protocol among n-PEs that can 720 disseminate the status of PWs (active or blocked) among themselves 721 and furthermore to have it tied up with the redundancy mechanism 722 such that per VPLS instance the status of active/backup n-PE gets 723 reflected on the corresponding PWs emanating from that n-PE. 725 The above discussion was centered on the lack of efficiency with 726 regards to packet replication over MPLS core network for current 727 VPLS redundancy mechanism. Another important issue to consider is 728 the interaction between customer and service provider redundancy 729 mechanisms especially when customer devices are IEEE bridges. If CEs 730 are IEEE bridges, then they can run RSTP/MSTP protocols, RSTP 731 convergence and detection time is much faster than its predecessor 732 (IEEE 802.1D STP which is obsolete). Therefore, if the provider 733 network offers VPLS redundancy mechanism, then it should provide 734 transparency to the customer�s network during a failure within its 735 network � e.g., the failure detection and recovery time within the 736 service provider network to be less than the one in the customer 737 network. If this is not the case, then a failure within the provider 738 network can result in unnecessary switch-over and temporary 739 flooding/loop within the customer�s network that is dual homed. 741 5.3. MAC Address Learning 743 When customer devices are routers, servers, or hosts, then the 744 number of MAC addresses per customer sites is very limited (most 745 often one MAC address per CE). However, when CEs are bridges, then 746 there can be many customer MAC addresses (e.g., hundreds of MAC 747 addresses) associated with each CE. 749 [P802.1ad] has devised a mechanism to alleviate MAC address learning 750 within provider Ethernet networks that can equally be applied to 751 VPLS networks. This mechanism calls for disabling MAC address 752 learning for an S-VLAN (or a service instance) within a provider 753 bridge (or PE) when there is only one ingress and one egress port 754 associated with that service instance on that PE. In such cases, 755 there is no need to learn customer MAC addresses on that PE since 756 the path through that PE for that service instance is fixed. For 757 example, if a service instance is associated with four CEs at four 758 different sites, then the maximum number of provider bridges (or 759 PEs), that need to participate in that customer MAC address 760 learning, is only three regardless of how many PEs are in the path 761 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 763 of that service instance. This mechanism can reduce the number of 764 MAC addressed learned in a H-VPLS with QinQ access configuration. 766 If the provider access network is of type Ethernet (e.g., IEEE 767 802.1ad-based network), then the MSTP protocol can be used to 768 partition access network into several loop-free spanning tree 769 topologies where Ethernet service instances (S-VLANs) are 770 distributed among these tree topologies. Furthermore, GVRP can be 771 used to limit the scope of each service instance to a subset of its 772 associated tree topology (and thus limiting the scope of customer 773 MAC address learning to that sub-tree). Finally, the MAC address 774 disabling mechanism (described above) can be applied to that sub- 775 tree, to further limit the number of nodes (PEs) on that sub-tree 776 that need to learn customer MAC addresses for that service instance. 778 Furthermore, [p802.1ah] provides the capability of encapsulating 779 customers� MAC addresses within the provider MAC header. A u-PE 780 capable of this functionality can reduce the number of MAC addressed 781 learned significantly within the provider network for H-VPLS with 782 QinQ access as well as H-VPLS with MPLS access. 784 6. Interoperability with 802.1ad Networks 786 [VPLS-LDP] discusses H-VPLS provider-network topologies with both 787 Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is 788 of paramount importance to ensure seamless interoperability between 789 these two types of networks. 791 Provider bridges as specified in [P802.1ad] are intended to operate 792 seamlessly with customer bridges and provide the required services. 793 Therefore, if a PE is modeled based on Figures 1&2 which includes a 794 [802.1ad] bridge module, then it should operate seamlessly with 795 Provider Bridges given that the issues discussed in this draft have 796 been taken into account. 798 7. Acknowledgments 800 The authors would like to thank Norm Finn for his comments and 801 feedbacks. 803 8. Security Considerations 805 There are no additional security aspects beyond that of VPLS/H-VPLS 806 that needs to be discussed here. 808 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 810 9. Normative References 812 [L2VPN-REQ] Agustyn, W. et al, "Service Requirements for Layer-2 813 Provider Provisioned Virtual Provider Networks", work in progress 815 [L2VPN-FRWK] Andersson, L. and et al, "Framework for Layer 2 Virtual 816 Private Networks (L2VPNs)", Work in Progress 818 [VPLS-LDP] Lasserre, M. and et al, "Virtual Private LAN Services 819 over MPLS", work in progress 821 [P802.1ad] IEEE Draft P802.1ad/D2.4 �Virtual Bridged Local Area 822 Networks: Provider Bridges�, Work in progress, September 2004 824 [P802.1ag] IEEE Draft P802.1ag/D0.1 �Virtual Bridge Local Area 825 Networks: Connectivity Fault Management�, Work in Progress, October 826 2004 828 10. Informative References 830 [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS) ", work in 831 progress, October 2004 833 [MFA-Ether] Sajassi, A. and et al, �Ethernet Service Interworking 834 Over MPLS�, Work in Progress, September 2004 836 [Rosen-Mesh] �Detecting and Reacting to Failures of the Full Mesh in 837 IPLS and VPLS�,draft-rosen-l2vpn-mesh-failure-01.txt, March 2004 839 [PWE3-Ethernet] "Encapsulation Methods for Transport of Ethernet 840 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 841 01.txt, Work in progress, November 2002. 843 [802.1D-REV] IEEE Std. 802.1D-2003 �Media Access Control (MAC) 844 Bridges�. 846 [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area 847 Networks". 849 [IGMP-SNOOP] Christensen, M. and et al, �Considerations for IGMP and 850 MLD Snooping Switches�, Work in progress, May 2004 852 [Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, �L2VPN OAM 853 Requirements and Framework�, Work in progress, July 2006 855 11. Authors' Addresses 857 Ali Sajassi 858 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 860 Cisco Systems, Inc. 861 170 West Tasman Drive 862 San Jose, CA 95134 863 Email: sajassi@cisco.com 865 Yetik Serbest 866 SBC Labs 867 9505 Arboretum Blvd. 868 Austin, TX 78759 869 Email: yetik_serbest@labs.sbc.com 871 Frank Brockners 872 Cisco Systems, Inc. 873 Hansaallee 249 874 40549 Duesseldorf 875 Germany 876 Email: fbrockne@cisco.com 878 Dinesh Mohan 879 Nortel Networks 880 3500 Carling Ave 881 Ottawa, ON K2H8E9 882 Email: mohand@nortel.com 884 12. Intellectual Property Considerations 886 This document is being submitted for use in IETF standards 887 discussions. 889 13. Full Copyright Statement 891 Copyright (C) The Internet Society (2006). 893 This document is subject to the rights, licenses and restrictions 894 contained in BCP 78, and except as set forth therein, the authors 895 retain all their rights. 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 900 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 901 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 902 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 907 14. IPR Notice 909 The IETF takes no position regarding the validity or scope of any 910 Intellectual Property Rights or other rights that might be claimed to 911 pertain to the implementation or use of the technology described in 912 this document or the extent to which any license under such rights 913 might or might not be available; nor does it represent that it has 914 made any independent effort to identify any such rights. Information 915 on the procedures with respect to rights in RFC documents can be 916 found in BCP 78 and BCP 79. 918 Copies of IPR disclosures made to the IETF Secretariat and any 919 assurances of licenses to be made available, or the result of an 920 attempt made to obtain a general license or permission for the use of 921 such proprietary rights by implementers or users of this 922 specification can be obtained from the IETF on-line IPR repository at 923 http://www.ietf.org/ipr. 925 The IETF invites any interested party to bring to its attention any 926 copyrights, patents or patent applications, or other proprietary 927 rights that may cover technology that may be required to implement 928 this standard. Please address the information to the IETF at ietf 929 ipr@ietf.org.