idnits 2.17.1 draft-ietf-isis-rfc6326bis-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1699 has weird spacing: '...Section sub...' -- The document date (January 24, 2014) is 3717 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) -- Looks like a reference, but probably isn't: '2' on line 1676 -- Looks like a reference, but probably isn't: '3' on line 1677 -- Looks like a reference, but probably isn't: '4' on line 1678 -- Looks like a reference, but probably isn't: '5' on line 1679 -- Looks like a reference, but probably isn't: '6' on line 1680 -- Looks like a reference, but probably isn't: '7' on line 1684 -- Looks like a reference, but probably isn't: '8' on line 1685 -- Looks like a reference, but probably isn't: '15' on line 1693 -- Looks like a reference, but probably isn't: '16' on line 1694 -- Looks like a reference, but probably isn't: '17' on line 1695 -- Looks like a reference, but probably isn't: '18' on line 1696 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10589' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) -- Obsolete informational reference (is this intentional?): RFC 6326 (ref. 'Err2869') (Obsoleted by RFC 7176) -- Duplicate reference: RFC6326, mentioned in 'RFC6326', was also mentioned in 'Err2869'. -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Tissa Senevirathne 4 Obsoletes: 6326 Cisco 5 Anoop Ghanwani 6 Dell 7 Dinesh Dutt 8 Cumulus Networks 9 Ayan Banerjee 10 Insieme Networks 11 Expires: July 23, 2014 January 24, 2014 13 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS 14 16 Abstract 18 The IETF TRILL (Transparent Interconnection of Lots of Links) 19 protocol provides optimal pair-wise data frame forwarding without 20 configuration in multi-hop networks with arbitrary topology and link 21 technology, and support for multipathing of both unicast and 22 multicast traffic. This document specifies the data formats and code 23 points for the IS-IS extensions to support TRILL. These data formats 24 and code points may also be used by technologies other than TRILL. 25 This document obsoletes RFC 6326. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Distribution of this document is unlimited. Comments should be sent 33 to the TRILL working group mailing list. 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 Conventions Used in This Document....................3 54 2. TLV and Sub-TLV Extensions to IS-IS for TRILL..........5 55 2.1 Group Address TLV....................................5 56 2.1.1 Group MAC Address Sub-TLV..........................5 57 2.1.2 Group IPv4 Address Sub-TLV.........................7 58 2.1.3 Group IPv6 Address Sub-TLV.........................8 59 2.1.4 Group Labeled MAC Address Sub-TLV..................8 60 2.1.5 Group Labeled IPv4 Address Sub-TLV................10 61 2.1.6 Group Labeled IPv6 Address Sub-TLV................11 62 2.2 Multi-Topology-Aware Port Capability Sub-TLVs.......11 63 2.2.1 Special VLANs and Flags Sub-TLV...................12 64 2.2.2 Enabled-VLANs Sub-TLV.............................13 65 2.2.3 Appointed Forwarders Sub-TLV......................14 66 2.2.4 Port TRILL Version Sub-TLV........................15 67 2.2.5 VLANs Appointed Sub-TLV...........................16 68 2.3 Sub-TLVs of the Router and MT Capability TLVs.......17 69 2.3.1 TRILL Version Sub-TLV.............................17 70 2.3.2 Nickname Sub-TLV..................................18 71 2.3.3 Trees Sub-TLV.....................................19 72 2.3.4 Tree Identifiers Sub-TLV..........................20 73 2.3.5 Trees Used Identifiers Sub-TLV....................21 74 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV..21 75 2.3.7 VLAN Group Sub-TLV................................24 76 2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV.24 77 2.3.9 RBridge Channel Protocols Sub-TLV.................26 78 2.3.10 Affinity Sub-TLV.................................28 79 2.3.11 Label Group Sub-TLV..............................30 80 2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs...30 81 2.5 TRILL Neighbor TLV..................................31 82 3. MTU PDUs...............................................34 83 4. Use of Existing PDUs and TLVs..........................35 84 4.1 TRILL IIH PDUs......................................35 85 4.2 Area Address........................................35 86 4.3 Protocols Supported.................................35 87 4.4 Link State PDUs (LSPs)..............................36 88 4.5 Originating LSP Buffer Size.........................36 89 5. IANA Considerations....................................37 90 5.1 TLVs................................................37 91 5.2 sub-TLVs............................................37 92 5.3 PDUs................................................39 93 5.4 Reserved and Capability Bits........................39 94 5.5 TRILL Neighbor Record Flags.........................40 95 6. Security Considerations................................41 96 7. Change from RFC 6326...................................42 97 8. Normative References...................................44 98 9. Informative References.................................45 99 Acknowledgements..........................................47 100 Authors' Addresses........................................48 102 1. Introduction 104 The IETF TRILL (Transparent Interconnection of Lots of Links) 105 protocol [RFC6325] [RFC6327] provides transparent forwarding in 106 multi-hop networks with arbitrary topology and link technologies 107 using a header with a hop count and link state routing. TRILL 108 provides optimal pair-wise forwarding without configuration, safe 109 forwarding even during periods of temporary loops, and support for 110 multipathing of both unicast and multicast traffic. Intermediate 111 Systems (ISs) implementing TRILL are called RBridges (Routing 112 Bridges) or TRILL Switches. 114 This document, in conjunction with [RFC6165], specifies the data 115 formats and code points for the IS-IS [ISO-10589] [RFC1195] 116 extensions to support TRILL. These data formats and code points may 117 also be used by technologies other than TRILL. 119 This document obsoletes [RFC6326], which generally corresponded to 120 the base TRILL protocol as the TRILL Working Group passed it up to 121 the IESG in 2009. There has been substantial development of TRILL 122 since them. The main changes from [RFC6326] are summarized below and 123 a full list is given in Section 7. 125 1. Addition of multicast group announcements by IPv4 and IPv6 126 address. 128 2. Addition of facilities for announcing capabilities supported. 130 3. Addition of a tree affinity sub-TLV whereby ISs can request 131 distribution tree association. 133 4. Addition of multi-topology support. 135 5. Addition of control plane support for TRILL Data frame fine- 136 grained labels. This support is independent of the data plane 137 representation. 139 6. Fix the reported errata [Err2869] in [RFC6326]. 141 Changes herein to TLVs and sub-TLVs specified in [RFC6326] are 142 backwards compatible. 144 1.1 Conventions Used in This Document 146 The terminology and acronyms defined in [RFC6325] are used herein 147 with the same meaning. 149 Additional acronyms and phrases used in this document are: 151 BVL - Bit Vector Length 153 BVO - Bit Vector Offset 155 IIH - IS-IS Hello 157 IS - Intermediate System. For this document, all relevant 158 intermediate systems are RBridges [RFC6325]. 160 NLPID - Network Layer Protocol Identifier 162 SNPA - SubNetwork Point of Attachment (MAC Address) 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 2. TLV and Sub-TLV Extensions to IS-IS for TRILL 170 This section, in conjunction with [RFC6165], specifies the data 171 formats and code points for the TLVs and sub-TLVs for IS-IS to 172 support the IETF TRILL protocol. Information as to the number of 173 occurrences allowed, such as for a TLV in a PDU or set of PDUs or for 174 a sub-TLV in a TLV, is summarized in Section 5. 176 2.1 Group Address TLV 178 The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an 179 LSP PDU and carries sub-TLVs that in turn advertise multicast group 180 listeners. The sub-TLVs that advertises listeners are specified 181 below. The sub-TLVs under GADDR constitute a new series of sub-TLV 182 types (see Section 5.2). 184 GADDR has the following format: 186 +-+-+-+-+-+-+-+-+ 187 |Type=GADDR-TLV | (1 byte) 188 +-+-+-+-+-+-+-+-+ 189 | Length | (1 byte) 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 191 | sub-TLVs... 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 194 o Type: TLV Type, set to GADDR-TLV 142. 196 o Length: variable depending on the sub-TLVs carried. 198 o sub-TLVs: The Group Address TLV value consists of sub-TLVs 199 formatted as described in [RFC5305]. 201 2.1.1 Group MAC Address Sub-TLV 203 The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 204 within the GADDR TLV. In TRILL, it is used to advertise multicast 205 listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. 206 It has the following format: 208 +-+-+-+-+-+-+-+-+ 209 |Type=GMAC-ADDR | (1 byte) 210 +-+-+-+-+-+-+-+-+ 211 | Length | (1 byte) 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | RESV | Topology-ID | (2 bytes) 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | RESV | VLAN ID | (2 bytes) 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |Num Group Recs | (1 byte) 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | GROUP RECORDS (1) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | GROUP RECORDS (2) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | ................. | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | GROUP RECORDS (N) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 where each group record is of the following form with k=6: 230 +-+-+-+-+-+-+-+-+ 231 | Num of Sources| (1 byte) 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Group Address (k bytes) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Source 1 Address (k bytes) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Source 2 Address (k bytes) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | ..... | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Source M Address (k bytes) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR). 246 o Length: 5 + m + k*n = 5 + m + 6*n where m is the number of group 247 records and n is the sum of the number of group and source 248 addresses. 250 o RESV: Reserved. 4-bit fields that MUST be sent as zero and 251 ignored on receipt. 253 o Topology-ID: This field carries a topology ID [RFC5120] or zero if 254 topologies are not in use. 256 o VLAN ID: This carries the 12-bit VLAN identifier for all 257 subsequent MAC addresses in this sub-TLV, or the value zero if no 258 VLAN is specified. 260 o Number of Group Records: A 1-byte unsigned integer that is the 261 number of group records in this sub-TLV. 263 o Group Record: Each group record carries the number of sources. If 264 this field is zero, it indicates a listener for (*,G), that is, a 265 listener not restricted by source. It then has a 6-byte (48-bit) 266 multicast MAC address followed by 6-byte source MAC addresses. If 267 the sources do not fit in a single sub-TLV, the same group address 268 may be repeated with different source addresses in another sub-TLV 269 of another instance of the Group Address TLV. 271 The GMAC-ADDR sub-TLV is carried only within a GADDR TLV. 273 2.1.2 Group IPv4 Address Sub-TLV 275 The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type TBDa 276 [2 suggested] within the GADDR TLV. It has the same format as the 277 Group MAC Address sub-TLV described in Section 2.1.1 except that k=4. 278 The fields are as follows: 280 o Type: sub-TLV Type, set to TBDa [2 suggested] (GIP-ADDR). 282 o Length: 5 + m + k*n = 5 + m + 4*n where m is the number of group 283 records and n is the sum of the number of group and source 284 addresses. 286 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 287 topologies are not in use. 289 o RESV: Must be sent as zero on transmission and is ignored on 290 receipt. 292 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 293 all subsequent addresses in this sub-TLV, or the value zero if no 294 VLAN is specified. 296 o Number of Group Records: This is of length 1 byte and lists the 297 number of group records in this sub-TLV. 299 o Group Record: Each group record carries the number of sources. If 300 this field is zero, it indicates a listener for (*,G), that is, a 301 listener not restricted by source. It then has a 4-byte (32-bit) 302 IPv4 Group Address followed by 4-byte source IPv4 addresses. If 303 the number of sources do not fit in a single sub-TLV, it is 304 permitted to have the same group address repeated with different 305 source addresses in another sub-TLV of another instance of the 306 Group Address TLV. 308 The GIP-ADDR sub-TLV is carried only within a GADDR TLV. 310 2.1.3 Group IPv6 Address Sub-TLV 312 The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 313 TBDb [3 suggested] within the GADDR TLV. It has the same format as 314 the Group MAC Address sub-TLV described in Section 2.1.1 except that 315 k=16. The fields are as follows: 317 o Type: sub-TLV Type, set to TBDb [3 suggested] (GIPV6-ADDR). 319 o Length: 5 + m + k*n = 5 + m + 16*n where m is the number of group 320 records and n is the sum of the number of group and source 321 addresses. 323 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 324 topologies are not in use. 326 o RESV: Must be sent as zero on transmission and is ignored on 327 receipt. 329 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 330 all subsequent addresses in this sub-TLV, or the value zero if no 331 VLAN is specified. 333 o Number of Group Records: This is of length 1 byte and lists the 334 number of group records in this sub-TLV. 336 o Group Record: Each group record carries the number of sources. If 337 this field is zero, it indicates a listener for (*,G), that is, a 338 listener not restricted by source. It then has a 16-byte (128-bit) 339 IPv6 Group Address followed by 16-byte source IPv6 addresses. If 340 the number of sources do not fit in a single sub-TLV, it is 341 permitted to have the same group address repeated with different 342 source addresses in another sub-TLV of another instance of the 343 Group Address TLV. 345 The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV. 347 2.1.4 Group Labeled MAC Address Sub-TLV 349 The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in 350 Section 2.1.1 provides for a VLAN-ID. The Group Labeled MAC Address 351 sub-TLV, below, extends this to a fine-grained label. 353 +-+-+-+-+-+-+-+-+ 354 |Type=GLMAC-ADDR| (1 byte) 355 +-+-+-+-+-+-+-+-+ 356 | Length | (1 byte) 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | RESV | Topology-ID | (2 bytes) 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Fine-Grained Label | (3 bytes) 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |Num Group Recs | (1 byte) 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | GROUP RECORDS (1) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | GROUP RECORDS (2) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | ................. | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | GROUP RECORDS (N) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 where each group record is of the following form with k=6: 375 +-+-+-+-+-+-+-+-+ 376 | Num of Sources| (1 byte) 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Group Address (k bytes) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Source 1 Address (k bytes) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Source 2 Address (k bytes) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | ..... | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Source M Address (k bytes) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 o Type: GADDR sub-TLV Type, set to TBDc [4 suggested] (GLMAC-ADDR). 391 o Length: 6 + m + k*n = 6 + m + 6*n where m is the number of group 392 records and n is the sum of the number of group and source 393 addresses. 395 o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored 396 on receipt. 398 o Topology-ID: This field carries a topology ID [RFC5120] or zero if 399 topologies are not in use. 401 o Label: This carries the fine-grained label [RFCfgl] identifier for 402 all subsequent MAC addresses in this sub-TLV, or the value zero if 403 no label is specified. 405 o Number of Group Records: A 1-byte unsigned integer that is the 406 number of group records in this sub-TLV. 408 o Group Record: Each group record carries the number of sources. If 409 this field is zero, it indicates a listener for (*,G), that is, a 410 listener not restricted by source. It then has a 6-byte (48-bit) 411 multicast address followed by 6-byte source MAC addresses. If the 412 sources do not fit in a single sub-TLV, the same group address may 413 be repeated with different source addresses in another sub-TLV of 414 another instance of the Group Address TLV. 416 The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV. 418 2.1.5 Group Labeled IPv4 Address Sub-TLV 420 The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV 421 type TBDd [5 suggested] within the GADDR TLV. It has the same format 422 as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 423 except that k=4. The fields are as follows: 425 o Type: sub-TLV Type, set to TBDd [5 suggested] (GLIP-ADDR). 427 o Length: 6 + m + k*n = 6 + m + 4*n where m is the number of group 428 records and n is the sum of the number of group and source 429 addresses. 431 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 432 topologies are not in use. 434 o RESV: Must be sent as zero on transmission and is ignored on 435 receipt. 437 o Label: This carries the fine-grained label [RFCfgl] identifier for 438 all subsequent IPv4 addresses in this sub-TLV, or the value zero 439 if no label is specified. 441 o Number of Group Records: This is of length 1 byte and lists the 442 number of group records in this sub-TLV. 444 o Group Record: Each group record carries the number of sources. If 445 this field is zero, it indicates a listener for (*,G), that is, a 446 listener not restricted by source. It then has a 4-byte (32-bit) 447 IPv4 Group Address followed by 4-byte source IPv4 addresses. If 448 the number of sources do not fit in a single sub-TLV, it is 449 permitted to have the same group address repeated with different 450 source addresses in another sub-TLV of another instance of the 451 Group Address TLV. 453 The GLIP-ADDR sub-TLV is carried only within a GADDR TLV. 455 2.1.6 Group Labeled IPv6 Address Sub-TLV 457 The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV 458 type TBDe [6 suggested] within the GADDR TLV. It has the same format 459 as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 460 except that k=16. The fields are as follows: 462 o Type: sub-TLV Type, set to TBDe [6 suggested] (GLIPV6-ADDR). 464 o Length: 6 + m + k*n = 6 + m + 16*n where m is the number of group 465 records and n is the sum of the number of group and source 466 addresses. 468 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 469 topologies are not in use. 471 o RESV: Must be sent as zero on transmission and is ignored on 472 receipt. 474 o Label: This carries the fine-grained label [RFCfgl] identifier for 475 all subsequent IPv6 addresses in this sub-TLV, or the value zero 476 if no label is specified. 478 o Number of Group Records: This of length 1 byte and lists the 479 number of group records in this sub-TLV. 481 o Group Record: Each group record carries the number of sources. If 482 this field is zero, it indicates a listener for (*,G), that is, a 483 listener not restricted by source. It then has a 16-byte (128-bit) 484 IPv6 Group Address followed by 16-byte source IPv6 addresses. If 485 the number of sources do not fit in a single sub-TLV, it is 486 permitted to have the same group address repeated with different 487 source addresses in another sub-TLV of another instance of the 488 Group Address TLV. 490 The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV. 492 2.2 Multi-Topology-Aware Port Capability Sub-TLVs 494 TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT- 495 CAP) TLV as specified in [RFC6165]. The following subsections of 496 this Section 2.2 specify the sub-TLVs transported by the MT-PORT-CAP 497 TLV for TRILL. 499 2.2.1 Special VLANs and Flags Sub-TLV 501 In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried 502 in every IIH PDU. It has the following format: 504 +--+--+--+--+--+--+--+--+ 505 | Type | (1 byte) 506 +--+--+--+--+--+--+--+--+ 507 | Length | (1 byte) 508 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 509 | Port ID | (2 bytes) 510 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 511 | Sender Nickname | (2 bytes) 512 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 513 |AF|AC|VM|BY| Outer.VLAN | (2 bytes) 514 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 515 |TR|R |R |R | Designated-VLAN | (2 bytes) 516 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 518 o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1. 520 o Length: 8. 522 o Port ID: An ID for the port on which the enclosing TRILL IIH 523 PDU is being sent as specified in [RFC6325], Section 4.4.2. 525 o Sender Nickname: If the sending IS is holding any nicknames as 526 discussed in [RFC6325], Section 3.7, one MUST be included here. 527 Otherwise, the field is set to zero. This field is to support 528 intelligent end stations that determine the egress IS (RBridge) 529 for unicast data through a directory service or the like and 530 that need a nickname for their first hop to insert as the 531 ingress nickname to correctly format a TRILL Data frame (see 532 [RFC6325], Section 4.6.2, point 8). It is also referenced in 533 connection with the VLANs Appointed Sub-TLV (see Section 2.2.5) 534 and can be used as the egress on one-hop RBridge Channel 535 messages [Channel], for example those use for BFD over TRILL 536 [RFCtrillBFD]. 538 o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH 539 frame containing this sub-TLV, as specified in [RFC6325], 540 Section 4.4.5. 542 o Designated-VLAN: The 12-bit ID of the Designated VLAN for the 543 link, as specified in [RFC6325], Section 4.2.4.2. 545 o AF, AC, VM, BY, and TR: These flag bits have the following 546 meanings when set to one, as specified in the listed section of 547 [RFC6325]: 549 RFC 6325 550 Bit Section Meaning if bit is one 551 -------------------------------------- 553 AF 4.4.2 Originating IS believes it is appointed 554 forwarder for the VLAN and port on which the 555 containing IIH PDU was sent. 557 AC 4.9.1 Originating port configured as an access port 558 (TRILL traffic disabled). 560 VM 4.4.5 VLAN mapping detected on this link. 562 BY 4.4.2 Bypass pseudonode. 564 TR 4.9.1 Originating port configured as a trunk port 565 (end-station service disabled). 567 o R: Reserved bit. MUST be sent as zero and ignored on receipt. 569 2.2.2 Enabled-VLANs Sub-TLV 571 The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the 572 port of the originating IS on which the containing Hello was sent, as 573 specified in [RFC6325], Section 4.4.2. It has the following format: 575 +-+-+-+-+-+-+-+-+ 576 | Type | (1 byte) 577 +-+-+-+-+-+-+-+-+ 578 | Length | (1 byte) 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | RESV | Start VLAN ID | (2 bytes) 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | VLAN bit-map.... 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 o Type: sub-TLV type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2. 587 o Length: Variable, minimum 3. 589 o RESV: 4 reserved bits that MUST be sent as zero and ignored on 590 receipt. 592 o Start VLAN ID: The 12-bit VLAN ID that is represented by the high 593 order bit of the first byte of the VLAN bit-map. 595 o VLAN bit-map: The highest order bit indicates the VLAN equal to 596 the start VLAN ID, the next highest bit indicates the VLAN equal 597 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 598 field. 600 If this sub-TLV occurs more than once in a Hello, the set of enabled 601 VLANs is the union of the sets of VLANs indicated by each of the 602 Enabled-VLAN sub-TLVs in the Hello. 604 2.2.3 Appointed Forwarders Sub-TLV 606 The DRB on a link uses the Appointed Forwarders sub-TLV to inform 607 other ISs on the link that they are the designated VLAN-x forwarder 608 for one or more ranges of VLAN IDs as specified in [RFC6439]. It has 609 the following format: 611 +-+-+-+-+-+-+-+-+ 612 | Type | (1 byte) 613 +-+-+-+-+-+-+-+-+ 614 | Length | (1 byte) 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Appointment Information (1) | (6 bytes) 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Appointment Information (2) | (6 bytes) 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | ................. | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Appointment Information (N) | (6 bytes) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 where each appointment is of the form: 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Appointee Nickname | (2 bytes) 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | RESV | Start.VLAN | (2 bytes) 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | RESV | End.VLAN | (2 bytes) 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 o Type: sub-TLV type, set to MT-PORT-CAP AppointedFwrdrs sub-TLV 3. 637 o Length: 6*n bytes, where there are n appointments. 639 o Appointee Nickname: The nickname of the IS being appointed a 640 forwarder. 642 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 644 o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting 645 both VLAN.start and VLAN.end to the same value indicates a range 646 of one VLAN ID. If VLAN.start is not equal to VLAN.end and 647 VLAN.start is 0x000, the sub-TLV is interpreted as if VLAN.start 648 was 0x001. If VLAN.start is not equal to VLAN.end and VLAN.end is 649 0xFFF, the sub-TVL is interpreted as if VLAN.end was 0xFFE. If 650 VLAN.end is less than VLAN.start, the sub-TLV is ignored. If both 651 VLAN.start and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV 652 is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs and 653 a port cannot be enabled for them. 655 An IS's nickname may occur as appointed forwarder for multiple VLAN 656 ranges by occurrences of this sub-TLV within the same or different MT 657 Port Capability TLVs within an IIH PDU. See [RFC6439]. 659 2.2.4 Port TRILL Version Sub-TLV 661 The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum 662 version of the TRILL standard supported and the support of optional 663 hop-by-hop capabilities. By implication, lower versions are also 664 supported. If this sub-TLV is missing from an IIH, it is assumed that 665 the originating IS only supports the base version (version zero) of 666 the protocol [RFC6325] and supports no optional capabilities 667 indicated by this sub-TLV. 669 +-+-+-+-+-+-+-+-+ 670 | Type | (1 byte) 671 +-+-+-+-+-+-+-+-+ 672 | Length | (1 byte) 673 +-+-+-+-+-+-+-+-+ 674 | Max-version | (1 byte) 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 676 | Capabilities and Header Flags Supported | (4 bytes) 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 678 0 1 3 679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 681 o Type: MT-PORT-CAP sub-TLV type, set to TBDf [7 suggested] (PORT- 682 TRILL-VER). 684 o Length: 5. 686 o Max-version: A one byte unsigned integer set to maximum version 687 supported. 689 o Capabilities and Header Flags Supported: A bit vector of 32 bits 690 numbered 0 through 31 in network order. Bits 3 through 13 indicate 691 that the corresponding TRILL Header hop-by-hop extended flags 692 [ExtendHeader] are supported. Bits 0 through 2 and 14 to 31 are 693 reserved to indicate support of optional capabilities. A one bit 694 indicates that the flag or capability is supported by the sending 695 IS. Bits in this field MUST be set to zero except as permitted for 696 a capability being advertised or if a hop-by-hop extended header 697 flag is supported. 699 This sub-TLV, if present, MUST occur in an MT-PORT-CAP TLV in a TRILL 700 IIH. If there is more than one occurrence, the minimum of the 701 supported versions is assumed to be correct and a capability or 702 header flag is assumed to be supported only if indicated by all 703 occurrences. The flags and capabilities for which support can be 704 indicated in this sub-TLV are disjoint from those in the TRILL-VER 705 sub-TLV (Section 2.3.1) so they cannot conflict. The flags and 706 capabilities indicated in this sub-TLV relate to hop-by-hop 707 processing that can differ between the ports of an IS (RBridge), and 708 thus must be advertised in IIHs. For example, a capability requiring 709 cryptographic hardware assist might be supported on some ports and 710 not others. However, the TRILL version is the same as that in the 711 PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of 712 TRILL version sub-TLV(s) uses the TRILL version it received in PORT- 713 TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- 714 TLV(s). 716 2.2.5 VLANs Appointed Sub-TLV 718 The optional VLANs sub-TLV specifies, for the port of the originating 719 IS on which the containing Hello was sent, the VLANs for which it is 720 appointed forwarder. This sub-TLV has the following format: 722 +-+-+-+-+-+-+-+-+ 723 | Type | (1 byte) 724 +-+-+-+-+-+-+-+-+ 725 | Length | (1 byte) 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | RESV | Start VLAN ID | (2 bytes) 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | VLAN bit-map.... 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 o Type: sub-TLV type, set to MT-PORT-CAP VLANS-Appointed sub-TLV 733 TBDg [8 suggested]. 735 o Length: Variable, minimum 3. 737 o RESV: 4 reserved bits that MUST be sent as zero and ignored on 738 receipt. 740 o Start VLAN ID: The 12-bit VLAN ID that is represented by the high 741 order bit of the first byte of the VLAN bit-map. 743 o VLAN bit-map: The highest order bit indicates the VLAN equal to 744 the start VLAN ID, the next highest bit indicates the VLAN equal 745 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 746 field. 748 If this sub-TLV occurs more than once in a Hello, the originating IS 749 is declaring that it believes itself to be appointed forwarder on the 750 port on which the enclosing IIH was sent for the union of the sets of 751 VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello. 753 2.3 Sub-TLVs of the Router and MT Capability TLVs 755 The Router Capability TLV is specified in [RFC4971] and the MT 756 Capability TLV in [RFC6329]. All of the sub-sections of this Section 757 2.3 below specify sub-TLVs that can be carried in the Router 758 Capability TLV (#242) and the MT (multi-topology) Capability TLV 759 (#144) with the same sub-TLV number for both TLVs. These TLVs are in 760 turn carried only by LSPs. 762 2.3.1 TRILL Version Sub-TLV 764 The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version 765 of the TRILL standard supported and the support of optional 766 capabilities by the originating IS. By implication, lower versions 767 are also supported. If this sub-TLV is missing, it is assumed that 768 the originating IS only supports the base version (version zero) of 769 the protocol [RFC6325] and no optional capabilities indicated by this 770 sub-TLV are supported. 772 +-+-+-+-+-+-+-+-+ 773 | Type | (1 byte) 774 +-+-+-+-+-+-+-+-+ 775 | Length | (1 byte) 776 +-+-+-+-+-+-+-+-+ 777 | Max-version | (1 byte) 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 779 | Capabilities and Header Flags Supported | (4 bytes) 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 781 0 1 3 782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 784 o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). 786 o Length: 5. 788 o Max-version: A one byte unsigned integer set to maximum version 789 supported. 791 o Capabilities and Header Flags Supported: A bit vector of 32 bits 792 numbered 0 through 31 in network order. Bits 14 through 31 793 indicate that the corresponding TRILL Header extended flags 794 [ExtendHeader] are supported. Bits 0 through 13 are reserved to 795 indicate support of optional capabilities. A one bit indicates 796 that the originating IS supports the flag or capability. For 797 example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in 798 this field MUST be set to zero except as permitted for a 799 capability being advertised or an extended header flag supported. 801 This sub-TLV, if present in a Router Capabilities TLV, MUST occur in 802 the LSP number zero for the originating IS. If found in a Router 803 Capabilities TLV in other fragments, it is ignored. If there is more 804 than one occurrence in LSP number zero, the minimum of the supported 805 versions is assumed to be correct and an extended header flag or 806 capability is assumed to be supported only if indicated by all 807 occurrences. The flags and capabilities supported bits in this sub- 808 TLV are disjoint from those in the PORT-TRILL-VER sub-TLV (Section 809 2.2.4) so they cannot conflict. However, the TRILL version is the 810 same as that in the PORT-TRILL-VER sub-TLV and an IS that is adjacent 811 to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version 812 it received in PORT-TRILL-VER sub-TLV(s) in preference to that 813 received in TRILL-VER sub-TLV(s). 815 For multi-topology aware TRILL switches, the TRILL version and 816 capabilities announced for the base topology are assumed to apply to 817 all topologies for which a separate TRILL version announcement does 818 not occur in an MT Capabilities TLV. Such announcements for non-zero 819 topologies need not occur in fragment zero. 821 2.3.2 Nickname Sub-TLV 823 The Nickname (NICKNAME) Router Capability sub-TLV carries information 824 about the nicknames of the originating IS, along with information 825 about its priority to hold those nicknames and the priority for each 826 nickname to be a tree root as specified in [RFC6325] Section 3.7.3. 827 Multiple instances of this sub-TLV may occur. 829 +-+-+-+-+-+-+-+-+ 830 |Type = NICKNAME| (1 byte) 831 +-+-+-+-+-+-+-+-+ 832 | Length | (1 byte) 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | NICKNAME RECORDS (1) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | NICKNAME RECORDS (2) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | ................. | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | NICKNAME RECORDS (N) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 where each nickname record is of the form: 845 +-+-+-+-+-+-+-+-+ 846 | Nickname.Pri | (1 byte) 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Tree Root Priority | (2 byte) 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Nickname | (2 bytes) 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 o Type: Router and MT Capability sub-TLV type, set to 6 (NICKNAME). 855 o Length: 5*n, where n is the number of nickname records present. 857 o Nickname.Pri: An 8-bit unsigned integer priority to hold a 858 nickname as specified in Section 3.7.3 of [RFC6325]. 860 o Tree Root Priority: This is an unsigned 16-bit integer priority to 861 be a tree root as specified in Section 4.5 of [RFC6325]. 863 o Nickname: This is an unsigned 16-bit integer as specified in 864 Section 3.7 of [RFC6325]. 866 2.3.3 Trees Sub-TLV 868 Each IS providing TRILL service uses the TREES sub-TLV to announce 869 three numbers related to the computation of distribution trees as 870 specified in Section 4.5 of [RFC6325]. Its format is as follows: 872 +-+-+-+-+-+-+-+-+ 873 |Type = TREES | (1 byte) 874 +-+-+-+-+-+-+-+-+ 875 | Length | (1 byte) 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Number of trees to compute | (2 byte) 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Maximum trees able to compute | (2 byte) 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Number of trees to use | (2 byte) 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 o Type: Router and MT Capability sub-TLV type, set to 7 (TREES). 886 o Length: 6. 888 o Number of trees to compute: An unsigned 16-bit integer as 889 specified in Section 4.5 of [RFC6325]. 891 o Maximum trees able to compute: An unsigned 16-bit integer as 892 specified in Section 4.5 of [RFC6325]. 894 o Number of trees to use: An unsigned 16-bit integer as specified in 895 Section 4.5 of [RFC6325]. 897 2.3.4 Tree Identifiers Sub-TLV 899 The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of 900 nicknames. When originated by the IS that has the highest priority to 901 be a tree root, it lists the distribution trees that the other ISs 902 are required to compute as specified in Section 4.5 of [RFC6325]. If 903 this information is spread across multiple sub-TLVs, the starting 904 tree number is used to allow the ordered lists to be correctly 905 concatenated. The sub-TLV format is as follows: 907 +-+-+-+-+-+-+-+-+ 908 |Type=TREE-RT-IDs| (1 byte) 909 +-+-+-+-+-+-+-+-+ 910 | Length | (1 byte) 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |Starting Tree Number | (2 bytes) 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Nickname (K-th root) | (2 bytes) 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Nickname (K+1 - th root) | (2 bytes) 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Nickname (...) | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 o Type: Router and MT Capability sub-TLV type, set to 8 (TREE-RT- 922 IDs). 924 o Length: 2 + 2*n, where n is the number of nicknames listed. 926 o Starting Tree Number: This identifies the starting tree number of 927 the nicknames that are trees for the domain. This is set to 1 for 928 the sub-TLV containing the first list. Other Tree-Identifiers sub- 929 TLVs will have the number of the starting list they contain. In 930 the event the same tree identifier can be computed from two such 931 sub-TLVs and they are different, then it is assumed that this is a 932 transient condition that will get cleared. During this transient 933 time, such a tree SHOULD NOT be computed unless such computation 934 is indicated by all relevant sub-TLVs present. 936 o Nickname: The nickname at which a distribution tree is rooted. 938 2.3.5 Trees Used Identifiers Sub-TLV 940 This Router Capability sub-TLV has the same structure as the Tree 941 Identifiers sub-TLV specified in Section 2.3.4. The only difference 942 is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees 943 listed are those that the originating IS wishes to use as specified 944 in [RFC6325], Section 4.5. 946 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV 948 The value of this sub-TLV consists of a VLAN range and information in 949 common to all of the VLANs in the range for the originating IS. This 950 information consists of flags, a variable length list of spanning 951 tree root bridge IDs, and an appointed forwarder status lost counter, 952 all as specified in the sections of [RFC6325] listed with the 953 respective information items below. 955 In the set of LSPs originated by an IS, the union of the VLAN ranges 956 in all occurrences of this sub-TLV MUST be the set of VLANs for which 957 the originating IS is appointed forwarder on at least one port, and 958 the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap 959 unless the information provided about a VLAN is the same in every 960 instance. However, as a transient state these conditions may be 961 violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, 962 that IS is assumed to be uninterested in receiving traffic for that 963 VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS 964 with different information in the different instances, the following 965 apply: 967 - If those sub-TLVs provide different nicknames, it is unspecified 968 which nickname takes precedence. 969 - The largest appointed forwarder status lost counter, using serial 970 number arithmetic [RFC1982], is used. 971 - The originating IS is assumed to be attached to a multicast IPv4 972 router for that VLAN if any of the INT-VLAN sub-TLVs assert that 973 it is so connected and similarly for IPv6 multicast router 974 attachment. 975 - The root bridge lists from all of the instances of the VLAN for 976 the originating IS are merged. 978 To minimize such occurrences, wherever possible, an implementation 979 SHOULD advertise the update to an interested VLAN and Spanning Tree 980 Roots sub-TLV in the same LSP fragment as the advertisement that it 981 replaces. Where this is not possible, the two affected LSP fragments 982 should be flooded as an atomic action. An IS that receives an update 983 to an existing interested VLAN and Spanning Tree Roots sub-TLV can 984 minimize the potential disruption associated with the update by 985 employing a hold-down timer prior to processing the update so as to 986 allow for the receipt of multiple LSP fragments associated with the 987 same update prior to beginning processing. 989 The sub-TLV layout is as follows: 991 +-+-+-+-+-+-+-+-+ 992 |Type = INT-VLAN| (1 byte) 993 +-+-+-+-+-+-+-+-+ 994 | Length | (1 byte) 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Nickname | (2 bytes) 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ 998 | Interested VLANS | (4 bytes) 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ 1000 | Appointed Forwarder Status Lost Counter | (4 bytes) 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+ 1002 | Root Bridges | (6*n bytes) 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 1005 o Type: Router and MT Capability sub-TLV type, set to 10 (INT-VLAN). 1007 o Length: 10 + 6*n, where n is the number of root bridge IDs. 1009 o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field 1010 may be used to associate a nickname held by the originating IS 1011 with the VLAN range indicated. When not used in this way, it is 1012 set to zero. 1014 o Interested VLANS: The Interested VLANs field is formatted as shown 1015 below. 1017 0 1 2 3 4 - 15 16 - 19 20 - 31 1018 +----+----+----+----+------------+----------+------------+ 1019 | M4 | M6 | R | R | VLAN.start | RESV | VLAN.end | 1020 +----+----+----+----+------------+----------+------------+ 1022 - M4, M6: These bits indicate, respectively, that there is an 1023 IPv4 or IPv6 multicast router on a link for which the 1024 originating IS is appointed forwarder for every VLAN in the 1025 indicated range as specified in [RFC6325], Section 4.2.4.4, 1026 item 5.1. 1028 - R, RESV: These reserved bits MUST be sent as zero and are 1029 ignored on receipt. 1031 - VLAN.start and VLAN.end: This VLAN ID range is inclusive. 1032 Setting both VLAN.start and VLAN.end to the same value 1033 indicates a range of one VLAN ID. If VLAN.start is not equal to 1034 VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as 1035 if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end 1036 and VLAN.end is 0xFFF, the sub-TVL is interpreted as if 1037 VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the 1038 sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 1039 or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 1040 0xFFF are not valid VLAN IDs and a port cannot be enabled for 1041 them. 1043 o Appointed Forwarder Status Lost Counter: This is a count of how 1044 many times a port that was appointed forwarder for the VLANs in 1045 the range given has lost the status of being an appointed 1046 forwarder for some port as discussed in Section 4.8.3 of 1047 [RFC6325]. It is initialized to zero at an IS when the zeroth LSP 1048 sequence number is initialized. No special action need be taken at 1049 rollover; the counter just wraps around. 1051 o Root Bridges: The list of zero or more spanning tree root bridge 1052 IDs is the set of root bridge IDs seen for all ports for which the 1053 IS is appointed forwarder for the VLANs in the specified range as 1054 discussed in [RFC6325], Section 4.9.3.2. While, of course, at most 1055 one spanning tree root could be seen on any particular port, there 1056 may be multiple ports in the same VLANs connected to different 1057 bridged LANs with different spanning tree roots. 1059 An INT-VLAN sub-TLV asserts that the information provided (multicast 1060 router attachment, appointed forwarder status lost counter, and root 1061 bridges) is the same for all VLANs in the range specified. If this is 1062 not the case, the range MUST be split into subranges meeting this 1063 criteria. It is always safe to use sub-TLVs with a "range" of one 1064 VLAN ID, but this may be too verbose. 1066 2.3.7 VLAN Group Sub-TLV 1068 The VLAN Group sub-TLV consists of two or more VLAN IDs as specified 1069 in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN 1070 learning is occurring at the originating IS between the listed VLANs. 1071 It is structured as follows: 1073 +-+-+-+-+-+-+-+-+ 1074 |Type=VLAN-GROUP| (1 byte) 1075 +-+-+-+-+-+-+-+-+ 1076 | Length | (1 byte) 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | RESV | Primary VLAN ID | (2 bytes) 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | RESV | Secondary VLAN ID | (2 bytes) 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | more Secondary VLAN IDs ... (2 bytes each) 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 o Type: Router and MT Capability sub-TLV type, set to 14 (VLAN- 1086 GROUP). 1088 o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields 1089 beyond the first. n MAY be zero. 1091 o RESV: a 4-bit field that MUST be sent as zero and ignored on 1092 receipt. 1094 o Primary VLAN ID: This identifies the primary VLAN ID. 1096 o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN 1097 Group. 1099 o more Secondary VLAN IDs: zero or more byte pairs, each with the 1100 top 4 bits as a RESV field and the low 12 bits as a VLAN ID. 1102 2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV 1104 An IS that can handle fine-grained labeling [RFCfgl] announces its 1105 fine-grained label connectivity and related information in the 1106 "Interested Labels and Bridge Spanning Tree Roots sub-TLV" (INT- 1107 LABEL) which is a variation of the "Interested VLANs and Spanning 1108 Tree Roots sub-TLV" (INT-VLAN) structured as below. 1110 +-+-+-+-+-+-+-+-+ 1111 |Type= INT-LABEL| (1 byte) 1112 +-+-+-+-+-+-+-+-+ 1113 | Length | (1 byte) 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Nickname | (2 bytes) 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 1117 | Interested Labels | (7 bytes) 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 1119 | Appointed Forwarder Status Lost Counter | (4 bytes) 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 1121 | Root Bridges | (6*n bytes) 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 1124 o Type: Router and MT Capability sub-TLV Type, set to TBDh [15 1125 suggested] (INT-LABEL). 1127 o Length: 11 + 6*n where n is the number of root bridge IDs. 1129 o Nickname: This field may be used to associate a nickname held by 1130 the originating IS with the Labels indicated. When not used in 1131 this way, it is set to zero. 1133 o Interested Labels: The Interested Labels field is seven bytes long 1134 and formatted as shown below. 1136 0 1 2 3 4 5 6 7 1137 +--+--+--+--+--+--+--+--+ 1138 |M4|M6|BM| R| R| R| R| R| . . 1139 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Label.start - 24 bits | 1141 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Label.end or Bit Map - 24 bits | 1143 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 0 1 2 1145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1147 - M4, M6: These bits indicate, respectively, that there is an 1148 IPv4 or IPv6 multicast router on a link to which the 1149 originating IS is appointed forwarder for the VLAN 1150 corresponding to every label in the indicated range. 1152 - BM: If the BM (Bit Map) bit is zero, the last three bytes of 1153 the Interested Labels is a Label.end label number. If the BM 1154 bit is one, those bytes are a bit map as described below. 1156 - R: These reserved bits MUST be sent as zero and are ignored on 1157 receipt. 1159 - Label.start and Label.end: If the BM bit is zero: This fine- 1160 grained label [RFCfgl] ID range is inclusive. These fields are 1161 treated as unsigned integers. Setting them both to that same 1162 label ID value indicates a range of one label ID. If Label.end 1163 is less than Label.start, the sub-TLV is ignored. 1165 - Label.start and Bit Map: If the BM bit is one: The fine-grained 1166 labels that the IS is interested in are indicated by a 24-bit 1167 bit map. The interested labels are the Label.start number plus 1168 the bit number of each one bit in the bit map. So, if bit zero 1169 of the bit map is a one, the IS in interested in the label with 1170 value Label.start and if bit 23 of the bit map is a one, the IS 1171 is interested in the label with value Label.start+23. 1173 o Appointed Forwarder Status Lost Counter: This is a count of how 1174 many times a port that was appointed forwarder for a VLAN mapping 1175 to the fine-grained label in the range or bit map given has lost 1176 the status of being an appointed forwarder as discussed in Section 1177 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the 1178 zeroth LSP sequence number is initialized. No special action need 1179 be taken at rollover; the counter just wraps around. 1181 o Root Bridges: The list of zero or more spanning tree root bridge 1182 IDs is the set of root bridge IDs seen for all ports for which the 1183 IS is appointed forwarder for a VLAN mapping to the fine-grained 1184 label in the specified range or bit map. (See [RFC6325], Section 1185 4.9.3.2.) While, of course, at most one spanning tree root could 1186 be seen on any particular port, there may be multiple relevant 1187 ports connected to different bridged LANs with different spanning 1188 tree roots. 1190 An INT-LABEL sub-TLV asserts that the information provided (multicast 1191 router attachment, appointed forwarder status lost counter, and root 1192 bridges) is the same for all labels specified. If this is not the 1193 case, the sub-TLV MUST be split into subranges and/or separate bit 1194 maps meeting this criteria. It is always safe to use sub-TLVs with a 1195 "range" of one VLAN ID, but this may be too verbose. 1197 2.3.9 RBridge Channel Protocols Sub-TLV 1199 An IS announces the RBridge Channel protocols [Channel] it supports 1200 through use of this sub-TLV. 1202 +-+-+-+-+-+-+-+-+ 1203 |Type=RBCHANNELS| (1 byte) 1204 +-+-+-+-+-+-+-+-+ 1205 | Length | (1 byte) 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1207 | Zero or more bit vectors (variable) 1208 +-+-+-+-... 1210 o Type: Router and MT Capabilities RBridge Channel Protocols sub- 1211 TLV, set to TBDi [16 suggested] (RBCHANNELS). 1213 o Length: variable. 1215 o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit 1216 indicates support of a particular RBridge Channel protocol. Each 1217 byte-aligned bit vector is formatted as follows: 1219 | 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15| 1220 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1221 | Bit Vector Length | Bit Vector Offset | 1222 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1223 | bits 1224 +--+--+--... 1226 The bit vector length (BVL) is a seven bit unsigned integer field 1227 giving the number of bytes of bit vector. The bit vector offset (BVO) 1228 is a nine bit unsigned integer field. 1230 The bits in each bit vector are numbered in network order, the high 1231 order bit of the first byte of bits being bit 0 + 8*BVO, the low 1232 order bit of that byte being 7 + 8*BVO, the high order bit of the 1233 second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge 1234 Channel protocols-supported bit vector MUST NOT extend beyond the end 1235 of the value in the sub-TLV in which it occurs. If it does, it is 1236 ignored. If multiple byte-aligned bit vectors are present in one such 1237 sub-TLV, their representations are contiguous, the BVL field for the 1238 next starting immediately after the last byte of bits for the 1239 previous bit vector. The one or more bit vectors present MUST exactly 1240 fill the sub-TLV value. If there are one or two bytes of value left 1241 over, they are ignored; if more than two, an attempt is made to parse 1242 them as one or more bit vectors. 1244 If different bit vectors overlap in the protocol number space they 1245 refer to and they have inconsistent bit values for a channel 1246 protocol, support for the protocol is assumed if any of these bit 1247 vectors has a 1 for that protocol. 1249 The absence of any occurrences of this sub-TLV in the LSP for an IS 1250 implies that that IS does not support the RBridge Channel facility. 1252 To avoid wasted space, trailing bit vector zero bytes SHOULD be 1253 eliminated by reducing BVL, any null bit vectors (ones with BVL equal 1254 to zero) eliminated, and generally the most compact encoding used. 1255 For example, support for channel protocols 1 and 32 could be encoded 1256 as 1258 BVL = 5 1259 BVO = 0 1260 0b01000000 1261 0b00000000 1262 0b00000000 1263 0b00000000 1264 0b10000000 1266 or as 1268 BVL = 1 1269 BVO = 0 1270 0b01000000 1271 BLV = 1 1272 BVO = 4 1273 0b1000000 1275 The first takes 7 bytes while the second takes only 6 and thus the 1276 second would be preferred. 1278 In multi-topology aware RBridges, RBridge channel protocols for which 1279 support is announced in the base topology are assumed to be supported 1280 in all topologies for which there is no separate RBridge channel 1281 protocol support announcement. 1283 2.3.10 Affinity Sub-TLV 1285 Association of an IS to a multi-destination distribution tree through 1286 a specific path is accomplished by using the tree Affinity sub-TLV. 1287 The announcement of an Affinity sub-TLV by RB1 with the nickname of 1288 RB2 as the first part of an Affinity Record in the sub-TLV value is a 1289 request by RB1 that all ISes in the campus connect RB2 as a child of 1290 RB1 when calculating any of the trees listed in that Affinity Record. 1291 Examples of use include [Affinity] and [Resilient]. 1293 The structure of the AFFINITY sub-TLV is shown below. 1295 +-+-+-+-+-+-+-+-+ 1296 | Type=AFFINITY | (1 byte) 1297 +-+-+-+-+-+-+-+-+ 1298 | Length | (1 byte) 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | AFFINITY RECORD 1 | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | AFFINITY RECORD 2 | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | .......... 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | AFFINITY RECORD N | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 Where each AFFINITY RECORD is structured as follows: 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Nickname | (2 bytes) 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 |Affinity Flags | (1 byte) 1315 +-+-+-+-+-+-+-+-+ 1316 |Number of trees| (1 byte) 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Tree-num of 1st root | (2 bytes) 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Tree-num of 2nd root | (2 bytes) 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | .......... | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Tree-num of Nth root | (2 bytes) 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 o Type: Router and MT Capability sub-TLV type, set to TBDj [17 1328 suggested] (AFFINITY). 1330 o Length: 1 + size of all Affinity Records included, where an 1331 Affinity Record listing n tree roots is 3+2*n bytes long. 1333 o Nickname: 16-bit nickname of the IS whose associations to the 1334 multi-destination trees listed in the Affinity Record are through 1335 the originating IS. 1337 o Affinity Flags: 8 bits reserved for future needs to provide 1338 additional information about the affinity being announced. MUST be 1339 sent as zero and ignored on receipt. 1341 o Number of trees: A one byte unsigned integer giving the number of 1342 trees for which affinity is being announced by this Affinity 1343 Record. 1345 o Tree-num of roots: The tree numbers of the distribution trees this 1346 Affinity Record is announcing. 1348 There is no need for a field giving the number of Affinity Records as 1349 this can be determined by processing those records. 1351 2.3.11 Label Group Sub-TLV 1353 The Label Group sub-TLV consists of two or more fine-grained label 1354 [RFCfgl] IDs. This sub-TLV indicates that shared Label MAC address 1355 learning is occurring at the announcing IS between the listed Labels. 1356 It is structured as follows: 1358 +-+-+-+-+-+-+-+-+ 1359 |Typ=LABEL-GROUP| (1 byte) 1360 +-+-+-+-+-+-+-+-+ 1361 | Length | (1 byte) 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Primary Label ID | (3 bytes) 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Secondary Label ID | (3 bytes) 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | more Secondary Label IDs ... (3 bytes each) 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 o Type: Router and MT Capability sub-TLV type, set to TBDk [18 1371 suggested] (LABEL-GROUP). 1373 o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields 1374 beyond the first. n MAY be zero. 1376 o Primary Label ID: This identifies the primary Label ID. 1378 o Secondary Label ID: This identifies a secondary Label in the Label 1379 Group. 1381 o more Secondary Label IDs: zero or more byte triples, each with a 1382 Label ID. 1384 2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs 1386 The MTU sub-TLV is used to optionally announce the MTU of a link as 1387 specified in [RFC6325] Section 4.2.4.4. It occurs within the Extended 1388 Reachability (#22) and MT (multi-topology) ISN (Intermediate System 1389 Neighbors) (#222) TLVs. 1391 +-+-+-+-+-+-+-+-+ 1392 | Type = MTU | (1 byte) 1393 +-+-+-+-+-+-+-+-+ 1394 | Length | (1 byte) 1395 +-+-+-+-+-+-+-+-+ 1396 |F| RESV | (1 byte) 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | MTU | (2 bytes) 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 o Type: Extended Reachability and MT IS sub-TLV type, set to MTU 1402 sub-TLV 28. 1404 o Length: 3. 1406 o F: Failed. This bit is a one if MTU testing failed on this link at 1407 the required campus-wide MTU. 1409 o RESV: 7 bits that MUST be sent as zero and ignored on receipt. 1411 o MTU: This field is set to the largest successfully tested MTU size 1412 for this link, or zero if it has not been tested, as specified in 1413 Section 4.3.2 of [RFC6325]. 1415 2.5 TRILL Neighbor TLV 1417 The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see 1418 Section 4.1 below) in place of the IS Neighbor TLV, as specified in 1419 Section 4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the 1420 TRILL Neighbor TLV is as follows: 1422 +-+-+-+-+-+-+-+-+ 1423 | Type | (1 byte) 1424 +-+-+-+-+-+-+-+-+ 1425 | Length | (1 byte) 1426 +-+-+-+-+-+-+-+-+ 1427 |S|L|R| SIZE | (1 byte) 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Neighbor RECORDS (1) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Neighbor RECORDS (2) | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | ................. | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Neighbor RECORDS (N) | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 The information present for each neighbor is as follows: 1440 +-+-+-+-+-+-+-+-+ 1441 |F|O| RESV | (1 bytes) 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | MTU | (2 bytes) 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ 1445 | SNPA (MAC Address) | (SIZE bytes) 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ 1448 o Type: TLV Type, set to TRILL Neighbor TLV 145. 1450 o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records, 1451 which may be zero. 1453 o S: Smallest flag. If this bit is a one, then the list of neighbors 1454 includes the neighbor with the smallest MAC address considered as 1455 an unsigned integer. 1457 o L: Largest flag. If this bit is a one, then the list of neighbors 1458 includes the neighbor with the largest MAC address considered as 1459 an unsigned integer. 1461 o R, RESV: These bits are reserved and MUST be sent as zero and 1462 ignored on receipt. 1464 o SIZE: The SNPA size as an unsigned integer in bytes except that 6 1465 is encoded as zero. An actual size of zero is meaningless and 1466 cannot be encoded. The meaning of the value 6 in this field is 1467 reserved and TRILL Neighbor TLVs received with a SIZE of 6 are 1468 ignored. The SIZE is inherent to the technology of a link and is 1469 fixed for all TRILL Neighbor TLVs on that link but may vary 1470 between different links in the campus if those links are different 1471 technologies. For example, 6 for EUI-48 SNPAs or 8 for EUI-64 1472 SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL 1473 campus is independent of the System ID size.) 1475 o F: failed. This bit is a one if MTU testing to this neighbor 1476 failed at the required campus-wide MTU (see [RFC6325], Section 1477 4.3.1). 1479 o O: OOMF. This bit is a one if the IS sending the enclosing TRILL 1480 Neighbor TLV is willing to offer the Overload Originated Multi- 1481 destination Frame (OOMF) service [ClearCorrect] to the IS whose 1482 port has the SNPA in the enclosing Neighbor RECORD. 1484 o MTU: This field is set to the largest successfully tested MTU size 1485 for this neighbor or to zero if it has not been tested. 1487 o SNPA: Sub-Network Point of Attachment (MAC address) of the 1488 neighbor. 1490 As specified in [RFC6327] and Section 4.4.2.1 of [RFC6325], all MAC 1491 addresses may fit into one TLV, in which case both the S and L flags 1492 would be set to one in that TLV. If the MAC addresses don't fit into 1493 one TLV, the highest MAC address in a TRILL Neighbor TLV with the L 1494 flag zero MUST also appear as a MAC address in some other TRILL 1495 Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the 1496 lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST 1497 also appear in some other TRILL Neighbor TLV (possibly in a different 1498 TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a 1499 TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will 1500 have both the S and L bits on. 1502 3. MTU PDUs 1504 The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine 1505 the MTU on a link between ISs as specified in Section 4.3.2 of 1506 [RFC6325] and in [RFC6327]. 1508 The MTU PDUs have the IS-IS PDU common header (up through the Maximum 1509 Area Addresses byte) with PDU Type numbers as indicated in Section 5. 1510 They also have a common fixed MTU PDU header as shown below that is 8 1511 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes 1512 System IDs. 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | PDU Length | (2 bytes) 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1517 | Probe ID (6 bytes) | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1519 | Probe Source ID (ID Length bytes) | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1521 | Ack Source ID (ID Length bytes) | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1524 As with other IS-IS PDUs, the PDU length gives the length of the 1525 entire IS-IS packet starting with and including the IS-IS common 1526 header. 1528 The Probe ID field is an opaque 48-bit quantity set by the IS issuing 1529 an MTU-probe and copied by the responding IS into the corresponding 1530 MTU-ack. For example, an IS creating an MTU-probe could compose this 1531 quantity from a port identifier and probe sequence number relative to 1532 that port. 1534 The Probe Source ID is set by an IS issuing an MTU-probe to its 1535 System ID and copied by the responding IS into the corresponding MTU- 1536 ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored 1537 on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to 1538 its System ID. The System ID length is usually 6 bytes but could be a 1539 different value as indicated by the ID Length field in the IS-IS PDU 1540 Header. 1542 The TLV area follows the MTU PDU header area. This area MAY contain 1543 an Authentication TLV and MUST be padded with the Padding TLV to the 1544 exact size being tested. Since the minimum size of the Padding TLV is 1545 2 bytes, it would be impossible to pad to exact size if the total 1546 length of the required information bearing fixed fields and TLVs 1547 added up to 1 byte less than the desired length. However, the length 1548 of the fixed fields and substantive TLVs for MTU PDUs is expected to 1549 be quite small compared with their minimum length (minimum 1470-byte 1550 MTU on an IEEE 802.3 link, for example), so this should not be a 1551 problem. 1553 4. Use of Existing PDUs and TLVs 1555 The sub-sections below provide details of TRILL use of existing PDUs 1556 and TLVs. 1558 4.1 TRILL IIH PDUs 1560 The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL 1561 protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC6327] 1562 specify the contents of the TRILL IIH and how its use in TRILL 1563 differs from Layer 3 LAN IIH PDU use. The adjacency state machinery 1564 for TRILL neighbors is specified in detail in [RFC6327]. 1566 In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header 1567 are the same as a Level 1 IIH PDU. 1569 The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored 1570 if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL 1571 Neighbor TLV (see Section 2.5). 1573 4.2 Area Address 1575 TRILL uses a fixed zero Area Address as specified in [RFC6325], 1576 Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) 1577 as follows: 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | 0x01, Area Address Type | (1 byte) 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | 0x02, Length of Value | (1 byte) 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | 0x01, Length of Address | (1 byte) 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | 0x00, zero Area Address | (1 byte) 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 4.3 Protocols Supported 1591 NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL 1592 [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that 1593 value appears in TRILL IIH PDUs and LSP number zero PDUs. 1595 4.4 Link State PDUs (LSPs) 1597 A number zero LSP MUST NOT be originated larger than 1470 bytes but a 1598 larger number zero LSP successfully received MUST be processed and 1599 forwarded normally. 1601 4.5 Originating LSP Buffer Size 1603 The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; 1604 however, if found in other LSP fragments, it is processed normally. 1605 Should there be more than one originatingLSPBufferSize TLV for an IS, 1606 the minimum size, but not less than 1470, is used. 1608 5. IANA Considerations 1610 This section gives IANA Considerations for the TLVs, sub-TLVs, and 1611 PDUs specified herein. A number of new code points are assigned and 1612 those that were assigned by [RFC6326] are included here for 1613 convenience. IANA is requested to replace all [RFC6326] references 1614 in the IANA Registries with references to this document. 1616 5.1 TLVs 1618 This document specifies two IS-IS TLV types -- namely, the Group 1619 Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type 1620 145). The PDUs in which these TLVs are permitted for TRILL are shown 1621 in the table below along with the section of this document where they 1622 are discussed. The final "NUMBER" column indicates the permitted 1623 number of occurrences of the TLV in their PDU, or set of PDUs in the 1624 case of LSP, which in these two cases is "*" indicating that the TLV 1625 MAY occur 0, 1, or more times. 1627 IANA has registered these two code points in the IANA IS-IS TLV 1628 registry (ignoring the "Section" and "NUMBER" columns, which are 1629 irrelevant to that registry). 1631 Section TLV IIH LSP SNP Purge NUMBER 1632 ======= === === === === ===== ====== 1633 GADDR-TLV 2.1 142 - X - - * 1634 TRILL Neighbor TLV 2.5 145 X - - - * 1636 5.2 sub-TLVs 1638 This document specifies a number of sub-TLVs. The TLVs in which these 1639 sub-TLVs occur are shown in the second table below along with the 1640 section of this document where they are discussed. The TLVs within 1641 which these sub-TLVs can occur are determined by the presence of an 1642 "X" in the relevant column and the column header as shown in the 1643 first table below. In some cases, the column header corresponds to 1644 two different TLVs in which the sub-TLV can occur. 1646 Column Head TLV RFCref TLV Name 1647 =========== ===== ======== ============== 1648 Grp. Adr. 142 This doc Group Address 1650 MT Port 143 6165 MT-PORT-CAP 1652 MT Cap. 242 4971 Router CAPABILITY 1653 144 6329 MT-Capability 1655 Ext. Reach 22 5305 Extended IS Reachability 1656 222 5120 MT ISN 1658 The final "NUMBER" column below indicates the permitted number of 1659 occurrences of the sub-TLV cumulatively within all occurrences of 1660 their TLV(s) in those TLVs' carrying PDU (or set of PDUs in the case 1661 of LSP), as follows: 1663 0-1 = MAY occur zero or one times. 1664 1 = MUST occur exactly once. If absent, the PDU is ignored. If it 1665 occurs more than once, results are unspecified. 1666 * = MAY occur 0, 1, or more times. 1668 The values in the "Section" and "NUMBER" columns are irrelevant to 1669 the IANA sub-registries. The numbers in square brackets are suggested 1670 values. 1672 sub- Grp. MT MT Ext. 1673 Name Section TLV# Adr. Port Cap. Reach NUMBER 1674 ================================================================= 1675 GMAC-ADDR 2.1.1 1 X - - - * 1676 GIP-ADDR 2.1.2 TBDa[2] X - - - * 1677 GIPV6-ADDR 2.1.3 TBDb[3] X - - - * 1678 GLMAC-ADDR 2.1.4 TBDc[4] X - - - * 1679 GLIP-ADDR 2.1.5 TBDd[5] X - - - * 1680 GLIPV6-ADDR 2.1.6 TBDe[6] X - - - * 1681 VLAN-FLAGS 2.2.1 1 - X - - 1 1682 Enabled-VLANs 2.2.2 2 - X - - * 1683 AppointedFwrdrs 2.2.3 3 - X - - * 1684 PORT-TRILL-VER 2.2.4 TBDf[7] - X - - 0-1 1685 VLANs-Appointed 2.2.5 TBDg[8] - X - - * 1686 NICKNAME 2.3.2 6 - - X - * 1687 TREES 2.3.3 7 - - X - 0-1 1688 TREE-RT-IDs 2.3.4 8 - - X - * 1689 TREE-USE-IDs 2.3.5 9 - - X - * 1690 INT-VLAN 2.3.6 10 - - X - * 1691 TRILL-VER 2.3.1 13 - - X - 0-1 1692 VLAN-GROUP 2.3.7 14 - - X - * 1693 INT-LABEL 2.3.8 TBDh[15] - - X - * 1694 RBCHANNELS 2.3.9 TBDi[16] - - X - * 1695 AFFINITY 2.3.10 TBDj[17] - - X - * 1696 LABEL-GROUP 2.3.11 TBDk[18] - - X - * 1697 MTU 2.4 28 - - - X 0-1 1698 ================================================================= 1699 Name Section sub- Grp. MT MT Ext. NUMBER 1700 TLV# Adr. Port Cap. Reach 1702 IANA is requested to enter the newly assigned sub-TLV numbers in the 1703 above table in the one or two relevant existing sub-TLV registries, 1704 as determined by which column has an X opposite that sub-TLV. For the 1705 sub-TLVs from NICKNAME through and including VLAN-GROUP, which 1706 currently exist only in the registry of sub-TLVs under TLV 242, IANA 1707 is requested to add each sub-TLV with the same sub-TLV number to the 1708 existing registry for sub-TLVs under TLV 144. 1710 5.3 PDUs 1712 The IS-IS PDUs registry remains as established in [RFC6326] except 1713 that the references to [RFC6326] are updated to reference this 1714 document. 1716 5.4 Reserved and Capability Bits 1718 Any reserved bits (R) or bits in reserved fields (RESV) or the 1719 capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which 1720 are specified herein as "MUST be sent as zero and ignored on receipt" 1721 or the like, are allocated based on IETF Review [RFC5226]. 1723 Two sub-registries are created within the TRILL Parameters Registry 1724 as follows: 1726 Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags 1727 Registration Procedures: IETF Review 1728 Reference: (This document) 1730 Bit Description Reference 1731 ===== ============= =========== 1732 0 Affinity sub-TLV support. [Affinity] 1733 1-13 Unassigned 1734 14-31 Extended header flag support. [ExtendHeader] 1736 Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags 1737 Registration Procedures: IETF Review 1738 Reference: (This document) 1740 Bit Description Reference 1741 ===== ============= =========== 1742 0 Hello reduction support. [ClearCorrect] 1743 1-2 Unassigned 1744 3-13 Hop-by-hop extended flag support. [ExtendHeader] 1745 14-31 Unassigned 1747 5.5 TRILL Neighbor Record Flags 1749 A sub-registry is created within the TRILL Parameters Registry as 1750 follows: 1752 Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags 1753 Registration Procedures: Standards Action 1754 Reference: (This document) 1756 Bit Short Name Description Reference 1757 ============== ============= =========== 1758 0 Fail Failed MTU test [RFC6325] 1759 1 OOMF Offering OOMF service [ClearCorrect] 1760 2-7 - Unassigned 1762 6. Security Considerations 1764 For general TRILL protocol security considerations, see the TRILL 1765 base protocol standard [RFC6325]. 1767 This document raises no new security issues for IS-IS. IS-IS security 1768 may be used to secure the IS-IS messages discussed here. See 1769 [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, 1770 replays of Hello packets can create denial-of-service conditions; see 1771 [RFC6039] for details. These issues are similar in scope to those 1772 discussed in Section 6.2 of [RFC6325], and the same mitigations may 1773 apply. 1775 7. Change from RFC 6326 1777 Non-editorial changes from [RFC6326] are summarized in the list 1778 below: 1780 1. Additional of five sub-TLVs under the Group Address (GADDR) TLV 1781 covering VLAN labeled IPv4 and IPv6 addresses and fine-grained 1782 labeled MAC, IPv4, and IPv6 addresses. (Sections 2.1.2, 2.1.3, 1783 2.1.4, 2.1.5, and 2.1.6). 1785 2. Addition of the PORT-TRILL-VER sub-TLV. (Section 2.2.4) 1787 3. Addition of the VLANs-Appointed sub-TLV. (Section 2.2.5) 1789 4. Change the TRILL-VER sub-TLV as listed below. 1791 4.a Addition of 4 bytes of TRILL Header extended flags and 1792 capabilities supported information. 1794 4.b Require that the TRILL-VER sub-TLV appear in LSP number zero. 1796 The above changes to TRILL-VER are backwards compatible because 1797 the [RFC6326] conformant implementations of TRILL thus far have 1798 only supported version zero and not supported any optional 1799 capabilities or extended flags, the level of support indicated by 1800 the absence of the TRILL-VER sub-TLV. Thus, if an [RFC6326] 1801 conformant implementation of TRILL rejects this sub-TLV due to 1802 the changes specified in this document, it will, at worst, decide 1803 that support of version zero and no extended flags or 1804 capabilities is indicated, which is the best an [RFC6326] 1805 conformant implementation of TRILL can do anyway. Similarly, a 1806 TRILL implementation that supports TRILL-VER as specified herein 1807 and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL 1808 implementation because they are not in LSP number zero will 1809 decide that that implementation supports only version zero with 1810 no extended flag or capabilities support, which will be correct. 1811 (Section 2.3.1) 1813 5. Clarification of the use of invalid VLAN IDs (0x000 and 0xFFF) in 1814 the Appointed Forwarders sub-TLV and the Interested VLANs and 1815 Spanning Tree Roots sub-TLV. (Sections 2.2.3 and 2.3.6) 1817 6. Addition of the Interested Labels and Spanning Tree Roots sub-TLV 1818 to indicate attachment of an IS to a fine-grained label [RFCfgl] 1819 analogous to the existing Interested VLANs and Spanning Tree 1820 Roots sub-TLV for VLANs. (Section 2.3.8) 1822 7. Addition of the RBridge Channel Protocols sub-TLV so ISs can 1823 announce the RBridge Channel protocols they support. (Section 1824 2.3.9) 1826 8. Permit specification of the length of the link SNPA field in 1827 TRILL Neighbor TLVs. This change is backwards compatible because 1828 the size of 6 bytes is specially encoded as zero, the previous 1829 value of the bits in the new SIZE field. (Section 2.5) 1831 9. Make the size of the MTU PDU Header Probe Source ID and Ack 1832 Source ID fields be the ID Length from the IS-IS PDU Header 1833 rather than the fixed value 6. (Section 3) 1835 10. For robustness, require LSP number zero PDUs be originated as no 1836 larger than 1470 bytes but processed regardless of size. (Section 1837 4.4) 1839 11. Require that the originatingLSPBufferSize TLV, if present, appear 1840 in LSP number zero. (Section 4.5) 1842 12. Create sub-registries for and specify the IANA Considerations 1843 policy for reserved and capability bits in the TRILL version sub- 1844 TLVs. (Section 5.4) 1846 13. Addition of the distribution tree Affinity sub-TLV so ISs can 1847 request distribution tree attachments. (Section 2.3.10) 1849 14. Add LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV. 1850 (Section 2.3.11) 1852 15. Add multi-topology: permit sub-TLVs previously only in Router 1853 Capabilities TLV to also appear in MT Capabilities TLV; permit 1854 MTU sub-TLV previously limited to Extended Reachability TLV to 1855 also appear in MT ISN TLV. 1857 16. Addition of a sub-registry for Neighbor TLV Neighbor RECORD flag 1858 bits. (Section 5.5) 1860 17. Explicitly state that if the number of sources in a GADDR-TLV 1861 sub-TLV is zero, it indicates a listener for (*,G), that is, a 1862 listener not restricted by source. (Section 2.1) 1864 8. Normative References 1866 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 1867 System to Intermediate System Intra-Domain Routing Exchange 1868 Protocol for use in Conjunction with the Protocol for Providing 1869 the Connectionless-mode Network Service (ISO 8473)", 2002. 1871 [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1872 Dual Environments", 1990. 1874 [RFC1982] - Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1875 1982, August 1996. 1877 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1878 Requirement Levels", BCP 14, RFC 2119, March 1997. 1880 [RFC4971] - Vasseur, JP. and N. Shen, "Intermediate System to 1881 Intermediate System (IS-IS) Extensions for Advertising Router 1882 Information", 2007. 1884 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1885 Topology (MT) Routing in Intermediate System to Intermediate 1886 Systems (IS-ISs)", RFC 5120, February 2008. 1888 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 1889 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1890 2008. 1892 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1893 Engineering", 2008. 1895 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1896 Layer-2 Systems", RFC 6165, April 2011. 1898 [RFC6325] - Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 1899 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 1900 June 2011. 1902 [RFC6327] - Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. 1903 Manral, "RBridges: Adjacency", RFC 6327, July 2011. 1905 [RFC6328] - Eastlake, D., "IANA Considerations for Network Layer 1906 Protocol Identifiers", RFC 6328, June 2011. 1908 [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, 1909 A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 1910 Shortest Path Bridging", RFC 6329, April 2012. 1912 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1913 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1914 6439, November 2011. 1916 [Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, 1917 draft-ietf-trill-rbridge-channel, in RFC Editor's queue. 1919 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. 1920 Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's 1921 queue. 1923 [ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. 1924 Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's 1925 queue. 1927 [RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 1928 "TRILL (Transparent Interconnection of Lots of Links): Fine- 1929 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 1930 Ediotr's queue. 1932 9. Informative References 1934 [Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc- 1935 editor.org. 1937 [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1938 Authentication", RFC 5304, October 2008. 1940 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1941 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1942 5310, February 2009. 1944 [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, 1945 "Issues with Existing Cryptographic Protection Methods for 1946 Routing Protocols", RFC 6039, October 2010. 1948 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 1949 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 1950 Use of IS-IS", RFC 6326, July 2011. 1952 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1953 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1954 BCP 141, RFC 7042, October 2013. 1956 [RFCtrillBFD] - V. Manral, D, Eastlake, D. Ward, A. Banerjee, draft- 1957 ietf-trill-rbridge-bfd-07.txt, in RFC Editor's queue. 1959 [Affinity] - draft-ietf-trill-cmt, work in progress. 1961 [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in 1962 progress. 1964 [Resilient] - draft-zhang-trill-resilient-trees, work in progress. 1966 Acknowledgements 1968 The authors gratefully acknowledge the contributions and review by 1969 the following: 1971 Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, 1972 Radia Perlman, Carlos Pignataro, Joe Touch. 1974 And the contributions by the following to [RFC6326]: 1976 Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam 1977 Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, 1978 thanks to Mike Shand for the detailed and helpful comments. 1980 This document was produced with raw nroff. All macros used were 1981 defined in the source files. 1983 Authors' Addresses 1985 Donald Eastlake 1986 Huawei Technologies 1987 155 Beaver Street 1988 Milford, MA 01757 USA 1990 Phone: +1-508-333-2270 1991 EMail: d3e3e3@gmail.com 1993 Tissa Senevirathne 1994 Cisco Systems 1995 375 East Tasman Drive, 1996 San Jose, CA 95134 1998 Phone: +1-408-853-2291 1999 EMail: tsenevir@cisco.com 2001 Anoop Ghanwani 2002 Dell 2003 350 Holger Way 2004 San Jose, CA 95134 USA 2006 Phone: +1-408-571-3500 2007 EMail: anoop@alumni.duke.edu 2009 Dinesh Dutt 2010 Cumulus Networks 2011 1089 West Evelyn Avenue 2012 Sunnyvale, CA 94086 USA 2014 EMail: ddutt.ietf@hobbesdutt.com 2016 Ayan Banerjee 2017 Insieme Networks 2018 210 West Tasman Drive 2019 San Jose, CA 95134 USA 2021 Email: ayabaner@gmail.com 2023 Copyright, Disclaimer, and Additional IPR Provisions 2025 Copyright (c) 2014 IETF Trust and the persons identified as the 2026 document authors. All rights reserved. 2028 This document is subject to BCP 78 and the IETF Trust's Legal 2029 Provisions Relating to IETF Documents 2030 (http://trustee.ietf.org/license-info) in effect on the date of 2031 publication of this document. Please review these documents 2032 carefully, as they describe your rights and restrictions with respect 2033 to this document. Code Components extracted from this document must 2034 include Simplified BSD License text as described in Section 4.e of 2035 the Trust Legal Provisions and are provided without warranty as 2036 described in the Simplified BSD License.