idnits 2.17.1 draft-ietf-l2vpn-trill-evpn-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TRILL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 10, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6325' is mentioned on line 310, but not defined == Unused Reference: 'EVPN-REQ' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-evpn-req-04 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-04 == Outdated reference: A later version (-04) exists of draft-ietf-trill-oam-framework-03 -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. 'MPLS-OAM') (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group Ali Sajassi 3 Internet Draft Samer Salam 4 Category: Standards Track Cisco 6 Aldrin Issac 7 Bloomberg 9 Nabil Bitar 10 Verizon 12 Sam Aldrin 13 Huawei 15 Expires: April 10, 2014 October 10, 2013 17 TRILL-EVPN 18 draft-ietf-l2vpn-trill-evpn-01 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Abstract 58 This document discusses how Ethernet VPN (E-VPN) technology is used 59 to interconnect TRILL [TRILL] networks over an MPLS/IP network, with 60 two key characteristics: C-MAC address transparency on the hand-off 61 point and control-plane isolation among the interconnected TRILL 62 networks. 64 Conventions 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4.1. C-MAC Address Transparency on the Hand-off Point . . . . . 4 77 4.2. Control Plane Isolation among TRILL Networks . . . . . . . 5 78 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 79 5.1. TRILL Nickname Assignment . . . . . . . . . . . . . . . . . 6 80 5.2. TRILL Nickname Advertisement Route . . . . . . . . . . . . 7 81 5.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 7 82 5.4. Unicast Forwarding . . . . . . . . . . . . . . . . . . . . 8 83 5.5. Handling Multicast . . . . . . . . . . . . . . . . . . . . 9 84 5.5.1. Multicast Stitching with Per-Source Load Balancing . . 10 85 5.5.2. Multicast Stitching with Per-VLAN Load Balancing . . . 10 86 5.5.3. Multicast Stitching with Per-Flow Load Balancing . . . 11 87 5.5.4. Multicast Stitching with Per-Tree Load Balancing . . . 11 88 6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . . 12 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 10. Intellectual Property Considerations . . . . . . . . . . . . 12 93 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 94 12. Informative References . . . . . . . . . . . . . . . . . . . 13 95 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 [E-VPN] introduces a solution for multipoint L2VPN services, with 100 advanced multi-homing capabilities, using BGP for distributing 101 customer/client MAC address reach-ability information over the core 102 MPLS/IP network. [TRILL] defines a solution for optimal forwarding of 103 Ethernet frames with support for multipathing of unicast and 104 multicast traffic, using IS-IS control-plane and associated tunneling 105 encapsulation that includes a hop count. In this document, we discuss 106 how Ethernet VPN (E-VPN) technology can be used to interconnect TRILL 107 [TRILL] networks over an MPLS/IP network, while guaranteeing two key 108 characteristics: C-MAC address transparency on the hand-off point and 109 control-plane isolation among the interconnected TRILL networks. The 110 resulting solution is referred to as TRILL-EVPN. 112 2. Contributors 114 In addition to the authors listed above, the following individuals 115 also contributed to this document. 117 Keyur Patel Cisco 118 Tissa Senevirathne Cisco 120 3. Terminology 122 CE: Customer Edge 123 C-MAC: Customer/Client MAC Address 124 DHD: Dual-homed Device 125 DHN: Dual-homed Network 126 E-VPN: Ethernet VPN 127 LACP: Link Aggregation Control Protocol 128 LSM: Label Switched Multicast 129 MDT: Multicast Delivery Tree 130 MES: MPLS Edge Switch 131 MP2MP: Multipoint to Multipoint 132 P2MP: Point to Multipoint 133 P2P: Point to Point 134 PoA: Point of Attachment 135 PW: Pseudowire 136 TRILL: Transparent Interconnect of Lots of Links 138 4. Requirements 140 4.1. C-MAC Address Transparency on the Hand-off Point 142 [TRILL] addresses the problem of MAC address table scalability on 143 intermediate switching devices by introducing a tunneling technology 144 and confining C-MAC address learning/forwarding to the edge of the 145 TRILL network. When TRILL networks are interconnected over an MPLS/IP 146 network, it is required to maintain C-MAC address transparency on the 147 hand-off point and the edge (i.e. MES) of the MPLS network. 148 Otherwise, the MPLS edge nodes may suffer from MAC address table 149 space exhaustion given that they would need to learn the C-MAC 150 addresses from all interconnected TRILL networks. 152 TRILL-EVPN supports seamless interconnect with TRILL while 153 guaranteeing C-MAC address transparency on the MES nodes. 155 4.2. Control Plane Isolation among TRILL Networks 157 It is required to maintain control-plane isolation among the various 158 TRILL networks being interconnected over the MPLS/IP network. This 159 ensures the following characteristics: 161 - scalability of the IS-IS control plane in large deployments. In 162 TRILL, all nodes must calculate the shared multicast trees, so as the 163 number of interconnected cloud networks scales, this places a burden 164 on the RBridges, especially if roots are to be located in every site 165 to ensure optimality of the data-path. 167 - fault domain localization, where link or node failures in one site 168 do not trigger SPF re-computations in remote sites. 170 Interconnect solutions which extend the IS-IS control-plane over the 171 MPLS network, as an overlay, do not meet this requirement. TRILL-EVPN 172 provides control-plane isolation between interconnected TRILL 173 networks by terminating the TRILL IS-IS at the MPLS edge nodes. 175 5. Solution Overview 177 TRILL-EVPN enables seamless connectivity of TRILL networks over an 178 MPLS/IP core while ensuring control-plane separation among these 179 networks, and maintaining C-MAC address transparency on the MES 180 nodes. 182 Every TRILL network that is connected to the MPLS core runs an 183 independent instance of the IS-IS control-plane. Each MES 184 participates in the TRILL IS-IS control plane of its local site. The 185 MES peers, in IS-IS protocol, with the RBridges internal to the site, 186 but does not terminate the TRILL data-plane encapsulation. So, from a 187 control-plane viewpoint, the MES appears as an edge RBridge; whereas, 188 from a data-plane viewpoint, the MES appears as a core RBridge to the 189 TRILL network. The MES nodes encapsulate TRILL frames with MPLS in 190 the imposition path, and de-capsulate them in the disposition path. 192 +--------------+ 193 | | 194 +---------+ | MPLS | +---------+ 195 +----+ | | +----+ +----+ | | +----+ 196 |RB1 |--| | |MES1| |MES2| | |--| RB3| 197 +----+ | TRILL |---| | | |--| TRILL | +----+ 198 +----+ | | +----+ +----+ | | +----+ 199 |RB2 |--| | | Backbone | | |--| RB4| 200 +----+ +---------+ +--------------+ +---------+ +----+ 202 |<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP 204 |<------------------------- TRILL -------------------------->| DP 205 |<----MPLS----->| 207 Legend: CP = Control Plane View 208 DP = Data Plane View 210 Figure 1: Interconnecting TRILL Networks with TRILL-EVPN 212 5.1. TRILL Nickname Assignment 214 In TRILL, edge RBridges build forwarding tables that associate remote 215 C-MAC addresses with remote edge RBridge nicknames via data-path 216 learning (except if the optional ESADI function is in use). When 217 different TRILL networks are interconnected over an MPLS/IP network 218 using a seamless hand-off, the edge RBridges (corresponding to the 219 ingress and egress RBridges of particular traffic flows) may very 220 well reside in different TRILL networks. Therefore, in order to 221 guarantee correct connectivity, the TRILL Nicknames must be globally 222 unique across all the interconnected TRILL islands in a given EVI. 223 This can be achieved, for instance, by using a hierarchical Nickname 224 assignment paradigm, and encoding a Site ID in the high-order bits of 225 the Nickname: 227 Nickname = [Site ID : Rbridge ID ] 229 The Site ID uniquely identifies a TRILL network, whereas the RBridge 230 ID portion of the Nickname has local significance to a TRILL site, 231 and can be reused in different sites to designate different RBridges. 232 However, the fully qualified Nickname is globally unique in the 233 entire domain of interconnected TRILL networks for a given EVI. 235 It is worth noting here that this hierarchical Nickname encoding 236 scheme guarantees that Nickname collisions do not occur between 237 different TRILL islands. Therefore, there is no need to define TRILL 238 Nickname collision detection/resolution mechanisms to operate across 239 separate TRILL islands interconnected via TRILL-EVPN. 241 Another point to note is that there are proposals to achieve per-site 242 Nickname significance; however, these proposals either require C-MAC 243 learning on the border RBridge (i.e. violate the C-MAC address 244 transparency requirement), or require a completely new encapsulation 245 and associated data-path for TRILL [TRILL-MULTILEVEL]. 247 5.2. TRILL Nickname Advertisement Route 249 A new BGP route is defined to support the interconnection of TRILL 250 networks over TRILL-EVPN: the TRILL Nickname Advertisement' route, 251 encoded as follows: 253 +---------------------------------------+ 254 | RD (8 octets) | 255 +---------------------------------------+ 256 |Ethernet Segment Identifier (10 octets)| 257 +---------------------------------------+ 258 | Ethernet Tag ID (4 octets) | 259 +---------------------------------------+ 260 | Nickname Length (1 octet) | 261 +---------------------------------------+ 262 | RBridge Nickname (2 octets) | 263 +---------------------------------------+ 264 | MPLS Label (1 octet) | 265 +---------------------------------------+ 267 Figure 2: TRILL Nickname Advertisement Route 269 The MES uses this route to advertise the reachability of TRILL 270 RBridge nicknames to other MES nodes in the EVI. The MPLS label 271 advertised in this route is allocated on a per EVI basis and serves 272 the purpose of identifying to the disposition MES that the MPLS- 273 encapsulated packet holds an MPLS encapsulated TRILL frame. 275 5.3. Frame Format 277 The encapsulation for the transport of TRILL frames over MPLS is 278 encoded as shown in the figure below: 280 +------------------+ 281 | IP/MPLS Header | 282 +------------------+ 283 | TRILL Header | 284 +------------------+ 285 | Ethernet Header | 286 +------------------+ 287 | Ethernet Payload | 288 +------------------+ 289 | Ethernet FCS | 290 +------------------+ 292 Figure 3: TRILL over MPLS Encapsulation 294 It is worth noting here that while it is possible to transport 295 Ethernet encapsulated TRILL frames over MPLS, that approach 296 unnecessarily wastes 16 bytes per packet. That approach further 297 requires either the use of well-known MAC addresses or having the MES 298 nodes advertise in BGP their device MAC addresses, in order to 299 resolve the TRILL next-hop L2 adjacency. To that end, it is simpler 300 and more efficient to transport TRILL natively over MPLS, and this is 301 the reason why a new BGP route for TRILL Nickname advertisement is 302 defined. 304 5.4. Unicast Forwarding 306 Every MES advertises in BGP the Nicknames of all RBridges local to 307 its site in the TRILL Nickname Advertisement routes. Furthermore, the 308 MES advertises in IS-IS, to the local island, the Rbridge nicknames 309 of all remote switches in all the other TRILL islands that the MES 310 has learned via BGP. This is required since TRILL [RFC6325] currently 311 does not define the concept of default routes. However, if the 312 concept of default routes is added to TRILL, then the MES can 313 advertise itself as a border RBridge, and all the other Rbridges in 314 the TRILL network would install a default route pointing to the MES. 315 The default route would be used for all unknown destination 316 Nicknames. This eliminates the need to redistribute Nicknames learnt 317 via BGP into TRILL IS-IS. 319 Note that by having multiple MES nodes (connected to the same TRILL 320 island) advertise routes to the same RBridge nickname, with equal BGP 321 Local_Pref attribute, it is possible to perform active/active load- 322 balancing to/from the MPLS core. 324 When a MES receives an Ethernet-encapsulated TRILL frame from the 325 access side, it removes the Ethernet encapsulation (i.e. outer MAC 326 header), and performs a lookup on the egress RBridge nickname in the 327 TRILL header to identify the next-hop. If the lookup yields that the 328 next hop is a remote MES, the local MES would then encapsulate the 329 TRILL frame with appropriate MPLS label stack. The label stack 330 comprises of the VPN label (advertised by the remote MES), followed 331 by an LSP/IGP label. From that point onwards, regular MPLS forwarding 332 is applied. 334 On the disposition MES, assuming penultimate-hop-popping is employed, 335 the MES receives the MPLS-encapsulated TRILL frame with a single 336 label: the VPN label. The value of the label indicates to the 337 disposition MES that this is a TRILL packet, so the label is popped, 338 the TTL field (in the TRILL header) is reinitialized and normal TRILL 339 processing is employed from this point onwards. 341 5.5. Handling Multicast 343 Each TRILL network independently builds its shared multicast trees. 344 The number of these trees need not match in the different 345 interconnected TRILL islands. In the MPLS/IP network, multiple 346 options are available for the delivery of multicast traffic: 348 - Ingress replication 349 - LSM with Inclusive trees 350 - LSM with Aggregate Inclusive trees 351 - LSM with Selective trees 352 - LSM with Aggregate Selective trees 354 When LSM is used, the trees may be either P2MP or MP2MP. 356 The MES nodes are responsible for stitching the TRILL multicast 357 trees, on the access side, to the ingress replication tunnels or LSM 358 trees in the MPLS/IP core. The stitching must ensure that the 359 following characteristics are maintained at all times: 361 1. Avoiding Packet Duplication: In the case where the TRILL network 362 is multi-homed to multiple MES nodes, if all of the MES nodes forward 363 the same multicast frame, then packet duplication would arise. This 364 applies to both multicast traffic from site to core as well as from 365 core to site. 367 2. Avoiding Forwarding Loops: In the case of TRILL network multi- 368 homing, the solution must ensure that a multicast frame forwarded by 369 a given MES to the MPLS core is not forwarded back by another MES (in 370 the same TRILL network) to the TRILL network of origin. The same 371 applies for traffic in the core to site direction. 373 3. Pacifying TRILL RPF Checks: For multicast traffic originating from 374 a different TRILL network, the RPF checks must be performed against 375 the disposition MES (i.e. the MES on which the traffic ingress into 376 the destination TRILL network). 378 There are two approaches by which the above operation can be 379 guaranteed: one offers per-source load-balancing while the other 380 offers per-flow load-balancing. 382 5.5.1. Multicast Stitching with Per-Source Load Balancing 384 The MES nodes, connected to a multi-homed TRILL network, perform BGP 385 DF election to decide which MES is responsible for forwarding 386 multicast traffic from a given source RBridge. An MES would only 387 forward multicast traffic from source RBridges for which it is the 388 DF, in both the site to core as well as core to site directions. This 389 solves both the issue of avoiding packet duplication as well as the 390 issue of avoiding forwarding loops. 392 In addition, the MES node advertises in IS-IS the nicknames of remote 393 RBridges, learnt in BGP, for which it is the elected DF. This allows 394 all RBridges in the local TRILL network to build the correct RPF 395 state for these remote RBridge nicknames. Note that this results in 396 all unicast traffic to a given remote RBridge being forwarded to the 397 DF MES only (i.e. load-balancing of unicast traffic would not be 398 possible in the site to core direction). 400 Alternatively, all MES nodes in a redundancy group can advertise the 401 nicknames of all remote RBridges learnt in BGP. In addition, each MES 402 advertises the Affinity sub-TLV, defined in [TRILL-CMT], on behalf of 403 each of the remote RBridges for which it is the elected DF. This 404 ensures that the RPF check state is set up correctly in the TRILL 405 network, while allowing load-balancing of unicast traffic among the 406 MES nodes. 408 In this approach, all MES nodes in a given redundancy group can 409 forward and receive traffic on all TRILL trees. 411 5.5.2. Multicast Stitching with Per-VLAN Load Balancing 413 The MES nodes, connected to a multi-homed TRILL network, perform BGP 414 DF election to decide which MES node is responsible for forwarding 415 multicast traffic associated with a given VLAN. An MES would forward 416 multicast traffic for a given VLAN only when it is the DF for this 417 VLAN. This forwarding rule applies in both the site to core as well 418 as core to site directions. 420 In addition, the MES nodes in the redundancy group partition among 421 themselves the set of TRILL multicast trees so that each MES only 422 sends traffic on a unique set of trees. This can be done using the RP 423 Election Protocol as discussed in [TRILL-MULTILEVEL]. Alternatively, 424 the BGP DF election could be used for that. Each MES, then, 425 advertises to the local TRILL network a Default Affinity sub-TLV, per 426 [TRILL-MULTILEVEL], listing the trees that it will be using for 427 multicast traffic originating from remote RBridges. 429 In this approach, each MES node in given TRILL network receives 430 traffic from all TRILL trees but forwards traffic on only a dedicated 431 subset of trees. Hence, the TRILL network must have at least as many 432 multicast trees as the number of directly attached MES nodes. 434 5.5.3. Multicast Stitching with Per-Flow Load Balancing 436 This approach is similar to the per-VLAN load-balancing approach 437 described above, with the difference being that the MES nodes perform 438 the BGP DF election on a per-flow basis. The flow is identified by an 439 N-Tuple comprising of Layer 2 and Layer 3 addresses in addition to 440 Layer 4 ports. This can be done by treating the N-Tuple as a numeric 441 value, and performing, for e.g., a modulo hash function against the 442 number of PEs in the redundancy group in order to identify the index 443 of the PE that is the DF for a given N-Tuple. 445 In this approach, each MES node in given TRILL network receives 446 traffic from all TRILL trees but forwards traffic on only a dedicated 447 subset of trees. Hence, the TRILL network must have at least as many 448 multicast trees as the number of directly attached MES nodes. 450 5.5.4. Multicast Stitching with Per-Tree Load Balancing 452 The MES nodes, connected to a multi-homed TRILL network, perform BGP 453 DF election to decide which MES node is responsible for forwarding 454 multicast traffic associated with a given TRILL multicast tree. An 455 MES would forward multicast traffic with a given destination RBridge 456 nickname only when it is the DF for this nickname. This forwarding 457 rule applies in both the site to core as well as core to site 458 directions. The outcome of the BGP DF election is then used to drive 459 TRILL IS-IS advertisements: the MES advertises to the local TRILL 460 network a Default Affinity sub-TLV, per [TRILL-MULTILEVEL], listing 461 the trees for which it is the elected DF. 463 Note that on the egress MES, the destination RBridge Nickname in 464 multicast frames identifies the multicast tree of the remote TRILL 465 network from which the frame originated. If the TRILL tree 466 identifiers are not coordinated between sites, then the egress 467 Nickname has no meaning in the directly attached (destination) TRILL 468 network. So, the MES needs to select a new tree (after the MPLS 469 disposition) based on a hash function, and rewrite the frame with 470 this new destination Nickname before forwarding the traffic. This may 471 be necessary in certain deployments to ensure complete decoupling 472 between the TRILL sites connected to the MPLS core. On the other 473 hand, if the TRILL tree identifiers are coordinated between sites, 474 then the MES doesn't have to rewrite the destination nickname in the 475 TRILL header, after the MPLS disposition. 477 In this approach, each MES node in a given redundancy group forwards 478 and receives traffic on a disjoint set of TRILL trees. At a minimum, 479 the TRILL network must have as many multicast trees as the number of 480 directly attached MES nodes. 482 6. OAM Considerations 484 When TRILL networks are interconnected over MPLS networks, the IS-IS 485 control plane is not extended across the MPLS network. As described 486 in earlier sections, this will provide advantage in scaling the TRILL 487 networks without any issues when changes happen within different 488 TRILL networks. 490 TRILL OAM could be performed in TRILL networks, within the framework 491 defined in [TRILL-OAM-FWRK]. When TRILL networks are interconnected, 492 TRILL OAM frames just like TRILL data frames are transparently sent 493 over the MPLS network. There are no changes required to perform TRILL 494 OAM operations. MPLS OAM operations could be performed as defined in 495 [MPLS-OAM] to ensure the working of MPLS network interconnecting the 496 TRILL networks. 498 7. Acknowledgements 500 The authors would like to thank Sami Boutros and Dennis Cai for their 501 valuable comments. 503 8. Security Considerations 505 There are no additional security aspects beyond those of VPLS/H-VPLS 506 that need to be discussed here. 508 9. IANA Considerations 510 This document requires IANA to assign a new SAFI value for L2VPN_MAC 511 SAFI. 513 10. Intellectual Property Considerations 515 This document is being submitted for use in IETF standards 516 discussions. 518 11. Normative References 520 [TRILL] Perlman et al., "Routing Bridges (RBridges): Base Protocol 521 Specification", RFC 6325, July, 2011. 523 12. Informative References 525 [EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)", 526 draft-ietf-l2vpn-evpn-req-04.txt, work in progress, July, 527 2013. 529 [E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 530 l2vpn-evpn-04.txt, work in progress, July, 2013. 532 [TRILL-CMT] Senevirathne et al., "Coordinated Multicast Trees for 533 TRILL", draft-tissa-trill-cmt-01.txt, work in progress, 534 January 2012. 536 [TRILL-MULTILEVEL] Senevirathne et al., "Default Nickname Based 537 Approach for Multilevel TRILL", draft-tissa-trill- 538 multilevel-02.txt, work in progress, February 2012. 540 [TRILL-OAM-FWRK] Salam et al., "TRILL OAM Framework", draft-ietf- 541 trill-oam-framework-03, September, 2013. 543 [MPLS-OAM] Kompella & Swallow, "Detecting MPLS Data Plane Failures", 544 RFC 4379, February, 2006. 546 13. Authors' Addresses 548 Ali Sajassi 549 Cisco 550 Email: sajassi@cisco.com 552 Samer Salam 553 Cisco 554 Email: ssalam@cisco.com 556 Nabil Bitar 557 Verizon Communications 558 Email : nabil.n.bitar@verizon.com 560 Aldrin Isaac 561 Bloomberg 562 Email: aisaac71@bloomberg.net 563 Sam Aldrin 564 Huawei 565 Email: sam.aldrin@gmail.com