idnits 2.17.1 draft-ietf-l2vpn-etree-frwk-00.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 (January 30, 2012) is 4463 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 (editor), Huawei 3 Internet Draft Simon Delord, Alcatel-Lucent 4 Category: Informational Frederic Jounay, Orange CH 5 Expires: July 2012 Lucy Yong, Huawei 6 Lizhong Jin, ZTE 7 Yuji Kamite, NTT Communications 8 Wim Henderickx, Alcatel-Lucent 10 January 30, 2012 12 A Framework for E-Tree Service over MPLS Network 13 draft-ietf-l2vpn-etree-frwk-00 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 July 30, 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...........................................18 85 Authors' Addresses................................................28 86 Intellectual Property and Copyright Statements....................29 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 | | Reference: [TR-101] | | | 373 +---+---------------------------+--------------+------------+ 374 | 6 | Broadcast Video | Video Source | Subscriber | 375 | | (unidirectional only) | | | 376 +---+---------------------------+--------------+------------+ 377 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 378 | | plus Control Channel | | | 379 +---+---------------------------+--------------+------------+ 380 | 8 | Device Management | Management | Managed | 381 | | | System | Device | 382 +---+---------------------------+--------------+------------+ 384 Table 1: E-Tree Use cases 386 Common to all use cases, direct Layer 2 Leaf-to-Leaf communication is 387 not required. For Mobile backhaul, this may not be valid for LTE X2 388 interfaces in the future. 390 If direct Layer 2 Leaf-to-Leaf communication is not allowed due to 391 security concern, then E-Tree should be used to prohibit 392 communication between Leaf endpoints, otherwise E-LAN is also a 393 feasible option. 395 Also common to the use cases mentioned above, there may be single or 396 multiple Root endpoints in one E-Tree service. The need for multiple 397 Root endpoints is usually driven by redundancy requirement. Whether 398 a particular E-Tree service needs to support single or multiple Root 399 endpoints depends on the target application. 401 A generic E-Tree service supports all the following traffic flows: 402 - Ethernet Unicast from Root to Leaf 403 - Ethernet Unicast from Leaf to Root 404 - Ethernet Unicast from Root to Root 405 - Ethernet Broadcast/Multicast from Root to Roots & Leafs 406 - Ethernet Broadcast/Multicast from Leaf to Roots 407 A particular E-Tree service may need to support all the above or only 408 a subset depending on the target application. 410 Among the use cases mentioned above, broadcast video draws most 411 attention. Actually, broadcast video is a representing example for 412 content delivery in general, such as news feed, financial data 413 feed, etc. 415 4. Challenges 417 4.1. Generic E-Tree Service Definition 419 This section highlights why the current standard VPLS is insufficient 420 for emulating E-Tree service over MPLS network. 422 4.1.1. Mandatory Leaf-to-Leaf Communication Restriction 424 Current standard VPLS treats all ACs equal (i.e. not classified into 425 Root or Leaf) and provides any-to-any connectivity among all ACs. The 426 current standard VPLS does not include any mechanism of communication 427 restriction between specific ACs, therefore is insufficient for 428 emulating generic E-Tree service over MPLS network. 430 A problem occurs when there are two or more PEs with both Root AC and 431 Leaf AC. 433 Let's look at the scenario illustrated in Figure 2 below. VPLS is 434 used to emulate an E-Tree service over a MPLS network. 436 Note: Figure 2 is a hypothetical case solely for explaining the 437 problem, and not meant to represent a typical E-Tree service. 439 <------------E-Tree------------> 440 +---------+ +---------+ 441 | PE1 | | PE2 | 442 +---+ | +---+ | | +---+ | +---+ 443 |CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3| 444 +---+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +---+ 445 | | S +--+-----PW-----+--+ S | | 446 +---+ | | I | | | | I | | +---+ 447 |CE2+-----AC2----+--+ | | | | +--+----AC4-----+CE4| 448 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 449 +---------+ +---------+ 451 Figure 2: Problem Scenario for Leaf-to-Leaf Communication Restriction 452 When PE2 receives a frame from PE1 via the Ethernet PW, 453 - PE2 does not know which AC on PE1 is the ingress AC 454 - PE2 does not know whether the ingress AC is a Leaf AC or not 455 - PE2 does not have sufficient information to enforce the 456 Leaf-to-Leaf communication restriction 458 Examples: 459 - CE2 sends a Broadcast/Multicast frame to PE1 via AC2 460 - CE2 sends a Unicast frame to PE1 via AC2, destination address in 461 Ethernet header equal to CE4's MAC address 463 In order to fulfil the generic E-Tree service definition, extension 464 to the current VPLS standard will be required. Extension to related 465 PWE3 standard may also be required, depending on solution approach. 466 Such extensions should have minimal impact on the emulated E-LAN 467 services already in operation. 469 There are some possible ways to get around this problem that do not 470 require extension to the current VPLS standard but they all come with 471 significant design complexity or deployment constraints. Appendix A 472 highlights the major ones and the related concerns. 474 4.2. Use Case Desirable Requirements 476 There are quite a variety of use cases for E-Tree. For some use 477 cases, the generic MEF E-Tree service definition is good enough. For 478 some other use cases, there are desirable requirements beyond that. 480 The challenges discussed in this section are not related to the 481 generic MEF E-Tree service definition but the desirable requirements 482 of specific use cases. They may be critical to the success in some 483 E-Tree services while totally irrelevant in some others. 485 4.2.1. Ethernet Broadcast/Multicast Optimisation 487 According to MAC-based forwarding, an Ethernet broadcast/multicast/ 488 unicast unknown frame is forwarded to all ACs other than the ingress 489 AC, which implies point-to-multipoint traffic from the ingress PE to 490 all other PEs in the VPLS instance. 492 The current standard VPLS uses only point-to-point PW between PEs. 493 When the Ethernet destination address is broadcast, multicast or 494 unicast unknown, the ingress PE replicates the frame on every PW 495 towards remote PE belonging to the same VPLS instance. Depending on 496 the mapping between the logical topology of the E-Tree service and 497 the physical topology of the network, multiple PWs may transverse 498 same physical link, result in multiple copies of the same payload 499 Ethernet frame on the physical link. Such approach is inefficient in 500 terms of bandwidth usage. 502 For some use cases, for example broadcast/multicast video, due to 503 nature of the application, there is significant volume of point-to- 504 multipoint traffic. Bandwidth optimisation for such traffic within 505 the network becomes a concern from the service provider perspective. 507 [RFC5501] provides an in-depth discussion on broadcast/multicast 508 related requirements for VPLS, see issue B (Replication of PWs on 509 shared physical path) in section 3.2. 511 4.2.2. IP Multicast Optimisation 513 The current standard VPLS is a L2VPN service agnostic to customer's 514 Layer 3 traffic, hence does not maintain any information about IP 515 multicast group membership. Although a Layer 3 IP multicast packet is 516 encapsulated in a Layer 2 Ethernet multicast frame, the current 517 standard VPLS treats Ethernet multicast frame in exactly the same way 518 as Ethernet broadcast frame. Therefore, such payload IP multicast 519 packet will be forwarded to every other AC of the same VPLS instance. 521 A payload IP multicast packet will be forwarded to all ACs, including 522 those with no member of the specific IP multicast group attached. 523 Unnecessary traffic consumes bandwidth on access link and may become 524 a concern from the customer perspective. In some cases, it may also 525 be a security concern as the multicast frame may be forwarded to an 526 endpoint other than the intended destinations. 528 A payload IP multicast packet will be forwarded to a remote PE with 529 no member of the specific IP multicast group attached. Unnecessary 530 traffic consumes bandwidth in the network and may become a concern 531 from the service provider perspective. 533 For some use cases, for example multicast video, due to nature of the 534 application, there is significant volume of IP multicast traffic and 535 different IP multicast groups are required in one E-Tree service. The 536 above may become a real concern from both the customer and service 537 provider perspectives. 539 [RFC5501] provides an in-depth discussion on broadcast/multicast 540 related requirements for VPLS, see both issue A (Replication to non- 541 member site) and issue B (Replication of PWs on shared physical path) 542 in section 3.2. 544 4.2.3. MAC-based Forwarding Unnecessary 546 For some use cases, for example broadcast video, due to nature of the 547 application, there is only broadcast unidirectional traffic from Root 548 to all other endpoints. It is unnecessary to use destination address 549 for data forwarding. Deliver unconditionally for ingress frame at 550 Root endpoint may be a simpler approach than MAC-based forwarding. 552 4.2.4. MAC-based Forwarding Security Concern 554 MAC-based forwarding will make an unicast frame from a Root destined 555 for a specific Leaf being forwarded to other endpoints in addition to 556 the intended destination when the frame is classified as unicast 557 unknown, may be due to MAC address aged out or MAC address table 558 overflow. 560 MAC address spoofing may cause an unicast frame from a Root destined 561 for a specific Leaf being forwarded to an endpoint different from the 562 intended destination. 564 If such unicast frame carries sensitive information strictly for the 565 intended destination only, then the MAC-based forwarding may cause a 566 security concern from the customer perspective. 568 For some use cases where mutually un-trusted subscribers are 569 connected to leaf endpoints in the same E-Tree service, such as 570 Internet access and wholesale access, this is a valid concern. 572 There are some possible mitigations: 573 - For every Leaf endpoint of the particular E-Tree service, deploy 574 a service provider controlled router between the Leaf endpoint 575 and the customer network 576 - Customer to deploy encryption for sensitive information, for 577 example IPsec, SSL, SSH, HTTPS 579 Whether the MAC-based forwarding really becomes a security concern 580 depends on the particular application and the deployment scenario. 581 This is unlikely to be a critical concern in most cases. 583 5. A Solution Framework for MAC-based Forwarding E-Tree 585 As mentioned in section 1.3.1. E-Tree can use MAC-based forwarding or 586 something else for data forwarding. This section presents a solution 587 framework for MAC-based forwarding E-Tree. Section 6 will discuss 588 other variants. 590 This is a VPLS-based solution. Functional components of the solution 591 are identified and discussed in the subsections. 593 5.1. MAC-based Forwarding Any-to-Any Ethernet VPN 595 This is a REQUIRED component. 597 This component is the current standard VPLS and PWE3 as specified in 598 [RFC4385] [RFC4447] [RFC4448] [RFC4761] [RFC4762], which provides 599 any-to-any connectivity among all ACs in one VPLS instance. 601 This is the base component. All other REQUIRED/OPTIONAL components 602 are to be added on top of this component. 604 5.2. Leaf-to-Leaf Communication Restriction 606 This is in response to the challenge in section 4.1.1. Mandatory 607 Leaf-to-Leaf Communication Restriction. 609 This is a REQUIRED component. 611 This component is a minimal extension to the current VPLS and PWE3 612 standards, with the objective to provide a simple and effective way 613 to support generic E-Tree services in addition to E-LAN services 614 using VPLS on a MPLS network. 616 [Draft VPLS ETree Req] is a work in progress requirement draft. 618 Different solutions have been proposed: 619 - Control Word L-bit solution, [Draft CW L-bit] [Draft VPLS ETree] 620 - Dual VLAN solution, [Draft VPLS PE ETree] 621 - Two PW solution, [Draft VPLS ETree 2PW] 622 - Two VE ID solution [Draft VPLS ETree 2VEID] 624 5.3. Optional Enhancement - Point-to-Multipoint PW 626 This is in response to the challenge in section 4.2.1. Ethernet 627 Broadcast/Multicast Optimisation. 629 This is an OPTIONAL component, applicable only when there is 630 significant volume of Ethernet broadcast/multicast traffic. 632 Point-to-Multipoint pseudowire (P2MP PW) is a PW attached to a source 633 used to distribute Layer 1 or Layer 2 format traffic to a set of 634 receivers. P2MP PW is unidirectional but optionally bidirectional. 636 By using P2MP PW, the ingress PE is not responsible for replicating 637 the payload frame on each P2P PW towards egress PE, instead the 638 network elements along the physical path participate in replication. 639 The replication is done by the underlying point-to-multipoint label 640 switched path (P2MP LSP). 642 Extension to current VPLS standard will be required to specify how 643 P2MP PW and P2P PW should be used and how MAC learning works on P2MP 644 PW. Please refer to [Draft LDP-VPLS Bcast]. 646 P2MP PW is currently under development. Please refer to [Draft P2MP 647 PW Req] [Draft P2MP PW Sig]. 649 It is important to note that this component will align with the 650 recommendation in [RFC4665], 651 "With the exception of IPLS, an L2VPN service SHOULD be agnostic to 652 customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated 653 within Layer 2 frames." 655 5.4. Optional Enhancement - IP Multicast in VPLS 657 This is in response to the challenge in section 4.2.2. IP Multicast 658 Optimisation. 660 This is an OPTIONAL component, applicable only when there is 661 significant volume of IP multicast traffic and different IP multicast 662 groups are required in one E-Tree service. 664 Multicast in VPLS is currently under development, with the objective 665 to provide efficient ways to support IP multicast services over VPLS. 666 It covers IP multicast group membership control and also bandwidth 667 optimisation. Please refer to [Draft Mcast VPLS]. 669 It is important to note that this component will make use of Layer 3 670 IP multicast information in payload frames to improve transport 671 efficiency, hence will not align with the recommendation in [RFC4665] 672 that an L2VPN service SHOULD be agnostic to customer's Layer 3 673 traffic. 675 6. Non-MAC-based Forwarding E-Tree 677 This section presents some variants of E-Tree services which do not 678 use MAC-based forwarding as the service frame delivery attribute. 680 6.1. Single Root, Broadcast Only - VPMS 682 This is in response to the challenge in section 4.2.3. MAC-based 683 Forwarding Unnecessary. 685 VPMS provides single coverage of receiver membership. Destination 686 address in Ethernet frame is not used in data forwarding. 688 For E-Tree service of single Root and only unidirectional broadcast 689 traffic from the Root, for example certain broadcast video or similar 690 content delivery applications, VPMS will be a much more simple and 691 effective solution than VPLS. 693 VPMS is currently under development. Please refer to [Draft VPMS 694 Frmwk]. 696 6.2. Multiple Roots, Broadcast and Unicast 698 This is in response to the challenge in section 4.2.4. MAC-based 699 Forwarding Security Concern. 701 This will be added in later version of this document. 703 7. Security Considerations 705 This will be added in later version of this document. 707 8. IANA Considerations 709 This will be added in later version of this document. 711 9. Acknowledgements 713 This will be added in later version of this document. 715 10. References 717 10.1. Normative References 719 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - 720 Phase 2, April 2008 722 [MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes 723 Phase 2, October 2009 725 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 726 Requirement Levels, BCP 14, RFC 2119, March 1997 728 [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation 729 Edge-to-Edge (PWE3) Control Word for Use over an MPLS 730 PSN, February 2006. 732 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 733 Using the Label Distribution Protocol (LDP), April 2006 735 [RFC4448] Martini, L., and al, Encapsulation Methods for 736 Transport of Ethernet over MPLS Networks, April 2006 738 [RFC4665] Augustyn & Serbest, Service Requirements for Layer 2 739 Provider-Provisioned Virtual Private Networks, 740 September 2006 742 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) 743 Using BGP for Auto-Discovery and Signaling, January 2007 745 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 746 Using Label Distribution Protocol (LDP) Signaling, 747 January 2007 749 [RFC5501] Kamite, et al., Requirements for Multicast Support in 750 Virtual Private LAN Services, March 2009 752 10.2. Informative References 754 [TR-101] Broadband Forum, Migration to Ethernet-Based Broadband 755 Aggregation Issue 2, July 2011 757 [Draft VPLS ETree Req] 758 Key, et al., Requirements for MEF E-Tree Support in 759 VPLS, draft-ietf-l2vpn-etree-reqt-00 (work in progress), 760 October 2011 762 [Draft CW L-bit] 763 Delord, et al., Control Word Reserved bit for use in 764 E-Tree, draft-delord-pwe3-cw-bit-etree-06 (work in 765 progress), October 2011 767 [Draft VPLS ETree] 768 Key, et al., Extension to VPLS for E-Tree, 769 draft-key-l2vpn-vpls-etree-06 (work in progress), 770 October 2011 772 [Draft VPLS PE ETree] 773 Jiang, et al., VPLS PE Model for E-Tree Support, 774 draft-jiang-l2vpn-vpls-pe-etree-05 (work in progress), 775 October 2011 777 [Draft VPLS ETree 2PW] 778 Ram, et al., Extension to LDP-VPLS for E-Tree Using Two 779 PW, draft-ram-l2vpn-ldp-vpls-etree-2pw-02 (work in 780 progress), May 2011 782 [Draft VPLS ETree 2VEID] 783 Cao, Extension to VPLS for E-Tree, 784 draft-cao-l2vpn-vpls-etree-02 (work in progress), 785 January 2012 787 [Draft P2MP PW Req] 788 Jounay, et al., Requirements for Point-to-Multipoint 789 Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-05 790 (work in progress), September 2011 792 [Draft P2MP PW Sig] 793 Boutros, et al., Signaling Root-Initiated Point-to- 794 Multipoint Pseudowires using LDP, 795 draft-ietf-pwe3-p2mp-pw-03 (work in progress), 796 October 2011 798 [Draft LDP-VPLS Bcast] 799 Delord, et al., Extension to LDP-VPLS for Ethernet 800 Broadcast and Multicast, 801 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-03 (work in 802 progress), December 2011 804 [Draft Mcast VPLS] 805 Raggarwa, Kamite & Fang, Multicast in VPLS, 806 draft-ietf-l2vpn-vpls-mcast-09 (work in progress), 807 July 2011 809 [Draft VPMS Frmwk] 810 Kamite, et al., Framework and Requirements for Virtual 811 Virtual Private Multicast Service (VPMS), 812 draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in 813 progress), July 2011 815 Appendix A. Some Possible Ways for Leaf-to-Leaf Communication 816 Restriction 818 This appendix briefly describes the following approaches: 819 - Single Root Only (A.1) 820 - Only one PE has Roots (A.2) 821 - Only one PE with both Root & Leaf 822 - Backhaul Root (A.3) 823 - Backhaul Leaf (A.4) 824 - H-VPLS Root (A.5) 825 - H-VPLS Leaf (A.6) 826 - Separate PEs for Root and Leaf (A.7) 827 - Separate VSI for Root and Leaf 828 - Internal Connection (A.8) 829 - External Connection (A.9) 830 - Separate PWs for "From Root" traffic and "From Leaf" traffic (A.10) 831 - "From Root" or "From Leaf" derived from source MAC address (A.11) 832 - Static MAC address configuration for Root AC (A.12) 834 Reference Model for Leaf-to-Leaf Communication Restriction 836 <------------E-Tree------------> 837 +---------+ +---------+ 838 | PE1 | | PE2 | 839 +----+ | +---+ | | +---+ | +----+ 840 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 841 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 842 +----+ | | | | | | | | +----+ 843 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 844 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 845 +----+ | | | | | | | | +----+ 846 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 847 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 848 +----+ | | | | | | | | +----+ 849 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 850 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 851 | | | | 852 +---------+ +---------+ 854 For the diagrams in this appendix, "L" indicates the particular AC or 855 PW belonging to the PE local split horizon group specifically for 856 Leaf-to-Leaf Communication Restriction. No communication is allowed 857 between any two members of a split horizon group. 859 A.1. Single Root Only 861 <------------E-Tree------------> 862 +---------+ +---------+ 863 | PE1 | | PE2 | 864 +----+ | +---+ | | +---+ | 865 |CE01+----AC1----+--+ | | | | | | 866 +----+ (Root AC) | | V | | | | V | | 867 | | | | | | | | 868 | | | | Ethernet | | | | 869 | | S +L-+-----PW-----+--+ S | | 870 +----+ | | | | | | | | +----+ 871 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 872 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 873 +----+ | | | | | | | | +----+ 874 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 875 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 876 | | | | 877 +---------+ +---------+ 879 Concerns: 880 - Not fulfil multi-Root requirement of generic MEF E-Tree service 881 definition 883 A.2. Only one PE has Roots 885 <------------E-Tree------------> 886 +---------+ +---------+ 887 | PE1 | | PE2 | 888 +----+ | +---+ | | +---+ | 889 |CE01+----AC1----+--+ | | | | | | 890 +----+ (Root AC) | | V | | | | V | | 891 +----+ | | | | | | | | 892 |CE02+----AC2----+--+ | | Ethernet | | | | 893 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | 894 +----+ | | | | | | | | +----+ 895 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 896 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 897 +----+ | | | | | | | | +----+ 898 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 899 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 900 | | | | 901 +---------+ +---------+ 903 Concerns: 904 - Deployment constraint 906 A.3. Only one PE with both Root & Leaf - Backhaul Root 908 +---AC5(Root AC)---------------------------+ 909 | | 910 | +-AC6(Root AC)----------------------+ | 911 | | | | 912 | | | | 913 | | | | 914 +---+-+---+ +---------+ | | 915 | | | | | | | | 916 +----+ | ++-++ | | +---+ | | +-+--+ 917 |CE01+----AC1----+--+ | | | | | | | |CE05| 918 +----+ (Root AC) | | V | | | | V | | | +----+ 919 +----+ | | | | | | | | | +----+ 920 |CE02+----AC2----+--+ | | Ethernet | | | | +--+CE06| 921 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | +----+ 922 +----+ | | | | | | | | +----+ 923 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 924 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 925 +----+ | | | | | | | | +----+ 926 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 927 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 928 | PE1 | | PE2 | 929 +---------+ +---------+ 930 <------------E-Tree------------> 932 Concerns: 933 - Deployment constraint 934 - Long fibre path 936 A.4. Only one PE with both Root & Leaf - Backhaul Leaf 938 <------------E-Tree------------> 939 +---------+ +---------+ 940 | PE1 | | PE2 | 941 +----+ | +---+ | | +---+ | +----+ 942 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 943 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 944 +----+ | | | | | | | | +----+ 945 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 946 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 947 +----+ | | | | | | | | +----+ 948 |CE03+----AC3----+-L+ | | | | | | +--+CE07| 949 +----+ (Leaf AC) | | I | | | | I | | | +----+ 950 +----+ | | | | | | | | | +----+ 951 |CE04+----AC4----+-L+ | | | | | | | |CE08| 952 +----+ (Leaf AC) | ++-++ | | +---+ | | +-+--+ 953 | L L | | | | | 954 +---+-+---+ +---------+ | | 955 | | | | 956 | | | | 957 | | | | 958 | +-AC7(Leaf AC)----------------------+ | 959 | | 960 +---AC8(Leaf AC)---------------------------+ 962 Concerns: 963 - Deployment constraint 964 - Long fibre path 966 A.5. Only one PE with both Root & Leaf - H-VPLS Root 968 <------------E-Tree------------> 969 +---------+ +---------+ 970 | PE1 | | PE2 | 971 +----+ | +---+ | Ethernet | | +----+ 972 |CE01+----AC1----+--+ +--+-----PW-----+---------+----AC5----+CE05| 973 +----+ (Root AC) | | V | | | | (Root AC) +----+ 974 +----+ | | | | Ethernet | | +----+ 975 |CE02+----AC2----+--+ +--+-----PW-----+---------+----AC6----+CE06| 976 +----+ (Root AC) | | S | | | +---+ | (Root AC) +----+ 977 +----+ | | | | | | | | +----+ 978 |CE03+----AC3----+-L+ | | Ethernet | | V +L-+----AC7----+CE07| 979 +----+ (Leaf AC) | | I +L-+-----PW-----+--+ S | | (Leaf AC) +----+ 980 +----+ | | | | | | I | | +----+ 981 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 982 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 983 | | | | 984 +---------+ +---------+ 986 Concerns: 987 - Design complexity 988 - More PW 989 - Hair pinning (e.g. CE05 to CE06/07/08) impact bandwidth and delay 991 A.6. Only one PE with both Root & Leaf - H-VPLS Leaf 993 <------------E-Tree------------> 994 +---------+ +---------+ 995 | PE1 | | PE2 | 996 +----+ | +---+ | | +---+ | +----+ 997 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 998 +----+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +----+ 999 +----+ | | +--+-----PW-----+--+ S | | +----+ 1000 |CE02+----AC2----+--+ | | | | I +--+----AC6----+CE06| 1001 +----+ (Root AC) | | S | | | | | | (Root AC) +----+ 1002 +----+ | | | | Ethernet | +---+ | +----+ 1003 |CE03+----AC3----+-L+ +L-+-----PW-----+---------+----AC7----+CE07| 1004 +----+ (Leaf AC) | | I | | | | (Leaf AC) +----+ 1005 +----+ | | | | Ethernet | | +----+ 1006 |CE04+----AC4----+-L+ +L-+-----PW-----+---------+----AC8----+CE08| 1007 +----+ (Leaf AC) | +---+ | | | (Leaf AC) +----+ 1008 | | | | 1009 +---------+ +---------+ 1011 Concerns: 1012 - Design complexity 1013 - More PW 1014 - Hair pinning (e.g. CE08 to CE05/06) impact bandwidth and delay 1016 A.7. Separate PEs for Root and Leaf 1017 (PE2 split to PE2R & PE2L) 1019 <------------E-Tree------------> 1020 +---------+ +---------+ 1021 | PE1 | | PE2R | 1022 +----+ | +---+ | | +---+ | +----+ 1023 |CE01+----AC1----+--+ | | Ethernet | | V +--+----AC5----+CE05| 1024 +----+ (Root AC) | | V +--+-----PW-----+--+ S | | (Root AC) +----+ 1025 +----+ | | | | | | I | | +----+ 1026 |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06| 1027 +----+ (Root AC) | | S | | | +-+-+ | (Root AC) +----+ 1028 +----+ | | | | | L | 1029 |CE03+----AC3----+-L+ | | +----+----+ 1030 +----+ (Leaf AC) | | I | | | 1031 +----+ | | | | |Ethernet 1032 |CE04+----AC4----+-L+ | | |PW 1033 +----+ (Leaf AC) | +-+-+ | | 1034 | L | +----+----+ 1035 +----+----+ | | | 1036 | | +-+-+ | +----+ 1037 | Ethernet | | V +L-+----AC7----+CE07| 1038 +----------PW-----+--+ S | | (Leaf AC) +----+ 1039 | | I | | +----+ 1040 | | +L-+----AC8----+CE08| 1041 | +---+ | (Leaf AC) +----+ 1042 | PE2L | 1043 +---------+ 1044 <------------E-Tree------------> 1046 Concerns: 1047 - Require two PEs in one POP 1048 - More PW 1050 A.8. Separate VSI for Root and Leaf - Internal Connection 1051 (VSI on PE split to VSIR & VSIL) 1053 <------------E-Tree------------> 1054 +---------+ +---------+ 1055 | PE1 | | PE2 | 1056 +----+ | +---+ | | +---+ | +----+ 1057 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1058 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1059 +----+ | | I | | | | I | | +----+ 1060 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1061 +----+ (Root AC) | +-+-+ | | | | +-+-+ | (Root AC) +----+ 1062 | L | | | | L | 1063 | | | \ / | | | 1064 | | | \ / | | | 1065 | | | \ / | | | 1066 Internal| | \/ | |Internal 1067 Connection| | /\ | |Connection 1068 | | | / \ | | | 1069 | | | / \ | | | 1070 | | | / \ | | | 1071 +----+ | +-+-+ | | | | +-+-+ | +----+ 1072 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1073 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1074 +----+ | | I | | | | I | | +----+ 1075 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1076 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1077 | | PWs | | 1078 +---------+ +---------+ 1080 Concerns: 1081 - Design complexity 1082 - More VSI 1083 - More PW 1084 - Some vendor implementation may require additional hardware module 1085 to support internal connection between two VSIs 1086 - Some vendor implementation may have bandwidth limitation on 1087 internal connection between two VSIs 1088 - Some vendor implementation of service-aware management system may 1089 assume only one VSI per VPLS on one PE 1091 A.9. Separate VSI for Root and Leaf - External Connection 1092 (VSI on PE split to VSIR & VSIL) 1094 <------------E-Tree------------> 1095 +---------+ +---------+ 1096 | PE1 | | PE2 | 1097 +----+ | +---+ | | +---+ | +----+ 1098 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1099 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1100 +----+ | | I | | | | I | | +----+ 1101 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1102 +----+ (Root AC) | | | | | | | | | | (Root AC) +----+ 1103 | | | | | | | | | | 1104 +------AC-X1---+-L+ | | \ / | | +L-+----AC-X2-----+ 1105 | (Leaf AC) | +---+ | \ / | +---+ | (Leaf AC) | 1106 | | | \ / | | | 1107 |External | | \/ | | External| 1108 |Connection | | /\ | | Connection| 1109 | | +---+ | / \ | +---+ | | 1110 +------AC-Y1---+--+ | | / \ | | +--+----AC-Y2-----+ 1111 (Root AC) | | | | / \ | | | | (Root AC) 1112 +----+ | | | | | | | | | | +----+ 1113 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1114 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1115 +----+ | | I | | | | I | | +----+ 1116 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1117 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1118 | | PWs | | 1119 +---------+ +---------+ 1121 Concerns: 1122 - Design complexity 1123 - More VSI 1124 - More PW 1125 - More AC (for external connection between two VSIs) 1126 - Require additional two high speed physical ports on PE to support 1127 such external connections 1128 - Some vendor implementation of service-aware management system may 1129 assume only one VSI per VPLS on one PE 1131 A.10. Separate PWs for "From Root" traffic and "From Leaf" traffic 1133 <------------E-Tree------------> 1134 +---------+ +---------+ 1135 | PE1 | | PE2 | 1136 +----+ | +---+ | | +---+ | +----+ 1137 |CE01+----AC1----+--+ | | Ethernet | | +--+----AC5----+CE05| 1138 +----+ (Root AC) | | V +--+---PW for---+--+ V | | (Root AC) +----+ 1139 +----+ | | | |"From Root" | | | | +----+ 1140 |CE02+----AC2----+--+ | | Traffic | | +--+----AC6----+CE06| 1141 +----+ (Root AC) | | S | | | | S | | (Root AC) +----+ 1142 +----+ | | | | | | | | +----+ 1143 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 1144 +----+ (Leaf AC) | | I | | Ethernet | | I | | (Leaf AC) +----+ 1145 +----+ | | +--+---PW for---+--+ | | +----+ 1146 |CE04+----AC4----+--+ | |"From Leaf" | | +--+----AC8----+CE08| 1147 +----+ (Leaf AC) | +---+ | Traffic | +---+ | (Leaf AC) +----+ 1148 | | | | 1149 +---------+ +---------+ 1151 Concerns: 1152 - More PW 1153 - Most, if not all, vendor implementation support only one PW 1154 between two VSIs on different PEs 1155 - Most, if not all, vendor implementation of service-aware management 1156 system assume only one PW between two VSIs on different PEs 1157 - Asymmetric path for bidirectional traffic between Root and Leaf on 1158 different PEs (e.g. CE01-->CE07 use the "From Root" PW, CE07-->CE01 1159 use the "From Leaf" PW) 1160 - Require extension to current standard VPLS 1161 - support two PWs between two VSIs on different PEs (both active 1162 but no loop) 1163 - share MAC learning between the "From Root" PW and "From Leaf" PW 1164 (bidirectional traffic may be on asymmetric path) 1165 - in addition to standard MAC-based forwarding, select which PW to 1166 use based on whether ingress AC is Root or Leaf 1167 - filter Leaf-to-Leaf traffic (split horizon group at PW/AC level 1168 is not good enough because of asymmetric path) 1170 A.11. "From Root" or "From Leaf" derived from source MAC address 1172 Based on the current standard VPLS, a PE has no information about ACs 1173 on another PE. 1175 This approach will need additional information exchange between 1176 ingress PE and egress PE, via OSS or peer to peer. 1178 Concerns: 1179 - Require system development or additional signaling between PEs 1180 - Not an ideal solution from security perspective because of the 1181 dynamic nature of MAC address to AC mapping 1183 A.12. Static MAC address configuration for Root AC 1185 This approach requires additional configuration on PEs 1186 - Disable MAC address learning for Root ACs 1187 - Static configuration of MAC addresses per Root AC 1188 - Add filtering for each Root AC 1189 - Drop ingress frame if source MAC address not equal to any of the 1190 static MAC addresses configured for the particular Root AC 1191 - Add filtering for each Leaf AC 1192 - Drop ingress frame if source MAC address equal to any of the 1193 static MAC addresses configured for any Root ACs of the VPLS 1194 instance 1195 - Drop egress frame if source MAC address not equal to any of the 1196 static MAC addresses configured for any Root ACs of the VPLS 1197 instance 1199 Concerns: 1200 - No MAC address learning capability for Root ACs 1201 - Need resources for maintaining the static MAC address configuration 1202 per Root AC 1204 Authors' Addresses 1206 Raymond Key (editor) 1207 Huawei 1208 Email: raymond.key@ieee.org 1210 Simon Delord 1211 Alcatel-Lucent 1212 Email: simon.delord@gmail.com 1214 Frederic Jounay 1215 Orange CH 1216 4 rue caudray 1020 Renens 1217 Switzerland 1218 Email: frederic.jounay@orange.ch 1220 Lucy Yong 1221 Huawei USA 1222 1700 Alma Dr. Suite 500 1223 Plano, TX 75075, USA 1224 Email: lucy.yong@huawei.com 1226 Lizhong Jin 1227 ZTE Corporation 1228 889, Bibo Road 1229 Shanghai, 201203, China 1230 Email: lizhong.jin@zte.com.cn 1232 Yuji Kamite 1233 NTT Communications Corporation 1234 Granpark Tower 1235 3-4-1 Shibaura, Minato-ku 1236 Tokyo 108-8118, Japan 1237 Email: y.kamite@ntt.com 1239 Wim Henderickx 1240 Alcatel-Lucent 1241 Copernicuslaan 50 1242 2018 Antwerp, Belgium 1243 Email: wim.henderickx@alcatel-lucent.com 1245 Copyright Notice 1247 Copyright (c) 2012 IETF Trust and the persons identified as the 1248 document authors. All rights reserved. 1250 This document is subject to BCP 78 and the IETF Trust's Legal 1251 Provisions Relating to IETF Documents 1252 (http://trustee.ietf.org/license-info) in effect on the date of 1253 publication of this document. Please review these documents 1254 carefully, as they describe your rights and restrictions with respect 1255 to this document. Code Components extracted from this document must 1256 include Simplified BSD License text as described in Section 4.e of 1257 the Trust Legal Provisions and are provided without warranty as 1258 described in the Simplified BSD License.