idnits 2.17.1 draft-ietf-l2vpn-etree-frwk-03.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 (September 6, 2013) is 3884 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) 3 Internet Draft Simon Delord, Telstra 4 Category: Informational Frederic Jounay, Orange CH 5 Expires: March 2014 Lucy Yong, Huawei 6 Lizhong Jin 7 Yuji Kamite, NTT Communications 8 Wim Henderickx, Alcatel-Lucent 10 September 6, 2013 12 A Framework for E-Tree Service over MPLS Network 13 draft-ietf-l2vpn-etree-frwk-03 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 March 6, 2014. 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.4.3. Ethernet VPN (E-VPN)........................................6 59 1.5. Terminology...................................................6 60 2. Reference Model.................................................6 61 3. Use Cases.......................................................8 62 4. Challenges......................................................9 63 4.1. Generic E-Tree Service Definition.............................9 64 4.1.1. Mandatory Leaf-to-Leaf Communication Restriction............9 65 4.2. Use Case Desirable Requirements..............................10 66 4.2.1. Ethernet Broadcast/Multicast Optimisation..................10 67 4.2.2. IP Multicast Optimisation..................................11 68 4.2.3. MAC-based Forwarding Unnecessary...........................11 69 4.2.4. MAC-based Forwarding Security Concern......................12 70 5. A Solution Framework for MAC-based Forwarding E-Tree...........12 71 5.1. VPLS Solution................................................12 72 5.1.1. MAC-based Forwarding Any-to-Any Ethernet VPN...............12 73 5.1.2. Leaf-to-Leaf Communication Restriction.....................13 74 5.1.3. Optional Enhancement - Point-to-Multipoint PW..............13 75 5.1.4. Optional Enhancement - IP Multicast in VPLS........ .......14 76 5.2. E-VPN Solution...............................................14 77 6. Non-MAC-based Forwarding E-Tree................................14 78 6.1. Single Root, Broadcast Only - VPMS...........................14 79 6.2. Multiple Roots, Broadcast and Unicast........................14 80 6.3. E-VPN Solution...............................................15 81 7. Security Consideration.........................................15 82 8. IANA Considerations............................................15 83 9. Acknowledgements...............................................15 84 10. References....................................................15 85 10.1. Normative References........................................15 86 10.2. Informative References......................................16 87 Appendix A. Some Possible Ways for Leaf-to-Leaf Communication 88 Restriction...........................................18 89 Authors' Addresses................................................28 90 Intellectual Property and Copyright Statements....................29 92 Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 1. Introduction 100 1.1. Objective and Scope 102 This document proposes a solution framework for supporting Metro 103 Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a MPLS 104 network. The objective is to provide a simple and effective approach 105 to emulate E-Tree services in addition to Ethernet LAN (E-LAN) 106 services on an existing MPLS network. 108 This solution framework makes use of existing IETF specified 109 mechanisms unless there are technical reasons why the existing 110 mechanisms are insufficient or unnecessary. 112 This document does not intend to provide a full specification of the 113 solution, but rather to identify the functional components of the 114 overall solution, and for each component, whether it is REQUIRED or 115 OPTIONAL, whether existing mechanism is sufficient, or whether 116 relevant mechanism is already under development. 118 In this document, "current standard" refers to [RFC4385], [RFC4447], 119 [RFC4448], [RFC4761] and [RFC4762]. 121 1.2. Traditional Ethernet Network 123 In this document, traditional Ethernet network refers to the Ethernet 124 bridge/switch network, not the Ethernet repeater/hub network. 126 Data frame is Ethernet frame. 128 Data forwarding is MAC-based forwarding, which includes MAC address 129 learning and aging. 131 It is important to note that in traditional Ethernet network unicast 132 unknown, multicast and broadcast frames are forwarded in exactly the 133 same way to every port except the ingress port. 135 An Ethernet host receiving a frame checks the destination address in 136 the frame to decide whether it is the intended destination. 138 1.3. MEF Multipoint Ethernet Services 140 MEF defines two multipoint Ethernet Service types: 141 - E-LAN (Ethernet LAN), multipoint-to-multipoint service 142 - E-Tree (Ethernet Tree), rooted-multipoint service 144 According to MEF's technical specification, a generic E-LAN/E-Tree 145 service is always bidirectional in the sense that ingress frames can 146 originate at any endpoint in the service. However, some application 147 scenarios of E-Tree may have unidirectional traffic only. Section 3 148 will discuss about different use cases. 150 For full specification, please refer to MEF's "Ethernet Services 151 Definitions - Phase 2" [MEF6.1] and "Ethernet Services Attributes 152 Phase 2" [MEF10.2]. 154 1.3.1. Similarity between E-LAN and E-Tree 156 Data frame is Ethernet frame. 158 Data forwarding can be MAC-based forwarding or something else, to be 159 specified by service provider in the particular service definition. 161 Extract from [MEF6.1] Table 7 and Table 9: 162 +---------------+---------------------------------------------------+ 163 | EVC Service | E-LAN/E-Tree Service Type Requirement | 164 | Attribute | | 165 +---------------+---------------------------------------------------+ 166 | Unicast | Deliver Unconditionally or Deliver Conditionally. | 167 | Service Frame | If Delivered Conditionally, MUST specify the | 168 | Delivery | delivery criteria. | 169 +---------------+---------------------------------------------------+ 170 | Multicast | Deliver Unconditionally or Deliver Conditionally. | 171 | Service Frame | If Delivered Conditionally, MUST specify the | 172 | Delivery | delivery criteria. | 173 +---------------+---------------------------------------------------+ 174 | Broadcast | Deliver Unconditionally or Deliver Conditionally. | 175 | Service Frame | If Delivered Conditionally, MUST specify the | 176 | Delivery | delivery criteria. | 177 +---------------+---------------------------------------------------+ 179 It is important to note that it is not a must for a MEF multipoint 180 Ethernet service (E-LAN or E-Tree) to use MAC-based forwarding. This 181 document presents a solution framework for MAC-based forwarding 182 E-Tree in section 5, and also discusses non-MAC-based forwarding 183 E-Tree in section 6. 185 1.3.2. Difference between E-LAN and E-Tree 187 Within the context of a multipoint Ethernet service, each endpoint is 188 designated as either a Root or a Leaf. A Root can communicate with 189 all other endpoints in the same multipoint Ethernet service, however 190 a Leaf can only communicate with Roots but not Leafs. 192 The only difference between E-LAN and E-Tree is: 193 - E-LAN has Root endpoints only, which implies there is no 194 communication restriction between endpoints 195 - E-Tree has both Root and Leaf endpoints, which implies there is a 196 need to enforce communication restriction between Leaf endpoints 198 Extract from [MEF10.2] Section 6.3: 199 The UNI Type MUST have the value either "Root" or "Leaf." If the type 200 of EVC is Point-to-Point or Multipoint-to-Multipoint, then the UNI 201 Type MUST equal "Root." 202 Extract from [MEF10.2] Section 6.1.2.2: 203 An ingress Service Frame mapped to the EVC at a Leaf UNI MUST NOT 204 result in an egress Service Frame at another Leaf UNI but MAY result 205 in an egress Service Frame at some or all of the Root UNIs. 207 It is important to note that one E-Tree service may have single or 208 multiple Root UNIs. 210 Extract from [MEF6.1] Section 6.3: 211 In its simplest form, an E-Tree Service type can provide a single 212 Root for multiple Leaf UNIs. Each Leaf UNI can exchange data with 213 only the Root UNI. ... In more sophisticated forms, an E-Tree Service 214 type may support two or more Root UNIs. In this scenario, each Leaf 215 UNI can exchange data only with the Root UNIs. As well, the Roots can 216 communicate with each other. In such a service, redundant access to 217 the Root can also be provided, effectively allowing for enhanced 218 service reliability and flexibility. 220 1.4. IETF Multipoint L2VPN Services 222 1.4.1. Virtual Private LAN Service (VPLS) 224 VPLS is a L2VPN service that provides multipoint-to-multipoint 225 connectivity for Ethernet across an IP or MPLS-enabled IP Packet 226 Switched Network. VPLS emulates the Ethernet VLAN functionality of 227 traditional Ethernet network. 229 VPLS is a current IETF standard, please refer to [RFC4761] [RFC4762]. 231 Data frame is Ethernet frame. 233 Data forwarding is MAC-based forwarding, which includes MAC address 234 learning and aging. 236 It is important to note that the current standard VPLS treats 237 Ethernet multicast frame in exactly the same way as Ethernet 238 broadcast frame and does not restrict transmission of Ethernet 239 multicast frame to a smaller set of receivers. An Ethernet host 240 receiving a frame checks the destination address in the frame to 241 determine whether it is the intended destination. 243 VPLS can be used to emulate E-LAN service over MPLS network provided 244 that the E-LAN service uses MAC-based forwarding as service frame 245 delivery attribute. Considerable number of service providers have 246 adopted this approach to provide E-LAN services to customers. 248 1.4.2. Virtual Private Multicast Service (VPMS) 250 VPMS is a L2VPN service that provides point-to-multipoint 251 connectivity across a variety of link layers, including Frame Relay, 252 ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP Packet 253 Switched Network. 255 In the Ethernet use case, VPMS provides single coverage of receiver 256 membership, i.e. there is no distinct differentiation for multiple 257 multicast groups in one VPN. Destination address in Ethernet frame is 258 not used in data forwarding. 260 VPMS MUST support unidirectional point-to-multipoint traffic from a 261 sender to multiple receivers and MAY support reverse traffic in a 262 point-to-point manner. 264 VPMS is currently under development. Please refer to [Draft VPMS 265 Frmwk]. 267 1.4.3. Ethernet VPN (E-VPN) 269 E-VPN is an enhanced Layer-2 service that emulates an Ethernet (V)LAN 270 across a PSN, primarily targeted to support large-scale L2VPNs with 271 resiliency requirements not satisfied by other L2VPN solutions. 273 E-VPN is currently under development. Please refer to [Draft EVPN 274 Req] [Draft BGP EVPN]. 276 1.5. Terminology 278 E-Tree 280 An Ethernet VPN in which each Root AC can communicate with every 281 other AC, whereas Leaf ACs can only communicate with Root ACs. Each 282 AC on an E-Tree construct is designated as either a Root AC or a Leaf 283 AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct. 285 Root AC 287 An ingress frame at a Root AC can be delivered to one or more of 288 any of the other ACs in the E-Tree. Please note that this AC is 289 bidirectional. 291 Leaf AC 293 Ingress frame at a Leaf AC can only be delivered to one or more Root 294 ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered 295 to any Leaf ACs in the E-Tree. Please note that this AC is 296 bidirectional. 298 2. Reference Model 300 Figure 1 below describes a generic reference model where PE1, PE2 and 301 PE3 need to establish an E-Tree construct between different Ethernet 302 endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI. 303 These VSIs are then linked together via Ethernet PWs. 305 In most use cases, an E-Tree construct has only a few Root ACs but 306 many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE. 308 <------------E-Tree------------> 309 +---------+ +---------+ 310 | PE1 | | PE2 | 311 +----+ | +---+ | | +---+ | +----+ 312 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 313 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 314 +----+ | | | | | | | | +----+ 315 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 316 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 317 +----+ | | | | | | | | +----+ 318 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 319 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 320 +----+ | | | | | | | | +----+ 321 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 322 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 323 | | | | | | 324 +----+----+ +----+----+ 325 | | 326 |Ethernet |Ethernet 327 |PW |PW 328 | | 329 | +----+----+ 330 | | | | 331 | | +-+-+ | +----+ 332 | | | +--+----AC9----+CE09| 333 | | | V | | (Root AC) +----+ 334 | | | | | +----+ 335 | | | +--+----AC10---+CE10| 336 +-----------------+--+ S | | (Root AC) +----+ 337 | | | | +----+ 338 | | +--+----AC11---+CE11| 339 | | I | | (Leaf AC) +----+ 340 | | | | +----+ 341 | | +--+----AC12---+CE12| 342 | +---+ | (Leaf AC) +----+ 343 | PE3 | 344 +---------+ 345 <------------E-Tree------------> 347 Figure 1: E-Tree Reference Model 349 With an E-Tree construct: 350 - A Root AC can receive from and transmit to any other ACs. 351 - A Leaf AC can receive from and transmit to any Root ACs. 352 - A Leaf AC cannot receive from and transmit to any other Leaf ACs. 354 This applies to all traffic, including Unicast Known, Unicast 355 Unknown, Broadcast and Multicast. 357 When an Ethernet Frame is received on PE1 via AC1, the frame can be 358 transmitted to any other local ACs on PE1 and via Ethernet PWs to any 359 remote ACs on PE2 and PE3. 361 However when an Ethernet frame is received on PE1 via AC3, the frame 362 can be transmitted to any other local Root ACs on PE1 and via 363 Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame 364 cannot be transmitted to any local Leaf ACs on PE1 nor any remote 365 Leaf ACs on PE2 and PE3. 367 3. Use Cases 369 Table 1 below presents some major use cases. 371 +---------------------------+--------------+------------+ 372 | Use Case | Root | Leaf | 373 +---+---------------------------+--------------+------------+ 374 | 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 375 +---+---------------------------+--------------+------------+ 376 | 2 | Wholesale Access | Customer's | Customer's | 377 | | | Interconnect | Subscriber | 378 +---+---------------------------+--------------+------------+ 379 | 3 | Mobile Backhaul | RAN NC | RAN BS | 380 +---+---------------------------+--------------+------------+ 381 | 4 | IEEE 1588 PTPv2 | PTP Server | PTP Client | 382 | | Clock Synchronisation | | | 383 +---+---------------------------+--------------+------------+ 384 | 5 | Internet Access | BNG Router | Subscriber | 385 | | Reference: [TR-101] | | | 386 +---+---------------------------+--------------+------------+ 387 | 6 | Broadcast Video | Video Source | Subscriber | 388 | | (unidirectional only) | | | 389 +---+---------------------------+--------------+------------+ 390 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 391 | | plus Control Channel | | | 392 +---+---------------------------+--------------+------------+ 393 | 8 | Device Management | Management | Managed | 394 | | | System | Device | 395 +---+---------------------------+--------------+------------+ 397 Table 1: E-Tree Use cases 399 Common to all use cases, direct Layer 2 Leaf-to-Leaf communication is 400 not required. For Mobile backhaul, this may not be valid for LTE X2 401 interfaces in the future. 403 If direct Layer 2 Leaf-to-Leaf communication is not allowed due to 404 security concern, then E-Tree should be used to prohibit 405 communication between Leaf endpoints, otherwise E-LAN is also a 406 feasible option. 408 Also common to the use cases mentioned above, there may be single or 409 multiple Root endpoints in one E-Tree service. The need for multiple 410 Root endpoints is usually driven by redundancy requirement. Whether 411 a particular E-Tree service needs to support single or multiple Root 412 endpoints depends on the target application. 414 A generic E-Tree service supports all the following traffic flows: 415 - Ethernet Unicast from Root to Leaf 416 - Ethernet Unicast from Leaf to Root 417 - Ethernet Unicast from Root to Root 418 - Ethernet Broadcast/Multicast from Root to Roots & Leafs 419 - Ethernet Broadcast/Multicast from Leaf to Roots 420 A particular E-Tree service may need to support all the above or only 421 a subset depending on the target application. 423 Among the use cases mentioned above, broadcast video draws most 424 attention. Actually, broadcast video is a representing example for 425 content delivery in general, such as news feed, financial data 426 feed, etc. 428 4. Challenges 430 4.1. Generic E-Tree Service Definition 432 This section highlights why the current standard VPLS is insufficient 433 for emulating E-Tree service over MPLS network. 435 4.1.1. Mandatory Leaf-to-Leaf Communication Restriction 437 Current standard VPLS treats all ACs equal (i.e. not classified into 438 Root or Leaf) and provides any-to-any connectivity among all ACs. The 439 current standard VPLS does not include any mechanism of communication 440 restriction between specific ACs, therefore is insufficient for 441 emulating generic E-Tree service over MPLS network. 443 A problem occurs when there are two or more PEs with both Root AC and 444 Leaf AC. 446 Let's look at the scenario illustrated in Figure 2 below. VPLS is 447 used to emulate an E-Tree service over a MPLS network. 449 Note: Figure 2 is a hypothetical case solely for explaining the 450 problem, and not meant to represent a typical E-Tree service. 452 <------------E-Tree------------> 453 +---------+ +---------+ 454 | PE1 | | PE2 | 455 +---+ | +---+ | | +---+ | +---+ 456 |CE1+-----AC1----+--+ | | | | +--+----AC3-----+CE3| 457 +---+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +---+ 458 | | S +--+-----PW-----+--+ S | | 459 +---+ | | I | | | | I | | +---+ 460 |CE2+-----AC2----+--+ | | | | +--+----AC4-----+CE4| 461 +---+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +---+ 462 +---------+ +---------+ 464 Figure 2: Problem Scenario for Leaf-to-Leaf Communication Restriction 465 When PE2 receives a frame from PE1 via the Ethernet PW, 466 - PE2 does not know which AC on PE1 is the ingress AC 467 - PE2 does not know whether the ingress AC is a Leaf AC or not 468 - PE2 does not have sufficient information to enforce the 469 Leaf-to-Leaf communication restriction 471 Examples: 472 - CE2 sends a Broadcast/Multicast frame to PE1 via AC2 473 - CE2 sends a Unicast frame to PE1 via AC2, destination address in 474 Ethernet header equal to CE4's MAC address 476 In order to fulfil the generic E-Tree service definition, extension 477 to the current VPLS standard will be required. Extension to related 478 PWE3 standard may also be required, depending on solution approach. 479 Such extensions should have minimal impact on the emulated E-LAN 480 services already in operation. 482 There are some possible ways to get around this problem that do not 483 require extension to the current VPLS standard but they all come with 484 significant design complexity or deployment constraints. Appendix A 485 highlights the major ones and the related concerns. 487 4.2. Use Case Desirable Requirements 489 There are quite a variety of use cases for E-Tree. For some use 490 cases, the generic MEF E-Tree service definition is good enough. For 491 some other use cases, there are desirable requirements beyond that. 493 The challenges discussed in this section are not related to the 494 generic MEF E-Tree service definition but the desirable requirements 495 of specific use cases. They may be critical to the success in some 496 E-Tree services while totally irrelevant in some others. 498 4.2.1. Ethernet Broadcast/Multicast Optimisation 500 According to MAC-based forwarding, an Ethernet broadcast/multicast/ 501 unicast unknown frame is forwarded to all ACs other than the ingress 502 AC, which implies point-to-multipoint traffic from the ingress PE to 503 all other PEs in the VPLS instance. 505 The current standard VPLS uses only point-to-point PW between PEs. 506 When the Ethernet destination address is broadcast, multicast or 507 unicast unknown, the ingress PE replicates the frame on every PW 508 towards remote PE belonging to the same VPLS instance. Depending on 509 the mapping between the logical topology of the E-Tree service and 510 the physical topology of the network, multiple PWs may transverse 511 same physical link, result in multiple copies of the same payload 512 Ethernet frame on the physical link. Such approach is inefficient in 513 terms of bandwidth usage. 515 For some use cases, for example broadcast/multicast video, due to 516 nature of the application, there is significant volume of point-to- 517 multipoint traffic. Bandwidth optimisation for such traffic within 518 the network becomes a concern from the service provider perspective. 520 [RFC5501] provides an in-depth discussion on broadcast/multicast 521 related requirements for VPLS, see issue B (Replication of PWs on 522 shared physical path) in section 3.2. 524 4.2.2. IP Multicast Optimisation 526 The current standard VPLS is a L2VPN service agnostic to customer's 527 Layer 3 traffic, hence does not maintain any information about IP 528 multicast group membership. Although a Layer 3 IP multicast packet is 529 encapsulated in a Layer 2 Ethernet multicast frame, the current 530 standard VPLS treats Ethernet multicast frame in exactly the same way 531 as Ethernet broadcast frame. Therefore, such payload IP multicast 532 packet will be forwarded to every other AC of the same VPLS instance. 534 A payload IP multicast packet will be forwarded to all ACs, including 535 those with no member of the specific IP multicast group attached. 536 Unnecessary traffic consumes bandwidth on access link and may become 537 a concern from the customer perspective. In some cases, it may also 538 be a security concern as the multicast frame may be forwarded to an 539 endpoint other than the intended destinations. 541 A payload IP multicast packet will be forwarded to a remote PE with 542 no member of the specific IP multicast group attached. Unnecessary 543 traffic consumes bandwidth in the network and may become a concern 544 from the service provider perspective. 546 For some use cases, for example multicast video, due to nature of the 547 application, there is significant volume of IP multicast traffic and 548 different IP multicast groups are required in one E-Tree service. The 549 above may become a real concern from both the customer and service 550 provider perspectives. 552 [RFC5501] provides an in-depth discussion on broadcast/multicast 553 related requirements for VPLS, see both issue A (Replication to non- 554 member site) and issue B (Replication of PWs on shared physical path) 555 in section 3.2. 557 4.2.3. MAC-based Forwarding Unnecessary 559 For some use cases, for example broadcast video, due to nature of the 560 application, there is only broadcast unidirectional traffic from Root 561 to all other endpoints. It is unnecessary to use destination address 562 for data forwarding. Deliver unconditionally for ingress frame at 563 Root endpoint may be a simpler approach than MAC-based forwarding. 565 4.2.4. MAC-based Forwarding Security Concern 567 MAC-based forwarding will make an unicast frame from a Root destined 568 for a specific Leaf being forwarded to other endpoints in addition to 569 the intended destination when the frame is classified as unicast 570 unknown, may be due to MAC address aged out or MAC address table 571 overflow. 573 MAC address spoofing may cause an unicast frame from a Root destined 574 for a specific Leaf being forwarded to an endpoint different from the 575 intended destination. 577 If such unicast frame carries sensitive information strictly for the 578 intended destination only, then the MAC-based forwarding may cause a 579 security concern from the customer perspective. 581 For some use cases where mutually un-trusted subscribers are 582 connected to leaf endpoints in the same E-Tree service, such as 583 Internet access and wholesale access, this is a valid concern. 585 There are some possible mitigations: 586 - For every Leaf endpoint of the particular E-Tree service, deploy 587 a service provider controlled router between the Leaf endpoint 588 and the customer network 589 - Customer to deploy encryption for sensitive information, for 590 example IPsec, SSL, SSH, HTTPS 592 Whether the MAC-based forwarding really becomes a security concern 593 depends on the particular application and the deployment scenario. 594 This is unlikely to be a critical concern in most cases. 596 5. A Solution Framework for MAC-based Forwarding E-Tree 598 As mentioned in section 1.3.1. E-Tree can use MAC-based forwarding or 599 something else for data forwarding. This section presents a solution 600 framework for MAC-based forwarding E-Tree. Section 6 will discuss 601 other variants. 603 5.1. VPLS Solution 605 This is a VPLS based solution. Functional components of the solution 606 are identified and discussed in the subsections. 608 5.1.1. MAC-based Forwarding Any-to-Any Ethernet VPN 610 This is a REQUIRED component. 612 This component is the current standard VPLS and PWE3 as specified in 613 [RFC4385] [RFC4447] [RFC4448] [RFC4761] [RFC4762], which provides 614 any-to-any connectivity among all ACs in one VPLS instance. 616 This is the base component. All other REQUIRED/OPTIONAL components 617 are to be added on top of this component. 619 5.1.2. Leaf-to-Leaf Communication Restriction 621 This is in response to the challenge in section 4.1.1. Mandatory 622 Leaf-to-Leaf Communication Restriction. 624 This is a REQUIRED component. 626 This component is a minimal extension to the current VPLS and PWE3 627 standards, with the objective to provide a simple and effective way 628 to support generic E-Tree services in addition to E-LAN services 629 using VPLS on a MPLS network. 631 [Draft VPLS ETree Req] is a work in progress requirement draft. 633 Different solutions have been proposed: 634 - Control Word L-bit solution, [Draft CW L-bit] [Draft VPLS ETree] 635 - Dual VLAN solution, [Draft VPLS PE ETree] [Draft VPLS ETree BGP] 636 - Multiple PW solution, [Draft VPLS ETree Multi PW] 638 5.1.3. Optional Enhancement - Point-to-Multipoint PW 640 This is in response to the challenge in section 4.2.1. Ethernet 641 Broadcast/Multicast Optimisation. 643 This is an OPTIONAL component, applicable only when there is 644 significant volume of Ethernet broadcast/multicast traffic. 646 Point-to-Multipoint pseudowire (P2MP PW) is a PW attached to a source 647 used to distribute Layer 1 or Layer 2 format traffic to a set of 648 receivers. P2MP PW is unidirectional but optionally bidirectional. 650 By using P2MP PW, the ingress PE is not responsible for replicating 651 the payload frame on each P2P PW towards egress PE, instead the 652 network elements along the physical path participate in replication. 653 The replication is done by the underlying point-to-multipoint label 654 switched path (P2MP LSP). 656 Extension to current VPLS standard will be required to specify how 657 P2MP PW and P2P PW should be used and how MAC learning works on P2MP 658 PW. Please refer to [Draft LDP-VPLS Bcast]. 660 P2MP PW is currently under development. Please refer to [Draft P2MP 661 PW Req] [Draft P2MP PW Sig]. 663 It is important to note that this component will align with the 664 recommendation in [RFC4665], 665 "With the exception of IPLS, an L2VPN service SHOULD be agnostic to 666 customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated 667 within Layer 2 frames." 669 5.1.4. Optional Enhancement - IP Multicast in VPLS 671 This is in response to the challenge in section 4.2.2. IP Multicast 672 Optimisation. 674 This is an OPTIONAL component, applicable only when there is 675 significant volume of IP multicast traffic and different IP multicast 676 groups are required in one E-Tree service. 678 Multicast in VPLS is currently under development, with the objective 679 to provide efficient ways to support IP multicast services over VPLS. 680 It covers IP multicast group membership control and also bandwidth 681 optimisation. Please refer to [Draft Mcast VPLS]. 683 It is important to note that this component will make use of Layer 3 684 IP multicast information in payload frames to improve transport 685 efficiency, hence will not align with the recommendation in [RFC4665] 686 that an L2VPN service SHOULD be agnostic to customer's Layer 3 687 traffic. 689 5.2. E-VPN Solution 691 A E-VPN based solution has been proposed. Please refer to [Draft EVPN 692 ETree]. 694 6. Non-MAC-based Forwarding E-Tree 696 This section presents some variants of E-Tree services which do not 697 use MAC-based forwarding as the service frame delivery attribute. 699 6.1. Single Root, Broadcast Only - VPMS 701 This is in response to the challenge in section 4.2.3. MAC-based 702 Forwarding Unnecessary. 704 VPMS provides single coverage of receiver membership. Destination 705 address in Ethernet frame is not used in data forwarding. 707 For E-Tree service of single Root and only unidirectional broadcast 708 traffic from the Root, for example certain broadcast video or similar 709 content delivery applications, VPMS will be a much more simple and 710 effective solution than VPLS. 712 VPMS is currently under development. Please refer to [Draft VPMS 713 Frmwk]. 715 6.2. Multiple Roots, Broadcast and Unicast 717 This is in response to the challenge in section 4.2.4. MAC-based 718 Forwarding Security Concern. 720 This will be added in later version of this document. 722 6.3. E-VPN Solution 724 A E-VPN based solution has been proposed. Please refer to [Draft EVPN 725 ETree]. 727 7. Security Considerations 729 This will be added in later version of this document. 731 8. IANA Considerations 733 This will be added in later version of this document. 735 9. Acknowledgements 737 This will be added in later version of this document. 739 10. References 741 10.1. Normative References 743 [MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - 744 Phase 2, April 2008 746 [MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes 747 Phase 2, October 2009 749 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 750 Requirement Levels, BCP 14, RFC 2119, March 1997 752 [RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation 753 Edge-to-Edge (PWE3) Control Word for Use over an MPLS 754 PSN, February 2006. 756 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 757 Using the Label Distribution Protocol (LDP), April 2006 759 [RFC4448] Martini, L., and al, Encapsulation Methods for 760 Transport of Ethernet over MPLS Networks, April 2006 762 [RFC4665] Augustyn & Serbest, Service Requirements for Layer 2 763 Provider-Provisioned Virtual Private Networks, 764 September 2006 766 [RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS) 767 Using BGP for Auto-Discovery and Signaling, January 2007 769 [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) 770 Using Label Distribution Protocol (LDP) Signaling, 771 January 2007 773 [RFC5501] Kamite, et al., Requirements for Multicast Support in 774 Virtual Private LAN Services, March 2009 776 10.2. Informative References 778 [TR-101] Broadband Forum, Migration to Ethernet-Based Broadband 779 Aggregation Issue 2, July 2011 781 [Draft VPLS ETree Req] 782 Key, et al., Requirements for Metro Ethernet Forum (MEF) 783 Ethernet-Tree (E-Tree) Support in L2VPN, 784 draft-ietf-l2vpn-etree-reqt-05 (work in progress), 785 July 2013 787 [Draft CW L-bit] 788 Delord, et al., Control Word Reserved bit for use in 789 E-Tree, draft-delord-pwe3-cw-bit-etree-07 (work in 790 progress), April 2012 792 [Draft VPLS ETree] 793 Key, et al., Extension to VPLS for E-Tree, 794 draft-key-l2vpn-vpls-etree-07 (work in progress), 795 April 2012 797 [Draft VPLS PE ETree] 798 Jiang, et al., VPLS PE Model for E-Tree Support, 799 draft-ietf-l2vpn-vpls-pe-etree-01 (work in progress), 800 February 2013 802 [Draft VPLS ETree BGP] 803 Jiang, et al., E-Tree Support in VPLS with BGP 804 Signaling, draft-jiang-l2vpn-etree-bgp-00 805 (work in progress), February 2012 807 [Draft VPLS ETree Multi PW] 808 Ram, et al., Extension to VPLS for E-Tree Using Multiple 809 PWs, draft-ram-l2vpn-etree-multiple-pw-01 (work in 810 progress), March 2012 812 [Draft P2MP PW Req] 813 Jounay, et al., Requirements for Point-to-Multipoint 814 Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-05 815 (work in progress), September 2011 817 [Draft P2MP PW Sig] 818 Sivabalan, et al., Signaling Root-Initiated Point-to- 819 Multipoint Pseudowires using LDP, 820 draft-ietf-pwe3-p2mp-pw-04 (work in progress), 821 March 2012 823 [Draft LDP-VPLS Bcast] 824 Delord & Key, Extension to LDP-VPLS for Ethernet 825 Broadcast and Multicast, 826 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-06 (work in 827 progress), September 2013 829 [Draft Mcast VPLS] 830 Raggarwa, Kamite & Fang, Multicast in VPLS, 831 draft-ietf-l2vpn-vpls-mcast-14 (work in progress), 832 July 2013 834 [Draft VPMS Frmwk] 835 Kamite, et al., Framework and Requirements for Virtual 836 Private Multicast Service (VPMS), 837 draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in 838 progress), October 2012 840 [Draft EVPN Req] 841 Sajassi, et al., Requirements for Ethernet VPN (E-VPN), 842 draft-ietf-l2vpn-evpn-req-04 (work in progress), 843 July 2013 845 [Draft BGP EVPN] 846 Sajassi, et al., BGP MPLS Based Ethernet VPN, 847 draft-ietf-l2vpn-evpn-04 (work in progress), 848 July 2013 850 [Draft EVPN ETree] 851 Sajassi, et al., E-TREE Support in E-VPN, 852 draft-sajassi-l2vpn-evpn-etree-01 (work in progress), 853 October 2012 855 Appendix A. Some Possible Ways for Leaf-to-Leaf Communication 856 Restriction 858 This appendix briefly describes the following approaches: 859 - Single Root Only (A.1) 860 - Only one PE has Roots (A.2) 861 - Only one PE with both Root & Leaf 862 - Backhaul Root (A.3) 863 - Backhaul Leaf (A.4) 864 - H-VPLS Root (A.5) 865 - H-VPLS Leaf (A.6) 866 - Separate PEs for Root and Leaf (A.7) 867 - Separate VSI for Root and Leaf 868 - Internal Connection (A.8) 869 - External Connection (A.9) 870 - Separate PWs for "From Root" traffic and "From Leaf" traffic (A.10) 871 - "From Root" or "From Leaf" derived from source MAC address (A.11) 872 - Static MAC address configuration for Root AC (A.12) 874 Reference Model for Leaf-to-Leaf Communication Restriction 876 <------------E-Tree------------> 877 +---------+ +---------+ 878 | PE1 | | PE2 | 879 +----+ | +---+ | | +---+ | +----+ 880 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 881 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 882 +----+ | | | | | | | | +----+ 883 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 884 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 885 +----+ | | | | | | | | +----+ 886 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 887 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 888 +----+ | | | | | | | | +----+ 889 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 890 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 891 | | | | 892 +---------+ +---------+ 894 For the diagrams in this appendix, "L" indicates the particular AC or 895 PW belonging to the PE local split horizon group specifically for 896 Leaf-to-Leaf Communication Restriction. No communication is allowed 897 between any two members of a split horizon group. 899 A.1. Single Root Only 901 <------------E-Tree------------> 902 +---------+ +---------+ 903 | PE1 | | PE2 | 904 +----+ | +---+ | | +---+ | 905 |CE01+----AC1----+--+ | | | | | | 906 +----+ (Root AC) | | V | | | | V | | 907 | | | | | | | | 908 | | | | Ethernet | | | | 909 | | S +L-+-----PW-----+--+ S | | 910 +----+ | | | | | | | | +----+ 911 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 912 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 913 +----+ | | | | | | | | +----+ 914 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 915 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 916 | | | | 917 +---------+ +---------+ 919 Concerns: 920 - Not fulfil multi-Root requirement of generic MEF E-Tree service 921 definition 923 A.2. Only one PE has Roots 925 <------------E-Tree------------> 926 +---------+ +---------+ 927 | PE1 | | PE2 | 928 +----+ | +---+ | | +---+ | 929 |CE01+----AC1----+--+ | | | | | | 930 +----+ (Root AC) | | V | | | | V | | 931 +----+ | | | | | | | | 932 |CE02+----AC2----+--+ | | Ethernet | | | | 933 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | 934 +----+ | | | | | | | | +----+ 935 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 936 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 937 +----+ | | | | | | | | +----+ 938 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 939 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 940 | | | | 941 +---------+ +---------+ 943 Concerns: 944 - Deployment constraint 946 A.3. Only one PE with both Root & Leaf - Backhaul Root 948 +---AC5(Root AC)---------------------------+ 949 | | 950 | +-AC6(Root AC)----------------------+ | 951 | | | | 952 | | | | 953 | | | | 954 +---+-+---+ +---------+ | | 955 | | | | | | | | 956 +----+ | ++-++ | | +---+ | | +-+--+ 957 |CE01+----AC1----+--+ | | | | | | | |CE05| 958 +----+ (Root AC) | | V | | | | V | | | +----+ 959 +----+ | | | | | | | | | +----+ 960 |CE02+----AC2----+--+ | | Ethernet | | | | +--+CE06| 961 +----+ (Root AC) | | S +L-+-----PW-----+--+ S | | +----+ 962 +----+ | | | | | | | | +----+ 963 |CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07| 964 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 965 +----+ | | | | | | | | +----+ 966 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 967 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 968 | PE1 | | PE2 | 969 +---------+ +---------+ 970 <------------E-Tree------------> 972 Concerns: 973 - Deployment constraint 974 - Long fibre path 976 A.4. Only one PE with both Root & Leaf - Backhaul Leaf 978 <------------E-Tree------------> 979 +---------+ +---------+ 980 | PE1 | | PE2 | 981 +----+ | +---+ | | +---+ | +----+ 982 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 983 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 984 +----+ | | | | | | | | +----+ 985 |CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06| 986 +----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+ 987 +----+ | | | | | | | | +----+ 988 |CE03+----AC3----+-L+ | | | | | | +--+CE07| 989 +----+ (Leaf AC) | | I | | | | I | | | +----+ 990 +----+ | | | | | | | | | +----+ 991 |CE04+----AC4----+-L+ | | | | | | | |CE08| 992 +----+ (Leaf AC) | ++-++ | | +---+ | | +-+--+ 993 | L L | | | | | 994 +---+-+---+ +---------+ | | 995 | | | | 996 | | | | 997 | | | | 998 | +-AC7(Leaf AC)----------------------+ | 999 | | 1000 +---AC8(Leaf AC)---------------------------+ 1002 Concerns: 1003 - Deployment constraint 1004 - Long fibre path 1006 A.5. Only one PE with both Root & Leaf - H-VPLS Root 1008 <------------E-Tree------------> 1009 +---------+ +---------+ 1010 | PE1 | | PE2 | 1011 +----+ | +---+ | Ethernet | | +----+ 1012 |CE01+----AC1----+--+ +--+-----PW-----+---------+----AC5----+CE05| 1013 +----+ (Root AC) | | V | | | | (Root AC) +----+ 1014 +----+ | | | | Ethernet | | +----+ 1015 |CE02+----AC2----+--+ +--+-----PW-----+---------+----AC6----+CE06| 1016 +----+ (Root AC) | | S | | | +---+ | (Root AC) +----+ 1017 +----+ | | | | | | | | +----+ 1018 |CE03+----AC3----+-L+ | | Ethernet | | V +L-+----AC7----+CE07| 1019 +----+ (Leaf AC) | | I +L-+-----PW-----+--+ S | | (Leaf AC) +----+ 1020 +----+ | | | | | | I | | +----+ 1021 |CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08| 1022 +----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+ 1023 | | | | 1024 +---------+ +---------+ 1026 Concerns: 1027 - Design complexity 1028 - More PW 1029 - Hair pinning (e.g. CE05 to CE06/07/08) impact bandwidth and delay 1031 A.6. Only one PE with both Root & Leaf - H-VPLS Leaf 1033 <------------E-Tree------------> 1034 +---------+ +---------+ 1035 | PE1 | | PE2 | 1036 +----+ | +---+ | | +---+ | +----+ 1037 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 1038 +----+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +----+ 1039 +----+ | | +--+-----PW-----+--+ S | | +----+ 1040 |CE02+----AC2----+--+ | | | | I +--+----AC6----+CE06| 1041 +----+ (Root AC) | | S | | | | | | (Root AC) +----+ 1042 +----+ | | | | Ethernet | +---+ | +----+ 1043 |CE03+----AC3----+-L+ +L-+-----PW-----+---------+----AC7----+CE07| 1044 +----+ (Leaf AC) | | I | | | | (Leaf AC) +----+ 1045 +----+ | | | | Ethernet | | +----+ 1046 |CE04+----AC4----+-L+ +L-+-----PW-----+---------+----AC8----+CE08| 1047 +----+ (Leaf AC) | +---+ | | | (Leaf AC) +----+ 1048 | | | | 1049 +---------+ +---------+ 1051 Concerns: 1052 - Design complexity 1053 - More PW 1054 - Hair pinning (e.g. CE08 to CE05/06) impact bandwidth and delay 1056 A.7. Separate PEs for Root and Leaf 1057 (PE2 split to PE2R & PE2L) 1059 <------------E-Tree------------> 1060 +---------+ +---------+ 1061 | PE1 | | PE2R | 1062 +----+ | +---+ | | +---+ | +----+ 1063 |CE01+----AC1----+--+ | | Ethernet | | V +--+----AC5----+CE05| 1064 +----+ (Root AC) | | V +--+-----PW-----+--+ S | | (Root AC) +----+ 1065 +----+ | | | | | | I | | +----+ 1066 |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06| 1067 +----+ (Root AC) | | S | | | +-+-+ | (Root AC) +----+ 1068 +----+ | | | | | L | 1069 |CE03+----AC3----+-L+ | | +----+----+ 1070 +----+ (Leaf AC) | | I | | | 1071 +----+ | | | | |Ethernet 1072 |CE04+----AC4----+-L+ | | |PW 1073 +----+ (Leaf AC) | +-+-+ | | 1074 | L | +----+----+ 1075 +----+----+ | | | 1076 | | +-+-+ | +----+ 1077 | Ethernet | | V +L-+----AC7----+CE07| 1078 +----------PW-----+--+ S | | (Leaf AC) +----+ 1079 | | I | | +----+ 1080 | | +L-+----AC8----+CE08| 1081 | +---+ | (Leaf AC) +----+ 1082 | PE2L | 1083 +---------+ 1084 <------------E-Tree------------> 1086 Concerns: 1087 - Require two PEs in one POP 1088 - More PW 1090 A.8. Separate VSI for Root and Leaf - Internal Connection 1091 (VSI on PE split to VSIR & VSIL) 1093 <------------E-Tree------------> 1094 +---------+ +---------+ 1095 | PE1 | | PE2 | 1096 +----+ | +---+ | | +---+ | +----+ 1097 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1098 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1099 +----+ | | I | | | | I | | +----+ 1100 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1101 +----+ (Root AC) | +-+-+ | | | | +-+-+ | (Root AC) +----+ 1102 | L | | | | L | 1103 | | | \ / | | | 1104 | | | \ / | | | 1105 | | | \ / | | | 1106 Internal| | \/ | |Internal 1107 Connection| | /\ | |Connection 1108 | | | / \ | | | 1109 | | | / \ | | | 1110 | | | / \ | | | 1111 +----+ | +-+-+ | | | | +-+-+ | +----+ 1112 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1113 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1114 +----+ | | I | | | | I | | +----+ 1115 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1116 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1117 | | PWs | | 1118 +---------+ +---------+ 1120 Concerns: 1121 - Design complexity 1122 - More VSI 1123 - More PW 1124 - Some vendor implementation may require additional hardware module 1125 to support internal connection between two VSIs 1126 - Some vendor implementation may have bandwidth limitation on 1127 internal connection between two VSIs 1128 - Some vendor implementation of service-aware management system may 1129 assume only one VSI per VPLS on one PE 1131 A.9. Separate VSI for Root and Leaf - External Connection 1132 (VSI on PE split to VSIR & VSIL) 1134 <------------E-Tree------------> 1135 +---------+ +---------+ 1136 | PE1 | | PE2 | 1137 +----+ | +---+ | | +---+ | +----+ 1138 |CE01+----AC1----+--+ V | | | | V +--+----AC5----+CE05| 1139 +----+ (Root AC) | | S +--+------------+--+ S | | (Root AC) +----+ 1140 +----+ | | I | | | | I | | +----+ 1141 |CE02+----AC2----+--+ R +L-+--+ +--+-L+ R +--+----AC6----+CE06| 1142 +----+ (Root AC) | | | | | | | | | | (Root AC) +----+ 1143 | | | | | | | | | | 1144 +------AC-X1---+-L+ | | \ / | | +L-+----AC-X2-----+ 1145 | (Leaf AC) | +---+ | \ / | +---+ | (Leaf AC) | 1146 | | | \ / | | | 1147 |External | | \/ | | External| 1148 |Connection | | /\ | | Connection| 1149 | | +---+ | / \ | +---+ | | 1150 +------AC-Y1---+--+ | | / \ | | +--+----AC-Y2-----+ 1151 (Root AC) | | | | / \ | | | | (Root AC) 1152 +----+ | | | | | | | | | | +----+ 1153 |CE03+----AC3----+-L+ V | | | | | | V +L-+----AC7----+CE07| 1154 +----+ (Leaf AC) | | S +--+--+ +--+--+ S | | (Leaf AC) +----+ 1155 +----+ | | I | | | | I | | +----+ 1156 |CE04+----AC4----+-L+ L | | Three | | L +L-+----AC8----+CE08| 1157 +----+ (Leaf AC) | +-+-+ | Ethernet | +---+ | (Leaf AC) +----+ 1158 | | PWs | | 1159 +---------+ +---------+ 1161 Concerns: 1162 - Design complexity 1163 - More VSI 1164 - More PW 1165 - More AC (for external connection between two VSIs) 1166 - Require additional two high speed physical ports on PE to support 1167 such external connections 1168 - Some vendor implementation of service-aware management system may 1169 assume only one VSI per VPLS on one PE 1171 A.10. Separate PWs for "From Root" traffic and "From Leaf" traffic 1173 <------------E-Tree------------> 1174 +---------+ +---------+ 1175 | PE1 | | PE2 | 1176 +----+ | +---+ | | +---+ | +----+ 1177 |CE01+----AC1----+--+ | | Ethernet | | +--+----AC5----+CE05| 1178 +----+ (Root AC) | | V +--+---PW for---+--+ V | | (Root AC) +----+ 1179 +----+ | | | |"From Root" | | | | +----+ 1180 |CE02+----AC2----+--+ | | Traffic | | +--+----AC6----+CE06| 1181 +----+ (Root AC) | | S | | | | S | | (Root AC) +----+ 1182 +----+ | | | | | | | | +----+ 1183 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 1184 +----+ (Leaf AC) | | I | | Ethernet | | I | | (Leaf AC) +----+ 1185 +----+ | | +--+---PW for---+--+ | | +----+ 1186 |CE04+----AC4----+--+ | |"From Leaf" | | +--+----AC8----+CE08| 1187 +----+ (Leaf AC) | +---+ | Traffic | +---+ | (Leaf AC) +----+ 1188 | | | | 1189 +---------+ +---------+ 1191 Concerns: 1192 - More PW 1193 - Most, if not all, vendor implementation support only one PW 1194 between two VSIs on different PEs 1195 - Most, if not all, vendor implementation of service-aware management 1196 system assume only one PW between two VSIs on different PEs 1197 - Asymmetric path for bidirectional traffic between Root and Leaf on 1198 different PEs (e.g. CE01-->CE07 use the "From Root" PW, CE07-->CE01 1199 use the "From Leaf" PW) 1200 - Require extension to current standard VPLS 1201 - support two PWs between two VSIs on different PEs (both active 1202 but no loop) 1203 - share MAC learning between the "From Root" PW and "From Leaf" PW 1204 (bidirectional traffic may be on asymmetric path) 1205 - in addition to standard MAC-based forwarding, select which PW to 1206 use based on whether ingress AC is Root or Leaf 1207 - filter Leaf-to-Leaf traffic (split horizon group at PW/AC level 1208 is not good enough because of asymmetric path) 1210 A.11. "From Root" or "From Leaf" derived from source MAC address 1212 Based on the current standard VPLS, a PE has no information about ACs 1213 on another PE. 1215 This approach will need additional information exchange between 1216 ingress PE and egress PE, via OSS or peer to peer. 1218 Concerns: 1219 - Require system development or additional signaling between PEs 1220 - Not an ideal solution from security perspective because of the 1221 dynamic nature of MAC address to AC mapping 1223 A.12. Static MAC address configuration for Root AC 1225 This approach requires additional configuration on PEs 1226 - Disable MAC address learning for Root ACs 1227 - Static configuration of MAC addresses per Root AC 1228 - Add filtering for each Root AC 1229 - Drop ingress frame if source MAC address not equal to any of the 1230 static MAC addresses configured for the particular Root AC 1231 - Add filtering for each Leaf AC 1232 - Drop ingress frame if source MAC address equal to any of the 1233 static MAC addresses configured for any Root ACs of the VPLS 1234 instance 1235 - Drop egress frame if source MAC address not equal to any of the 1236 static MAC addresses configured for any Root ACs of the VPLS 1237 instance 1239 Concerns: 1240 - No MAC address learning capability for Root ACs 1241 - Need resources for maintaining the static MAC address configuration 1242 per Root AC 1244 Authors' Addresses 1246 Raymond Key (editor) 1247 Email: raymond.key@ieee.org 1249 Simon Delord 1250 Telstra 1251 Email: simon.delord@gmail.com 1253 Frederic Jounay 1254 Orange CH 1255 4 rue caudray 1020 Renens 1256 Switzerland 1257 Email: frederic.jounay@orange.ch 1259 Lucy Yong 1260 Huawei USA 1261 207 Extrella Crossing 1262 Georgetown, TX 78628, USA 1263 Email: lucy.yong@huawei.com 1265 Lizhong Jin 1266 Email: lizho.jin@gmail.com 1268 Yuji Kamite 1269 NTT Communications Corporation 1270 Granpark Tower 1271 3-4-1 Shibaura, Minato-ku 1272 Tokyo 108-8118, Japan 1273 Email: y.kamite@ntt.com 1275 Wim Henderickx 1276 Alcatel-Lucent 1277 Copernicuslaan 50 1278 2018 Antwerp, Belgium 1279 Email: wim.henderickx@alcatel-lucent.com 1281 Copyright Notice 1283 Copyright (c) 2013 IETF Trust and the persons identified as the 1284 document authors. All rights reserved. 1286 This document is subject to BCP 78 and the IETF Trust's Legal 1287 Provisions Relating to IETF Documents 1288 (http://trustee.ietf.org/license-info) in effect on the date of 1289 publication of this document. Please review these documents 1290 carefully, as they describe your rights and restrictions with respect 1291 to this document. Code Components extracted from this document must 1292 include Simplified BSD License text as described in Section 4.e of 1293 the Trust Legal Provisions and are provided without warranty as 1294 described in the Simplified BSD License.