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