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