idnits 2.17.1 draft-ietf-l2vpn-etree-frwk-10.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 (August 25, 2014) is 3532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN WG Raymond Key (editor) 2 Internet Draft Lucy Yong, Huawei (editor) 3 Intended status: Informational Simon Delord 4 Expires: February 2015 Telstra 5 Frederic Jounay, Orange CH 6 Lizhong Jin 7 August 25, 2014 9 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol 10 Label Switching (MPLS) Network 11 draft-ietf-l2vpn-etree-frwk-10.txt 13 Abstract 15 This document describes an Ethernet-Tree (E-Tree) solution framework 16 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 17 Multiprotocol Label Switching (MPLS) network. The objective is to 18 provide a simple and effective approach to emulate E-Tree services 19 in addition to Ethernet LAN (E-LAN) services on an existing MPLS 20 network. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on February 25, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Terminology...............................................3 64 2. Overview.......................................................4 65 2.1. Ethernet Bridge Network...................................4 66 2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree........4 67 2.3. IETF L2VPN................................................5 68 2.3.1. Virtual Private LAN Service (VPLS)...................5 69 2.3.2. Ethernet VPN (EVPN)..................................5 70 2.3.3. Virtual Private Multicast Service (VPMS).............6 71 3. E-Tree Architecture Reference Model............................6 72 4. E-Tree Use Cases...............................................8 73 5. L2VPN Gaps for Emulating MEF E-Tree Service....................9 74 5.1. No Differentiation on AC Role.............................9 75 5.2. No AC Role Indication or Advertisement....................9 76 5.3. Other Issues..............................................9 77 6. Security Considerations.......................................10 78 7. IANA Considerations...........................................10 79 8. References....................................................11 80 8.1. Normative References.....................................11 81 8.2. Informative References...................................11 82 9. Contributing Authors..........................................12 83 10. Acknowledgments..............................................12 85 1. Introduction 87 This document describes an Ethernet-Tree (E-Tree) solution framework 88 for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 89 Multiprotocol Label Switching (MPLS) network. The objective is to 90 provide a simple and effective approach to emulate E-Tree services in 91 addition to Ethernet LAN (E-LAN) services on an existing MPLS 92 network. 94 This document extends the existing IETF specified Layer 2 Virtual 95 Private Network (L2VPN) framework [RFC4664] to provide the emulation 96 of E-Tree services over an MPLS network. It specifies the E-Tree 97 architecture reference model and describes the corresponding 98 functional components. It also points out the gaps and required 99 extension areas in existing L2VPN solutions such as Virtual Private 100 LAN Service (VPLS)[RFC4761][RFC4762] and Ethernet Virtual Private 101 Network (EVPN)[EVPN] for supporting E-Tree services. 103 1.1. Terminology 105 This document adopts all the terminologies defined in RFC4664 106 [RFC4664], RFC4761 [RFC4761], and RFC4762 [RFC4762]. It also uses the 107 following terminologies: 109 Leaf Attachment Circuit (AC): An AC with Leaf role. An ingress 110 Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at 111 the provider edge (PE) of an MPLS network) can only be delivered to 112 one or more Root ACs in an E-Tree service instance. An ingress 113 Ethernet frame at a Leaf AC must not be delivered to any Leaf ACs in 114 the E-Tree service instance. 116 Root AC: An AC with Root role. An ingress Ethernet frame at a Root AC 117 can be delivered to one or more of the other ACs in the associated E- 118 Tree service instance. 120 E-Tree: An Ethernet VPN service in which each AC is assigned the role 121 of a Root or Leaf. The forwarding rules in E-Tree are: Root AC can 122 communicate with other Root ACs and Leaf ACs; Leaf ACs can only 123 communicate with Root ACs. 125 2. Overview 127 2.1. Ethernet Bridge Network 129 In this document, Ethernet bridge network refers to the Ethernet 130 bridge/switch network defined in IEEE802.1Q [IEEE802.1Q]. In a bridge 131 network, a data frame is an Ethernet frame; data forwarding is based 132 on destination MAC address; MAC reachability is learned in the data 133 plane based on the source MAC address and the port (or tagged port) 134 on which the frame arrives; and the MAC aging mechanism is used to 135 remove inactive MAC addresses from the MAC forwarding table on an 136 Ethernet switch. 138 Data frames arriving at a switch may be destined to known unicast MAC 139 destinations, unknown, multicast, or broadcast MAC destinations. 140 Unknown, multicast, and broadcast frames are forwarded in a similar 141 way, i.e. to every port except the ingress port on which the frame 142 arrives. Multicast forwarding can be further constrained when using 143 multicast control protocol snooping or multicast MAC registration 144 protocols. [IEEE802.1Q] 146 An Ethernet host receiving an Ethernet frame checks the destination 147 address in the frame to decide whether it is the intended 148 destination. 150 2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree 152 MEF6.1 [MEF6.1] defines two multipoint Ethernet Service types: 154 o E-LAN (Ethernet LAN), a multipoint-to-multipoint service 156 o E-Tree (Ethernet Tree), a rooted-multipoint service 158 MEF defines User-Network Interface (UNI) in a multipoint service as 159 the Ethernet interface between a Customer Equipment (CE) and a 160 Provider Edge (PE), i.e. the PE can send and receive Ethernet frames 161 to/from the CE. MEF also defines UNI roles in a multipoint service. 162 One role is Root and another is Leaf. 164 Note that MEF UNI in a service is equivalent to the Attachment 165 Circuit (AC) defined in L2VPN [RFC4664]. The Root AC and Leaf AC 166 defined in this document are the same as of the root UNI and leaf UNI 167 defined in MEF10.3 [MEF10.3]. The Root AC and Leaf AC terms are used 168 in the following MEF service description. 170 For an E-LAN service, all ACs have the Root role, which means that 171 any AC can communicate with other ACs in the service. The E-LAN 172 service defined by MEF may be implemented by IETF L2VPN solutions 173 such as VPLS and EVPN [EVPN]. 175 An E-Tree service has one or more Root ACs and at least two Leaf ACs. 176 An E-Tree service supports the communication among the roots and 177 between a root and a leaf but prohibits the communication among the 178 leaves. Existing IETF L2VPN solutions can't support the E-Tree 179 service. This document specifies the E-Tree architecture reference 180 model that supports the E-Tree service defined by MEF [MEF6.1]. 181 Section 4 will discuss different E-Tree use cases. 183 2.3. IETF L2VPN 185 2.3.1. Virtual Private LAN Service (VPLS) 187 VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides 188 multipoint-to-multipoint Ethernet connectivity across IP/MPLS 189 networks. VPLS emulates traditional Ethernet Virtual LAN Services 190 (VLAN) in MPLS networks, and may support MEF E-LAN services. 192 A data frame in VPLS is an Ethernet frame. Data forwarding in a VPLS 193 instance is based on the destination MAC address and the VLAN on 194 which the frame arrives. MAC reachability learning is performed in 195 the data plane based on the source address and the AC or Pseudowire 196 (PW) on which the frame arrives. MAC aging is also the mechanism used 197 to remove inactive MAC addresses from a VPLS switching instance (VSI) 198 on a Provider Edge (PE). VPLS supports forwarding for known unicast, 199 unknown unicast, broadcast, and multicast Ethernet frames. 201 Many service providers have deployed VPLS in their networks to 202 provide L2VPN services to customers. 204 2.3.2. Ethernet VPN (EVPN) 206 Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an 207 Ethernet LAN or virtual LAN(s) across MPLS networks. 209 EVPN supports active-active multi-homing of CEs and uses 210 Multiprotocol Border Gateway Protocol (MP-BGP) control plane to 211 advertise MAC address reachability from an ingress PE to egress PEs. 212 Thus, a PE learns MAC addresses reachable over local ACs in the data 213 plane and other MAC addresses reachable across the MPLS network over 214 remote ACs via the EVPN MP-BGP control plane. As a result, EVPN aims 215 to support large-scale L2VPN with better resiliency compared to VPLS. 217 EVPN is relatively new technique and is still under development in 218 IETF L2VPN WG. 220 2.3.3. Virtual Private Multicast Service (VPMS) 222 VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint 223 connectivity across MPLS networks and supports various attachment 224 circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc. 226 In the case of Ethernet ACs, VPMS provides single coverage of 227 receiver membership, i.e. there is no differentiation among multicast 228 groups in one VPN. Destination address in the Ethernet frame is not 229 used in data forwarding. 231 VPMS supports unidirectional point-to-multipoint transport from a 232 sender to multiple receivers and may support reverse transport in a 233 point-to-point manner. 235 3. E-Tree Architecture Reference Model 237 Figure 1 illustrates E-Tree architecture reference model. Three 238 provider edges (PEs), PE1, PE2, and PE3 are shown in the Figure. Each 239 PE has a Virtual Service Instance (VSI) associated with an E-Tree 240 service instance. A CE attaches to the VSI on a PE via an AC. Each AC 241 must be configured with a root or leaf role. In Figure 1, AC1 AC2, 242 AC5, AC6, AC9, AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11, AC12 are 243 Leaf ACs. This implies that a PE (local or remote) processes the 244 Ethernet frames from CE01, CE02, etc as if they are originated from a 245 Root AC; and processes the Ethernet frames from CE03, CE04, etc as if 246 they are originated from a Leaf AC. 248 Under this architecture model, the forwarding rules among the ACs, 249 regardless whether sending AC and receiving AC are on the same PE or 250 on different PEs, are described as follow: 252 o An egress frame (frame to be transmitted over an AC) at an AC with 253 Root role must be the result of an ingress frame at an AC (frame 254 received at an AC) that has Root or Leaf role attached to the same 255 E-tree service instance. 257 o An egress frame at the AC with Leaf role must be the result of an 258 ingress frame at an AC that has Root role attached to the same E- 259 tree service instance. 261 <------------E-Tree-----------> 262 PE1+---------+ +---------+PE2 263 +----+ | +---+ | | +---+ | +----+ 264 |CE01+----AC1----+--+ | | | | +--+----AC5----+CE05| 265 +----+ (Root AC) | | V | | | | V | | (Root AC) +----+ 266 +----+ | | | | | | | | +----+ 267 |CE02+----AC2----+--+ | | | | +--+----AC6----+CE06| 268 +----+ (Root AC) | | S +--+---------+--+ S | | (Root AC) +----+ 269 +----+ | | | | | | | | +----+ 270 |CE03+----AC3----+--+ | | | | +--+----AC7----+CE07| 271 +----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+ 272 +----+ | | | | | | | | +----+ 273 |CE04+----AC4----+--+ | | | | +--+----AC8----+CE08| 274 +----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+ 275 +----+----+ +----+----+ 276 | MPLS Core | 277 | +----+----+ 278 | | +-+-+ | +----+ 279 | | | +--+----AC9----+CE09| 280 | | | V | | (Root AC) +----+ 281 | | | | | +----+ 282 | | | +--+----AC10---+CE10| 283 +--------------+--+ S | | (Root AC) +----+ 284 | | | | +----+ 285 | | +--+----AC11---+CE11| 286 | | I | | (Leaf AC) +----+ 287 | | | | +----+ 288 | | +--+----AC12---+CE12| 289 | +---+ | (Leaf AC) +----+ 290 PE3 +---------+ 291 <-------------E-Tree----------> 293 Figure 1 E-Tree Architecture Reference Model 295 These rules apply to all frame types, i.e. Known Unicast, Unknown, 296 Broadcast, and Multicast. For Known Unicast frames, forwarding in a 297 VSI context is based on the destination MAC address. 299 A VSI on a PE corresponds to an E-Tree service instance and maintains 300 a MAC forwarding table which is isolated from other VSI tables on the 301 PE. It also keeps the track of local AC roles. The VSI receives a 302 frame from an AC or across the MPLS core; and forwards the frame to 303 another AC over which the destination is reachable according to the 304 VSI forwarding table and forwarding rules described above. When the 305 target AC is on a remote PE, the VSI forwards the frame to the remote 306 PE over the MPLS core. Forwarding over the MPLS core will be 307 dependent on the E-tree solution. For instance, a solution may adopt 308 PWs to mesh VSIs as in VPLS, and forward frames over VSIs subject to 309 the E-tree forwarding rules. Alternatively, a solution may adopt the 310 EVPN forwarding paradigm constrained by the E-tree forwarding rules. 311 Thus, solutions that satisfy the E-tree requirements could be 312 extensions to VPLS and EVPN. 314 In most use cases, an E-Tree service has only a few Root ACs (root CE 315 sites) but many Leaf ACs (leaf CE sites). Furthermore, a PE may have 316 only Root ACs or only Leaf ACs. Figure 1 provides a general E-Tree 317 architecture model. 319 4. E-Tree Use Cases 321 Table 1 below presents some major use cases for E-Tree. 323 +---------------------------+--------------+------------+ 324 | Use Case | Root AC | Leaf AC | 325 +---+---------------------------+--------------+------------+ 326 | 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 327 +---+---------------------------+--------------+------------+ 328 | 2 | Wholesale Access | Customer's | Customer's | 329 | | | Interconnect | Subscriber | 330 +---+---------------------------+--------------+------------+ 331 | 3 | Mobile Backhaul | RAN NC | RAN BS | 332 +---+---------------------------+--------------+------------+ 333 | 4 | IEEE 1588 PTPv2 [1588] | PTP Server | PTP Client | 334 | | Clock Synchronization | | | 335 +---+---------------------------+--------------+------------+ 336 | 5 | Internet Access | BNG Router | Subscriber | 337 | | Reference: [TR-101] | | | 338 +---+---------------------------+--------------+------------+ 339 | 6 | Broadcast Video | Video Source | Subscriber | 340 | | (unidirectional only) | | | 341 +---+---------------------------+--------------+------------+ 342 | 7 | Broadcast/Multicast Video | Video Source | Subscriber | 343 | | plus Control Channel | | | 344 +---+---------------------------+--------------+------------+ 345 | 8 | Device Management | Management | Managed | 346 | | | System | Device | 347 +---+---------------------------+--------------+------------+ 349 Where: 350 RAN: Radio Access Network NC: Network Controller 351 BS: Base Station PTP: Precision Time Protocol 352 BNG: Broadband Network Gateway 354 Table 1 E-Tree Use Cases 356 Common to all use cases, direct Layer2 Leaf-to-Leaf communication is 357 required to be prohibited. For Mobile backhaul, this may not be valid 358 for LTE X2 interfaces; LTE X2 interface [LTE] between two evolved 359 node B (eNB) enables the communication in between. E-Tree service is 360 appropriate for such use cases. 362 Also common to the use cases mentioned above, there may be single or 363 multiple Root ACs in one E-Tree service. The need of multiple Root- 364 ACs may be driven by redundancy requirement or multiple serving 365 sites. Whether a particular E-Tree service needs to support single or 366 multiple Root ACs depends on an application. 368 5. L2VPN Gaps for Emulating MEF E-Tree Service 370 E-Tree Service defines special forwarding rules that prohibit 371 forwarding Ethernet frames among leaves. This poses some challenges 372 to IETF L2VPN solutions such as VPLS and EVPN in emulating E-Tree 373 service over an MPLS network. There are two major issues described in 374 the following sections. 376 5.1. No Differentiation on AC Role 378 IP/MPLS L2VPN architecture has no distinct role on Attachment Circuit 379 (AC) and supports any-to-any connectivity among all ACs. It does not 380 have any mechanism to support forwarding constraint based on an AC 381 role. However, E-Tree service defines two AC roles, Root and Leaf, 382 and defines the forwarding rules based on the frame originating and 383 receiving AC roles. 385 5.2. No AC Role Indication or Advertisement 387 In an L2VPN, when a PE, say PE2, receives a frame from another PE, 388 say PE1, over the MPLS core, PE2 does not know if the frame from PE1 389 is originated from a root AC or leaf AC. This causes the forwarding 390 issue on PE2 because the E-Tree forwarding rules require that the 391 forwarder must know the role of the frame origin, i.e. from root AC 392 or leaf AC. This is specifically important, when PE2 has both root AC 393 and leaf AC attached to the VSI. E-Tree forwarding rules apply to all 394 types of frames (known unicast destination, unknown unicast 395 destination, multicast and broadcast). 397 5.3. Other Issues 399 Some desirable requirements for IETF E-Tree are specific to an 400 IP/MPLS L2VPN implementation such as Leaf-only PE. Leaf-only PE is 401 the PE that only has Leaf AC(s) in an E-Tree service instance, thus 402 other PEs on the same E-Tree service instance do not necessarily 403 forward the frames originated from a Leaf AC to the Leaf-only PE, 404 which may save some network resources. It is also desirable for E- 405 Tree solution to work with existing PEs that support single-role AC 406 and the role is equivalent to the root in an E-Tree Service. These 407 requirements are described in the E-Tree requirement document. 408 [RFC7152] 410 6. Security Considerations 412 An E-tree service may be deployed for security reasons to prohibit 413 communication among sites (leaves). An E-tree solution must enforce 414 E-Tree forwarding constraints. The solution must also guarantee that 415 Ethernet frames do not leak outside of the E-tree service instance to 416 which they belong. 418 An E-Tree service prohibits communication among leaf sites but does 419 not have knowledge of higher layer security constraint. Therefore, in 420 general, higher layer applications can not rely on E-Tree to provide 421 the security protection unless all security constraints are fully 422 implemented by E-Tree service. 424 Enhancing L2VPN for E-Tree service inherits the same security issues 425 described in L2VPN framework [RFC4664]. These relate to both control 426 plane and data plane security issues that may arise in the following 427 areas: 429 o issues fully contained in the provider network 431 o issues fully contained in the customer network 433 o issues in the customer-provider interface network 435 The framework has substantial discussions on the security issues and 436 potential solutions to address them. An E-Tree solution must consider 437 these issues and address them properly. VPLS [RFC4761] [RFC4762] 438 and/or EVPN [EVPN] will likely be candidate solutions for E-Tree 439 Service over MPLS network. The security capabilities built in these 440 solutions will be naturally adopted in supporting E-Tree. For the 441 detail, see the security consideration section in [RFC4761], 442 [RFC4762], and [EVPN]. 444 7. IANA Considerations 446 The document requires no IANA action. 448 8. References 450 8.1. Normative References 452 [MEF6.1] MEF, "Metro Ethernet Forum, Ethernet Services Definitions - 453 Phase 2", MEF6.1, April 2008 455 [MEF10.3] MEF, "Ethernet Service Attributes Phase 3", MEF10.3, 456 October 2013 458 [RFC4664] Andersson, L., et al, "Framework for Layer 2 Virtual 459 Private Network (L2VPNs)", RFC4664, Sept. 2006 461 [RFC4761] Kompella & Rekhter, "Virtual Private LAN Service (VPLS) 462 Using BGP for Auto-Discovery and Signaling", RFC4761, 463 January 2007 465 [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS) 466 Using Label Distribution Protocol (LDP) Signaling", 467 RFC4762, January 2007 469 [RFC7152] Key, et al., "Requirements for Metro Ethernet Forum (MEF) 470 Ethernet-Tree (E-Tree) Support in L2VPN", RFC7152, April 471 2011997. 473 8.2. Informative References 475 [IEEE802.1Q] IEEE802.1, "Media Access Control (MAC) Bridges and 476 Virtual Bridged Local Area", IEEE802.1Q, 2011 478 [1588] IEEE 1588, "Precision Time Protocol", IEEE 1588, 2013 480 [LTE] 3GPP TS, "Evolved Universal Terrestrial Radio Access (E- 481 UTRA) and Evolved Universal Terrestrial Radio Access 482 Network (E-UTRAN)", V11.2.0, June, 2012 484 [TR-101] Broadband Forum, "Migration to Ethernet-Based Broadband 485 Aggregation Issue 2", July 2011 487 [VPMS] Kamite, et al., "Framework and Requirements for Virtual 488 Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- 489 frmwk-requirements-05, work in progress 491 [EVPN] Sajassi, et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 492 l2vpn-evpn-07, work in progress 494 9. Contributing Authors 496 The following people contribute the document as co-authors. 498 Yuji Kamite 499 NTT Communications Corporation 500 Granpark Tower 501 3-4-1 Shibaura, Minato-ku 502 Tokyo 108-8118, Japan 503 Email: y.kamite@ntt.com 505 Wim Henderickx 506 Alcatel-Lucent 507 Copernicuslaan 50 508 2018 Antwerp, Belgium 509 Email: wim.henderickx@alcatel-lucent.com 511 10. Acknowledgments 513 Authors like to thank Nabil Bitar for this detail review and 514 suggestions. 516 Authors' Addresses 518 Raymond Key (editor) 520 Email: raymond.key@ieee.org 522 Lucy Yong (editor) 523 Huawei USA 525 Email: lucy.yong@huawei.com 527 Simon Delord 528 Telstra 530 Email: simon.delord@gmail.com 531 Frederic Jounay 532 Orange CH 533 4 rue caudray 1020 Renens 534 Switzerland 536 Email: frederic.jounay@orange.ch 538 Lizhong Jin 540 Email: lizho.jin@gmail.com