idnits 2.17.1 draft-zhang-trill-multilevel-unique-nickname-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([MultiL]), 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 date (March 16, 2016) is 2962 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group M. Zhang 3 Internet Draft D. Eastlake 3rd 4 Intended Category: Proposed Standard Huawei 5 R. Perlman 6 EMC 7 M. Cullen 8 Painless Security 9 H. Zhai 10 JIT 11 Expires: September 17, 2016 March 16, 2016 13 TRILL Multilevel Using Unique Nicknames 14 draft-zhang-trill-multilevel-unique-nickname-00.txt 16 Abstract 18 TRILL routing can be extended to support multiple levels by building 19 on the multilevel feature of IS-IS routing. Depending on how 20 nicknames are managed, there are two primary alternatives to realize 21 TRILL multilevel: the unique nickname approach and the aggregated 22 nickname approach as discussed in [MultiL]. This document specifies 23 the unique nickname approach. This approach gives unique nicknames to 24 all TRILL switches across the multilevel TRILL campus. 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 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 65 3. Data Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Unicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. Local Distribution Trees . . . . . . . . . . . . . . . 5 69 3.2.2. Global Distribution Trees . . . . . . . . . . . . . . . 5 70 4. Protocol Basics and Extensions . . . . . . . . . . . . . . . . 8 71 4.1. Multilevel TRILL Basics . . . . . . . . . . . . . . . . . . 8 72 4.2. Nickname Allocation . . . . . . . . . . . . . . . . . . . . 8 73 4.3. Nickname Announcements . . . . . . . . . . . . . . . . . . 9 74 4.4. Capability Indication . . . . . . . . . . . . . . . . . . . 11 75 5. Mix with Aggregated nickname Areas . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The multiple level feature of [IS-IS] can increase the scalability of 86 TRILL as discussed in [MultiL]. However, multilevel IS-IS needs some 87 extensions to support the TRILL multilevel feature. The two most 88 significant extensions are how TRILL switch nicknames are managed and 89 how distribution trees are handled [MultiL]. 91 There are two primary alternatives to realize TRILL multilevel 92 [MultiL]. One approach, which is referred as the "aggregated 93 nickname" approach, involves assigning nicknames to the areas, and 94 allowing nicknames to be reused in different areas, by having the 95 border TRILL switches rewrite nickname fields when entering or 96 leaving an area. For more description about the aggregated nickname 97 approach, one can refer to [MultiL] and [SingleN]. The other 98 approach, which is referred as the "unique nickname" approach, is 99 specified in this document. Unique nickname approach gives unique 100 nicknames to all the TRILL switches in the multilevel campus, by 101 having the Level-1/Level-2 border TRILL switches advertise into the 102 Level 1 area which nicknames are not available for assignment in the 103 area, and insert into Level 2 area which nicknames are used by this 104 area so that other areas cannot use them anymore, as well as 105 informing the rest of the campus how to reach the nicknames residing 106 in this area. In the document, protocol extensions that support such 107 advertisement are specified. 109 Each RBridge in a unique nickname area calculates two types of trees: 110 local distribution trees and global distributions trees. For multi- 111 destination traffic that is limited to an area, the packets will be 112 flooded on the local distribution tree. Otherwise, the multi- 113 destination packets will be flooded along the global distribution 114 tree. 116 In the unique nickname approach, nicknames are globally valid so that 117 border RBridges do not rewrite the nickname field of TRILL data 118 packets that are transitions between Level 1 and Level 2, as border 119 RBrides do in the aggregated nickname approach. If a border RBridge 120 is a transit node on a forwarding path, it does not learn MAC 121 addresses of the TRILL data packets forwarded along this path. 122 Testing and maintenance operations that originate in one area and 123 terminate in a different area are also simplified [MultiL]. For these 124 reasons, unique nickname approach might realize simpler border 125 RBridges than the aggregated nickname approach. However, the unique 126 nickname approach is less scalable and may be less well suited for 127 very large campuses. 129 2. Acronyms and Terminology 131 Data Label: VLAN or FGL 133 IS-IS: Intermediate System to Intermediate System [IS-IS] 135 RBridge: A device implementing the TRILL protocol. 137 TRILL: TRansparent Interconnection of Lots of Links or Tunneled 138 Routing in the Link Layer [RFC6325]. 140 TRILL switch: An alternative name for an RBridge. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Data Routing 148 Area X level 2 Area Y 149 +-------------------+ +-----------------+ +--------------+ 150 | | | | | | 151 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 152 | 27 | | | | 44 | 153 | | | | | | 154 +-------------------+ +-----------------+ +--------------+ 156 Figure 3.1: An example topology for TRILL multilevel 158 Figure 3.1 is adapted from the example topology of [MultiL]. 160 The routing processes are described in the following two subsections. 162 3.1. Unicast Routing 164 The plain RBridge RB27 has a different view of the topology of the 165 TRILL campus than its border RBridge RB2. For an outward path that 166 reaches an RBridge not in the same area (say RB44), RB27 calculates 167 the segment of the path in Area X, the border RBridge RB2 calculates 168 the segment in Level 2, while the border RBridge to the destination 169 area, RBridge RB3, calculates the segment from itself to RB44. 171 Let's say that S transmits a frame to destination D and let's say 172 that D's location is learned by the relevant TRILL switches already. 173 These relevant switches have learned the following: 175 1) RB27 has learned that D is connected to nickname 44. 177 The following sequence of events will occur: 179 - S transmits an Ethernet frame with source MAC = S and destination 180 MAC = D. 182 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 183 and egress RBridge = 44 producing a TRILL Data packet. 185 - RB2 has announced in the Level 1 IS-IS instance in Area X, that it 186 owns all nicknames of other areas, including 44. Therefore, IS-IS 187 routes the packet to RB2. 189 - The packet is forwarded through Level 2, from RB2 to RB3, which 190 has advertised, in Level 2, it owns the nickname 44. 192 - RB3, when forwarding into Area Y, does not change the ingress 193 nickname 27 or the egress nickname 44. 195 - RB44, when decapsulating, learns that S is attached to nickname 196 27. 198 3.2. Multicast Routing 200 The scope of multicast routing is defined by the tree root nickname. 201 A tree with a Level 2 tree root nickname is global and a tree with 202 Level 1 tree root nickname is local. See Section 4.2 for the Level 1 203 and Level 2 nickname allocation. 205 Border RBridges announce the global trees to be calculated only for 206 those Data Labels that span across areas. APPsub-TLVs as specified in 207 Section 3.2 of [TreeSel] will be advertised for this purpose. Based 208 on the Data Label, an ingress RBridge can determine whether a global 209 tree or a local tree is to be used for a TRILL multi-destination Data 210 packet. 212 If there are legacy TRILL switches that do not understand the APPsub- 213 TLVs for tree selection, configuration MUST guarantee that global 214 Data Labels are disabled on these legacy TRILL switches (Otherwise, 215 the legacy TRILL switches might use local trees for multi-destination 216 traffic with a global scope.). These legacy TRILL switches may use 217 global trees to flood multi-destination packets with a scope of the 218 local area. Those global trees MUST be pruned at the border TRILL 219 switches based on Data Labels. 221 3.2.1. Local Distribution Trees 223 The root RBridge RB1 of a local distribution tree resides in the 224 area. RBridges in this area calculate this local tree based on the 225 link state information of this area, using RB1's nickname as the 226 root. Protocol behaviors for local distribution trees have been 227 specified in 4.5 of [RFC6325]. The only different is that the local 228 distribution tree spans this area only. A multi-destination packet 229 with an egress nickname of the root RBridge of a local tree MUST NOT 230 be leaked into Level 2 at the border RBridge. 232 3.2.2. Global Distribution Trees 234 Within Level 2, the RBridge with the highest tree root priority 235 advertises the set of global trees by providing a list of Level 2 236 RBridge nicknames just as defined in Section 4.5 of [RFC6325]. 238 According to [RFC6325], the RBridge with the highest root priority 239 advertises the tree roots for a Level 1 area. There has to be a 240 border RBridge with the highest root tree priority in each area so 241 that it can advertises the global tree root nicknames into the area. 242 Also, this border RBridge needs to advertise the set of local 243 distribution trees by providing another set of nicknames. Since 244 nicknames of global tree roots and local tree roots indicate 245 different flooding scopes, these two set MUST NOT overlap. If a 246 border RBridge has been assigned both as a global tree root and a 247 local tree root, it has to acquire both a global tree root 248 nickname(s) and local tree root nickname(s). However, non-border 249 RBridges in an area do not differentiate between a global tree root 250 nickname and a local tree root nickname. 252 Suppose RB3 is the RBridge with the highest tree root priority within 253 Level 2, and RB2 is the highest tree root priority in Area X. RB2 254 advertises in Area X that nickname RB3 is the root of a distribution 255 tree. Figure 3.2 through Figure 3.5 illustrate how different RBridges 256 view the global distribution tree. 258 RB3,RB2,Rb,Rc,Rd,Re,Rk,RB44 259 o 260 / 261 Rz o 262 / 263 Rx o 264 / 265 RB27 o 267 Figure 3.2: RB27's view of the global distribution tree 268 RB3,Rk,RB44 269 o 270 / 271 Re o 272 / 273 Rd o 274 / 275 Rc o 276 / 277 Rb o 278 / 279 RB2 o 280 / 281 Rz o 282 / 283 Rx o 284 / 285 RB27 o 287 Figure 3.3: RB2's view of the global distribution tree 289 RB3 290 o 291 / \ 292 Re o o Rk 293 / \ 294 Rd o o RB44 295 / 296 Rc o 297 / 298 Rb o 299 / 300 R27,Rx,Rz,RB2 o 302 Figure 3.4: RB3's view of the global distribution tree 304 RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re 305 o 306 \ 307 o Rk 308 \ 309 o RB44 311 Figure 3.5: RB44's view of the global distribution tree 313 The following sequence of events will occur when a multi-destination 314 TRILL Data packet is forwarded using the global distribution tree: 316 - RB27 produces a multi-destination TRILL Data packet with ingress 317 RBridge = 27. RB27 floods this packet using the segment of the 318 global distribution tree that resides in Area X. 320 - RB2, when flooding the packet in Level 2, uses the segment of the 321 global distribution tree that resides in Level 2. 323 - RB3, when flooding the packet into Area Y, uses the segment of the 324 global distribution tree that resides in Area Y. 326 - The multicast listener RB44, when decapsulating the received 327 packet, learns that S is attached to nickname 27. 329 4. Protocol Basics and Extensions 331 4.1. Multilevel TRILL Basics 333 Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border 334 RBridges are in both a Level 1 area and in Level 2. They establish 335 adjacency with Level 1 RBridges as specified in [RFC7177] and 336 [RFC6325]. They establish adjacency with Level 2 RBridges in exactly 337 the same way except that (1) for a LAN link the IS-IS Hellos used are 338 Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link the 339 Level is configured and indicated in flags in the point-to-point 340 Hello. The state machines for Level 1 and Level 2 adjacency are 341 independent and two RBridges on the same LAN link can have any 342 adjacency state for Level 1 and, separately, any adjacency state for 343 Level 2. Level 1 and Level 2 link state flooding are independent 344 using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP, 345 CSNP, PSNP, FS-LSP, FS-CSNP and FS-PSNP). Thus Level 1 link state 346 information stays within a Level 1 area and Level 2 link state 347 information stays in Level 2 unless there are specific provisions for 348 leaking (copying) information between levels. This is why multilevel 349 can address the TRILL scalability issues as specified in Section 2 of 350 [MultiL]. 352 The former "campus wide" minimum acceptable link size Sz is 353 calculated as before by Level 1 RBridges (including border RBridges) 354 using the originatingLSPBufferSize advertised in Level 1 LSP so it is 355 area local in multilevel TRILL. A minimum acceptable link size in 356 Level 2, called Sz2, is calculated by the RBridges participating in 357 Level 2 in the same way as Sz is calculated but using the 358 originatingLSPBufferSize distributed in Level 2 LSPs. 360 4.2. Nickname Allocation 362 Level 2 RBridges contend for nicknames in the range from 0xF000 363 through 0xFBFF the same way as specified in [RFC6325], using Level 2 364 LSPs. The highest priority border router for a Level 1 area should 365 contend with others in Level 2 for smallish blocks of nicknames for 366 the range from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of 367 64 boundaries are RECOMMENDED in this document. 369 The nickname contention in Level 2 will figure out which blocks of 370 nicknames are available for an area and which blocks of nicknames are 371 used else where. The NickBlockFlags APPsub-TLV as specified in 372 Section 4.3 will be used by the border RBridge(s) to announce the 373 nickname availability. 375 4.3. Nickname Announcements 377 Border RBridges need to exchange nickname information between Level 1 378 and Level 2, otherwise forwarding paths inward/outward will not be 379 calculated. For this purpose, border RBridges need to fabricate 380 nickname announcements. Sub-TLVs used for such artificial 381 announcements are specified as follows. 383 Besides its own nickname(s), a border RBridge needs to announce, in 384 its area, the ownership of all external nicknames that are reachable 385 from this border RBridge. These external nicknames include nicknames 386 used in other unique nickname areas and nicknames in Level 2. Non- 387 border RBridge nicknames within aggregated nickname areas are 388 excluded. Also, a border RBridge needs to announce, in Level 2, the 389 ownership of all nicknames within its area. From listening to these 390 Level 2 announcements, border RBridges can figure out the nicknames 391 used by other areas. 393 RBridges in the TRILL base protocol use the Nickname Sub-TLV as 394 specified in Section 2.3.2 of [RFC7176] to announce the ownership of 395 nicknames. However, it becomes uneconomic to use this Sub-TLV to 396 announce a mass of internal/external nicknames. To address this 397 issue, border RBridges should make use of the NickBlockFlags APPsub- 398 TLV to advertise into the Level 1 area the inclusive range of 399 nicknames that are available or not for self allocation by the Level 400 1 RBridges in that area. Its structure is as follows: 402 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 403 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 404 | type = tbd2 | 405 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 406 | length | 407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 408 |OK| RESV | 409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 410 | Nickname Block 1 | 411 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 412 | ... 413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 | Nickname Block K | 415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 417 o Type: tbd2 (TRILL NickBlockFlags) 419 o Length: 2 + 2*K where K is the number of nickname blocks. 421 o OK: 423 - When this bit is set to 1, the blocks of nicknames in this 424 APPsub-TLV are available for Level 1 use of the area. The 425 APPsub-TLV will be advertised in both Level 1 and Level 2. 426 For nicknames that fall in the ranges or the nickname blocks, 427 RBridges of Level 2 always route to the originating border 428 RBridge, just as if this border RBridge owns these 429 nicknames. 431 - When this bit is set to 0, it indicates that the nicknames 432 covered by the nickname blocks are being used in Level 2 or 433 other areas so that they are not available for Level 1 use of 434 the area. The APPsub-TLV will be advertised into Level 1 435 only. For nicknames that fall in the ranges of the nickname 436 blocks, RBridges of the area always route to the originating 437 border RBridge, just as if this border RBridge owns these 438 nicknames. 440 o RESV: reserved for future flag allocation. MUST be sent as zero 441 and ignored on receipt. 443 o Nickname Block: a starting and ending nickname as follows: 445 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 446 | starting nickname | 447 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 448 | ending nickname | 449 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 451 For nicknames in these ranges, other RBridges will deem that they are 452 owned by the originating border RBridge. The paths to nicknames that 453 fall in these ranges will be calculated to reach the originating 454 border RBridge. TRILL Data packets with egress nicknames that are 455 neither in these ranges nor announced by any RBridge in the area MUST 456 be discarded. 458 There might be multiple border RBridges connected to the same area. 460 Each border RBridges may advertise a subset of the entire 461 internal/external nickname space in order to realize load balance. 462 However, optimization of such load balance is an implementation issue 463 and is out the scope of this document. 465 As specified in Section 4.2.6 of [RFC6325], multiple border RBridges 466 may claim the same nicknames outward and/or inward. Other RBridges 467 add those nicknames as if they are attached to all of those border 468 RBridges. 470 4.4. Capability Indication 472 All border RBridge MUST understand the NickBlockFlags APPsub-TLV. Non 473 border RBridges in an area SHOULD understand the NickBlockFlags 474 APPsub-TLV. If an RBridge within an area understands the 475 NickBlockFlags APPsub-TLV, it MUST indicate this capability by 476 announcing it in its TRILL-VER Sub-TLV. (See Section 7). 478 If there are RBridges that do not understand the NickBlockFlags 479 APPsub-TLV, border RBridges of the area will also use the traditional 480 Nickname Sub-TLV [RFC7176] to announce into the area those nicknames 481 covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose 482 OK is 0. The available range of nicknames for this area should be 483 configure on these traditional RBridges. 485 5. Mix with Aggregated nickname Areas 487 The design of TRILL multilevel allows a mixture of unique nickname 488 areas and aggregated nickname areas (see Section 1.2 of [MultiL]). 489 Usage of nickname space must be planed so that nicknames used in any 490 one unique nickname area and Level 2 are never used in any other 491 areas which includes unique nickname areas as well as aggregated 492 nickname areas. In other words, nickname re-usage is merely allowed 493 among aggregated nickname areas. 495 Border RBridges of an aggregated area need to announce nicknames 496 heard from Level 2 into their area like just like an unique nickname 497 border RBridge. But these RBridges do not announce nicknames of their 498 area into Level 2. 500 Each border RBridge of the aggregated areas will appear on the global 501 tree, as specified in Section 4.1, as a single node. The global trees 502 for unique nickname areas span unique nickname areas and Level 2 but 503 never reach the inside of aggregated areas. 505 6. Security Considerations 507 Malicious devices may fake the Nickname Properties Sub-TLV to 508 announce a range of nicknames. By doing this, the attacker can 509 attract TRILL data packets that are originally to reach other 510 RBridges. 512 RBridges SHOULD be configured to include the IS-IS Authentication TLV 513 (10) in the IS-IS PDUs that contains the Nickname Properties Sub-TLV, 514 so that IS-IS security ([RFC5304] [RFC5310]) can be used to secure 515 the network. 517 If border RBridges do not prune multi-destination distribution tree 518 traffic in Data Labels that are configured to be area local, then 519 traffic that should have been contained within an area might be 520 wrongly delivered to end stations in that Data Label in other areas. 521 This would generally violate security constraints. 523 For general TRILL Security Considerations, see [RFC6325]. 525 7. IANA Considerations 527 IANA is requested to register a new flag bit with mnemonic "B" (Block 528 of Nicknames) under the TRILL-VER Sub-TLV Capabilities registry. 530 Bit Mnemonic Description Reference 531 --- -------- ----------- --------- 532 tbd1 B Able to handle the [This document] 533 Nickname Properties 534 Sub-TLV 536 IANA is requested to assign a new type for the NickBlockFlags APPsub- 537 TLV from the range available below 256 and add the following entry to 538 the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 539 Identifier 1" registry as follows: 541 Type Name Reference 542 ---- ------ --------- 543 tbd2 NickBlockFlags [This document] 545 8. References 547 8.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, DOI 551 10.17487/RFC2119, March 1997, . 554 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 555 Ghanwani, "Routing Bridges (RBridges): Base Protocol 556 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 557 . 559 [TreeSel] Li, Y., Eastlake, D., et al, "TRILL: Data Label based Tree 560 Selection for Multi-destination Data", draft-ietf-trill- 561 tree-selection, Work in Progress. 563 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., 564 and A. Banerjee, "Transparent Interconnection of Lots of 565 Links (TRILL) Use of IS-IS", RFC 7176, DOI 566 10.17487/RFC7176, May 2014, . 569 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 570 V. Manral, "Transparent Interconnection of Lots of Links 571 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 572 2014, . 574 [IS-IS] International Organization for Standardization, 575 "Information technology -- Telecommunications and 576 information exchange between systems -- Intermediate System 577 to Intermediate System intra-domain routeing information 578 exchange protocol for use in conjunction with the protocol 579 for providing the connectionless-mode network service (ISO 580 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. 582 8.2. Informative References 584 [MultiL] Perlman, R., Eastlake, D., et al, "Alternatives for 585 Multilevel TRILL (Transparent Interconnection of Lots of 586 Links)", draft-ietf-trill-rbridge-multilevel, Work in 587 Progress. 589 [SingleN] Zhang, M., Eastlake, D., et al, "Single Area Border RBridge 590 Nickname for TRILL Multilevel", draft-ietf-trill- 591 multilevel-single-nickname, Work in Progress. 593 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 594 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 595 2008, . 597 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 598 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 599 RFC 5310, DOI 10.17487/RFC5310, February 2009, 600 . 602 Author's Addresses 604 Mingui Zhang 605 Huawei Technologies 606 No. 156 Beiqing Rd., Haidian District 607 Beijing 100095 608 China 610 Phone: +86-13810702575 611 Email: zhangmingui@huawei.com 613 Donald E. Eastlake 3rd 614 Huawei Technologies 615 155 Beaver Street 616 Milford, MA 01757 617 United States 619 Phone: +1-508-333-2270 620 Email: d3e3e3@gmail.com 622 Radia Perlman 623 EMC 624 2010 256th Avenue NE, #200 625 Bellevue, WA 98007 626 United States 628 Email: radia@alum.mit.edu 630 Margaret Cullen 631 Painless Security 632 14 Summer St. Suite 202 633 Malden, MA 02148 634 United States 636 Email: margaret@painless-security.com 638 Hongjun Zhai 639 Jinling Institute of Technology 640 99 Hongjing Avenue, Jiangning District 641 Nanjing, Jiangsu 211169 642 China 644 Email: honjun.zhai@tom.com