idnits 2.17.1 draft-ietf-trill-transport-over-mpls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2018) is 2286 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mohammed Umair 2 Intended Status: Informational 3 Kingston Smiler Selvaraj 4 IPInfusion 5 Donald Eastlake 3rd 6 Huawei 7 Lucy Yong 8 Self 9 Expires: July 18, 2018 January 19, 2018 11 TRILL Transparent Transport over MPLS 12 draft-ietf-trill-transport-over-mpls-07.txt 14 Abstract 16 This document specifies methods to interconnect multiple Transparent 17 Interconnection of Lots of links (TRILL) sites with an intervening 18 MPLS network using existing TRILL and VPLS standards. This draft 19 addresses two problems as follows: 21 1) Providing connection between more than two TRILL sites that are 22 separated by an MPLS provider network. 24 2) Providing a single logical virtualized TRILL network for different 25 tenants that are separated by an MPLS provider network. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Distribution of this document is unlimited. Comments should be sent 33 to the authors or the TRILL working group mailing list: 34 trill@ietf.org. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................3 54 1.1. Terminology...........................................3 56 2. TRILL Over MPLS Model...................................5 58 3. VPLS Model..............................................6 59 3.1 Entities in the VPLS Model.............................7 60 3.2 TRILL Adjacency for VPLS model.........................8 61 3.3 MPLS encapsulation for VPLS model......................8 62 3.4 Loop Free provider PSN/MPLS............................8 63 3.5 Frame Processing.......................................8 65 4. VPTS Model..............................................9 66 4.1 Entities in the VPTS Model............................11 67 4.1.1 TRILL Intermediate Routers (TIR)....................11 68 4.1.2 Virtual TRILL Switch/Service Domain (VTSD)..........12 69 4.2 TRILL Adjacency for VPTS model........................12 70 4.3 MPLS encapsulation for VPTS model.....................12 71 4.4 Loop Free provider PSN/MPLS...........................12 72 4.5. Frame Processing.....................................13 73 4.5.1 Multi-Destination Frame Processing..................13 74 4.5.2 Unicast Frame Processing............................13 76 5. VPTS Model Versus VPLS Model...........................14 77 6. Packet Processing Between Pseudowires..................14 78 7. Efficiency Considerations..............................15 80 8. Security Considerations................................15 81 9. IANA Considerations....................................15 83 Normative References......................................16 84 Informative References....................................17 86 Acknowledgements..........................................18 87 Authors' Addresses........................................18 89 1. Introduction 91 The IETF Transparent Interconnection of Lots of Links (TRILL) 92 protocol [RFC6325] [RFC7177] [RFC7780] provides transparent 93 forwarding in multi-hop networks with arbitrary topology and link 94 technologies using a header with a hop count and link-state routing. 95 TRILL provides optimal pair-wise forwarding without configuration, 96 safe forwarding even during periods of temporary loops, and support 97 for multipathing of both unicast and multicast traffic. Intermediate 98 Systems (ISs) implementing TRILL are called Routing Bridges 99 (RBridges) or TRILL Switches 101 This document, in conjunction with [RFC7173] on TRILL Transport using 102 Pseudowires, addresses two problems: 104 1) Providing connection between more than two TRILL sites belongs to 105 a single TRILL network that are separated by an MPLS provider 106 network using [RFC7173]. (Herein also called problem statement 1.) 108 2) Providing a single logical virtualized TRILL network for different 109 tenants that are separated by an MPLS provider network. In short 110 providing connection between TRILL sites belonging to a 111 tenant/tenants over a MPLS provider network. (Herein also called 112 problem statement 2.) 114 A tenant is the administrative entity on whose behalf their 115 associated services are managed. Here tenant refers to a TRILL campus 116 that is segregated from other tenants for security reasons. 118 A key multi-tenancy requirement is traffic isolation so that one 119 tenant's traffic is not visible to any other tenant. This draft also 120 addresses the problem of multi-tenancy by isolating one tenant's 121 traffic from the other. 123 [RFC7173] mentions how to interconnect a pair of Transparent 124 Interconnection of Lots of Links (TRILL) switch ports using 125 pseudowires. This document explains, how to connect multiple TRILL 126 sites (not limited to only two sites) using the mechanisms and 127 encapsulations defined in [RFC7173]. 129 1.1. Terminology 131 Acronyms used in this document include the following: 133 AC - Attachment Circuit [RFC4664] 135 Data Label - VLAN or FGL 136 database - IS-IS link state database 138 ECMP - Equal Cost Multi Path 140 FGL - Fine-Grained Labeling [RFC7172] 142 IS-IS - Intermediate System to Intermediate System [IS-IS] 144 LDP - Label Distribution Protocol 146 LAN - Local Area Network 148 MPLS - Multi-Protocol Label Switching 150 PBB - Provider Backbone Bridging 152 PE - Provider Edge Device 154 PSN - Packet Switched Network 156 PW - Pseudowire [RFC4664] 158 TIR - TRILL Intermediate Router (Devices that has both 159 IP/MPLS and TRILL functionality) 161 TRILL - Transparent Interconnection of Lots of Links OR 162 Tunneled Routing in the Link Layer 164 TRILL Site - A part of a TRILL campus that contains at least 165 one RBridge. 167 VLAN - Virtual Local Area Network. 169 VPLS - Virtual Private LAN Service 171 VPTS - Virtual Private TRILL Service 173 VSI - Virtual Service Instance [RFC4664] 175 VTSD - Virtual TRILL Switch Domain OR Virtual TRILL 176 Service Domain. A Virtual RBridge that segregates 177 one tenant's TRILL database as well as traffic from 178 the other. 180 WAN - Wide Area Network 182 2. TRILL Over MPLS Model 184 TRILL Over MPLS can be achieved in two different ways. 186 a) the VPLS Model for TRILL 187 b) the VPTS Model/TIR Model for TRILL 189 Both these models can be used to solve problem statements 1 and 2. 190 Herein the VPLS Model for TRILL is also called Model 1 and the VPTS 191 Model/TIR Model is also called Model 2. 193 3. VPLS Model 195 Figure 1 shows the topological model of TRILL over MPLS using VPLS 196 model. The PE routers in the below topology model should support all 197 the functional Components mentioned in [RFC4664]. 199 +-----+ +-----+ 200 | RBa +---+ ........................... +---| RBb | 201 +-----+ | . . | +-----+ 202 Site 1 | +----+ +----+ | Site 2 203 +----|PE1 | |PE2 |----+ 204 +----+ MPLS Cloud +----+ 205 . . 206 . +----+ . 207 ..........|PE3 |........... 208 +----+ ^ 209 | | 210 | +-- Emulated LAN 211 +-----+ 212 | RBc | 213 +-----+ 214 Site 3 216 Figure 1. Topological Model of TRILL over MPLS 217 connecting three TRILL Sites 219 Figure 2 below shows the topological model of TRILL over MPLS to 220 connect multiple TRILL sites belonging to a tenant. (Tenant here is a 221 TRILL campus, not a specific Data label.) VSI1 and VSI2 are two 222 Virtual Service Instances that segregate Tenant1's traffic from other 223 tenant traffic. VSI1 will maintain its own database for Tenant1, 224 similarly VSI2 will maintain its own database for Tenant2. 226 +-----+ ............................ +-----+ 227 |RBat1+---+ . ++++++++++++++++++++++++ . +---|RBbt1| 228 +-----+ | . + + . | +-----+ 229 Tenant1 Site 1 | +----+ +----+ | Tenant1 Site2 230 +----|VSI1| |VSI1|----+ 231 +----|VSI2| MPLS Cloud |VSI2|----+ 232 | +----+ +----+ | 233 +-----+ | . + + . | +-----+ 234 |RBat2+---+ . +++++++++ +----+ ++++++++ . +---|RBbt2| 235 +-----+ ............|VSI1|........... +-----+ 236 Tenant2 Site 2 |VSI2| ^ Tenant2 Site2 237 +----+ | 238 | | 239 +-----+ +-----Emulated 240 |RBct2| LAN 241 +-----+ 242 Tenant2 Site 3 244 .... VSI1 Path 245 ++++ VSI2 Path 247 Figure 2. Topological Model for VPLS Model 248 connecting 2 Tenants with 3 sites each 250 In this model, TRILL sites are connected to VPLS-capable PE devices 251 that provide a logical interconnect, such that TRILL RBridges 252 belonging to a specific tenant connected via an single bridged 253 Ethernet. These PE devices are the same as the PE devices specified 254 in [RFC4026]. The Attachment Circuit ports of PE Routers are layer 2 255 switch ports that are connected to the RBridges at a TRILL site. Here 256 each VPLS instance looks like an emulated LAN. This model is similar 257 to connecting different RBridges by a layer 2 bridge domain (multi 258 access link) as specified in [RFC6325]. This model doesn't requires 259 any changes in PE routers to carry TRILL packets, as TRILL packets 260 will be transferred transparently. 262 3.1 Entities in the VPLS Model 264 The PE (VPLS-PE) and CE devices are defined in [RFC4026]. 266 The Generic L2VPN Transport Functional Components like Attachment 267 Circuits, Pseudowires, VSI etc. are defined in [RFC4664]. 269 The RB (RBridge) and TRILL Sites are defined in [RFC6325] as updated 270 by [RFC7780]. 272 3.2 TRILL Adjacency for VPLS model 274 As specified in section 3 of this document, the MPLS cloud looks like 275 an emulated LAN (also called multi-access link or broadcast link). 276 This results in RBridges at different sites looking like they are 277 connected by a multi-access link. With such interconnection, the 278 TRILL adjacencies over the link are automatically discovered and 279 established through TRILL IS-IS control messages [RFC7177]. These IS- 280 IS control messages are transparently forwarded by the VPLS domain, 281 after doing MPLS encapsulation as specified in the section 3.4. 283 3.3 MPLS encapsulation for VPLS model 285 Use of VPLS [RFC4762] [RFC4761] to interconnect TRILL sites requires 286 no changes to a VPLS implementation, in particular the use of 287 Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal 288 Ethernet frames from an RBridge (i.e., CE) and is not aware that the 289 CE is an RBridge device. As an example, an MPLS-encapsulated TRILL 290 packet within the MPLS network can use the format illustrated in 291 Appendix A of [RFC7173] for the non-PBB case. For the PBB case, 292 additional header fields illustrated in [RFC7041] can be added by 293 entry PE and removed by the exit PE. 295 3.4 Loop Free provider PSN/MPLS 297 No explicit handling is required to avoid loop free topology. Split 298 Horizon technique specified in [RFC4664] will take care of avoiding 299 loops in the provider PSN network. 301 3.5 Frame Processing 303 The PE devices transparently process the TRILL control and data 304 frames. Procedures to forward the frames are defined in [RFC4664]. 306 4. VPTS Model 308 The VPTS (Virtual Private TRILL Service) is a L2 TRILL service, that 309 emulates TRILL service across a Wide Area Network (WAN). VPTS is 310 similar to what VPLS does for bridge core but provides a TRILL core. 311 VPLS provides "Virtual Private LAN Service" for different customers. 312 VPTS provides "Virtual Private TRILL Service" for different TRILL 313 tenants. 315 Figure 3 shows the topological model of TRILL over MPLS using VPTS. 316 In this model the PE routers are replaced with TIR (TRILL 317 Intermediate Router) and VSI is replaced with VTSD (Virtual TRILL 318 Switch Domain). The TIR devices must be capable of supporting both 319 MPLS and TRILL as specified in section 4.1.1. The TIR devices are 320 interconnected via PWs and appear as a unified emulated TRILL campus 321 with each VTSD inside a TIR equivalent to a RBridge. 323 Some of the reasons for interconnecting TRILL Sites without isolating 324 the TRILL Control plane of one TRILL site from other sites are as 325 described below. 327 1) Nickname Uniqueness: One of the basic requirements of TRILL is 328 that, RBridge Nicknames are unique within the campus [RFC6325]. If 329 we segregate control plane of one TRILL site from other TRILL site 330 and provide interconnection between these sites, it may result in 331 Nickname collision. 333 2) Distribution Trees and their pruning: When a TRILL Data packet 334 traverses a Distribution Tree, it will stay on it even in other 335 TRILL sites. If no end-station service is enabled for a particular 336 Data Label in a TRILL site, the Distribution Tree may be pruned 337 and TRILL data packets of that particular Data Label might never 338 get to another TRILL site where the pckets had no receivers. The 339 TRILL RPF check will always be performed on the packets that are 340 received by TIRs through pseudowires. 342 3) Hop Count values: When a TRILL data packet is received over a 343 pseudowire by a TIR, the TIR does the processing of Hop Count 344 defined in [RFC6325] and will not perform any resetting of Hop 345 Count. 347 +-----+ +-----+ 348 | RBa +---+ ........................... +---| RBb | 349 +-----+ | . . | +-----+ 350 Site 1 | +----+ +----+ | Site 2 351 +----|TIR1| |TIR2|----+ 352 +----+ MPLS Cloud +----+ 353 . . 354 . +----+ . 355 ..........|TIR3|........... 356 +----+ ^ 357 | | 358 | +-- Emulated TRILL 359 +-----+ 360 | RBc | 361 +-----+ 362 Site 3 364 Figure 3. Topological Model of VPTS/TIR 365 connecting three TRILL Sites 367 In the above Figure 3, Site1, Site2 and Site3 (running the TRILL 368 protocol) are connected to TIR Devices. These TIR devices, along with 369 the MPLS cloud, look like an unified emulated TRILL network. Only the 370 PE devices in the MPLS network should be replaced with TIRs so the 371 intermediate Provider routers are agnostic to the TRILL protocol. 373 Figure 4 below extends the topological model of TRILL over MPLS to 374 connect multiple TRILL sites belonging to a tenant (tenant here is a 375 campus, not a Data label) using VPTS model. VTSD1 and VTSD2 are two 376 Virtual TRILL Switch Domains (Virtual RBridges) that segregate 377 Tenant1's traffic from Tenant2's traffic. VTSD1 will maintain its own 378 TRILL database for Tenant1. Similarly VTSD2 will maintain its own 379 TRILL database for Tenant2. 381 +-----+ ............................ +-----+ 382 |RBat1+---+ . ######################## . +---|RBbt1| 383 +-----+ | . # # . | +-----+ 384 Tenant1 Site 1| +-----+ +-----+ | Tenant1 Site 2 385 +----|VTSD1| |VTSD1|----+ 386 +----|VTSD2| MPLS Cloud |VTSD2|----+ 387 | +-----+ +-----+ | 388 +-----+ | . # # . | +-----+ 389 |RBat2+---+ . #########+-----+######### . +---|RBbt2| 390 +-----+ ...........|VTSD1|........... +-----+ 391 Tenant2 Site2 |VTSD2| ^ Tenant2 Site 2 392 +-----+ | 393 | | 394 +-----+ +-----Emulated 395 |RBct2| TRILL 396 +-----+ 397 Tenant2 Site 3 399 .... VTSD1 Connectivity 400 #### VTSD2 Connectivity 402 Figure 4. Topological Model of VPTS/TIR 403 connecting 2 tenants with three TRILL Sites 405 4.1 Entities in the VPTS Model 407 The CE devices are defined in [RFC4026]. 409 The Generic L2VPN Transport Functional Components like Attachment 410 Circuits, Pseudowires etc. are defined in [RFC4664]. 412 The RB (RBridge) and TRILL Campus are defined in [RFC6325] as updated 413 by [RFC7780]. 415 This model introduces two new entities called TIR and VTSD that are 416 described below. 418 4.1.1 TRILL Intermediate Routers (TIR) 420 The TIRs (TRILL Intermediate Routers) must be capable of running both 421 VPLS and TRILL protocols. TIR devices are a superset of the VPLS-PE 422 devices defined in [RFC4026] with the additional functionality of 423 TRILL. The VSI instance that provides transparent bridging 424 functionality in the PE device is replaced with VTSD in a TIR. 426 4.1.2 Virtual TRILL Switch/Service Domain (VTSD) 428 The VTSD (Virtual Trill Switch Domain) is similar to VSI (layer 2 429 bridge) in the VPLS model, but the VTSD acts as a TRILL RBridge. The 430 VTSD is a superset of VSI and must support all the functionality 431 provided by the VSI as defined in [RFC4026]. Along with VSI 432 functionality, the VTSD must be capable of supporting TRILL protocols 433 and forming TRILL adjacencies. The VTSD must be capable of performing 434 all the operations that a standard TRILL Switch can do. 436 One VTSD instance per tenant must be maintained, when multiple 437 tenants are connected to a TIR. The VTSD must maintain all the 438 information maintained by the RBridge on a per tenant basis. The VTSD 439 must also take care of segregating one tenant traffic from other. 440 Each VTSD will have its own nickname for each tenant, If a TIR 441 supports 10 TRILL tenants, it needs to be assigned with ten TRILL 442 nicknames, one for the nickname space of each of its tenants, and run 443 ten copies of TRILL protocols, one for each tenant. It is possible 444 that it would have the same nickname for two or more tenants but, 445 since the TRILL data and control traffic are separated for the 446 tenants, there is no confusion. 448 4.2 TRILL Adjacency for VPTS model 450 The VTSD must be capable of forming TRILL adjacency with the 451 corresponding VTSDs present in its peer VPTS neighbor, and also the 452 neighbor RBridges present in the TRILL sites. The procedure to form 453 TRILL Adjacency is specified in [RFC7173] and [RFC7177]. 455 4.3 MPLS encapsulation for VPTS model 457 The VPTS model uses PPP or Ethernet pseudowires for MPLS 458 encapsulation as specified in [RFC7173], and requires no changes in 459 the packet format in that RFC. In accordance with [RFC7173], the PPP 460 encapsulation is the default. 462 4.4 Loop Free provider PSN/MPLS 464 This model isn't required to employ Split Horizon mechanism in the 465 provider PSN network, as TRILL takes care of Loop free topology using 466 Distribution Trees. Any multi-destination packet will traverse a 467 distribution tree path. All distribution trees are calculated based 468 on TRILL base protocol standard [RFC6325] as updated by [RFC7780]. 470 4.5. Frame Processing 472 This section specifies multi-destination and unicast frame processing 473 in VPTS/TIR model. 475 4.5.1 Multi-Destination Frame Processing 477 Any multi-destination (unknown unicast, multicast or broadcast, as 478 indicated by multi-destination bit in the TRILL Header) packets 479 inside a VTSD will be processed or forwarded through the distribution 480 tree for which they were encapsulated on TRILL ingress. If any multi- 481 destination packet is received from the wrong pseudowire at a VTSD, 482 the TRILL protocol running in the VTSD will perform an RPF check as 483 specified in [RFC7780] and drop the packet. 485 The Pruning mechanism in Distribution Trees, as specified in 486 [RFC6325] and [RFC7780], can also be used to avoid forwarding of 487 multi-destination data packets on the branches where there are no 488 potential destinations. 490 4.5.2 Unicast Frame Processing 492 Unicast packets are forwarded in same way they get forwarded in a 493 standard TRILL Campus as specified in [RFC6325]. If multiple equal 494 cost paths are available over pseudowires to reach destination, then 495 VTSD should be capable of doing ECMP for them. 497 5. VPTS Model Versus VPLS Model 499 VPLS Model uses a simpler loop-breaking rule: the "split horizon" 500 rule, where a PE must not forward traffic from one PW to another in 501 the same VPLS mesh, whereas the VPTS Model uses distribution Trees 502 for loop free topology. As this is an emulated TRILL service, for 503 interoperability purposes the VPTS model is the default. 505 6. Packet Processing Between Pseudowires 507 Whenever a packet gets received over a pseudowire, a VTSD will 508 decapsulate the MPLS headers followed by checking the TRILL header. 509 If the egress nickname in the TRILL header is for a TRILL site 510 located beyond another pseudowire, then VTSD will encapsulate with 511 new MPLS headers and send it across the proper pseudowire. 513 For example in figure 3, consider that the pseudowire between TIR1 514 and TIR2 fails, Then TIR1 will communicate with TIR2 via TIR3, 515 whenever packets which are destined to TIR3 gets received from 516 pseudowire between TIR1 and TIR3, VTSD inside TIR3 will decapsulate 518 the MPLS headers, then check the TRILL header's egress nickname 519 field. If the egress nickname indicate it is destained for the 520 RBridge in site3 then the packet will be sent to RBc, if the egress 521 nickname is located at site2, VTSD will add MPLS headers for the 522 pseudowire between TIR3 and TIR2 and forward the packet on that 523 pseudowire. 525 7. Efficiency Considerations 527 Since the VPTS Model uses Distribution trees for processing of multi- 528 destination data packets, it is always advisable to have at least one 529 Distribution tree root to be located in every TRILL site. This will 530 avoid data packets getting received at TRILL sites where end-station 531 service is not enabled for that data packet. 533 8. Security Considerations 535 As an informational document specifying methods that use only 536 existing standards and facilities, this document has no effect on 537 security. 539 For general TRILL security considerations, see [RFC6325] 541 For transport of TRILL by Pseudowires security consideration, see 542 [RFC7173]. 544 For general VPLS security considerations, see [RFC4761] and [RFC4762] 546 9. IANA Considerations 548 This document requires no IANA actions. RFC Editor: Please delete 549 this section before publication 551 Normative References 553 [IS-IS] "Intermediate system to Intermediate system routeing 554 information exchange protocol for use in conjunction with the 555 Protocol for providing the Connectionless-mode Network Service 556 (ISO 8473)", ISO/IEC 10589:2002, 2002". 558 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 559 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", 560 RFC 4761, DOI 10.17487/RFC4761, January 2007, . 563 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 564 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 565 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 566 . 568 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 569 Ghanwani, "Routing Bridges (RBridges): Base Protocol 570 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 571 . 573 [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 574 "Transparent Interconnection of Lots of Links (TRILL) Transport 575 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 576 . 578 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 579 V. Manral, "Transparent Interconnection of Lots of Links 580 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 581 . 583 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 584 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 585 Lots of Links (TRILL): Clarifications, Corrections, and 586 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 587 . 589 Informative References 591 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 592 Private Network (VPN) Terminology", RFC 4026, DOI 593 10.17487/RFC4026, March 2005, . 596 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 597 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 598 10.17487/RFC4664, September 2006, . 601 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 602 "Extensions to the Virtual Private LAN Service (VPLS) Provider 603 Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 604 10.17487/RFC7041, November 2013, . 607 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 608 D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 609 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 610 2014, . 612 Acknowledgements 614 The contributions of Andrew G. Malis is gratefully acknowledged in 615 improving the quality of this document. 617 The document was prepared in raw nroff. All macros used were defined 618 within the source file. 620 Authors' Addresses 622 Mohammed Umair 623 Cisco Systems 624 SEZ, Cessna Business Park 625 Sarjapur - Marathahalli Outer Ring road 626 Bengaluru - 560103, India 628 EMail: mohammed.umair2@gmail.com 630 Kingston Smiler Selvaraj 631 IPInfusion 632 RMZ Centennial 633 Mahadevapura Post 634 Bangalore - 560048 India 636 EMail: kingstonsmiler@gmail.com 638 Donald E. Eastlake 3rd 639 Huawei Technologies 640 155 Beaver Street 641 Milford, MA 01757 642 USA 644 Phone: +1-508-333-2270 645 EMail: d3e3e3@gmail.com 647 Lucy Yong 648 Self 650 Phone: +1-469-227-5837 651 EMail: lucyyong@gmail.com 653 Copyright, Disclaimer, and Additional IPR Provisions 655 Copyright (c) 2018 IETF Trust and the persons identified as the 656 document authors. All rights reserved. 658 This document is subject to BCP 78 and the IETF Trust's Legal 659 Provisions Relating to IETF Documents 660 (http://trustee.ietf.org/license-info) in effect on the date of 661 publication of this document. Please review these documents 662 carefully, as they describe your rights and restrictions with respect 663 to this document. Code Components extracted from this document must 664 include Simplified BSD License text as described in Section 4.e of 665 the Trust Legal Provisions and are provided without warranty as 666 described in the Simplified BSD License. The definitive version of 667 an IETF Document is that published by, or under the auspices of, the 668 IETF. Versions of IETF Documents that are published by third parties, 669 including those that are translated into other languages, should not 670 be considered to be definitive versions of IETF Documents. The 671 definitive version of these Legal Provisions is that published by, or 672 under the auspices of, the IETF. Versions of these Legal Provisions 673 that are published by third parties, including those that are 674 translated into other languages, should not be considered to be 675 definitive versions of these Legal Provisions. For the avoidance of 676 doubt, each Contributor to the IETF Standards Process licenses each 677 Contribution that he or she makes as part of the IETF Standards 678 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 679 language to the contrary, or terms, conditions or rights that differ 680 from or are inconsistent with the rights and licenses granted under 681 RFC 5378, shall have any effect and shall be null and void, whether 682 published or posted by such Contributor, or included with or in such 683 Contribution.