idnits 2.17.1 draft-key-l2vpn-etree-frwk-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2011) is 4576 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Raymond Key, Huawei 3 Internet Draft Simon Delord, Alcatel-Lucent 4 Category: Informational Frederic Jounay, Orange France Telecom 5 Expires: April 2012 Lucy Yong, Huawei 6 Lizhong Jin, ZTE 7 Yuji Kamite, NTT Communications 8 Wim Henderickx, Alcatel-Lucent 10 October 16, 2011 12 A Framework for E-Tree Service over MPLS Network 13 draft-key-l2vpn-etree-frwk-06 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2012. 38 Abstract 40 This document proposes a solution framework for supporting Metro 41 Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a 42 Multiprotocol Label Switching (MPLS) network. The objective is to 43 provide a simple and effective approach to emulate E-Tree services 44 in addition to Ethernet LAN (E-LAN) services on an existing MPLS 45 network. 47 Table of Contents 49 1. Introduction....................................................3 50 1.1. Objective and Scope...........................................3 51 1.2. Traditional Ethernet Network..................................3 52 1.3. MEF Multipoint Ethernet Services..............................3 53 1.3.1. Similarity between E-LAN and E-Tree.........................4 54 1.3.2. Difference between E-LAN and E-Tree.........................4 55 1.4. IETF Multipoint L2VPN Services................................5 56 1.4.1. Virtual Private LAN Service (VPLS)..........................5 57 1.4.2. Virtual Private Multicast Service (VPMS)....................5 58 1.5. Terminology...................................................6 59 2. Reference Model.................................................6 60 3. Use Cases.......................................................8 61 4. Challenges......................................................9 62 4.1. Generic E-Tree Service Definition.............................9 63 4.1.1. Mandatory Leaf-to-Leaf Communication Restriction............9 64 4.2. Use Case Desirable Requirements..............................10 65 4.2.1. Ethernet Broadcast/Multicast Optimisation..................10 66 4.2.2. IP Multicast Optimisation..................................11 67 4.2.3. MAC-based Forwarding Unnecessary...........................11 68 4.2.4. MAC-based Forwarding Security Concern......................12 69 5. A Solution Framework for MAC-based Forwarding E-Tree...........12 70 5.1. MAC-based Forwarding Any-to-Any Ethernet VPN.................12 71 5.2. Leaf-to-Leaf Communication Restriction.......................13 72 5.3. Optional Enhancement - Point-to-Multipoint PW................13 73 5.4. Optional Enhancement - IP Multicast in VPLS.......... .......14 74 6. Non-MAC-based Forwarding E-Tree................................14 75 6.1. Single Root, Broadcast Only - VPMS...........................14 76 6.2. Multiple Roots, Broadcast and Unicast........................14 77 7. Security Consideration.........................................14 78 8. IANA Considerations............................................15 79 9. Acknowledgements...............................................15 80 10. References....................................................15 81 10.1. Normative References........................................15 82 10.2. Informative References......................................15 83 Appendix A. Some Possible Ways for Leaf-to-Leaf Communication 84 Restriction...........................................17 85 Authors' Addresses................................................27 86 Intellectual Property and Copyright Statements....................28 88 Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 1. Introduction 96 1.1. Objective and Scope 98 This document proposes a solution framework for supporting Metro 99 Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a MPLS 100 network. The objective is to provide a simple and effective approach 101 to emulate E-Tree services in addition to Ethernet LAN (E-LAN) 102 services on an existing MPLS network. 104 This solution framework makes use of existing IETF specified 105 mechanisms unless there are technical reasons why the existing 106 mechanisms are insufficient or unnecessary. 108 This document does not intend to provide a full specification of the 109 solution, but rather to identify the functional components of the 110 overall solution, and for each component, whether it is REQUIRED or 111 OPTIONAL, whether existing mechanism is sufficient, or whether 112 relevant mechanism is already under development. 114 In this document, "current standard" refers to [RFC4385], [RFC4447], 115 [RFC4448], [RFC4761] and [RFC4762]. 117 1.2. Traditional Ethernet Network 119 In this document, traditional Ethernet network refers to the Ethernet 120 bridge/switch network, not the Ethernet repeater/hub network. 122 Data frame is Ethernet frame. 124 Data forwarding is MAC-based forwarding, which includes MAC address 125 learning and aging. 127 It is important to note that in traditional Ethernet network unicast 128 unknown, multicast and broadcast frames are forwarded in exactly the 129 same way to every port except the ingress port. 131 An Ethernet host receiving a frame checks the destination address in 132 the frame to decide whether it is the intended destination. 134 1.3. MEF Multipoint Ethernet Services 136 MEF defines two multipoint Ethernet Service types: 137 - E-LAN (Ethernet LAN), multipoint-to-multipoint service 138 - E-Tree (Ethernet Tree), rooted-multipoint service 140 According to MEF's technical specification, a generic E-LAN/E-Tree 141 service is always bidirectional in the sense that ingress frames can 142 originate at any endpoint in the service. However, some application 143 scenarios of E-Tree may have unidirectional traffic only. Section 3 144 will discuss about different use cases. 146 For full specification, please refer to MEF's "Ethernet Services 147 Definitions - Phase 2" [MEF6.1] and "Ethernet Services Attributes 148 Phase 2" [MEF10.2]. 150 1.3.1. Similarity between E-LAN and E-Tree 152 Data frame is Ethernet frame. 154 Data forwarding can be MAC-based forwarding or something else, to be 155 specified by service provider in the particular service definition. 157 Extract from [MEF6.1] Table 7 and Table 9: 158 +---------------+---------------------------------------------------+ 159 | EVC Service | E-LAN/E-Tree Service Type Requirement | 160 | Attribute | | 161 +---------------+---------------------------------------------------+ 162 | Unicast | Deliver Unconditionally or Deliver Conditionally. | 163 | Service Frame | If Delivered Conditionally, MUST specify the | 164 | Delivery | delivery criteria. | 165 +---------------+---------------------------------------------------+ 166 | Multicast | Deliver Unconditionally or Deliver Conditionally. | 167 | Service Frame | If Delivered Conditionally, MUST specify the | 168 | Delivery | delivery criteria. | 169 +---------------+---------------------------------------------------+ 170 | Broadcast | Deliver Unconditionally or Deliver Conditionally. | 171 | Service Frame | If Delivered Conditionally, MUST specify the | 172 | Delivery | delivery criteria. | 173 +---------------+---------------------------------------------------+ 175 It is important to note that it is not a must for a MEF multipoint 176 Ethernet service (E-LAN or E-Tree) to use MAC-based forwarding. This 177 document presents a solution framework for MAC-based forwarding 178 E-Tree in section 5, and also discusses non-MAC-based forwarding 179 E-Tree in section 6. 181 1.3.2. Difference between E-LAN and E-Tree 183 Within the context of a multipoint Ethernet service, each endpoint is 184 designated as either a Root or a Leaf. A Root can communicate with 185 all other endpoints in the same multipoint Ethernet service, however 186 a Leaf can only communicate with Roots but not Leafs. 188 The only difference between E-LAN and E-Tree is: 189 - E-LAN has Root endpoints only, which implies there is no 190 communication restriction between endpoints 191 - E-Tree has both Root and Leaf endpoints, which implies there is a 192 need to enforce communication restriction between Leaf endpoints 194 Extract from [MEF10.2] Section 6.3: 195 The UNI Type MUST have the value either "Root" or "Leaf." If the type 196 of EVC is Point-to-Point or Multipoint-to-Multipoint, then the UNI 197 Type MUST equal "Root." 198 Extract from [MEF10.2] Section 6.1.2.2: 199 An ingress Service Frame mapped to the EVC at a Leaf UNI MUST NOT 200 result in an egress Service Frame at another Leaf UNI but MAY result 201 in an egress Service Frame at some or all of the Root UNIs. 203 It is important to note that one E-Tree service may have single or 204 multiple Root UNIs. 206 Extract from [MEF6.1] Section 6.3: 207 In its simplest form, an E-Tree Service type can provide a single 208 Root for multiple Leaf UNIs. Each Leaf UNI can exchange data with 209 only the Root UNI. ... In more sophisticated forms, an E-Tree Service 210 type may support two or more Root UNIs. In this scenario, each Leaf 211 UNI can exchange data only with the Root UNIs. As well, the Roots can 212 communicate with each other. In such a service, redundant access to 213 the Root can also be provided, effectively allowing for enhanced 214 service reliability and flexibility. 216 1.4. IETF Multipoint L2VPN Services 218 1.4.1. Virtual Private LAN Service (VPLS) 220 VPLS is a L2VPN service that provides multipoint-to-multipoint 221 connectivity for Ethernet across an IP or MPLS-enabled IP Packet 222 Switched Network. VPLS emulates the Ethernet VLAN functionality of 223 traditional Ethernet network. 225 VPLS is a current IETF standard, please refer to [RFC4761] [RFC4762]. 227 Data frame is Ethernet frame. 229 Data forwarding is MAC-based forwarding, which includes MAC address 230 learning and aging. 232 It is important to note that the current standard VPLS treats 233 Ethernet multicast frame in exactly the same way as Ethernet 234 broadcast frame and does not restrict transmission of Ethernet 235 multicast frame to a smaller set of receivers. An Ethernet host 236 receiving a frame checks the destination address in the frame to 237 determine whether it is the intended destination. 239 VPLS can be used to emulate E-LAN service over MPLS network provided 240 that the E-LAN service uses MAC-based forwarding as service frame 241 delivery attribute. Considerable number of service providers have 242 adopted this approach to provide E-LAN services to customers. 244 1.4.2. Virtual Private Multicast Service (VPMS) 246 VPMS is a L2VPN service that provides point-to-multipoint 247 connectivity across a variety of link layers, including Frame Relay, 248 ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP Packet 249 Switched Network. 251 In the Ethernet use case, VPMS provides single coverage of receiver 252 membership, i.e. there is no distinct differentiation for multiple 253 multicast groups. Destination address in Ethernet frame is not used 254 in data forwarding. 256 VPMS MUST support unidirectional point-to-multipoint traffic from a 257 sender to multiple receivers and MAY support reverse traffic in a 258 point-to-point manner. 260 VPMS is currently under development. Please refer to [Draft VPMS 261 Frmwk]. 263 1.5. Terminology 265 E-Tree 267 An Ethernet VPN in which each Root AC can communicate with every 268 other AC, whereas Leaf ACs can only communicate with Root ACs. Each 269 AC on an E-Tree construct is designated as either a Root AC or a Leaf 270 AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct. 272 Root AC 274 An ingress frame at a Root AC can be delivered to one or more of 275 any of the other ACs in the E-Tree. Please note that this AC is 276 bidirectional. 278 Leaf AC 280 Ingress frame at a Leaf AC can only be delivered to one or more Root 281 ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered 282 to any Leaf ACs in the E-Tree. Please note that this AC is 283 bidirectional. 285 2. Reference Model 287 Figure 1 below describes a generic reference model where PE1, PE2 and 288 PE3 need to establish an E-Tree construct between different Ethernet 289 endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI. 290 These VSIs are then linked together via Ethernet PWs. 292 In most use cases, an E-Tree construct has only a few Root ACs but 293 many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE. 295 <------------E-Tree------------> 296 +---------+ +---------+ 297 | PE1 | | PE2 | 298 +----+ | +---+ | | +---+ | +----+ 299 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 300 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 301 +----+ | | | | | | | | +----+ 302 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 303 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 304 +----+ | | | | | | | | +----+ 305 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 306 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 307 +----+ | | | | | | | | +----+ 308 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 309 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 310 | | | | | | 311 +----+----+ +----+----+ 312 | | 313 |Ethernet |Ethernet 314 |PW |PW 315 | | 316 | +----+----+ 317 | | | | 318 | | +-+-+ | +----+ 319 | | | +--+----AC9----+CE09| 320 | | | V | | (Root AC) +----+ 321 | | | | | +----+ 322 | | | +--+----AC10---+CE10| 323 +-----------------+--+ S | | (Root AC) +----+ 324 | | | | +----+ 325 | | +--+----AC11---+CE11| 326 | | I | | (Leaf AC) +----+ 327 | | | | +----+ 328 | | +--+----AC12---+CE12| 329 | +---+ | (Leaf AC) +----+ 330 | PE3 | 331 +---------+ 332 <------------E-Tree------------> 334 Figure 1: E-Tree Reference Model 336 With an E-Tree construct: 337 - A Root AC can receive from and transmit to any other ACs. 338 - A Leaf AC can receive from and transmit to any Root ACs. 339 - A Leaf AC cannot receive from and transmit to any other Leaf ACs. 341 This applies to all traffic, including Unicast Known, Unicast 342 Unknown, Broadcast and Multicast. 344 When an Ethernet Frame is received on PE1 via AC1, the frame can be 345 transmitted to any other local ACs on PE1 and via Ethernet PWs to any 346 remote ACs on PE2 and PE3. 348 However when an Ethernet frame is received on PE1 via AC3, the frame 349 can be transmitted to any other local Root ACs on PE1 and via 350 Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame 351 cannot be transmitted to any local Leaf ACs on PE1 nor any remote 352 Leaf ACs on PE2 and PE3. 354 3. Use Cases 356 Table 1 below presents some major use cases. 358 +---------------------------+--------------+------------+ 359 | Use Case | Root | Leaf | 360 +---+---------------------------+--------------+------------+ 361 | 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 362 +---+---------------------------+--------------+------------+ 363 | 2 | Wholesale Access | Customer's | Customer's | 364 | | | Interconnect | Subscriber | 365 +---+---------------------------+--------------+------------+ 366 | 3 | Mobile Backhaul | RAN NC | RAN BS | 367 +---+---------------------------+--------------+------------+ 368 | 4 | IEEE 1588 PTPv2 | PTP Server | PTP Client | 369 | | Clock Synchronisation | | | 370 +---+---------------------------+--------------+------------+ 371 | 5 | Internet Access | BNG Router | Subscriber | 372 +---+---------------------------+--------------+------------+ 373 | 6 | Broadcast Video | Video Source | Subscriber | 374 | | (unidirectional only) | | | 375 +---+---------------------------+--------------+------------+ 376 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 377 | | plus Control Channel | | | 378 +---+---------------------------+--------------+------------+ 379 | 8 | Device Management | Management | Managed | 380 | | | System | Device | 381 +---+---------------------------+--------------+------------+ 383 Table 1: E-Tree Use cases 385 Common to all use cases, direct Layer 2 Leaf-to-Leaf communication is 386 not required. For Mobile backhaul, this may not be valid for LTE X2 387 interfaces in the future. 389 If direct Layer 2 Leaf-to-Leaf communication is not allowed due to 390 security concern, then E-Tree should be used to prohibit 391 communication between Leaf endpoints, otherwise E-LAN is also a 392 feasible option. 394 Also common to the use cases mentioned above, there may be single or 395 multiple Root endpoints in one E-Tree service. The need for multiple 396 Root endpoints is usually driven by redundancy requirement. Whether 397 a particular E-Tree service needs to support single or multiple Root 398 endpoints depends on the target application. 400 A generic E-Tree service supports all the following traffic flows: 401 - Ethernet Unicast from Root to Leaf 402 - Ethernet Unicast from Leaf to Root 403 - Ethernet Unicast from Root to Root 404 - Ethernet Broadcast/Multicast from Root to Roots & Leafs 405 - Ethernet Broadcast/Multicast from Leaf to Roots 406 A particular E-Tree service may need to support all the above or only 407 a subset depending on the target application. 409 Among the use cases mentioned above, broadcast video draws most 410 attention. Actually, broadcast video is a representing example for 411 content delivery in general, such as news feed, financial data 412 feed, etc. 414 4. Challenges 416 4.1. Generic E-Tree Service Definition 418 This section highlights why the current standard VPLS is insufficient 419 for emulating E-Tree service over MPLS network. 421 4.1.1. Mandatory Leaf-to-Leaf Communication Restriction 423 Current standard VPLS treats all ACs equal (i.e. not classified into 424 Root or Leaf) and provides any-to-any connectivity among all ACs. The 425 current standard VPLS does not include any mechanism of communication 426 restriction between specific ACs, therefore is insufficient for 427 emulating generic E-Tree service over MPLS network. 429 A problem occurs when there are two or more PEs with both Root AC and 430 Leaf AC. 432 Let's look at the scenario illustrated in Figure 2 below. VPLS is 433 used to emulate an E-Tree service over a MPLS network. 435 Note: Figure 2 is a hypothetical case solely for explaining the 436 problem, and not meant to represent a typical E-Tree service. 438 <------------E-Tree------------> 439 +---------+ +---------+ 440 | PE1 | | PE2 | 441 +---+ | +---+ | | +---+ | +---+ 442 |CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3| 443 +---+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +---+ 444 | | S +--+-----PW-----+--+ S | | 445 +---+ | | I | | | | I | | +---+ 446 |CE2+-----AC2----+--+ | | | | +--+----AC4-----+CE4| 447 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 448 +---------+ +---------+ 450 Figure 2: Problem Scenario for Leaf-to-Leaf Communication Restriction 451 When PE2 receives a frame from PE1 via the Ethernet PW, 452 - PE2 does not know which AC on PE1 is the ingress AC 453 - PE2 does not know whether the ingress AC is a Leaf AC or not 454 - PE2 does not have sufficient information to enforce the 455 Leaf-to-Leaf communication restriction 457 Examples: 458 - CE2 sends a Broadcast/Multicast frame to PE1 via AC2 459 - CE2 sends a Unicast frame to PE1 via AC2, destination address in 460 Ethernet header equal to CE4's MAC address 462 In order to fulfil the generic E-Tree service definition, extension 463 to the current VPLS standard will be required. Extension to related 464 PWE3 standard may also be required, depending on solution approach. 465 Such extensions should have minimal impact on the emulated E-LAN 466 services already in operation. 468 There are some possible ways to get around this problem that do not 469 require extension to the current VPLS standard but they all come with 470 significant design complexity or deployment constraints. Appendix A 471 highlights the major ones and the related concerns. 473 4.2. Use Case Desirable Requirements 475 There are quite a variety of use cases for E-Tree. For some use 476 cases, the generic MEF E-Tree service definition is good enough. For 477 some other use cases, there are desirable requirements beyond that. 479 The challenges discussed in this section are not related to the 480 generic MEF E-Tree service definition but the desirable requirements 481 of specific use cases. They may be critical to the success in some 482 E-Tree services while totally irrelevant in some others. 484 4.2.1. Ethernet Broadcast/Multicast Optimisation 486 According to MAC-based forwarding, an Ethernet broadcast/multicast/ 487 unicast unknown frame is forwarded to all ACs other than the ingress 488 AC, which implies point-to-multipoint traffic from the ingress PE to 489 all other PEs in the VPLS instance. 491 The current standard VPLS uses only point-to-point PW between PEs. 492 When the Ethernet destination address is broadcast, multicast or 493 unicast unknown, the ingress PE replicates the frame on every PW 494 towards remote PE belonging to the same VPLS instance. Depending on 495 the mapping between the logical topology of the E-Tree service and 496 the physical topology of the network, multiple PWs may transverse 497 same physical link, result in multiple copies of the same payload 498 Ethernet frame on the physical link. Such approach is inefficient in 499 terms of bandwidth usage. 501 For some use cases, for example broadcast/multicast video, due to 502 nature of the application, there is significant volume of point-to- 503 multipoint traffic. Bandwidth optimisation for such traffic within 504 the network becomes a concern from the service provider perspective. 506 [RFC5501] provides an in-depth discussion on broadcast/multicast 507 related requirements for VPLS, see issue B (Replication of PWs on 508 shared physical path) in section 3.2. 510 4.2.2. IP Multicast Optimisation 512 The current standard VPLS is a L2VPN service agnostic to customer's 513 Layer 3 traffic, hence does not maintain any information about IP 514 multicast group membership. Although a Layer 3 IP multicast packet is 515 encapsulated in a Layer 2 Ethernet multicast frame, the current 516 standard VPLS treats Ethernet multicast frame in exactly the same way 517 as Ethernet broadcast frame. Therefore, such payload IP multicast 518 packet will be forwarded to every other AC of the same VPLS instance. 520 A payload IP multicast packet will be forwarded to all ACs, including 521 those with no member of the specific IP multicast group attached. 522 Unnecessary traffic consumes bandwidth on access link and may become 523 a concern from the customer perspective. In some cases, it may also 524 be a security concern as the multicast frame may be forwarded to an 525 endpoint other than the intended destinations. 527 A payload IP multicast packet will be forwarded to a remote PE with 528 no member of the specific IP multicast group attached. Unnecessary 529 traffic consumes bandwidth in the network and may become a concern 530 from the service provider perspective. 532 For some use cases, for example multicast video, due to nature of the 533 application, there is significant volume of IP multicast traffic and 534 different IP multicast groups are required in one E-Tree service. The 535 above may become a real concern from both the customer and service 536 provider perspectives. 538 [RFC5501] provides an in-depth discussion on broadcast/multicast 539 related requirements for VPLS, see both issue A (Replication to non- 540 member site) and issue B (Replication of PWs on shared physical path) 541 in section 3.2. 543 4.2.3. MAC-based Forwarding Unnecessary 545 For some use cases, for example broadcast video, due to nature of the 546 application, there is only broadcast unidirectional traffic from Root 547 to all other endpoints. It is unnecessary to use destination address 548 for data forwarding. Deliver unconditionally for ingress frame at 549 Root endpoint may be a simpler approach than MAC-based forwarding. 551 4.2.4. MAC-based Forwarding Security Concern 553 MAC-based forwarding will make an unicast frame from a Root destined 554 for a specific Leaf being forwarded to other endpoints in addition to 555 the intended destination when the frame is classified as unicast 556 unknown, may be due to MAC address aged out or MAC address table 557 overflow. 559 MAC address spoofing may cause an unicast frame from a Root destined 560 for a specific Leaf being forwarded to an endpoint different from the 561 intended destination. 563 If such unicast frame carries sensitive information strictly for the 564 intended destination only, then the MAC-based forwarding may cause a 565 security concern from the customer perspective. 567 For some use cases where mutually un-trusted subscribers are 568 connected to leaf endpoints in the same E-Tree service, such as 569 Internet access and wholesale access, this is a valid concern. 571 There are some possible mitigations: 572 - For every Leaf endpoint of the particular E-Tree service, deploy 573 a service provider controlled router between the Leaf endpoint 574 and the customer network 575 - Customer to deploy encryption for sensitive information, for 576 example IPsec, SSL, SSH, HTTPS 578 Whether the MAC-based forwarding really becomes a security concern 579 depends on the particular application and the deployment scenario. 580 This is unlikely to be a critical concern in most cases. 582 5. A Solution Framework for MAC-based Forwarding E-Tree 584 As mentioned in section 1.3.1. E-Tree can use MAC-based forwarding or 585 something else for data forwarding. This section presents a solution 586 framework for MAC-based forwarding E-Tree. Section 6 will discuss 587 other variants. 589 This is a VPLS-based solution. Functional components of the solution 590 are identified and discussed in the subsections. 592 5.1. MAC-based Forwarding Any-to-Any Ethernet VPN 594 This is a REQUIRED component. 596 This component is the current standard VPLS and PWE3 as specified in 597 [RFC4385] [RFC4447] [RFC4448] [RFC4761] [RFC4762], which provides 598 any-to-any connectivity among all ACs in one VPLS instance. 600 This is the base component. All other REQUIRED/OPTIONAL components 601 are to be added on top of this component. 603 5.2. Leaf-to-Leaf Communication Restriction 605 This is in response to the challenge in section 4.1.1. Mandatory 606 Leaf-to-Leaf Communication Restriction. 608 This is a REQUIRED component. 610 This component is a minimal extension to the current VPLS and PWE3 611 standards, with the objective to provide a simple and effective way 612 to support generic E-Tree services in addition to E-LAN services 613 using VPLS on a MPLS network. 615 [Draft VPLS ETree Req] is a work in progress requirement draft. 617 Different solutions have been proposed: 618 - Control Word L-bit solution, [Draft CW L-bit] [Draft VPLS ETree] 619 - Dual VLAN solution, [Draft VPLS PE ETree] 620 - Two PW solution, [Draft VPLS ETree 2PW] 621 - Two VE ID solution [Draft VPLS ETree 2VEID] 623 5.3. Optional Enhancement - Point-to-Multipoint PW 625 This is in response to the challenge in section 4.2.1. Ethernet 626 Broadcast/Multicast Optimisation. 628 This is an OPTIONAL component, applicable only when there is 629 significant volume of Ethernet broadcast/multicast traffic. 631 Point-to-Multipoint pseudowire (P2MP PW) is a PW attached to a source 632 used to distribute Layer 1 or Layer 2 format traffic to a set of 633 receivers. P2MP PW is unidirectional but optionally bidirectional. 635 By using P2MP PW, the ingress PE is not responsible for replicating 636 the payload frame on each P2P PW towards egress PE, instead the 637 network elements along the physical path participate in replication. 638 The replication is done by the underlying point-to-multipoint label 639 switched path (P2MP LSP). 641 Extension to current VPLS standard will be required to specify how 642 P2MP PW and P2P PW should be used and how MAC learning works on P2MP 643 PW. Please refer to [Draft LDP-VPLS Bcast]. 645 P2MP PW is currently under development. Please refer to [Draft P2MP 646 PW Req] [Draft P2MP PW Sig]. 648 It is important to note that this component will align with the 649 recommendation in [RFC4665], 650 "With the exception of IPLS, an L2VPN service SHOULD be agnostic to 651 customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated 652 within Layer 2 frames." 654 5.4. Optional Enhancement - IP Multicast in VPLS 656 This is in response to the challenge in section 4.2.2. IP Multicast 657 Optimisation. 659 This is an OPTIONAL component, applicable only when there is 660 significant volume of IP multicast traffic and different IP multicast 661 groups are required in one E-Tree service. 663 Multicast in VPLS is currently under development, with the objective 664 to provide efficient ways to support IP multicast services over VPLS. 665 It covers IP multicast group membership control and also bandwidth 666 optimisation. Please refer to [Draft Mcast VPLS]. 668 It is important to note that this component will make use of Layer 3 669 IP multicast information in payload frames to improve transport 670 efficiency, hence will not align with the recommendation in [RFC4665] 671 that an L2VPN service SHOULD be agnostic to customer's Layer 3 672 traffic. 674 6. Non-MAC-based Forwarding E-Tree 676 This section presents some variants of E-Tree services which do not 677 use MAC-based forwarding as the service frame delivery attribute. 679 6.1. Single Root, Broadcast Only - VPMS 681 This is in response to the challenge in section 4.2.3. MAC-based 682 Forwarding Unnecessary. 684 VPMS provides single coverage of receiver membership. Destination 685 address in Ethernet frame is not used in data forwarding. 687 For E-Tree service of single Root and only unidirectional broadcast 688 traffic from the Root, for example certain broadcast video or similar 689 content delivery applications, VPMS will be a much more simple and 690 effective solution than VPLS. 692 VPMS is currently under development. Please refer to [Draft VPMS 693 Frmwk]. 695 6.2. Multiple Roots, Broadcast and Unicast 697 This is in response to the challenge in section 4.2.4. MAC-based 698 Forwarding Security Concern. 700 This will be added in later version of this document. 702 7. Security Considerations 704 This will be added in later version of this document. 706 8. IANA Considerations 708 This will be added in later version of this document. 710 9. Acknowledgements 712 This will be added in later version of this document. 714 10. References 716 10.1. Normative References 718 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - 719 Phase 2, April 2008 721 [MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes 722 Phase 2, October 2009 724 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 725 Requirement Levels, BCP 14, RFC 2119, March 1997 727 [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation 728 Edge-to-Edge (PWE3) Control Word for Use over an MPLS 729 PSN, February 2006. 731 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 732 Using the Label Distribution Protocol (LDP), April 2006 734 [RFC4448] Martini, L., and al, Encapsulation Methods for 735 Transport of Ethernet over MPLS Networks, April 2006 737 [RFC4665] Augustyn & Serbest, Service Requirements for Layer 2 738 Provider-Provisioned Virtual Private Networks, 739 September 2006 741 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) 742 Using BGP for Auto-Discovery and Signaling, January 2007 744 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 745 Using Label Distribution Protocol (LDP) Signaling, 746 January 2007 748 [RFC5501] Kamite, et al., Requirements for Multicast Support in 749 Virtual Private LAN Services, March 2009 751 10.2. Informative References 753 [Draft VPLS ETree Req] 754 Key, et al., Requirements for MEF E-Tree Support in 755 VPLS, draft-ietf-l2vpn-etree-reqt-00 (work in progress), 756 October 2011 758 [Draft CW L-bit] 759 Delord, et al., Control Word Reserved bit for use in 760 E-Tree, draft-delord-pwe3-cw-bit-etree-06 (work in 761 progress), October 2011 763 [Draft VPLS ETree] 764 Key, et al., Extension to VPLS for E-Tree, 765 draft-key-l2vpn-vpls-etree-06 (work in progress), 766 October 2011 768 [Draft VPLS PE ETree] 769 Jiang, et al., VPLS PE Model for E-Tree Support, 770 draft-jiang-l2vpn-vpls-pe-etree-04 (work in progress), 771 July 2011 773 [Draft VPLS ETree 2PW] 774 Ram, et al., Extension to LDP-VPLS for E-Tree Using Two 775 PW, draft-ram-l2vpn-ldp-vpls-etree-2pw-02 (work in 776 progress), May 2011 778 [Draft VPLS ETree 2VEID] 779 Cao, Extension to Signaling in VPLS for E-Tree, 780 draft-cao-l2vpn-vpls-etree-00 (work in progress), 781 May 2011 783 [Draft P2MP PW Req] 784 Jounay, et al., Requirements for Point-to-Multipoint 785 Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-05 786 (work in progress), September 2011 788 [Draft P2MP PW Sig] 789 Boutros, et al., Signaling Root-Initiated Point-to- 790 Multipoint Pseudowires using LDP, 791 draft-ietf-pwe3-p2mp-pw-02 (work in progress), 792 March 2011 794 [Draft LDP-VPLS Bcast] 795 Delord, et al., Extension to LDP-VPLS for Ethernet 796 Broadcast and Multicast, 797 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02 (work in 798 progress), June 2011 800 [Draft Mcast VPLS] 801 Raggarwa, Kamite & Fang, Multicast in VPLS, 802 draft-ietf-l2vpn-vpls-mcast-09 (work in progress), 803 July 2011 805 [Draft VPMS Frmwk] 806 Kamite, et al., Framework and Requirements for Virtual 807 Virtual Private Multicast Service (VPMS), 808 draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in 809 progress), July 2011 811 Appendix A. Some Possible Ways for Leaf-to-Leaf Communication 812 Restriction 814 This appendix briefly describes the following approaches: 815 - Single Root Only (A.1) 816 - Only one PE has Roots (A.2) 817 - Only one PE with both Root & Leaf 818 - Backhaul Root (A.3) 819 - Backhaul Leaf (A.4) 820 - H-VPLS Root (A.5) 821 - H-VPLS Leaf (A.6) 822 - Separate PEs for Root and Leaf (A.7) 823 - Separate VSI for Root and Leaf 824 - Internal Connection (A.8) 825 - External Connection (A.9) 826 - Separate PWs for "From Root" traffic and "From Leaf" traffic (A.10) 827 - "From Root" or "From Leaf" derived from source MAC address (A.11) 828 - Static MAC address configuration for Root AC (A.12) 830 Reference Model for Leaf-to-Leaf Communication Restriction 832 <------------E-Tree------------> 833 +---------+ +---------+ 834 | PE1 | | PE2 | 835 +----+ | +---+ | | +---+ | +----+ 836 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 837 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 838 +----+ | | | | | | | | +----+ 839 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 840 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 841 +----+ | | | | | | | | +----+ 842 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 843 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 844 +----+ | | | | | | | | +----+ 845 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 846 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 847 | | | | 848 +---------+ +---------+ 850 For the diagrams in this appendix, "L" indicates the particular AC or 851 PW belonging to the PE local split horizon group specifically for 852 Leaf-to-Leaf Communication Restriction. No communication is allowed 853 between any two members of a split horizon group. 855 A.1. Single Root Only 857 <------------E-Tree------------> 858 +---------+ +---------+ 859 | PE1 | | PE2 | 860 +----+ | +---+ | | +---+ | 861 |CE01+----AC1----+--+ | | | | | | 862 +----+ (Root AC) | | V | | | | V | | 863 | | | | | | | | 864 | | | | Ethernet | | | | 865 | | S +L-+-----PW-----+--+ S | | 866 +----+ | | | | | | | | +----+ 867 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 868 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 869 +----+ | | | | | | | | +----+ 870 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 871 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 872 | | | | 873 +---------+ +---------+ 875 Concerns: 876 - Not fulfil multi-Root requirement of generic MEF E-Tree service 877 definition 879 A.2. Only one PE has Roots 881 <------------E-Tree------------> 882 +---------+ +---------+ 883 | PE1 | | PE2 | 884 +----+ | +---+ | | +---+ | 885 |CE01+----AC1----+--+ | | | | | | 886 +----+ (Root AC) | | V | | | | V | | 887 +----+ | | | | | | | | 888 |CE02+----AC2----+--+ | | Ethernet | | | | 889 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | 890 +----+ | | | | | | | | +----+ 891 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 892 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 893 +----+ | | | | | | | | +----+ 894 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 895 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 896 | | | | 897 +---------+ +---------+ 899 Concerns: 900 - Deployment constraint 902 A.3. Only one PE with both Root & Leaf - Backhaul Root 904 +---AC5(Root AC)---------------------------+ 905 | | 906 | +-AC6(Root AC)----------------------+ | 907 | | | | 908 | | | | 909 | | | | 910 +---+-+---+ +---------+ | | 911 | | | | | | | | 912 +----+ | ++-++ | | +---+ | | +-+--+ 913 |CE01+----AC1----+--+ | | | | | | | |CE05| 914 +----+ (Root AC) | | V | | | | V | | | +----+ 915 +----+ | | | | | | | | | +----+ 916 |CE02+----AC2----+--+ | | Ethernet | | | | +--+CE06| 917 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | +----+ 918 +----+ | | | | | | | | +----+ 919 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 920 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 921 +----+ | | | | | | | | +----+ 922 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 923 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 924 | PE1 | | PE2 | 925 +---------+ +---------+ 926 <------------E-Tree------------> 928 Concerns: 929 - Deployment constraint 930 - Long fibre path 932 A.4. Only one PE with both Root & Leaf - Backhaul Leaf 934 <------------E-Tree------------> 935 +---------+ +---------+ 936 | PE1 | | PE2 | 937 +----+ | +---+ | | +---+ | +----+ 938 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 939 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 940 +----+ | | | | | | | | +----+ 941 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 942 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 943 +----+ | | | | | | | | +----+ 944 |CE03+----AC3----+-L+ | | | | | | +--+CE07| 945 +----+ (Leaf AC) | | I | | | | I | | | +----+ 946 +----+ | | | | | | | | | +----+ 947 |CE04+----AC4----+-L+ | | | | | | | |CE08| 948 +----+ (Leaf AC) | ++-++ | | +---+ | | +-+--+ 949 | L L | | | | | 950 +---+-+---+ +---------+ | | 951 | | | | 952 | | | | 953 | | | | 954 | +-AC7(Leaf AC)----------------------+ | 955 | | 956 +---AC8(Leaf AC)---------------------------+ 958 Concerns: 959 - Deployment constraint 960 - Long fibre path 962 A.5. Only one PE with both Root & Leaf - H-VPLS Root 964 <------------E-Tree------------> 965 +---------+ +---------+ 966 | PE1 | | PE2 | 967 +----+ | +---+ | Ethernet | | +----+ 968 |CE01+----AC1----+--+ +--+-----PW-----+---------+----AC5----+CE05| 969 +----+ (Root AC) | | V | | | | (Root AC) +----+ 970 +----+ | | | | Ethernet | | +----+ 971 |CE02+----AC2----+--+ +--+-----PW-----+---------+----AC6----+CE06| 972 +----+ (Root AC) | | S | | | +---+ | (Root AC) +----+ 973 +----+ | | | | | | | | +----+ 974 |CE03+----AC3----+-L+ | | Ethernet | | V +L-+----AC7----+CE07| 975 +----+ (Leaf AC) | | I +L-+-----PW-----+--+ S | | (Leaf AC) +----+ 976 +----+ | | | | | | I | | +----+ 977 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 978 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 979 | | | | 980 +---------+ +---------+ 982 Concerns: 983 - Design complexity 984 - More PW 985 - Hair pinning (e.g. CE05 to CE06/07/08) impact bandwidth and delay 987 A.6. Only one PE with both Root & Leaf - H-VPLS Leaf 989 <------------E-Tree------------> 990 +---------+ +---------+ 991 | PE1 | | PE2 | 992 +----+ | +---+ | | +---+ | +----+ 993 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 994 +----+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +----+ 995 +----+ | | +--+-----PW-----+--+ S | | +----+ 996 |CE02+----AC2----+--+ | | | | I +--+----AC6----+CE06| 997 +----+ (Root AC) | | S | | | | | | (Root AC) +----+ 998 +----+ | | | | Ethernet | +---+ | +----+ 999 |CE03+----AC3----+-L+ +L-+-----PW-----+---------+----AC7----+CE07| 1000 +----+ (Leaf AC) | | I | | | | (Leaf AC) +----+ 1001 +----+ | | | | Ethernet | | +----+ 1002 |CE04+----AC4----+-L+ +L-+-----PW-----+---------+----AC8----+CE08| 1003 +----+ (Leaf AC) | +---+ | | | (Leaf AC) +----+ 1004 | | | | 1005 +---------+ +---------+ 1007 Concerns: 1008 - Design complexity 1009 - More PW 1010 - Hair pinning (e.g. CE08 to CE05/06) impact bandwidth and delay 1012 A.7. Separate PEs for Root and Leaf 1013 (PE2 split to PE2R & PE2L) 1015 <------------E-Tree------------> 1016 +---------+ +---------+ 1017 | PE1 | | PE2R | 1018 +----+ | +---+ | | +---+ | +----+ 1019 |CE01+----AC1----+--+ | | Ethernet | | V +--+----AC5----+CE05| 1020 +----+ (Root AC) | | V +--+-----PW-----+--+ S | | (Root AC) +----+ 1021 +----+ | | | | | | I | | +----+ 1022 |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06| 1023 +----+ (Root AC) | | S | | | +-+-+ | (Root AC) +----+ 1024 +----+ | | | | | L | 1025 |CE03+----AC3----+-L+ | | +----+----+ 1026 +----+ (Leaf AC) | | I | | | 1027 +----+ | | | | |Ethernet 1028 |CE04+----AC4----+-L+ | | |PW 1029 +----+ (Leaf AC) | +-+-+ | | 1030 | L | +----+----+ 1031 +----+----+ | | | 1032 | | +-+-+ | +----+ 1033 | Ethernet | | V +L-+----AC7----+CE07| 1034 +----------PW-----+--+ S | | (Leaf AC) +----+ 1035 | | I | | +----+ 1036 | | +L-+----AC8----+CE08| 1037 | +---+ | (Leaf AC) +----+ 1038 | PE2L | 1039 +---------+ 1040 <------------E-Tree------------> 1042 Concerns: 1043 - Require two PEs in one POP 1044 - More PW 1046 A.8. Separate VSI for Root and Leaf - Internal Connection 1047 (VSI on PE split to VSIR & VSIL) 1049 <------------E-Tree------------> 1050 +---------+ +---------+ 1051 | PE1 | | PE2 | 1052 +----+ | +---+ | | +---+ | +----+ 1053 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1054 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1055 +----+ | | I | | | | I | | +----+ 1056 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1057 +----+ (Root AC) | +-+-+ | | | | +-+-+ | (Root AC) +----+ 1058 | L | | | | L | 1059 | | | \ / | | | 1060 | | | \ / | | | 1061 | | | \ / | | | 1062 Internal| | \/ | |Internal 1063 Connection| | /\ | |Connection 1064 | | | / \ | | | 1065 | | | / \ | | | 1066 | | | / \ | | | 1067 +----+ | +-+-+ | | | | +-+-+ | +----+ 1068 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1069 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1070 +----+ | | I | | | | I | | +----+ 1071 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1072 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1073 | | PWs | | 1074 +---------+ +---------+ 1076 Concerns: 1077 - Design complexity 1078 - More VSI 1079 - More PW 1080 - Some vendor implementation may require additional hardware module 1081 to support internal connection between two VSIs 1082 - Some vendor implementation may have bandwidth limitation on 1083 internal connection between two VSIs 1084 - Some vendor implementation of service-aware management system may 1085 assume only one VSI per VPLS on one PE 1087 A.9. Separate VSI for Root and Leaf - External Connection 1088 (VSI on PE split to VSIR & VSIL) 1090 <------------E-Tree------------> 1091 +---------+ +---------+ 1092 | PE1 | | PE2 | 1093 +----+ | +---+ | | +---+ | +----+ 1094 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1095 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1096 +----+ | | I | | | | I | | +----+ 1097 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1098 +----+ (Root AC) | | | | | | | | | | (Root AC) +----+ 1099 | | | | | | | | | | 1100 +------AC-X1---+-L+ | | \ / | | +L-+----AC-X2-----+ 1101 | (Leaf AC) | +---+ | \ / | +---+ | (Leaf AC) | 1102 | | | \ / | | | 1103 |External | | \/ | | External| 1104 |Connection | | /\ | | Connection| 1105 | | +---+ | / \ | +---+ | | 1106 +------AC-Y1---+--+ | | / \ | | +--+----AC-Y2-----+ 1107 (Root AC) | | | | / \ | | | | (Root AC) 1108 +----+ | | | | | | | | | | +----+ 1109 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1110 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1111 +----+ | | I | | | | I | | +----+ 1112 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1113 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1114 | | PWs | | 1115 +---------+ +---------+ 1117 Concerns: 1118 - Design complexity 1119 - More VSI 1120 - More PW 1121 - More AC (for external connection between two VSIs) 1122 - Require additional two high speed physical ports on PE to support 1123 such external connections 1124 - Some vendor implementation of service-aware management system may 1125 assume only one VSI per VPLS on one PE 1127 A.10. Separate PWs for "From Root" traffic and "From Leaf" traffic 1129 <------------E-Tree------------> 1130 +---------+ +---------+ 1131 | PE1 | | PE2 | 1132 +----+ | +---+ | | +---+ | +----+ 1133 |CE01+----AC1----+--+ | | Ethernet | | +--+----AC5----+CE05| 1134 +----+ (Root AC) | | V +--+---PW for---+--+ V | | (Root AC) +----+ 1135 +----+ | | | |"From Root" | | | | +----+ 1136 |CE02+----AC2----+--+ | | Traffic | | +--+----AC6----+CE06| 1137 +----+ (Root AC) | | S | | | | S | | (Root AC) +----+ 1138 +----+ | | | | | | | | +----+ 1139 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 1140 +----+ (Leaf AC) | | I | | Ethernet | | I | | (Leaf AC) +----+ 1141 +----+ | | +--+---PW for---+--+ | | +----+ 1142 |CE04+----AC4----+--+ | |"From Leaf" | | +--+----AC8----+CE08| 1143 +----+ (Leaf AC) | +---+ | Traffic | +---+ | (Leaf AC) +----+ 1144 | | | | 1145 +---------+ +---------+ 1147 Concerns: 1148 - More PW 1149 - Most, if not all, vendor implementation support only one PW 1150 between two VSIs on different PEs 1151 - Most, if not all, vendor implementation of service-aware management 1152 system assume only one PW between two VSIs on different PEs 1153 - Asymmetric path for bidirectional traffic between Root and Leaf on 1154 different PEs (e.g. CE01-->CE07 use the "From Root" PW, CE07-->CE01 1155 use the "From Leaf" PW) 1156 - Require extension to current standard VPLS 1157 - support two PWs between two VSIs on different PEs (both active 1158 but no loop) 1159 - share MAC learning between the "From Root" PW and "From Leaf" PW 1160 (bidirectional traffic may be on asymmetric path) 1161 - in addition to standard MAC-based forwarding, select which PW to 1162 use based on whether ingress AC is Root or Leaf 1163 - filter Leaf-to-Leaf traffic (split horizon group at PW/AC level 1164 is not good enough because of asymmetric path) 1166 A.11. "From Root" or "From Leaf" derived from source MAC address 1168 Based on the current standard VPLS, a PE has no information about ACs 1169 on another PE. 1171 This approach will need additional information exchange between 1172 ingress PE and egress PE, via OSS or peer to peer. 1174 Concerns: 1175 - Require system development or additional signaling between PEs 1176 - Not an ideal solution from security perspective because of the 1177 dynamic nature of MAC address to AC mapping 1179 A.12. Static MAC address configuration for Root AC 1181 This approach requires additional configuration on PEs 1182 - Disable MAC address learning for Root ACs 1183 - Static configuration of MAC addresses per Root AC 1184 - Add filtering for each Root AC 1185 - Drop ingress frame if source MAC address not equal to any of the 1186 static MAC addresses configured for the particular Root AC 1187 - Add filtering for each Leaf AC 1188 - Drop ingress frame if source MAC address equal to any of the 1189 static MAC addresses configured for any Root ACs of the VPLS 1190 instance 1191 - Drop egress frame if source MAC address not equal to any of the 1192 static MAC addresses configured for any Root ACs of the VPLS 1193 instance 1195 Concerns: 1196 - No MAC address learning capability for Root ACs 1197 - Need resources for maintaining the static MAC address configuration 1198 per Root AC 1200 Authors' Addresses 1202 Raymond Key 1203 Huawei 1204 Email: raymond.key@ieee.org 1206 Simon Delord 1207 Alcatel-Lucent 1208 Email: simon.delord@gmail.com 1210 Frederic Jounay 1211 Orange France Telecom 1212 2, avenue Pierre-Marzin 1213 22307 Lannion Cedex, France 1214 Email: frederic.jounay@orange.com 1216 Lucy Yong 1217 Huawei USA 1218 1700 Alma Dr. Suite 500 1219 Plano, TX 75075, USA 1220 Email: lucy.yong@huawei.com 1222 Lizhong Jin 1223 ZTE Corporation 1224 889, Bibo Road 1225 Shanghai, 201203, China 1226 Email: lizhong.jin@zte.com.cn 1228 Yuji Kamite 1229 NTT Communications Corporation 1230 Granpark Tower 1231 3-4-1 Shibaura, Minato-ku 1232 Tokyo 108-8118, Japan 1233 Email: y.kamite@ntt.com 1235 Wim Henderickx 1236 Alcatel-Lucent 1237 Copernicuslaan 50 1238 2018 Antwerp, Belgium 1239 Email: wim.henderickx@alcatel-lucent.com 1241 Copyright Notice 1243 Copyright (c) 2011 IETF Trust and the persons identified as the 1244 document authors. All rights reserved. 1246 This document is subject to BCP 78 and the IETF Trust's Legal 1247 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 1248 license-info) in effect on the date of publication of this document. 1249 Please review these documents carefully, as they describe your rights 1250 and restrictions with respect to this document.