idnits 2.17.1 draft-muks-trill-evpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3112 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: 'RFC4672' is mentioned on line 100, but not defined == Missing Reference: 'RFC6439' is mentioned on line 171, but not defined ** Obsolete undefined reference: RFC 6439 (Obsoleted by RFC 8139) == Missing Reference: 'RFC6439bis' is mentioned on line 171, but not defined ** Obsolete undefined reference: RFC 6439 (Obsoleted by RFC 8139) == Missing Reference: 'RFC7180bis' is mentioned on line 405, but not defined ** Obsolete undefined reference: RFC 7180 (Obsoleted by RFC 7780) == Unused Reference: 'RFC4762' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC4124' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC3270' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC4026' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'RFC3985' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC4023' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC4448' is defined on line 561, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Downref: Normative reference to an Informational RFC: RFC 6718 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mohammed Umair 3 Intended Status: Proposed Standard Kingston Smiler S 4 Shaji Ravindranathan 5 IP Infusion 6 Lucy Yong 7 Donald Eastlake 3rd 8 Huawei Technologies 9 Expires: April 21, 2016 October 19, 2015 11 TRILL MPLS-Based Ethernet VPN 12 14 Abstract 16 This document describes a TRILL based L2VPN solution using VTSD. VTSD 17 (Virtual TRILL Service/Switch Domain) is specified in [draft-VTSD]. 18 This draft describes the advantages provided by a TRILL based EVPN 19 solution over an existing MPLS L2VPN solution, advantages such as 20 bandwidth scaling and providing multiple active pseudowires. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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 30 Internet-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/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Appointed Forwarders . . . . . . . . . . . . . . . . . . . . . 6 63 3. Multiple Parallel VPLS pseudowires. . . . . . . . . . . . . . 7 64 4. Active-Active Pseudowire . . . . . . . . . . . . . . . . . . . 8 65 4.1. Port-based AC operations. . . . . . . . . . . . . . . . . . 9 66 4.2. VLAN-based AC operations. . . . . . . . . . . . . . . . . . 9 67 5. MPLS encapsulation and Loop free provider PSN/MPLS . . . . . . 10 68 6. Frame processing . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Frame processing between CE's and TIR's. . . . . . . . . . 10 70 6.2. Frame processing between TIR's. . . . . . . . . . . . . . . 11 71 7. MAC Address learning and withdrawal. . . . . . . . . . . . . . 11 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 10.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1 Introduction 81 Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that 82 emulates the essential attributes of a service such as Ethernet over 83 a Packet Switched Network (PSN). The required functions of PWs 84 include encapsulating service-specific PDUs arriving at an ingress 85 port, and carrying them across a path or tunnel, managing their 86 timing and order, and any other operations required to emulate the 87 behavior and characteristics of the service as faithfully as 88 possible. 90 The IETF Transparent Interconnection of Lots of Links (TRILL) 91 protocol [RFC6325] [RFC7177] [rfc7180bis] provides transparent 92 forwarding in multi-hop networks with arbitrary topology and link 93 technologies using a header with a hop count and link-state routing. 94 TRILL provides optimal pair-wise forwarding without configuration, 95 safe forwarding even during periods of temporary loops, and support 96 for multipathing of both unicast and multicast traffic. Intermediate 97 Systems (ISs) implementing TRILL are called Routing 98 Bridges(RBridges)or TRILL Switches. 100 VPLS, specified in [RFC4672], is a proven widely deployed technology. 101 However, the existing solution has a number of limitations when it 102 comes to redundancy, flow-based load balancing, multipathing and 103 handling of BUM (Broadcast, Unknown Unicast, and Multicast) traffic. 105 The [draft-VTSD] introduces a new terminology called VTSD which is a 106 replacement for VSI (Virtual Service Instance) in a traditional VPLS 107 network. [draft-VTSD] states that a VTSD is a logical RBridge resides 108 inside TIR (TRILL Intermediate Router) that should be capable of 109 performing all the operations that a standard TRILL switch can do, 110 along with IP and MPLS functions. A TIR is a Provider Edge (PE) 111 device where VTSD resides and provides TRILL based EVPN solution. 113 The TRILL based EVPN solution is similar the to MPLS based L2VPN 114 solution and uses MPLS L2VPN concepts like pseudowire, attachment 115 circuit, PSN tunnel etc. TRILL EVPN requires extensions to existing 116 IP/MPLS protocols as described in this document. In addition to 117 these extensions, EVPN uses several building blocks from existing 118 MPLS technologies. The VSI in IP/MPLS L2VPN is replaced with VTSD. 119 Replacing VSI with VTSD with TRILL EVPN brings some new features and 120 advantages. This document states these advantages in detail. 122 TRILL as a protocol enables optimal use of the links in a layer2 123 network and running TRILL inside the TIR or VTSD provides a way for 124 optimally utilizing the following: 126 1. The PWE3 mesh connectivity in the VPLS core using parallel 128 pseudowires. 130 2. The PWE3 attachment circuit interface, when there are more 131 than one attachment circuit interfaces using active-active 132 pseudowires. 134 When there is a requirement to increase the bandwidth of a particular 135 pseudowire, with TRILL EVPN, new pseudowires could be created with 136 the same endpoints and with different peer address. These pseudowires 137 are termed as parallel pseudowires. As these pseudowires are attached 138 to VTSD (which is a TRILL RBridge), the TRILL protocol takes care of 139 optimally load sharing the traffic across these parallel 140 pseudowires. 142 Similarly when there is a requirement to increase the bandwidth of 143 customer facing interface (attachment circuit), this can be achieved 144 effectively by adding new attachment circuit interfaces and attaching 145 them to the same VTSD of TRILL EVPN. 147 The objective of a pseudowire (PW) connected in parallel or mesh is 148 to maintain connectivity across the packet switched network (PSN) 149 used by the emulated service. In this model all pseudowires that are 150 part of a service domain will carry data traffic without making any 151 of the pseudowire go in to standby mode. 153 1.1 Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 Acronyms used in this document include the following: 161 AC - Attachment Circuit [RFC4664] 163 Access Port - A TRILL switch port configured with 164 the "end station service enable" bit 165 on, as described in Section 4.9.1 166 of [RFC6325]. All AC's, VTSD ports 167 connected to CE's, should configured 168 as TRILL Access port. 170 AF - Appointed Forwarder [RFC6325], 171 [RFC6439] and [RFC6439bis]. 173 Data Label - VLAN or FGL 174 ECMP - Equal Cost Multi Pathing 176 FGL - Fine-Grained Labeling [RFC7172] 178 IS-IS - Intermediate System to Intermediate 179 System [IS-IS] 181 LAN - Local Area Network 183 Link - The means by which adjacent TRILL 184 switches or VTSD is connected. 185 May be a bridged LAN 187 MLAG - Multi-Chassis Link Aggregation 189 MPLS - Multi-Protocol Label Switching 191 PE - Provider Edge Device 193 PSN - Packet Switched Network 195 PW - Pseudowire [RFC4664] 197 RBridge - An alternative name for TRILL Switch 199 TIR - TRILL Intermediate Router 200 (Devices where Pseudowire starts and 201 Terminates) 203 TRILL - Transparent Interconnection of Lots 204 of Links OR Tunneled Routing in the 205 Link Layer 207 TRILL Site - A part of a TRILL campus that 208 contains at least one RBridge. 210 TRILL switch - A device implementing the TRILL 211 protocol. An alternative name 212 for an RBridge. 214 Trunk port - A TRILL switch port configured with 215 the "end station service disable" 216 bit on, as described in Section 4.9.1 217 of [RFC6325]. All pseudowires should 218 be configured as TRILL Trunk port. 220 VLAN - Virtual Local Area Network 221 VPLS - Virtual Private LAN Service 223 VPTS - Virtual Private TRILL Service 225 VSI - Virtual Service Instance [RFC4664] 227 VTSI - Virtual TRILL Service Instance 229 VTSD - Virtual TRILL Switch Domain OR 230 Virtual TRILL Service Domain 231 A Virtual RBridge that segregates 232 one tenant's TRILL database as well 233 as traffic from the other. 235 VTSD-AP - A VTSD TRILL Access port can be a 236 AC or a logical port connected with 237 CE's. it can be a combination of 238 physical port and Data Label. 239 OR just Physical port connected to 240 CE's 242 2. Appointed Forwarders 244 TRILL supports multi-access LAN (Local Area Network) links that can 245 have multiple end stations and RBridges attached. Where multiple 246 RBridges are attached to a link, native traffic to and from end 247 stations on that link is handled by a subset of those RBridges called 248 "Appointed Forwarders" [rfc6439bis], with the intent that native 249 traffic in each VLAN be handled by at most one RBridge. An RBridge 250 can be Appointed Forwarder for many VLANs. 252 The Appointed Forwarder mechanism is irrelevant to any link on which 253 end station service is not offered. This includes links configured 254 as point-to-point IS-IS links and any link with all RBridge ports on 255 that link configured as trunk ports. (In TRILL, configuration of a 256 port as a "trunk port" just means that no end station service will be 257 provided. It does not imply that all VLANs are enabled on that 258 port). Furthermore, Appointed Forwarder status has no effect on the 259 forwarding of TRILL Data frames. It only affects the handling of 260 native frames. 262 By default, the DRB (Designated RBridge) on a link is in-charge of 263 native traffic for all VLANs on the link. The DRB may, if it wishes, 264 act as Appointed Forwarder for any VLAN and it may appoint other 265 RBridges that have ports on the link as Appointed Forwarder for one 266 or more VLANs. 268 The DRB may appoint other RBridges on the link with any one of the 269 mechanism described in [rfc6439bis]. 271 A RBridge on a multi-access link forms adjacency [RFC7177] with other 272 RBridge if the VLAN's configured/enabled between them are common. For 273 example there are four RBridges attached to multi-access link, say 274 RB1, RB2, RB3 and RB4. RB1 and RB2 are configured with single VLAN 275 "VLAN 2", whereas RB3 and RB4 are configured with "VLAN 3". Assume 276 that there are no Native VLAN's present on any of the RBridges 277 connected to multi-access link. Since TRILL Hellos are sent with VLAN 278 Tag enabled on the interface, RB3 and RB4 drops the hellos of RB1 and 279 RB2 (since they are not configured for VLAN 2). Similarly RB1 and RB2 280 drops the Hellos of RB3 and RB4. This results in RB1 and RB2 not 281 forming adjacency with RB3 and RB4. RB1 and RB2 after electing DRB 282 and forming adjacency between them, will decide about VLAN 2 AF. 283 Similarly RB3 and RB4 decide about the VLAN 3 AF. 285 As VTSD should be capable of performing all the operations a standard 286 TRILL Switch should do, it should also be capable of performing 287 Appointed Forwarder selection. A group of VTSD that are configured 288 for same service's (VLAN's in our case) on different TIR's will form 289 adjacencies, whereas VTSD which are enabled for different VTSI will 290 never form adjacencies. 292 3. Multiple Parallel VPLS pseudowires. 294 TRILL supports multiple parallel adjacencies between neighbor 295 RBridges. Appendix C of [RFC6325] and section 3.5 of [RFC7177] 296 describes this in detail. Multipathing across such parallel 297 connections can be done for unicast TRILL Data traffic on a per-flow 298 basis, but is restricted for multi-destination traffic. VTSD should 299 also support this functionality. 301 TRILL EVPN Pseudowires which belong to same VTSD instance in a TIR 302 and connected to same remote TIR are referred to as parallel 303 pseudowires. These parallel pseudowires corresponds to a single link 304 inside VTSD. 306 Here all pseudowires should be capable of carrying traffic. 308 |<-------------- Emulated Service ---------------->| 309 | | 310 | |<------- Pseudo Wire ------>| | 311 | | | | 312 | | |<-- PSN Tunnels-->| | | 313 | V V V V | 314 V AC +-----+ PW1 +-----+ AC V 315 +-----+ | |VTSD1|==================|VTSD1| | +-----+ 316 | |----------| | | |-------| | 317 | CE1 | | TIR1|==================| TIR2| | CE2 | 318 | | +-----+ PW2 +-----+ | | 319 +-----+ +-----+ 320 Figure 1: Parallel pseudowires with TRILL EVPN 322 In above Figure 1, PW1 and PW2 are parallel pseudowires, as these 323 pseudowires belongs to same VTSD and provides a connectivity across 324 same TIRs. 326 This mechanism provides a way for actively increasing and optimally 327 utilizing the bandwidth in the service provider network without 328 affecting the existing traffic. 330 4. Active-Active Pseudowire 332 [RFC6718] describes pseudowire Redundancy mechanism, wherein among 333 the pair of pseudowires, one pseudowire will be selected as a active 334 pseudowire and the other will be selected as a standby pseudowire. 335 The standby pseudowire will not forward any user traffic under normal 336 circumstances. The introduction of VTSD in TRILL EVPN provides a very 337 simple mechanism for providing multiple active pseudowires. 339 Pseudowires which belongs to the same VTSD instance inside the same 340 TIR or between TIR's will be in active-active state. These 341 pseudowires are able to carry data-traffic without making any one of 342 pseudowire to go in standby mode. 344 To distribute traffic between pseudowires, TRILL protocol will be 345 used. 347 |<-------------- Emulated Service ---------------->| 348 | | 349 | |<------- Pseudo Wire ------>| | 350 | | | | 351 | | |<-- PSN Tunnels-->| | | 352 | V V V V | 353 V AC +----+ +----+ AC V 354 +-----+ | |TIR1|==================| | | +-----+ 355 | |----------|....|..PW1..(active)...|....| | | | 356 | | | |==================| | | | | 357 | | +----+ |TIR3| | | | 358 | | | | | |CE2 | 359 | | | |----------| | 360 | CE1 | | | | | 361 | | | | | | 362 | | +----+ | | +-----+ 363 | | |TIR2|==================| | 364 | |----------|....|..PW2..(active)...|....| 365 +-----+ | | |==================| | 366 AC +----+ +----+ 368 Figure 2: Dual-Home AC with Active-Active PW's 370 In the above Figure 2, pseudowires PW1 and PW2 are in active state 371 and will be capable of carrying user traffic without making anyone of 372 the pseudowire go in standby mode. The above Figure illustrates an 373 application of multiple active pseudowires, where one of the CEs 374 (CE1) is dual-homed. This scenario is designed to actively load 375 share the emulated service among the two TIRs attached to the multi- 376 homed CE (CE1). 378 The attachment circuit can be of either Port-based Attachment Circuit 379 or VLAN-based Attachment Circuit. 381 4.1. Port-based AC operations. 383 In this case, the VTSDs in TIR1 and TIR2 will form TRILL adjacency 384 via AC ports. If the attachment circuit port can carry N number of 385 end-station service VLANs, then TIR1 and TIR2's VTSDs can equally 386 distribute them using AF Mechanism of TRILL. 388 4.2. VLAN-based AC operations. 390 Likewise in Port-based AC, in this case also the VTSDs in TIR1 and 391 TIR2 will form TRILL adjacency via AC ports. Since only one VLAN end- 392 station service is enabled, only one TIR's VTSD can become AF for 393 that VLAN. Hence native traffic can be processed by any one of the 394 AC. 396 5. MPLS encapsulation and Loop free provider PSN/MPLS 398 TRILL with MPLS encapsulation over pseudowire is specified in 399 [RFC7173], and requires no changes in the frame format. 401 TRILL EVPN doesn't require to employ Split Horizon mechanism in the 402 provider PSN network, as TRILL takes care of Loop free topology using 403 Distribution Trees. Any multi-destination frame will traverse a 404 distribution tree path. All distribution trees are calculated based 405 on TRILL base protocol standard [RFC6325] as updated by [RFC7180bis]. 407 6. Frame processing 409 This section specifies frame processing from CE's and TIR's 411 6.1. Frame processing between CE's and TIR's. 413 In a multi-homed CE topology where in a CE is connected to two PEs / 414 TIRs, AF mechanism described in section 2 will be used to decide 415 which TIR/VTSD will carry the traffic for a particular VLAN. This is 416 applicable to the case wherein a CE device is connected to a PE/TIR 417 device via multiple layer 2 interfaces to increase the bandwidth. 419 As a frame gets ingressed into a TIR (or any one of the TIR, when 420 CE/CEs are connected to multiple TIR's) after having AF check, the 421 TIR encapsulates the frame with TRILL and MPLS headers and forwards 422 the frame on a pseudowire. If parallel pseudowires are present, the 423 TRILL protocol running in VTSD will select any one of the pseudowire 424 and forward the TRILL Data packet. Multi-destination packets will be 425 forwarded on Distribution tree's path [rfc7180bis] 427 The advantage of using TRILL for distribution of frames is, even if 428 any of the paths or links fails between CE and TIR's or between 429 TIR's, frames can be always be forwarded to any of available UP links 430 or paths through other links/pseudowires. 432 If multiple equal paths are available, TRILL will distribute traffic 433 among all the paths. 435 Also VTSD doesn't depend on the routing or signaling protocol that is 436 running between TIRs, provided there is a tunnel available with 437 proper encapsulation mechanism. 439 Any multi-destination frames when ingressed to TIR's will traverse 440 one of the Distribution-Trees, with strong RFC Checks. Hop count 441 field in TRILL Header will avoid loops or duplication of Traffic. 443 6.2. Frame processing between TIR's. 445 When a frame gets ingressed into a VTSD inside TIR, the TRILL 446 protocol will forward the frames to the proper pseudowire. When 447 multiple paths / pseudowires are available between the TIR's then 448 shortest path, calculated through TRILL protocol, will be used. If 449 multiple paths are of equal cost, then TRILL protocol will do ECMP 450 load spreading. If any multi-destination frame gets received by the 451 VTSD through a pseudowire, TRILL will do an RPF check and will take 452 proper action. 454 Once a frame gets to the VTSD through pseudowire, MPLS header will be 455 de-capsulated, further action will be taken depending on the egress 456 nickname field of TRILL header. If egress nickname is the nickname of 457 this VTSD, MAC address table and AF lookup will be performed and the 458 frame will be forwarded by decapsulating the TRILL header. If egress 459 nickname belongs to some other VTSD, frame will be forwarded on a 460 pseudowire connected to that VTSD by encapsulating with an MPLS 461 header. 463 7. MAC Address learning and withdrawal. 465 MAC address learning and withdrawal mechanism on a RBridge is 466 specified in section 4.8. of [RFC6325], this document requires no 467 changes for MAC address learning and its withdrawal. 469 8. Security Considerations 471 TBD 473 9. IANA Considerations 475 TBD 477 10. References 479 10.1. Normative References 481 [IS-IS] "Intermediate system to Intermediate system routeing 482 information exchange protocol for use in conjunction with 483 the Protocol for providing the Connectionless-mode Network 484 Service (ISO 8473)", ISO/IEC 10589:2002, 2002". 486 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 487 Ghanwani, "Routing Bridges (RBridges): Base Protocol 488 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 489 . 491 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 492 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 493 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 494 . 496 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 497 Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 498 10.17487/RFC4124, June 2005, . 501 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 502 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 503 Protocol Label Switching (MPLS) Support of Differentiated 504 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 505 . 507 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 508 Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, 509 . 511 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 512 V. Manral, "Transparent Interconnection of Lots of Links 513 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 514 2014, . 516 [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 517 "Transparent Interconnection of Lots of Links (TRILL) 518 Transport Using Pseudowires", RFC 7173, DOI 519 10.17487/RFC7173, May 2014, . 522 [rfc7180bis] Eastlake, D., et al, "TRILL: Clarifications, 523 Corrections, and Updates", draft-ietf-trill-rfc7180bis, 524 work in progress.,. 526 [draft-VTSD] Umair, M., Smiler, K., Eastlake, D., Yong, L., 527 "TRILL Transparent Transport over MPLS" 528 draft-muks-trill-transport-over-mpls, work in 529 progress.,. 531 [rfc6439bis] Eastlake, D., et al., "TRILL: Appointed Forwarders", 532 draft-eastlake-trill-rfc6439bis, work in progress.,. 534 10.2. Informative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, DOI 538 10.17487/RFC2119, March 1997, . 541 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 542 Private Network (VPN) Terminology", RFC 4026, DOI 543 10.17487/RFC4026, March 2005, . 546 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for 547 Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 548 10.17487/RFC4664, September 2006, . 551 [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 552 Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 553 10.17487/RFC3985, March 2005, . 556 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 557 "Encapsulating MPLS in IP or Generic Routing Encapsulation 558 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 559 . 561 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 562 "Encapsulation Methods for Transport of Ethernet over MPLS 563 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 564 . 566 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 567 D. Dutt, "Transparent Interconnection of Lots of Links 568 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 569 10.17487/RFC7172, May 2014, . 572 Authors' Addresses 574 Mohammed Umair 575 IP Infusion 576 RMZ Centennial 577 Mahadevapura Post 578 Bangalore - 560048 India 579 EMail: mohammed.umair2@gmail.com 581 Kingston Smiler S 582 IP Infusion 583 RMZ Centennial 584 Mahadevapura Post 585 Bangalore - 560048 India 586 EMail: kingstonsmiler@gmail.com 588 Shaji Ravindranathan 589 IP Infusion 590 3965 Freedom Circle, Suite 200 591 Santa Clara, CA 95054 USA 592 EMail: srnathan2014@gmail.com 593 Lucy Yong 594 Huawei Technologies 595 5340 Legacy Drive 596 Plano, TX 75024 597 USA 598 Phone: +1-469-227-5837 599 EMail: lucy.yong@huawei.com 601 Donald E. Eastlake 3rd 602 Huawei Technologies 603 155 Beaver Street 604 Milford, MA 01757 605 USA 607 Phone: +1-508-333-2270 608 EMail: d3e3e3@gmail.com