idnits 2.17.1 draft-ietf-trill-transport-over-mpls-08.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 (March 18, 2018) is 2224 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 ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mohammed Umair 2 Intended Status: Informational Kingston Smiler Selvaraj 3 IPInfusion 4 Donald Eastlake 3rd 5 Huawei 6 Lucy Yong 7 Self 8 Expires: September 17, 2018 March 18, 2018 10 TRILL Transparent Transport over MPLS 11 draft-ietf-trill-transport-over-mpls-08.txt 13 Abstract 15 This document specifies methods to interconnect multiple Transparent 16 Interconnection of Lots of links (TRILL) sites with an intervening 17 MPLS network using existing TRILL and VPLS standards. This draft 18 addresses two problems as follows: 20 1) Providing connection between more than two TRILL sites that are 21 separated by an MPLS provider network. 23 2) Providing a single logical virtualized TRILL network for different 24 tenants that are separated by an MPLS provider network. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Distribution of this document is unlimited. Comments should be sent 32 to the authors or the TRILL working group mailing list: 33 trill@ietf.org. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................3 53 1.1. Terminology...........................................3 55 2. TRILL Over MPLS Model...................................5 57 3. VPLS Model..............................................6 58 3.1 Entities in the VPLS Model.............................7 59 3.2 TRILL Adjacency for VPLS model.........................8 60 3.3 MPLS encapsulation for VPLS model......................8 61 3.4 Loop Free provider PSN/MPLS............................8 62 3.5 Frame Processing.......................................8 64 4. VPTS Model..............................................9 65 4.1 Entities in the VPTS Model............................11 66 4.1.1 TRILL Intermediate Routers (TIR)....................11 67 4.1.2 Virtual TRILL Switch/Service Domain (VTSD)..........12 68 4.2 TRILL Adjacency for VPTS model........................12 69 4.3 MPLS encapsulation for VPTS model.....................12 70 4.4 Loop Free provider PSN/MPLS...........................12 71 4.5. Frame Processing.....................................13 72 4.5.1 Multi-Destination Frame Processing..................13 73 4.5.2 Unicast Frame Processing............................13 75 5. VPTS Model Versus VPLS Model...........................14 76 6. Packet Processing Between Pseudowires..................14 78 7. Efficiency Considerations..............................15 79 8. Security Considerations................................15 80 9. IANA Considerations....................................16 82 Normative References......................................17 83 Informative References....................................18 85 Acknowledgements..........................................19 86 Authors' Addresses........................................19 88 1. Introduction 90 The IETF Transparent Interconnection of Lots of Links (TRILL) 91 protocol [RFC6325] [RFC7177] [RFC7780] 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 Bridges 98 (RBridges) or TRILL Switches 100 This document, in conjunction with [RFC7173] on TRILL Transport using 101 Pseudowires, addresses two problems: 103 1) Providing connection between more than two TRILL sites belongs to 104 a single TRILL network that are separated by an MPLS provider 105 network using [RFC7173]. (Herein also called problem statement 1.) 107 2) Providing a single logical virtualized TRILL network for different 108 tenants that are separated by an MPLS provider network. In short 109 providing connection between TRILL sites belonging to a 110 tenant/tenants over a MPLS provider network. (Herein also called 111 problem statement 2.) 113 A tenant is the administrative entity on whose behalf their 114 associated services are managed. Here tenant refers to a TRILL campus 115 that is segregated from other tenants for security reasons. 117 A key multi-tenancy requirement is traffic isolation so that one 118 tenant's traffic is not visible to any other tenant. This draft also 119 addresses the problem of multi-tenancy by isolating one tenant's 120 traffic from the other. 122 [RFC7173] mentions how to interconnect a pair of Transparent 123 Interconnection of Lots of Links (TRILL) switch ports using 124 pseudowires. This document explains, how to connect multiple TRILL 125 sites (not limited to only two sites) using the mechanisms and 126 encapsulations defined in [RFC7173]. 128 1.1. Terminology 130 Acronyms used in this document include the following: 132 AC - Attachment Circuit [RFC4664] 134 Data Label - VLAN or FGL 135 database - IS-IS link state database 137 ECMP - Equal Cost Multi Path 139 FGL - Fine-Grained Labeling [RFC7172] 141 IS-IS - Intermediate System to Intermediate System [IS-IS] 143 LDP - Label Distribution Protocol 145 LAN - Local Area Network 147 MPLS - Multi-Protocol Label Switching 149 PBB - Provider Backbone Bridging 151 PE - Provider Edge Device 153 PSN - Packet Switched Network 155 PW - Pseudowire [RFC4664] 157 TIR - TRILL Intermediate Router (Devices that has both 158 IP/MPLS and TRILL functionality) 160 TRILL - Transparent Interconnection of Lots of Links OR 161 Tunneled Routing in the Link Layer 163 TRILL Site - A part of a TRILL campus that contains at least 164 one RBridge. 166 VLAN - Virtual Local Area Network. 168 VPLS - Virtual Private LAN Service 170 VPTS - Virtual Private TRILL Service 172 VSI - Virtual Service Instance [RFC4664] 174 VTSD - Virtual TRILL Switch Domain OR Virtual TRILL 175 Service Domain. A Virtual RBridge that segregates 176 one tenant's TRILL database as well as traffic from 177 the other. 179 WAN - Wide Area Network 181 2. TRILL Over MPLS Model 183 TRILL Over MPLS can be achieved in two different ways. 185 a) the VPLS Model for TRILL 186 b) the VPTS Model/TIR Model for TRILL 188 Both these models can be used to solve problem statements 1 and 2. 189 Herein the VPLS Model for TRILL is also called Model 1 and the VPTS 190 Model/TIR Model is also called Model 2. 192 3. VPLS Model 194 Figure 1 shows the topological model of TRILL over MPLS using VPLS 195 model. The PE routers in the below topology model should support all 196 the functional Components mentioned in [RFC4664]. 198 +-----+ +-----+ 199 | RBa +---+ ........................... +---| RBb | 200 +-----+ | . . | +-----+ 201 Site 1 | +----+ +----+ | Site 2 202 +----|PE1 | |PE2 |----+ 203 +----+ MPLS Cloud +----+ 204 . . 205 . +----+ . 206 ..........|PE3 |........... 207 +----+ ^ 208 | | 209 | +-- Emulated LAN 210 +-----+ 211 | RBc | 212 +-----+ 213 Site 3 215 Figure 1. Topological Model of TRILL over MPLS 216 connecting three TRILL Sites 218 Figure 2 below shows the topological model of TRILL over MPLS to 219 connect multiple TRILL sites belonging to a tenant. (Tenant here is a 220 TRILL campus, not a specific Data label.) VSI1 and VSI2 are two 221 Virtual Service Instances that segregate Tenant1's traffic from other 222 tenant traffic. VSI1 will maintain its own database for Tenant1, 223 similarly VSI2 will maintain its own database for Tenant2. 225 +-----+ ............................ +-----+ 226 |RBat1+---+ . ++++++++++++++++++++++++ . +---|RBbt1| 227 +-----+ | . + + . | +-----+ 228 Tenant1 | +----+ +----+ | Tenant1 229 Site 1 +----|VSI1| |VSI1|----+ Site 2 230 +----|VSI2| MPLS Cloud |VSI2|----+ 231 | +----+ +----+ | 232 +-----+ | . + + . | +-----+ 233 |RBat2+---+ . +++++++++ +----+ ++++++++ . +---|RBbt2| 234 +-----+ ............|VSI1|........... +-----+ 235 Tenant2 |VSI2| ^ Tenant2 236 Site 1 +----+ | Site 2 237 | | 238 +-----+ +-----Emulated 239 |RBct2| LAN 240 +-----+ 241 Tenant2 Site 3 243 .... VSI1 Path 244 ++++ VSI2 Path 246 Figure 2. Topological Model for VPLS Model 247 connecting 2 Tenants with 3 sites each 249 In this model, TRILL sites are connected to VPLS-capable PE devices 250 that provide a logical interconnect, such that TRILL RBridges 251 belonging to a specific tenant connected via an single bridged 252 Ethernet. These PE devices are the same as the PE devices specified 253 in [RFC4026]. The Attachment Circuit ports of PE Routers are layer 2 254 switch ports that are connected to the RBridges at a TRILL site. Here 255 each VPLS instance looks like an emulated LAN. This model is similar 256 to connecting different RBridges by a layer 2 bridge domain (multi 257 access link) as specified in [RFC6325]. This model doesn't requires 258 any changes in PE routers to carry TRILL packets, as TRILL packets 259 will be transferred transparently. 261 3.1 Entities in the VPLS Model 263 The PE (VPLS-PE) and CE devices are defined in [RFC4026]. 265 The Generic L2VPN Transport Functional Components like Attachment 266 Circuits, Pseudowires, VSI etc. are defined in [RFC4664]. 268 The RB (RBridge) and TRILL Sites are defined in [RFC6325] as updated 269 by [RFC7780]. 271 3.2 TRILL Adjacency for VPLS model 273 As specified in section 3 of this document, the MPLS cloud looks like 274 an emulated LAN (also called multi-access link or broadcast link). 275 This results in RBridges at different sites looking like they are 276 connected by a multi-access link. With such interconnection, the 277 TRILL adjacencies over the link are automatically discovered and 278 established through TRILL IS-IS control messages [RFC7177]. These IS- 279 IS control messages are transparently forwarded by the VPLS domain, 280 after doing MPLS encapsulation as specified in the section 3.4. 282 3.3 MPLS encapsulation for VPLS model 284 Use of VPLS [RFC4762] [RFC4761] to interconnect TRILL sites requires 285 no changes to a VPLS implementation, in particular the use of 286 Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal 287 Ethernet frames from an RBridge (i.e., CE) and is not aware that the 288 CE is an RBridge device. As an example, an MPLS-encapsulated TRILL 289 packet within the MPLS network can use the format illustrated in 290 Appendix A of [RFC7173] for the non-PBB case. For the PBB case, 291 additional header fields illustrated in [RFC7041] can be added by 292 entry PE and removed by the exit PE. 294 3.4 Loop Free provider PSN/MPLS 296 No explicit handling is required to avoid loop free topology. Split 297 Horizon technique specified in [RFC4664] will take care of avoiding 298 loops in the provider PSN network. 300 3.5 Frame Processing 302 The PE devices transparently process the TRILL control and data 303 frames. Procedures to forward the frames are defined in [RFC4664]. 305 4. VPTS Model 307 The VPTS (Virtual Private TRILL Service) is a L2 TRILL service, that 308 emulates TRILL service across a Wide Area Network (WAN). VPTS is 309 similar to what VPLS does for bridge core but provides a TRILL core. 310 VPLS provides "Virtual Private LAN Service" for different customers. 311 VPTS provides "Virtual Private TRILL Service" for different TRILL 312 tenants. 314 Figure 3 shows the topological model of TRILL over MPLS using VPTS. 315 In this model the PE routers are replaced with TIR (TRILL 316 Intermediate Router) and VSI is replaced with VTSD (Virtual TRILL 317 Switch Domain). The TIR devices must be capable of supporting both 318 MPLS and TRILL as specified in section 4.1.1. The TIR devices are 319 interconnected via PWs and appear as a unified emulated TRILL campus 320 with each VTSD inside a TIR equivalent to a RBridge. 322 Some of the reasons for interconnecting TRILL Sites without isolating 323 the TRILL Control plane of one TRILL site from other sites are as 324 described below. 326 1) Nickname Uniqueness: One of the basic requirements of TRILL is 327 that, RBridge Nicknames are unique within the campus [RFC6325]. If 328 we segregate control plane of one TRILL site from other TRILL site 329 and provide interconnection between these sites, it may result in 330 Nickname collision. 332 2) Distribution Trees and their pruning: When a TRILL Data packet 333 traverses a Distribution Tree, it will stay on it even in other 334 TRILL sites. If no end-station service is enabled for a particular 335 Data Label in a TRILL site, the Distribution Tree may be pruned 336 and TRILL data packets of that particular Data Label might never 337 get to another TRILL site where the pckets had no receivers. The 338 TRILL RPF check will always be performed on the packets that are 339 received by TIRs through pseudowires. 341 3) Hop Count values: When a TRILL data packet is received over a 342 pseudowire by a TIR, the TIR does the processing of Hop Count 343 defined in [RFC6325] and will not perform any resetting of Hop 344 Count. 346 +-----+ +-----+ 347 | RBa +---+ ........................... +---| RBb | 348 +-----+ | . . | +-----+ 349 Site 1 | +----+ +----+ | Site 2 350 +----|TIR1| |TIR2|----+ 351 +----+ MPLS Cloud +----+ 352 . . 353 . +----+ . 354 ..........|TIR3|........... 355 +----+ ^ 356 | | 357 | +-- Emulated TRILL 358 +-----+ 359 | RBc | 360 +-----+ 361 Site 3 363 Figure 3. Topological Model of VPTS/TIR 364 connecting three TRILL Sites 366 In the above Figure 3, Site1, Site2 and Site3 (running the TRILL 367 protocol) are connected to TIR Devices. These TIR devices, along with 368 the MPLS cloud, look like an unified emulated TRILL network. Only the 369 PE devices in the MPLS network should be replaced with TIRs so the 370 intermediate Provider routers are agnostic to the TRILL protocol. 372 Figure 4 below extends the topological model of TRILL over MPLS to 373 connect multiple TRILL sites belonging to a tenant (tenant here is a 374 campus, not a Data label) using VPTS model. VTSD1 and VTSD2 are two 375 Virtual TRILL Switch Domains (Virtual RBridges) that segregate 376 Tenant1's traffic from Tenant2's traffic. VTSD1 will maintain its own 377 TRILL database for Tenant1. Similarly VTSD2 will maintain its own 378 TRILL database for Tenant2. 380 +-----+ ............................ +-----+ 381 |RBat1+---+ . ######################## . +---|RBbt1| 382 +-----+ | . # # . | +-----+ 383 Tenant1 | +-----+ +-----+ | Tenant1 384 Site 1 +----|VTSD1| |VTSD1|----+ Site 2 385 +----|VTSD2| MPLS Cloud |VTSD2|----+ 386 | +-----+ +-----+ | 387 +-----+ | . # # . | +-----+ 388 |RBat2+---+ . #########+-----+######### . +---|RBbt2| 389 +-----+ ...........|VTSD1|........... +-----+ 390 Tenant2 |VTSD2| ^ Tenant2 391 Site 1 +-----+ | Site 2 392 | | 393 +-----+ +-----Emulated 394 |RBct2| TRILL 395 +-----+ 396 Tenant2 Site 3 398 .... VTSD1 Connectivity 399 #### VTSD2 Connectivity 401 Figure 4. Topological Model of VPTS/TIR 402 connecting 2 tenants with three TRILL Sites 404 4.1 Entities in the VPTS Model 406 The CE devices are defined in [RFC4026]. 408 The Generic L2VPN Transport Functional Components like Attachment 409 Circuits, Pseudowires etc. are defined in [RFC4664]. 411 The RB (RBridge) and TRILL Campus are defined in [RFC6325] as updated 412 by [RFC7780]. 414 This model introduces two new entities called TIR and VTSD that are 415 described below. 417 4.1.1 TRILL Intermediate Routers (TIR) 419 The TIRs (TRILL Intermediate Routers) must be capable of running both 420 VPLS and TRILL protocols. TIR devices are a superset of the VPLS-PE 421 devices defined in [RFC4026] with the additional functionality of 422 TRILL. The VSI instance that provides transparent bridging 423 functionality in the PE device is replaced with VTSD in a TIR. 425 4.1.2 Virtual TRILL Switch/Service Domain (VTSD) 427 The VTSD (Virtual Trill Switch Domain) is similar to VSI (layer 2 428 bridge) in the VPLS model, but the VTSD acts as a TRILL RBridge. The 429 VTSD is a superset of VSI and must support all the functionality 430 provided by the VSI as defined in [RFC4026]. Along with VSI 431 functionality, the VTSD must be capable of supporting TRILL protocols 432 and forming TRILL adjacencies. The VTSD must be capable of performing 433 all the operations that a standard TRILL Switch can do. 435 One VTSD instance per tenant must be maintained, when multiple 436 tenants are connected to a TIR. The VTSD must maintain all the 437 information maintained by the RBridge on a per tenant basis. The VTSD 438 must also take care of segregating one tenant traffic from other. 439 Each VTSD will have its own nickname for each tenant, If a TIR 440 supports 10 TRILL tenants, it needs to be assigned with ten TRILL 441 nicknames, one for the nickname space of each of its tenants, and run 442 ten copies of TRILL protocols, one for each tenant. It is possible 443 that it would have the same nickname for two or more tenants but, 444 since the TRILL data and control traffic are separated for the 445 tenants, there is no confusion. 447 4.2 TRILL Adjacency for VPTS model 449 The VTSD must be capable of forming TRILL adjacency with the 450 corresponding VTSDs present in its peer VPTS neighbor, and also the 451 neighbor RBridges present in the TRILL sites. The procedure to form 452 TRILL Adjacency is specified in [RFC7173] and [RFC7177]. 454 4.3 MPLS encapsulation for VPTS model 456 The VPTS model uses PPP or Ethernet pseudowires for MPLS 457 encapsulation as specified in [RFC7173], and requires no changes in 458 the packet format in that RFC. In accordance with [RFC7173], the PPP 459 encapsulation is the default. 461 4.4 Loop Free provider PSN/MPLS 463 This model isn't required to employ Split Horizon mechanism in the 464 provider PSN network, as TRILL takes care of Loop free topology using 465 Distribution Trees. Any multi-destination packet will traverse a 466 distribution tree path. All distribution trees are calculated based 467 on TRILL base protocol standard [RFC6325] as updated by [RFC7780]. 469 4.5. Frame Processing 471 This section specifies multi-destination and unicast frame processing 472 in VPTS/TIR model. 474 4.5.1 Multi-Destination Frame Processing 476 Any multi-destination (unknown unicast, multicast or broadcast, as 477 indicated by multi-destination bit in the TRILL Header) packets 478 inside a VTSD will be processed or forwarded through the distribution 479 tree for which they were encapsulated on TRILL ingress. If any multi- 480 destination packet is received from the wrong pseudowire at a VTSD, 481 the TRILL protocol running in the VTSD will perform an RPF check as 482 specified in [RFC7780] and drop the packet. 484 The Pruning mechanism in Distribution Trees, as specified in 485 [RFC6325] and [RFC7780], can also be used to avoid forwarding of 486 multi-destination data packets on the branches where there are no 487 potential destinations. 489 4.5.2 Unicast Frame Processing 491 Unicast packets are forwarded in same way they get forwarded in a 492 standard TRILL Campus as specified in [RFC6325]. If multiple equal 493 cost paths are available over pseudowires to reach destination, then 494 VTSD should be capable of doing ECMP for them. 496 5. VPTS Model Versus VPLS Model 498 VPLS Model uses a simpler loop-breaking rule: the "split horizon" 499 rule, where a PE must not forward traffic from one PW to another in 500 the same VPLS mesh, whereas the VPTS Model uses distribution Trees 501 for loop free topology. As this is an emulated TRILL service, for 502 interoperability purposes the VPTS model is the default. 504 6. Packet Processing Between Pseudowires 506 Whenever a packet gets received over a pseudowire, a VTSD will 507 decapsulate the MPLS headers followed by checking the TRILL header. 508 If the egress nickname in the TRILL header is for a TRILL site 509 located beyond another pseudowire, then VTSD will encapsulate with 510 new MPLS headers and send it across the proper pseudowire. 512 For example in figure 3, consider that the pseudowire between TIR1 513 and TIR2 fails, Then TIR1 will communicate with TIR2 via TIR3, 514 whenever packets which are destined to TIR3 gets received from 515 pseudowire between TIR1 and TIR3, VTSD inside TIR3 will decapsulate 517 the MPLS headers, then check the TRILL header's egress nickname 518 field. If the egress nickname indicate it is destained for the 519 RBridge in site3 then the packet will be sent to RBc, if the egress 520 nickname is located at site2, VTSD will add MPLS headers for the 521 pseudowire between TIR3 and TIR2 and forward the packet on that 522 pseudowire. 524 7. Efficiency Considerations 526 Since the VPTS Model uses Distribution trees for processing of multi- 527 destination data packets, it is always advisable to have at least one 528 Distribution tree root to be located in every TRILL site. This will 529 avoid data packets getting received at TRILL sites where end-station 530 service is not enabled for that data packet. 532 8. Security Considerations 534 This document specifies methods using existing standards and 535 facilities in ways that do not create new security problems. 537 For general VPLS security considerations, including discussion of 538 isolating customers from each other, see [RFC4761] and [RFC4762]. 540 For transport of TRILL by Pseudowires security consideration, see 541 [RFC7173]. In particular, since pseudowires are support by MPLS or IP 542 which are in turn supported by a link layer, that document recommends 543 using IP security, such as IPsec [RFC4301] or DTLS [RFC6347], or the 544 lower link layer security, such as MACSEC [802.1AE] for Ethernet 545 links. 547 Transmission outside the customer environment through the provider 548 environment, as described in this document, increases risk of 549 compromise or injection of false data through failure of tenant 550 isolation or by the provider. In the VPLS model (Section 3), the use 551 of link encryption and authentication between the CEs of a tenant 552 that is being connected through provider facilities should be a good 553 defense. In the VPTS model (Section 4), it is assumed that the CEs 554 will peer with virtual TRILL switches of the provider network and 555 thus link security between TRILL switch ports is inadequate as it 556 will terminate at the edge PE. Thus, end station to end station 557 encryption and authentication is more appropriate for the VPTS model. 559 For added security against the compromise of data end-to-end 560 encryption and authentication should be considered; that is, 561 encryption and authentication from source end station to destination 562 end station. This would typically be provided by IPsec [RFC4301] or 563 DTLS [RFC6347] or other protocols convenient to protect information 564 of concern. 566 For general TRILL security considerations, see [RFC6325]. 568 9. IANA Considerations 570 This document requires no IANA actions. RFC Editor: Please delete 571 this section before publication 573 Normative References 575 [IS-IS] "Intermediate system to Intermediate system routeing 576 information exchange protocol for use in conjunction with the 577 Protocol for providing the Connectionless-mode Network Service 578 (ISO 8473)", ISO/IEC 10589:2002, 2002". 580 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 581 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", 582 RFC 4761, DOI 10.17487/RFC4761, January 2007, . 585 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 586 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 587 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 588 . 590 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 591 Ghanwani, "Routing Bridges (RBridges): Base Protocol 592 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 593 . 595 [RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 596 "Transparent Interconnection of Lots of Links (TRILL) Transport 597 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 598 . 600 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 601 V. Manral, "Transparent Interconnection of Lots of Links 602 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 603 . 605 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 606 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 607 Lots of Links (TRILL): Clarifications, Corrections, and 608 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 609 . 611 Informative References 613 [802.1AE] "IEEE Standard for Local and metropolitan area networks-- 614 Media Access Control (MAC) Security.", 2006. 616 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 617 Private Network (VPN) Terminology", RFC 4026, DOI 618 10.17487/RFC4026, March 2005, . 621 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 622 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 623 2005, . 625 [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 626 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 627 10.17487/RFC4664, September 2006, . 630 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 631 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 632 2012, . 634 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 635 "Extensions to the Virtual Private LAN Service (VPLS) Provider 636 Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 637 10.17487/RFC7041, November 2013, . 640 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 641 D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 642 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 643 2014, . 645 Acknowledgements 647 The contributions of Andrew G. Malis are gratefully acknowledged in 648 improving the quality of this document. 650 Authors' Addresses 652 Mohammed Umair 653 Cisco Systems 654 SEZ, Cessna Business Park 655 Sarjapur - Marathahalli Outer Ring road 656 Bengaluru - 560103, India 658 EMail: mohammed.umair2@gmail.com 660 Kingston Smiler Selvaraj 661 IPInfusion 662 RMZ Centennial 663 Mahadevapura Post 664 Bangalore - 560048 India 666 EMail: kingstonsmiler@gmail.com 668 Donald E. Eastlake 3rd 669 Huawei Technologies 670 155 Beaver Street 671 Milford, MA 01757 672 USA 674 Phone: +1-508-333-2270 675 EMail: d3e3e3@gmail.com 677 Lucy Yong 678 Self 680 Phone: +1-469-227-5837 681 EMail: lucyyong@gmail.com 683 Copyright, Disclaimer, and Additional IPR Provisions 685 Copyright (c) 2018 IETF Trust and the persons identified as the 686 document authors. All rights reserved. 688 This document is subject to BCP 78 and the IETF Trust's Legal 689 Provisions Relating to IETF Documents 690 (http://trustee.ietf.org/license-info) in effect on the date of 691 publication of this document. Please review these documents 692 carefully, as they describe your rights and restrictions with respect 693 to this document. Code Components extracted from this document must 694 include Simplified BSD License text as described in Section 4.e of 695 the Trust Legal Provisions and are provided without warranty as 696 described in the Simplified BSD License. The definitive version of 697 an IETF Document is that published by, or under the auspices of, the 698 IETF. Versions of IETF Documents that are published by third parties, 699 including those that are translated into other languages, should not 700 be considered to be definitive versions of IETF Documents. The 701 definitive version of these Legal Provisions is that published by, or 702 under the auspices of, the IETF. Versions of these Legal Provisions 703 that are published by third parties, including those that are 704 translated into other languages, should not be considered to be 705 definitive versions of these Legal Provisions. For the avoidance of 706 doubt, each Contributor to the IETF Standards Process licenses each 707 Contribution that he or she makes as part of the IETF Standards 708 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 709 language to the contrary, or terms, conditions or rights that differ 710 from or are inconsistent with the rights and licenses granted under 711 RFC 5378, shall have any effect and shall be null and void, whether 712 published or posted by such Contributor, or included with or in such 713 Contribution.