idnits 2.17.1 draft-ietf-trill-multilevel-unique-nickname-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 (March 14, 2018) is 2227 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: 0 errors (**), 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 Dell EMC 7 H. Zhai 8 JIT 9 D. Liu 10 China Telcom Co., Ltd 11 Expires: September 15, 2018 March 14, 2018 13 TRILL Multilevel Using Unique Nicknames 14 draft-ietf-trill-multilevel-unique-nickname-07.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 RFC 8243. This document specifies a 23 unique nickname approach. This approach gives unique nicknames to all 24 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) 2018 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. Multi-destination 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 . . . . . . . . . . . . . . . . . . . . 12 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The multiple level feature of [IS-IS] can increase the scalability of 87 TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs some 88 extensions to support the TRILL multilevel feature. The two most 89 significant extensions are how TRILL switch nicknames are managed and 90 how distribution trees are handled [RFC8243]. 92 There are two primary alternatives to realize TRILL multilevel 93 [RFC8243]. One approach, which is referred to as the "aggregated 94 nickname" approach, involves assigning nicknames to the areas, and 95 allowing nicknames to be reused in different areas, by having the 96 border TRILL switches rewrite nickname fields when entering or 97 leaving an area. For more description of the aggregated nickname 98 approach, one can refer to [RFC8243] and [SingleN]. The other 99 approach, which is referred to as the "unique nickname" approach, is 100 specified in this document. The unique nickname approach gives unique 101 nicknames to all the TRILL switches in the multilevel campus, by 102 having the Level-1/Level-2 border TRILL switches advertise into the 103 Level 1 area which nicknames are not available for assignment in the 104 area, and insert into Level 2 area which nicknames are used by this 105 area so that other areas cannot use them anymore, as well as 106 informing the rest of the campus how to reach the nicknames residing 107 in this area. In the document, protocol extensions that support such 108 advertisement are specified. 110 Each RBridge in a unique nickname area calculates two types of trees: 111 local distribution trees and global distributions trees. For multi- 112 destination traffic that is limited to an area, the packets will be 113 flooded on a local distribution tree. Otherwise, the multi- 114 destination packets will be flooded along a global distribution 115 tree. 117 In the unique nickname approach, nicknames are globally valid so that 118 border RBridges do not rewrite the nickname field of TRILL data 119 packets that transition between Level 1 and Level 2, as border 120 RBridges do in the aggregated nickname approach. If a border RBridge 121 is a transit node on a forwarding path, it does not learn MAC 122 addresses of the TRILL data packets forwarded along this path. 123 Testing and maintenance operations that originate in one area and 124 terminate in a different area are also simplified [RFC8243]. For 125 these reasons, the unique nickname approach might realize simpler 126 border RBridges than the aggregated nickname approach. However, the 127 unique nickname approach is less scalable and may be less well suited 128 for very large campuses. 130 2. Acronyms and Terminology 132 Data Label: VLAN or FGL [RFC7172] 134 IS-IS: Intermediate System to Intermediate System [IS-IS] 136 RBridge: A device implementing the TRILL protocol. 138 TRILL: TRansparent Interconnection of Lots of Links or Tunneled 139 Routing in the Link Layer [RFC6325]. 141 TRILL switch: An alternative name for an RBridge. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 3. Data Routing 149 Area X level 2 Area Y 150 +-----------------+ +---------------------+ +------------+ 151 | | | | | | 152 S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D 153 | 27 | | | | 44 | 154 | | | | | | 155 +-----------------+ +---------------------+ +------------+ 157 Figure 3.1: An example topology for TRILL multilevel 159 Figure 3.1 is adapted from the example topology of [RFC8243]. 161 The routing processes are described in the following two subsections. 163 3.1. Unicast Routing 165 The plain RBridge RB27 has a different view of the topology of the 166 TRILL campus than its border RBridge RB2. For an outward path that 167 reaches an RBridge not in the same area (say RB44), RB27 calculates 168 the segment of the path in Area X, the border RBridge RB2 calculates 169 the segment in Level 2, while the border RBridge to the destination 170 area, RBridge RB3, calculates the segment from itself to RB44. 172 Let us say that S transmits a frame to destination D and let us say 173 that D's location is learned by the relevant TRILL switches already. 174 These relevant switches have learned the following: 176 1) RB27 has learned that D is connected to nickname 44. 177 2) RB2 has learned that nickname 44 is accessible through RB3. 179 The following sequence of events will occur: 181 - S transmits an Ethernet frame with source MAC = S and destination 182 MAC = D. 184 - RB27 encapsulates with a TRILL header with ingress RBridge 185 nickname 27, and egress RBridge nickname 44 producing a TRILL Data 186 packet. 188 - RB2 has announced in the Level 1 IS-IS instance in Area X, that it 189 owns all nicknames of other areas, including 44. Therefore, IS-IS 190 routes the packet to RB2. 192 - The packet is forwarded through Level 2, from RB2 to RB3, which 193 has advertised, in Level 2, it owns the nickname 44. 195 - RB3, when forwarding into Area Y, does not change the ingress 196 nickname 27 or the egress nickname 44. 198 - RB44, when decapsulating, learns that S is attached to nickname 199 27. 201 3.2. Multi-destination Routing 203 The scope of Multi-destination routing is defined by the tree root 204 nickname. A tree with a Level 2 tree root nickname is global and a 205 tree with Level 1 tree root nickname is local. See Section 4.2 for 206 the Level 1 and Level 2 nickname allocation. 208 Border RBridges announce the global trees to be calculated only for 209 those Data Labels that span across areas. APPsub-TLVs as specified in 210 Section 3.2 of [RFC7968] will be advertised for this purpose. Based 211 on the Data Label, an ingress RBridge can determine whether a global 212 tree or a local tree is to be used for a TRILL multi-destination Data 213 packet. 215 If there are legacy TRILL switches that do not understand the APPsub- 216 TLVs for tree selection, configuration MUST guarantee that Data 217 Labels [RFC7172] being used globally in Level 2 are disabled on these 218 legacy TRILL switches (Otherwise, the legacy TRILL switches might use 219 local trees for multi-destination traffic with a global scope.). 220 These legacy TRILL switches may use global trees to flood multi- 221 destination packets with a scope of the local area. Those global 222 trees MUST be pruned at the border TRILL switches based on Data 223 Labels. 225 3.2.1. Local Distribution Trees 227 The root RBridge RB1 of a local distribution tree resides in the 228 area. RBridges in this area calculate this local tree based on the 229 link state information of this area, using RB1's nickname as the 230 root. Protocol behaviors for local distribution trees have been 231 specified in 4.5 of [RFC6325]. The only difference is that the local 232 distribution tree spans this area only. A multi-destination packet 233 with an egress nickname of the root RBridge of a local tree MUST NOT 234 be leaked into Level 2 at the border RBridge. 236 3.2.2. Global Distribution Trees 238 Within Level 2, the RBridge with the highest tree root priority 239 advertises the set of global trees by providing a list of Level 2 240 RBridge nicknames just as defined in Section 4.5 of [RFC6325]. 242 According to [RFC6325], the RBridge with the highest root priority 243 advertises the tree roots for a Level 1 area. There has to be a 244 border RBridge with the highest root tree priority in each area so 245 that it can advertises the global tree root nicknames into the area. 246 Also, this border RBridge MUST advertise the set of local 247 distribution trees by providing another set of nicknames. Since 248 nicknames of global tree roots and local tree roots indicate 249 different flooding scopes, these two set MUST NOT overlap. If a 250 border RBridge has been assigned both as a global tree root and a 251 local tree root, it MUST acquire both a global tree root nickname(s) 252 and local tree root nickname(s). However, non-border RBridges in an 253 area do not differentiate between a global tree root nickname and a 254 local tree root nickname. 256 Suppose RB3 is the RBridge with the highest tree root priority within 257 Level 2, and RB2 is the highest tree root priority in Area X. RB2 258 advertises in Area X that nickname RB3 is the root of a distribution 259 tree. Figure 3.2 through Figure 3.5 illustrate how different RBridges 260 view the global distribution tree. 262 RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44 263 o 264 / 265 Rz o 266 / 267 Rx o 268 / 269 RB27 o 271 Figure 3.2: RB27's view of the global distribution tree 272 RB3,Rk,RB44 273 o 274 / 275 Re o 276 / 277 Rd o 278 / 279 Rc o 280 / 281 Rb o 282 / 283 RB2 o 284 / 285 Rz o 286 / 287 Rx o 288 / 289 RB27 o 291 Figure 3.3: RB2's view of the global distribution tree 293 RB3 294 o 295 / \ 296 Re o o Rk 297 / \ 298 Rd o o RB44 299 / 300 Rc o 301 / 302 Rb o 303 / 304 R27,Rx,Rz,RB2 o 306 Figure 3.4: RB3's view of the global distribution tree 308 RB3,RB27,RBx,RBz,RB2,Rb,Rc,Rd,Re 309 o 310 \ 311 o Rk 312 \ 313 o RB44 315 Figure 3.5: RB44's view of the global distribution tree 317 The following sequence of events will occur when a multi-destination 318 TRILL Data packet is forwarded using the global distribution tree: 320 - RB27 produces a multi-destination (M bit is one) TRILL Data packet 321 with ingress RBridge nickname 27 and egress RBridge nickname 3. 322 RB27 floods this packet using the segment of the global 323 distribution tree that resides in Area X. 325 - RB2, when flooding the packet in Level 2, uses the segment of the 326 global distribution tree that resides in Level 2. 328 - RB3, when flooding the packet into Area Y, uses the segment of the 329 global distribution tree that resides in Area Y. 331 - The multicast listener RB44, when decapsulating the received 332 packet, learns that S is attached to nickname 27. 334 4. Protocol Basics and Extensions 336 4.1. Multilevel TRILL Basics 338 Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border 339 RBridges are in both a Level 1 area and in Level 2. They establish 340 adjacency with Level 1 RBridges as specified in [RFC7177] and 341 [RFC6325]. They establish adjacency with Level 2 RBridges in exactly 342 the same way except that (1) for a LAN link the IS-IS Hellos used are 343 Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link the 344 Level is configured and indicated in flags in the point-to-point 345 Hello. The state machines for Level 1 and Level 2 adjacency are 346 independent and two RBridges on the same LAN link can have any 347 adjacency state for Level 1 and, separately, any adjacency state for 348 Level 2. Level 1 and Level 2 link state flooding are independent 349 using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP, 350 CSNP, PSNP, FS-LSP, FS-CSNP and FS-PSNP). Thus Level 1 link state 351 information stays within a Level 1 area and Level 2 link state 352 information stays in Level 2 unless there are specific provisions for 353 leaking (copying) information between levels. This is why multilevel 354 can address the TRILL scalability issues as specified in Section 2 of 355 [RFC8243]. 357 The former "campus wide" minimum acceptable link size Sz is 358 calculated as before by Level 1 RBridges (including border RBridges) 359 using the originatingLSPBufferSize advertised in Level 1 LSP so it is 360 area local in multilevel TRILL. A minimum acceptable link size in 361 Level 2, called Sz2, is calculated by the RBridges participating in 362 Level 2 in the same way as Sz is calculated but using the 363 originatingLSPBufferSize distributed in Level 2 LSPs. 365 4.2. Nickname Allocation 367 Level 2 RBridges contend for nicknames in the range from 0xF000 368 through 0xFFBF 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 blocks of nicknames for the range 371 from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of 64 372 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 elsewhere. The NickBlockFlags APPsub-TLV as specified in Section 377 4.3 will be used by the border RBridge(s) to announce the nickname 378 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 MUST announce, in its 389 area, the ownership of all external nicknames that are reachable from 390 this border RBridge. These external nicknames include nicknames used 391 in other unique nickname areas and nicknames in Level 2. Non-border 392 RBridge nicknames within aggregated nickname areas are excluded. 393 Also, a border RBridge MUST announce, in Level 2, the ownership of 394 all nicknames within its area. From listening to these Level 2 395 announcements, border RBridges can figure out the nicknames used by 396 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. For nicknames in 444 these ranges, other RBridges will deem that they are owned by 445 the originating border RBridge. The paths to nicknames that 446 fall in these ranges will be calculated to reach the 447 originating border RBridge. TRILL Data packets with egress 448 nicknames that are neither in these ranges nor announced by 449 any RBridge in the area MUST be discarded. 451 o RESV: reserved for future flag allocation. MUST be sent as zero 452 and ignored on receipt. 454 o Nickname Block: a starting and ending nickname as follows: 456 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 457 | starting nickname | 458 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 459 | ending nickname | 460 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 462 Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] is still 463 allowed to be used given the above NickBlockFlags APPsub-TLV is being 464 used. 466 There might be multiple border RBridges connected to the same area. 467 Each border RBridges may advertise a subset of the entire 468 internal/external nickname space in order to realize load balance. 469 However, optimization of such load balance is an implementation issue 470 and is out the scope of this document. 472 As specified in Section 4.2.6 of [RFC6325], multiple border RBridges 473 may claim the same nicknames outward and/or inward. Other RBridges 474 add those nicknames as if they are attached to all of those border 475 RBridges. 477 4.4. Capability Indication 479 All border RBridge MUST understand the NickBlockFlags APPsub-TLV. Non 480 border RBridges in an area should understand the NickBlockFlags 481 APPsub-TLV. If an RBridge within an area understands the 482 NickBlockFlags APPsub-TLV, it MUST indicate this capability by 483 announcing it in its TRILL-VER Sub-TLV. (See Section 7). 485 If there are RBridges that do not understand the NickBlockFlags 486 APPsub-TLV, border RBridges of the area MUST also use the traditional 487 Nickname Sub-TLV [RFC7176] to announce into the area those nicknames 488 covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose 489 OK is 0. The available range of nicknames for this area should be 490 configure on these traditional RBridges. 492 5. Mix with Aggregated nickname Areas 494 The design of TRILL multilevel allows a mixture of unique nickname 495 areas and aggregated nickname areas (see Section 1.2 of [RFC8243]). 496 Usage of nickname space MUST be planed so that nicknames used in any 497 one unique nickname area and Level 2 are never used in any other 498 areas which includes unique nickname areas as well as aggregated 499 nickname areas. In other words, nickname re-usage is merely allowed 500 among aggregated nickname areas. 502 Border RBridges of an aggregated area MUST announce nicknames heard 503 from Level 2 into their area like just like an unique nickname border 504 RBridge. But these RBridges do not announce nicknames of their area 505 into Level 2. 507 Each border RBridge of the aggregated areas will appear on the global 508 tree, as specified in Section 4.1, as a single node. The global trees 509 for unique nickname areas span unique nickname areas and Level 2 but 510 never reach the inside of aggregated areas. 512 6. Security Considerations 514 Since TRILL multilevel uses the existing IS-IS multilevel facilities 515 [IS-IS], flooding of control traffic for link state information is 516 automatically confined to a Level 1 area or to Level 2 except (for 517 limited types of information that can be specifically flagged for 518 wider flooding). This addresses the TRILL scalability issues as 519 specified in Section 2 of [RFC8243] and also, except for the wider 520 flooding case, this confines the scope of the effects of malicious 521 events that could be communicated through the link state. However, 522 due to the nature that unique nickname areas share a common nickname 523 space, border RBridges still have to leak nickname information 524 between levels. Such leaking means that nickname related events in 525 one area can affect other areas. 527 For this purpose, border RBridges need to fabricate the nickname 528 announcements as specified in Section 4.3. Malicious devices may also 529 fake the NickBlockFlags APPsub-TLV to announce a range of nicknames. 530 By doing this, the attacker can attract TRILL data packets that are 531 originally to reach a bunch of other RBridges. For this reason, 532 RBridges SHOULD be configured to use the IS-IS Authentication TLV 533 (10) in the IS-IS PDUs, particularly those containing the 534 NickBlockFlags APPsub-TLV, so that IS-IS security ([RFC5310]) can be 535 used to authenticate those PDUs and discard them if they are forged. 537 If border RBridges do not prune multi-destination distribution tree 538 traffic in Data Labels that are configured to be area local, then 539 traffic that should have been contained within an area might be 540 wrongly delivered to end stations in that Data Label in other areas, 541 that is, the Data Label would no longer be area local. This would 542 generally violate security constraints that require traffic to be 543 delivered only to end stations in that Data Label in a single area. 545 For general TRILL Security Considerations, see [RFC6325]. 547 7. IANA Considerations 549 IANA is requested to register a new flag bit under the TRILL-VER Sub- 550 TLV Capability Flags registry. 552 Bit Description Reference 553 --- ----------- --------- 554 tbd1 Able to handle the [This document] 555 NickBlockFlags 556 APPsub-TLV 558 IANA is requested to assign a new type for the NickBlockFlags APPsub- 559 TLV from the range available below 256 and add the following entry to 560 the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 561 Identifier 1" registry as follows: 563 Type Name Reference 564 ---- ------ --------- 565 tbd2 NickBlockFlags [This document] 567 8. References 569 8.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, DOI 573 10.17487/RFC2119, March 1997, . 576 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 577 Ghanwani, "Routing Bridges (RBridges): Base Protocol 578 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 579 . 581 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., 582 and A. Banerjee, "Transparent Interconnection of Lots of 583 Links (TRILL) Use of IS-IS", RFC 7176, DOI 584 10.17487/RFC7176, May 2014, . 587 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 588 D. Dutt, "Transparent Interconnection of Lots of Links 589 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 590 10.17487/RFC7172, May 2014, . 593 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 594 V. Manral, "Transparent Interconnection of Lots of Links 595 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 596 2014, . 598 [RFC7968] Li, Y., Eastlake 3rd, D., Hao, W., Chen, H., and S. 599 Chatterjee, "Transparent Interconnection of Lots of Links 600 (TRILL): Using Data Labels for Tree Selection for Multi- 601 Destination Data", RFC 7968, DOI 10.17487/RFC7968, August 602 2016, . 604 [IS-IS] International Organization for Standardization, 605 "Information technology -- Telecommunications and 606 information exchange between systems -- Intermediate System 607 to Intermediate System intra-domain routeing information 608 exchange protocol for use in conjunction with the protocol 609 for providing the connectionless-mode network service (ISO 610 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. 612 8.2. Informative References 614 [SingleN] Zhang, M., Eastlake, D., et al, "Single Area Border RBridge 615 Nickname for TRILL Multilevel", draft-ietf-trill- 616 multilevel-single-nickname, Work in Progress. 618 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 619 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 620 RFC 5310, DOI 10.17487/RFC5310, February 2009, 621 . 623 [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., 624 and H. Zhai, "Alternatives for Multilevel Transparent 625 Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 626 10.17487/RFC8243, September 2017, . 629 9. Contributors 631 Margaret Cullen 632 Painless Security 633 14 Summer St. Suite 202 634 Malden, MA 02148 635 United States 637 Email: margaret@painless-security.com 639 Author's Addresses 641 Mingui Zhang 642 Huawei Technologies 643 No. 156 Beiqing Rd., Haidian District 644 Beijing 100095 645 China 647 Phone: +86-13810702575 648 Email: zhangmingui@huawei.com 650 Donald E. Eastlake 3rd 651 Huawei Technologies 652 155 Beaver Street 653 Milford, MA 01757 654 United States 656 Phone: +1-508-333-2270 657 Email: d3e3e3@gmail.com 659 Radia Perlman 660 Dell EMC 661 176 South Street 662 Hopkinton, MA 01748 663 United States 665 Email: radia@alum.mit.edu 667 Hongjun Zhai 668 Jinling Institute of Technology 669 99 Hongjing Avenue, Jiangning District 670 Nanjing, Jiangsu 211169 671 China 673 Email: honjun.zhai@tom.com 675 Dongxin Liu 676 China Telcom Co., Ltd 677 109 West Zhongshan Ave, Tianhe District 678 Guangzhou 510630 679 P.R. China 681 Email: liudx@gsta.com