idnits 2.17.1 draft-sajassi-l2vpn-vpls-bridge-interop-00.txt: -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(189): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(290): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(561): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(683): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(774): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(925): 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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-sajassi-l2vpn-vpls-bridge-interop-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-sajassi-l2vpn-vpls-bridge-interop-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-sajassi-l2vpn-vpls-bridge-interop-', but the file name used is 'draft-sajassi-l2vpn-vpls-bridge-interop-00' == There are 50 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 17) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 2004) is 7127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MEF-Ethernet' is mentioned on line 186, but not defined == Missing Reference: 'VPLS-APP' is mentioned on line 822, but not defined -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MFA-Ether' == Outdated reference: A later version (-02) exists of draft-rosen-l2vpn-mesh-failure-01 -- Possible downref: Normative reference to a draft: ref. 'Rosen-Mesh' == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMP-SNOOP' Summary: 5 errors (**), 1 flaw (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Document Ali Sajassi 2 Provider Provisioned VPN Working Group Cisco Systems 3 draft-sajassi-l2vpn-vpls-bridge-interop- 4 00.txt Yetik Serbest 5 SBC Communications 7 Frank Brockners 8 Cisco Systems 9 Expires: April 2005 October 2004 11 VPLS Interoperability with CE Bridges 12 draft-sajassi-l2vpn-vpls-bridge-interop-00.txt 14 1. 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 2. 36 Abstract 38 One of the main motivations behind VPLS is its ability to provide 39 connectivity not only among customer routers and servers/hosts but 40 also among customer bridges. If only connectivity among customer IP 41 routers/hosts was desired, then IPLS solution [IPLS] could have been 42 used. The strength of the VPLS solution is that it can provide 43 connectivity to both bridge and non-bridge types of CE devices. VPLS 44 is expected to deliver the same level of service that current 45 enterprise users are accustomed to from their own enterprise bridged 46 networks today or the same level of service that they receive from 47 their Ethernet Service Providers using IEEE 802.1ad-based networks 48 [P802.1ad] (or its predecessor � QinQ-based network). 50 When CE devices are IEEE bridges, then there are certain issues and 51 challenges that need to be accounted for in a VPLS network. Majority 52 of these issues have currently been addressed in IEEE 802.1ad 53 standard for provider bridges and they need to be addressed for VPLS 55 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 57 networks. This draft discusses these issues and wherever possible, 58 the recommended solutions to these issues. 60 3. 61 Conventions 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 67 Placement of this Memo in Sub-IP Area 69 RELATED DOCUMENTS 71 www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn-requirements- 72 02.txt 73 www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2-framework-05.txt 75 www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-05.txt 77 WHERE DOES THIS FIT IN THE PICTURE OF THE ROUTING WORK 79 L2VPN 81 WHY IS IT TARGETED AT THIS WG 83 This draft describes interoperability issues with customer bridges 84 in a VPLS network. 86 JUSTIFICATION 88 Existing Internet drafts specify how to provide multipoint Ethernet 89 services over MPLS (VPLS). This draft describes some of the issues 90 associated with the provision of such multipoint services when 91 customer devices are bridges. 93 Table of Contents 95 1. Status of this Memo.............................................1 96 2. Abstract........................................................1 97 3. Conventions.....................................................2 98 4. Overview........................................................3 99 5. Ethernet Service Instance.......................................3 100 5.1. Attachment Circuits Mapping to an ESI.........................5 101 6. VPLS-Capable PE Model...........................................7 102 7. CE Bridge Protocol Handling.....................................9 103 7.1. Customer Network Topology Changes............................10 104 8. Partial-mesh of Pseudowires....................................12 105 9. Redundancy.....................................................13 107 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 109 10. MAC Address Learning..........................................14 110 11. Multicast Traffic.............................................15 111 12. Interoperability with 802.1ad Networks........................16 112 13. Acknowledgments...............................................17 113 14. Security Considerations.......................................17 114 15. Full Copyright Statement......................................17 115 16. IPR Notice....................................................17 116 17. References....................................................18 117 18. Authors' Addresses............................................19 119 4. 120 Overview 122 Virtual Private LAN Service is a LAN emulation service intended for 123 providing connectivity between geographically dispersed customer 124 sites across MAN/WAN (over MPLS/IP) network(s), as if they were 125 connected using a LAN. One of the main motivations behind VPLS is 126 its ability to provide connectivity not only among customer routers 127 and servers/hosts but also among customer bridges. If only 128 connectivity among customer IP routers/hosts was desired, then IPLS 129 solution [IPLS] could have been used. The strength of the VPLS 130 solution is that it can provide connectivity to both bridge and non- 131 bridge types of CE devices. VPLS is expected to deliver the same 132 level of service that current enterprise users are accustomed to 133 from their own enterprise bridged networks today or the same level 134 of service that they receive from their Ethernet Service Providers 135 using IEEE 802.1ad-based networks [P802.1ad] (or its predecessor � 136 QinQ-based network). 138 When CE devices are IEEE bridges, then there are certain issues and 139 challenges that need to be accounted for in a VPLS network. Majority 140 of these issues have currently been addressed in IEEE 802.1ad 141 standard for provider bridges and they need to be addressed for VPLS 142 networks. This draft discusses these issues and wherever possible, 143 the recommended solutions to these issues. It also discusses 144 interoperability issues between VPLS and IEEE 802.1ad networks when 145 the end-to-end service spans across both types of networks, as 146 outlined in [VPLS-LDP]. 148 5. 149 Ethernet Service Instance 151 Before starting the discussion of bridging issues, it is important 152 to first clarify the Ethernet Service definition. The term �VPLS� is 153 used for both: the network architecture that provides a multipoint- 154 Ethernet service as well as for the service itself. Also sometimes, 155 it refers to the end-to-end network or service between different 156 customer sites as long as a portion of the network is MPLS/IP. For 158 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 160 better clarity, we differentiate between its usage as network versus 161 service by using the terms VPLS network and VPLS instance 162 respectively. Furthermore, we confine VPLS (both network and 163 service) to only the portion of the end-to-end network that spans 164 across an MPLS/IP network. For an end-to-end service (among 165 different sites of a given customer), we use the term �Ethernet 166 Service Instance� or ESI. 168 [MFA-Ether] defines the Ethernet Service Instance (ESI) as an 169 association of two or more Attachment Circuits (ACs) over which an 170 Ethernet service is offered to a given customer. An AC can be either 171 a UNI or a NNI; furthermore, it can be an Ethernet interface or a 172 VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface. 173 If an ESI is associated with more than two ACs, then it is a 174 multipoint ESI. In this document, where ever the keyword ESI is 175 used, it means multipoint ESI, unless it is stated otherwise. 177 An ESI can correspond to a VPLS instance if its associated ACs are 178 only connected to a VPLS network or an ESI can correspond to a 179 Service VLAN if its associated ACs are only connected to a Provider- 180 Bridged network [P802.1ad]. Furthermore, an ESI can correspond to 181 both a VPLS instance and a Service VLAN if its associated ACs are 182 connected to both VPLS and Provider-Bridged networks. An ESI can 183 span across different networks (e.g., IEEE 802.1ad and VPLS) 184 belonging to the same or different administrative domains. 186 [MEF-Ethernet] defines an Ethernet Virtual Connection (EVC) as an 187 association of two or more UNIs, where the UNI is a standard 188 Ethernet interface and point of demarcation between Customer 189 Equipment and service provider�s network. An EVC is either point-to- 190 point or multipoint-to-multipoint. It should be noted that an ESI 191 cannot be directly compare to an EVC per MEF definition since an ESI 192 is associated with a set of ACs; whereas, an EVC is associated with 193 a set of UNIs. However, if one limits the ACs associated with a 194 given ESI to only UNIs, then for a multipoint connection, an ESI 195 corresponds to a multipoint-to-multipoint EVC. 197 An ESI (either for a point-to-point or multipoint connectivity) is 198 associated with a forwarding path within the service provider�s 199 network and that is different from an Ethernet Class of Service 200 (CoS) which is associated with the frame Quality-of-Service 201 treatment by each node along the path defined by the ESI. An ESI can 202 have one or more CoS associated with it. 204 An ESI most often represents a customer or a specific service 205 requested by a customer. Since traffic isolation among different 206 customers (or their associated services) is of paramount importance 207 in service provider networks, its realization shall be done such 208 that it provides a separate MAC address domain and broadcast domain 209 per ESI. A separate MAC address domain is provided by using a 211 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 213 separate filtering database per ESI (for both VPLS and IEEE 802.1ad 214 networks) and separate broadcast domain is provided by using a full- 215 mesh of PWs per ESI over the IP/MPLS core in a VPLS network and a 216 dedicated Service VLAN per ESI in an IEEE 802.1ad network. 218 Different Ethernet AC types can be associated with an ESI. For 219 example, an ESI can be associated with only physical Ethernet ports, 220 VLANs, or a combination of two (e.g., one end of the service be 221 associated with physical Ethernet ports and the other end be 222 associated with VLANs). In the VPLS terminology, unqualified and 223 qualified learning is used to refer to port-based and vlan-based 224 operation respectively. Based on this VPLS definition, it is not 225 clear how to classify a customer service where traffic from some of 226 its sites (that is untagged and port-based) needs to be mapped to a 227 VLAN at another site. In general, the mapping of a customer port or 228 VLAN to a given service instance is a local function performed by 229 the local PE and the service provisioning shall accommodate it. In 230 other words, there is no reason to restrict and limit an ESI to have 231 only port-based ACs or to have only VLAN-based ACs. [P802.1ad] 232 allows for each customer AC to be mapped independently to an ESI 233 which provides better service offering to Enterprise customers. For 234 better and more flexible service offerings and for interoperability 235 purposes between VPLS and 802.1ad networks, it is imperative that 236 both networks offer the same capabilities in terms of customer ACs 237 mapping to the customer service instance. 239 5.1. 240 Attachment Circuits Mapping to an ESI 242 The following table lists possible mappings that can exist between 243 customer ACs and its associated ESI � this table is extracted from 244 [MFA-Ether]. As it can be seen, there are several possible ways to 245 perform such mapping. In the first scenario, it is assumed that an 246 Ethernet physical port only carries untagged traffic and all the 247 traffic is mapped to the corresponding service instance or ESI. This 248 is referred to as �port-based w/ untagged traffic�. In the second 249 scenario, it is assumed that an Ethernet physical port carries both 250 tagged and untagged traffic and all that traffic is mapped to the 251 corresponding service instance or ESI. This is referred to as �port- 252 based w/ tagged and untagged traffic�. In the third scenario, it is 253 assumed that only a single VLAN is mapped to the corresponding 254 service instance or ESI (referred to as VLAN mapping). Finally, in 255 the fourth scenario, it is assumed that a group of VLANs from the 256 Ethernet physical interface is mapped to the corresponding service 257 instance or ESI. 259 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 261 =================================================================== 262 Ethernet I/F & Associated Service Instance(s) 263 ------------------------------------------------------------------- 264 Port-based port-based VLAN VLAN 265 Untagged tagged & mapping bundling 266 untagged 267 ------------------------------------------------------------------- 268 Port-based Y N Y(Note-1) N 269 untagged 271 Port-based N Y Y(Note-2) Y 272 tagged & 273 untagged 275 VLAN Y(Note-1) Y(Note-2) Y Y(Note-3) 276 Mapping 278 VLAN N Y Y(Note-3) Y 279 Bundling 280 =================================================================== 282 Note-1: In this asymmetric mapping scenario, it is assumed that the 283 CE device with �VLAN mapping� AC is a device capable of supporting 284 [802.1Q] frame format. 286 Note-2: In this asymmetric mapping scenario, it is assumed that the 287 CE device with �VLAN mapping� AC is a device that can support 288 [P802.1ad] frame format because it will receive Ethernet frames 289 with two tags; where the outer tag is S-VLAN and the inner tag is C- 290 VLAN received from �port-based� AC. One application example for such 291 CE device is in feature server for DSL aggregation over Metro 292 Ethernet network. 294 Note�3: In this asymmetric mapping scenario, it is assumed that the 295 CE device with �VLAN mapping� AC can support the [P802.1ad] frame 296 format because it will receive Ethernet frames with two tags; where 297 the outer tag is S-VLAN and the inner tag is C-VLAN received from 298 �VLAN bundling� AC. 300 If a PE uses an S-VLAN tag for a given ESI (either by adding an S- 301 VLAN tag to customer traffic or by replacing a C-VLAN tag with a S- 302 VLAN tag), then the frame format and EtherType for S-VLAN shall 303 adhere to [P802.1ad]. 305 As mentioned before, the mapping function between the customer AC 306 and its associated ESI is a local function and thus when the AC is a 307 single customer VLAN, it is possible to map different customer VLANs 308 at different sites to a single ESI � e.g., no coordination is 309 required among different customer sites for that service instance 310 and each customer site can independently identify the same service 311 instance via a different VLAN pertinent to its local site. 313 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 315 When a port-based or a VLAN-bundling is used, then if the PE uses an 316 additional S-VLAN tag to mark the customer traffic received over 317 that AC as belonging to a given ESI, then that PE shall strip the S- 318 VLAN tag before sending the customer frames over the same AC. 319 However, when VLAN-mapping mode is used at an AC and if the PE uses 320 S-VLAN tag locally, then if the Ethernet interface is a UNI, the 321 tagged frames over this interface shall have a frame format based on 322 [802.1Q] and the PE shall translate the customer tag (C-VLAN) into 323 the provider tag (S-VLAN) upon receiving a frame from the customer. 325 6. 326 VPLS-Capable PE Model 328 [L2VPN-FRWK] defines three models for VPLS-capable PE (VPLS-PE) 329 based on the bridging functionality that needs to be supported by 330 the PE. If the CE devices can include both routers/hosts and IEEE 331 bridges, then the second model is the most suitable and adequate one 332 and it is consistent with IEEE standards for Provider Bridges 333 [P802.1ad]. We briefly describe the second model and then elaborate 334 upon this model to show its sub-components based on [P802.1ad] 335 Provider Bridge model. Finally, we show how this model can be used 336 to support all the different services and AC mapping (both symmetric 337 and asymmetric) described in the previous section. 339 As described in [L2VPN-FRWK], the second model for VPLS-PE contains 340 a single bridge module supporting all the VPLS instances on that PE 341 where each VPLS instance is represented by a unique VLAN inside that 342 bridge module (also known as Service VLAN or S-VLAN). The bridge 343 module has at least a single �Emulated LAN� interface over which 344 each VPLS instance is represented by a unique S-VLAN tag. Each VPLS 345 instance can consist of a set of PWs and its associated forwarder 346 corresponding to a single Virtual LAN (VLAN) as depicted in the 347 following figure. Thus, sometimes it is referred to as V-LAN 348 emulation. 350 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 352 +----------------------------------------+ 353 | VPLS-capable PE model | 354 | +---------------+ +------+ | 355 | | | |VPLS-1|------------ 356 | | |==========|Fwdr |------------ PWs 357 | | Bridge ------------ |------------ 358 | | | S-VLAN-1 +------+ | 359 | | Module | o | 360 | | | o | 361 | | (802.1ad | o | 362 | | bridge) | o | 363 | | | o | 364 | | | S-VLAN-n +------+ | 365 | | ------------VPLS-n|------------- 366 | | |==========| Fwdr |------------- PWs 367 | | | ^ | |------------- 368 | +---------------+ | +------+ | 369 | | | 370 +-------------------------|--------------+ 371 LAN emulation Interface 373 Figure 1. VPLS-capable PE Model 375 Customer frames associated with a given ESI, carry the S-VLAN ID for 376 that ESI over the LAN emulation interface. The S-VLAN ID is stripped 377 before transmitting the frames over the set of PWs associated with 378 that VPLS instance (assuming raw mode PW is used as specified in 379 [PWE3-Ethernet]). 381 The bridge module can itself consist of one or two sub-components 382 depending on the functionality that it needs to perform. The 383 following figure depicts the model for bridge module based on 384 [P802.1ad]. 386 +-------------------------------+ 387 | 802.1ad Bridge Module Model | 388 | | 389 +---+ | +------+ +-----------+ | 390 |CE |---------|C-VLAN|------| | | 391 +---+ | |bridge|------| | | 392 | +------+ | | | 393 | o | S-VLAN | | 394 | o | | | 395 | o | Bridge | | 396 +---+ | +------+ | | | 397 |CE |---------|C-VLAN|------| | | 398 +---+ | |bridge|------| | | 399 | +------+ +-----------+ | 400 +-------------------------------+ 402 Figure 2. The Model of 802.1ad Bridge Module 404 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 406 The S-VLAN bridge component is always required and it is responsible 407 for tagging customer frames with S-VLAN tags in the ingress 408 direction (from customer UNIs) and removing S-VLAN tags in the 409 egress direction (toward customer UNIs). It is also responsible for 410 running the provider�s bridge protocol such as RSTP, MSTP, GVRP, 411 GMRP, etc. among provider bridges within a single administrative 412 domain. 414 The C-VLAN bridge component is required when the customer Attachment 415 Circuits are VLANs (aka C-VLANs). In such cases, the VPLS-capable PE 416 needs to participate in some of the customer�s bridging protocol 417 such as RSTP and MSTP. The reason that such participation is 418 required is because a customer VLAN (C-VLAN) at one site can be 419 mapped into a different C-VLAN at a different site or in case of 420 asymmetric mapping (as describe in the previous section), a customer 421 Ethernet port at one site can be mapped into a customer VLAN (or 422 group of C-VLANs) at a different site. 424 In scenarios where C-VLAN bridge component is required, then there 425 will be one such component per customer UNI port in order to avoid 426 local switching within the C-VLAN bridge component and thus limiting 427 local switching among different UNIs for the same customer to S-VLAN 428 bridge component. 430 The C-VLAN bridge component does service selection and 431 identification based on C-VLAN tags. Each frame from the customer 432 device is assigned to a C-VLAN and presented at one or more internal 433 port-based interfaces, each supporting a single service instance 434 that the customer desires to carry that C-VLAN. Similarly frames 435 from the provider network are assigned to an internal interface or 436 �LAN� (e.g, between C-VLAN and S-VLAN components) on the basis of 437 the S-VLAN tag. Since each internal interface supports a single 438 service instance, the S-VLAN tag can be, and is, removed at this 439 interface by the S-VLAN bridge component. If multiple C-VLANs are 440 supported by this service instance (e.g., VLAN bundling), then the 441 frames will have already been tagged with C-VLAN tags. If a single 442 C-VLAN is supported by this service instance (e.g., VLAN mapping), 443 then the frames shall not have tagged with C-VLAN tag since C-VLAN 444 can be derived from the S-VLAN. The C-VLAN aware bridge component 445 applies a port VLAN ID (PVID) to untagged frames received on each 446 internal �LAN�, allowing full control over the delivery of frames 447 for each C-VLAN through the Customer UNI Port. 449 7. 450 CE Bridge Protocol Handling 452 When a VPLS-capable PE is connected to a CE bridge, then depending 453 on the type of Attachment Circuit, different protocol handling may 454 be required by the bridge module of the PE. [P802.1ad] states that 455 when a PE is connected to a CE bridge, then the service offered by 457 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 459 the PE may appear to specific customer protocols running on the CE 460 in one of the four ways: 462 i) Transparent to the operation of the protocol among CEs of 463 different sites using the service provided, appearing as an 464 individual LAN without bridges; or, 465 i 466 i) Discarding frames, acting as a non-participating barrier to the 467 operation of the protocol; or, 468 i 469 i 470 i) Peering, with a local protocol entity at the point of provider 471 ingress and egress, participating in and terminating the 472 operation of the protocol; or, 473 iv) Participation in individual instances of customer protocols. 475 For example, when an Attachment Circuit is port-based, then the 476 bridge module of the PE can operate transparently with respect to 477 the CE�s RSTP/MSTP protocols (and thus no C-VLAN component is 478 required for that customer UNI). However, when an Attachment Circuit 479 is VLAN-based (either VLAN mapping or VLAN bundling), then the 480 bridge module of the PE needs to peer with the RSTP/MSTP protocols 481 running on the CE (and thus the C-VLAN bridge component is 482 required). There are also protocols that require peering but are 483 independent from the type of Attachment Circuit. An example of such 484 protocol is link aggregation protocol [802.3ad]; however, one can 485 argue that this is a media-dependent protocol as its name implies. 486 Therefore, the peering requirement can be generalized such that the 487 media-independent protocols (RSTP/MSTP, CFM, etc) that require 488 peering are for VLAN-based Attachment Circuit. 490 [P802.1ad] reserves a block of 16 MAC addresses for the operation of 491 C-VLAN and S-VLAN bridge components and it shows which of these 492 reserved MAC addresses are only for C-VLAN bridge component and 493 which ones are only for S-VLAN bridge component and which ones apply 494 to both C-VLAN and S-VLAN components. 496 7.1. 497 Customer Network Topology Changes 499 A single CE or a customer network can be connected to a provider 500 network using more than one User-Network Interface (UNI). 501 Furthermore, a single CE or a customer network can be connected to 502 more than one provider network. [L2VPN-REQ] provides some examples 503 of such customer network connectivity that are depicted in the 504 figure below. Such network topologies are designed to protect 505 against the failure or removal of network components with the 506 customer network and it is assumed that the customer leverages the 507 spanning tree protocol to protect against these cases. Therefore, in 508 such scenarios, it is important to flush customer MAC addresses in 509 the provider network upon the customer topology change to avoid 510 black holing of customer frames. 512 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 514 +----------- +--------------- 515 | | 516 +------+ +------+ +------+ +------+ 517 | CE |-----| PE | | CE |-----| PE | 518 |device| |device| |device| |device| SP network 519 +------+\ +------+ +------+\ +------+ 520 | \ | | \ | 521 |Back \ | |Back \ +--------------- 522 |door \ | SP network |door \ +--------------- 523 |link \ | |link \ | 524 +------+ +------+ +------+ +------+ 525 | CE | | PE | | CE | | PE | 526 |device|-----|device| |device|-----|device| SP network 527 +------+ +------+ +------+ +------+ 528 | | 529 +------------ +--------------- 530 (a) (b) 532 Figure 3. Combination of Dual-Homing and Backdoor Links for CE 533 Devices 535 The customer networks use their own instances of spanning tree 536 protocol to configure and partition their active topology, so that 537 the provider connectivity doesn�t result in data loop. 538 Reconfiguration of a customer�s active topology can result in the 539 apparent movement of customer end stations from the point of view of 540 the PEs. However, the requirement for mutual independence of the 541 distinct ESIs that can be supported by a single provider spanning 542 tree active topology does not permit either the direct receipt of 543 provider topology change notifications from the CEs or the use of 544 received customer spanning tree protocol topology change 545 notifications to stimulate topology change signaling on a provider 546 spanning tree. 548 To address this issue, [P802.1ad] requires that customer topology 549 change notification to be detected at the ingress of the S-VLAN 550 bridge component and the S-VLAN bridge transmits a Customer Change 551 Notification (CCN) BPDU tagged with the S-VLAN ID associated with 552 that service instance and a destination MAC address as specified in 553 the block of 16 reserved multicast MAC addresses. Upon receiving the 554 CCN, the provider bridge will flush all the customer MAC addresses 555 associated with that S-VLAN ID on all the provider bridge interfaces 556 except the one that the CCN message is received from. 558 Based on the provider bridge model depicted in figure (1), there are 559 two methods of propagating the CCN message over the VPLS network. 560 The first method is to translate the in-band CCN message into an 561 out-of-band �MAC Address Withdrawal� message as specified in [VPLS- 562 LDP] and the second method is to treat the CCN message as customer 563 data and pass it transparently over the set of PWs associated with 565 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 567 that VPLS instance. The second method is recommended because of ease 568 of interoperability between the bridge and the LAN emulation modules 569 of the PE. 571 8. 572 Partial-mesh of Pseudowires 574 The effect of a PW failure (resulting in creation of partial-mesh of 575 PWs) on the CE devices and their supported services should be well 576 known. If the CE devices belonging to an ESI are routers running 577 link state routing protocols that use LAN procedures over that ESI, 578 then a partial-mesh of PWs can cause �black holes� among the 579 selected set of routers. And if the CE devices belonging to an ESI 580 are IEEE bridges, then a partial-mesh of PWs can cause broadcast 581 storms in the customer and provider networks. Furthermore, it can 582 cause multiple copies of a single frame to be received by the CE 583 and/or PE devices. Therefore, it is of paramount importance to be 584 able to detect PW failure and to take corrective action to prevent 585 creation of partial-mesh of PWs. 587 [P802.1ag] defines a set of procedures for fault detection, 588 verification, isolation, and notification per ESI. However, these 589 procedures are not very suitable for detection and isolation of PW 590 failure for a number of reasons. 592 First, [P802.1ag] checks the integrity of a service instance end-to- 593 end within an administrative domain � e.g., from one AC at one end 594 of the network to another AC at the other end of the network. 595 Therefore, its path coverage includes bridge module within a PE and 596 it is not limited to just PWs. Furthermore, [P802.1ag] operates 597 transparently over the full-mesh of PWs for a given service instance 598 since it operates at the Ethernet level (and not at PW level). 600 Second, [P802.1ag] is basically a slow protocol intended to check 601 the integrity for a given service instance end-to-end. Therefore, 602 the detection time may be longer than the detection time needed for 603 loop prevention inside the customer network. Some Enterprise 604 customers running spanning tree protocols in their network require 605 loop detection time in order of tens of milliseconds. 607 Third, [P802.1ag] assume that the Ethernet links or LAN segments 608 connecting provider bridges are full-duplex and the failure in one 609 direction results in the failure of the whole link. However, that is 610 not the case for VPLS instance since a PW consists of two uni- 611 directional LSPs and one direction can fail independent from the 612 other causing inconsistent view of the full-mesh by the 613 participating PEs till the failure is detected and propagated to the 614 other PEs. 616 [Rosen-Mesh] defines a procedure for detection of partial mesh in 617 which each PE keeps track of the status of PW Endpoint Entities (EEs 619 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 621 - e.g., VPLS forwarders) for itself as wells the ones reported by 622 other PEs. Therefore, upon a PW failure, the PE that detects the 623 failure not only takes notice locally but it notifies other PEs 624 belonging to that service instance of such failure so that all the 625 participants PEs have a consistent view of the PW mesh. The 626 procedure defined in [Rosen-Mesh] is for detection of partial mesh 627 per service instance and in turn it relies on additional procedure 628 for PW failure detection such as BFD or VCCV. Given that there can 629 be ten or hundreds of thousands of PWs in a PE, the scalability 630 aspects of this procedure needs to be worked out. Also [Rosen-Mesh] 631 acknowledges that many of the details regarding operational aspects 632 of such procedure are missing and need to be worked out. 634 9. 635 Redundancy 637 [VPLS-LDP] talks about dual-homing of a given u-PE to two n-PEs over 638 a provider MPLS access network to provide protection against link 639 and node failure � e.g., in case the primary n-PE fails or the 640 connection to it fails, then the u-PE uses the backup PWs to reroute 641 the traffic to the backup n-PE. Furthermore, it discusses the 642 provision of redundancy when a provider Ethernet access network is 643 used and how any arbitrary access network topology (not just limited 644 to hub-and-spoke) can be supported using the provider�s MSTP 645 protocol and how the provider MSTP for a given access network can be 646 confined to that access network and operate independently from MSTP 647 protocols running in other access networks. 649 In both types of redundancy mechanisms (Ethernet versus MPLS access 650 networks), only one n-PE is active for a given VPLS instance at any 651 time. In case of an Ethernet access network, core-facing PWs (for a 652 VPLS instance) at the n-PE are blocked by the MSTP protocol; 653 whereas, in case of a MPLS access network, the access-facing PW is 654 blocked at the u-PE for a given VPLS instance. 656 -------------------------+ Provider +------------------------- 657 . Core . 658 +------+ . . +------+ 659 | n-PE |======================| n-PE | 660 Provider | (P) |---------\ /-------| (P) | Provider 661 Access +------+ ._ \ / . +------+ Access 662 Network . \/ . Network 663 (1) +------+ . /\ . +------+ (2) 664 | n-PE |----------/ \--------| n-PE | 665 | (B) |----------------------| (B) |_ 666 +------+ . . +------+ 667 . . 668 ------------------------+ +------------------------- 670 Figure 3. Bridge Module Model 672 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 674 Figure-3 shows two provider access networks each with two n-PEs 675 where the n-PEs are connected via a full mesh of PWs for a given 676 VPLS instance. As shown in the figure, only one n-PE in each access 677 network is serving as a Primary PE (P) for that VPLS instance and 678 the other n-PE is serving as the backup PE (B). In this figure, each 679 primary PE has two active PWs originating from it. Therefore, when a 680 multicast, broadcast, and unknown unicast frame arrives at the 681 primary n-PE from the access network side, the n-PE replicates the 682 frame over both PWs in the core even though it only needs to send 683 the frames over a single PW (shown with �==� in the figure) to the 684 primary n-PE on the other side. This is an unnecessary replication 685 of the customer frames that consumes core-network bandwidth (half of 686 the frames get discarded at the receiving n-PE). This issue gets 687 aggravated when there are more than two n-PEs per provider access 688 network � e.g., if there are three n-PEs or four n-PEs per access 689 network, then 67% or 75% of core-BW for multicast, broadcast and 690 unknown unicast are respectively wasted. 692 Therefore, it is important to have a protocol among n-PEs that can 693 disseminate the status of PWs (active or blocked) among themselves 694 and furthermore to have it tied up with the redundancy mechanism 695 such that per VPLS instance the status of active/backup n-PE gets 696 reflected on the corresponding PWs emanating from that n-PE. 698 The above discussion was centered on the lack of efficiency with 699 regards to packet replication over MPLS core network for current 700 VPLS redundancy mechanism. Another important issue to consider is 701 the interaction between customer and service provider redundancy 702 mechanisms especially when customer devices are IEEE bridges. If CEs 703 are IEEE bridges, then they can run RSTP/MSTP protocols, RSTP 704 convergence and detection time is much faster than its predecessor 705 (IEEE 802.1D STP which is obsolete). Therefore, if the provider 706 network offers VPLS redundancy mechanism, then it should provide 707 transparency to the customer�s network during a failure within its 708 network � e.g., the failure detection and recovery time within the 709 service provider network to be less than the one in the customer 710 network. If this is not the case, then a failure within the provider 711 network can result in unnecessary switch-over and temporary 712 flooding/loop within the customer�s network that is dual homed. 714 10. 715 MAC Address Learning 717 When customer devices are routers, servers, or hosts, then the 718 number of MAC addresses per customer sites is very limited (most 719 often one MAC address per CE). However, when CEs are bridges, then 720 there can be many customer MAC addresses (e.g., hundreds of MAC 721 addresses) associated with each CE. 723 [P802.1ad] has devised a mechanism to alleviate MAC address learning 724 within provider Ethernet networks that can equally be applied to 726 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 728 VPLS networks. This mechanism calls for disabling MAC address 729 learning for an S-VLAN (or a service instance) within a provider 730 bridge (or PE) when there is only one ingress and one egress port 731 associated with that service instance on that PE. In such cases, 732 there is no need to learn customer MAC addresses on that PE since 733 the path through that PE for that service instance is fixed. For 734 example, if a service instance is associated with four CEs at four 735 different sites, then the maximum number of provider bridges (or 736 PEs), that need to participate in that customer MAC address 737 learning, is only three regardless of how many PEs are in the path 738 of that service instance. 740 If the provider access network is of type Ethernet (e.g., IEEE 741 802.1ad-based network), then the MSTP protocol can be used to 742 partition access network into several loop-free spanning tree 743 topologies where Ethernet service instances (S-VLANs) are 744 distributed among these tree topologies. Furthermore, GVRP can be 745 used to limit the scope of each service instance to a subset of its 746 associated tree topology (and thus limiting the scope of customer 747 MAC address learning to that sub-tree). Finally, the MAC address 748 disabling mechanism (described above) can be applied to that sub- 749 tree, to further limit the number of nodes (PEs) on that sub-tree 750 that need to learn customer MAC addresses for that service instance. 752 11. 753 Multicast Traffic 755 VPLS follows a centralized model for multicast replication within an 756 ESI. VPLS relies on ingress replication. The ingress PE replicates 757 the multicast packet for each egress PE and sends it to the egress 758 PE using PtP PW over a unicast tunnel. VPLS operates on an overlay 759 topology formed by the full mesh of pseudo-wires. Thus, depending on 760 the underlying topology, the same datagram can be sent multiple 761 times down the same physical link. VPLS currently does not offer any 762 mechanisms to restrict the distribution of multicast or broadcast 763 traffic of an ESI throughout the network causing additional burden 764 on the ingress PE for unnecessary packet replication, causing 765 additional load on the MPLS core network, and causing additional 766 processing at the receiving PE where multicast packet is discarded. 768 One possible approach, to deliver multicast more efficiently over 769 VPLS network, is to include the use of IGMP snooping in order to 770 send the packet only to the PEs that have receivers for that 771 traffic, rather than to all the PEs in the VPLS instance. If the 772 customer bridge or its network has dual-home connectivity as 773 described in section 7, then for proper operation of IGMP snooping, 774 the PE must generate a �General Query� over that customer UNIs upon 775 receiving a customer topology change notification as described in 776 [IGMP-SNOOP]. A �General Query� by the PE results in proper 777 registration of the customer multicast MAC address(s) at the PE when 778 there is customer topology change. It should be noted that IGMP 780 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 782 snooping provides a solution for IP multicast packets and is not 783 applicable to general multicast data. 785 Using the IGMP-snooping as described, the ingress PE can select a 786 sub-set of PWs for packet replication; therefore, avoiding sending 787 multicast packets to the egress PEs that don�t need them. However, 788 the replication is still performed by the ingress PE. In order to 789 avoid, replication at ingress PE, one may want to use multicast 790 distribution trees (MDTs) in the provider core network; however, 791 this comes with its potential pitfalls. If the MDT is used for all 792 multicast traffic of a given customer, then this results in customer 793 multicast and unicast traffic to be forwarded on different PWs and 794 even on a different physical topology within the provider network. 795 This is a serious issue for customer bridges because customer BPDUs, 796 which are multicast data, can take a different path through the 797 network than the unicast data. Situations might arise where either 798 unicast OR multicast connectivity is lost. If unicast connectivity 799 is lost, but multicast forwarding continues to work, the customer 800 spanning tree would not take notice which results in distribution of 801 its data traffic. Similarly, if multicast connectivity is lost, but 802 unicast is working, then the customer spanning tree will activate 803 the blocked port which will result in loop within the customer 804 network. Therefore, the MDT cannot be used for both customer 805 multicast control and data traffic. If it is used, it should only be 806 limited to customer data traffic. However, there can be potential 807 issue even when it is used for customer data traffic since the MDT 808 doesn�t fit the PE model described in Figure-1 (it operates 809 independently from the full-mesh of PWs that correspond to an S- 810 VLAN). It is also not clear how CFM procedures (802.1ag) used for 811 ESI integrity check (e.g., per service instance) can be applied to 812 check the integrity of the customer multicast traffic over the 813 provider MDT. Because of these potential issues, the applicability 814 of the provider MDT to customer multicast traffic is for future 815 study. 817 12. 818 Interoperability with 802.1ad Networks 820 [VPLS-LDP] discusses H-VPLS provider-network topologies with both 821 Ethernet [P802.1ad] as well as MPLS access networks. Furthermore, 822 [VPLS-APP] discusses several examples and scenarios where the end-to- 823 end Ethernet service spans across both VPLS and Provider Bridged 824 [P802.1ad] networks. Therefore, it is of paramount importance to 825 ensure seamless interoperability between these two types of networks. 827 Provider bridges as specified in [P802.1ad] are intended to operate 828 seamlessly with customer bridges and provide the required services. 829 Therefore, if a PE is modeled based on Figures 1&2 that includes a 830 [802.1ad] bridge module, then it should operate seamlessly with 831 Provider Bridges. The issues discussed in this draft have been taken 832 into account. 834 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 836 13. 837 Acknowledgments 839 The authors would like to thank Norm Finn for his valuable comments. 841 14. 842 Security Considerations 844 Security aspects of this draft will be discussed at a later point. 846 15. 847 Full Copyright Statement 849 Copyright (C) The Internet Society (2001). All Rights Reserved. 850 This document and translations of it may be copied and furnished to 851 others, and derivative works that comment on or otherwise explain it 852 or assist in its implementation may be prepared, copied, published 853 and distributed, in whole or in part, without restriction of any 854 kind, provided that the above copyright notice and this paragraph 855 are included on all such copies and derivative works. However, this 856 document itself may not be modified in any way, such as by removing 857 the copyright notice or references to the Internet Society or other 858 Internet organizations, except as needed for the purpose of 859 developing Internet standards in which case the procedures for 860 copyrights defined in the Internet Standards process must be 861 followed, or as required to translate it into languages other than 862 English. 864 The limited permissions granted above are perpetual and will not be 865 revoked by the Internet Society or its successors or assigns. 867 This document and the information contained herein is provided on an 868 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 869 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 870 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 871 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 872 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 874 16. 875 IPR Notice 877 The IETF takes no position regarding the validity or scope of any 878 intellectual property or other rights that might be claimed to 879 pertain to the implementation or use of the technology described in 880 this document or the extent to which any license under such rights 881 might or might not be available; neither does it represent that it 882 has made any effort to identify any such rights. Information on the 883 IETF's procedures with respect to rights in standards-track and 884 standards-related documentation can be found in BCP-11. Copies of 885 claims of rights made available for publication and any assurance of 887 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 889 licenses to be made available, or the result of an attempt made to 890 obtain a general license or permission for the use of such 891 proprietary rights by implementors or users of this specification 892 can be obtained from the IETF Secretariat. 894 The IETF invites any interested party to bring to its attention any 895 copyrights, patents or patent applications, or other proprietary 896 rights which may cover technology that may be required to practice 897 this standard. Please address the information to the IETF Executive 898 Director. 900 17. 901 References 903 [L2VPN-REQ] Agustyn, W. et al, "Service Requirements for Layer-2 904 Provider Provisioned Virtual Provider Networks", work in progress 906 [L2VPN-FRWK] Andersson, L. and et al, "Framework for Layer 2 Virtual 907 Private Networks (L2VPNs)", Work in Progress 909 [VPLS-LDP] Lasserre, M. and et al, "Virtual Private LAN Services 910 over MPLS", work in progress 912 [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS) ", work in 913 progress, October 2004 915 [MFA-Ether] Sajassi, A. and et al, �Ethernet Service Interworking 916 Over MPLS�, Work in Progress, September 2004 918 [P802.1ad] IEEE Draft P802.1ad/D2.4 �Virtual Bridged Local Area 919 Networks: Provider Bridges�, Work in progress, September 2004 921 [P802.1ag] IEEE Draft P802.1ag/D0.1 �Virtual Bridge Local Area 922 Networks: Connectivity Fault Management�, Work in Progress, October 923 2004 925 [Rosen-Mesh] �Detecting and Reacting to Failures of the Full Mesh in 926 IPLS and VPLS�,draft-rosen-l2vpn-mesh-failure-01.txt, March 2004 928 [PWE3-Ethernet] "Encapsulation Methods for Transport of Ethernet 929 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 930 01.txt, Work in progress, November 2002. 932 [802.1D-REV] IEEE Std. 802.1D-2003 �Media Access Control (MAC) 933 Bridges�. 935 [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area 936 Networks". 938 [IGMP-SNOOP] Christensen, M. and et al, "Considerations for IGMP and 939 MLD Snooping Switches", Work in progress, May 2004 941 draft-sajassi-l2vpn-vpls-bridge-interop.txt October 2004 943 18. 944 Authors' Addresses 946 Ali Sajassi 947 Cisco Systems, Inc. 948 170 West Tasman Drive 949 San Jose, CA 95134 950 Email: sajassi@cisco.com 952 Yetik Serbest 953 SBC Labs 954 9505 Arboretum Blvd. 955 Austin, TX 78759 956 Email: yetik_serbest@labs.sbc.com 958 Frank Brockners 959 Cisco Systems, Inc. 960 Hansaallee 249 961 40549 Duesseldorf 962 Germany 963 Email: fbrockne@cisco.com