idnits 2.17.1 draft-ietf-isis-rfc6326bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances 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 1688 has weird spacing: '...Section sub-...' -- The document date (October 12, 2012) is 4213 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 1665 -- Looks like a reference, but probably isn't: '3' on line 1666 -- Looks like a reference, but probably isn't: '4' on line 1667 -- Looks like a reference, but probably isn't: '5' on line 1668 -- Looks like a reference, but probably isn't: '6' on line 1669 -- Looks like a reference, but probably isn't: '7' on line 1673 -- Looks like a reference, but probably isn't: '8' on line 1674 -- Looks like a reference, but probably isn't: '15' on line 1682 -- Looks like a reference, but probably isn't: '16' on line 1683 -- Looks like a reference, but probably isn't: '17' on line 1684 -- Looks like a reference, but probably isn't: '18' on line 1685 -- 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) -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) -- 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 (==), 17 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 Ayan Banerjee 9 Cumulus Networks 10 Expires: April 11, 2013 October 12, 2012 12 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS 13 15 Abstract 17 The IETF TRILL (Transparent Interconnection of Lots of Links) 18 protocol provides optimal pair-wise data frame forwarding without 19 configuration in multi-hop networks with arbitrary topology and link 20 technology, and support for multipathing of both unicast and 21 multicast traffic. This document specifies the data formats and code 22 points for the IS-IS extensions to support TRILL. These data formats 23 and code points may also be used by technologies other than TRILL. 24 This document obsoletes RFC 6326. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Distribution of this document is unlimited. Comments should be sent 32 to the TRILL working group mailing list. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 46 Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Table of Contents 51 1. Introduction............................................3 52 1.1 Conventions Used in This Document....................3 53 2. TLV and Sub-TLV Extensions to IS-IS for TRILL..........5 54 2.1 Group Address TLV....................................5 55 2.1.1 Group MAC Address Sub-TLV..........................5 56 2.1.2 Group IPv4 Address Sub-TLV.........................7 57 2.1.3 Group IPv6 Address Sub-TLV.........................8 58 2.1.4 Group Labeled MAC Address Sub-TLV..................8 59 2.1.5 Group Labeled IPv4 Address Sub-TLV................10 60 2.1.6 Group Labeled IPv6 Address Sub-TLV................11 61 2.2 Multi-Topology-Aware Port Capability Sub-TLVs.......11 62 2.2.1 Special VLANs and Flags Sub-TLV...................12 63 2.2.2 Enabled-VLANs Sub-TLV.............................13 64 2.2.3 Appointed Forwarders Sub-TLV......................14 65 2.2.4 Port TRILL Version Sub-TLV........................15 66 2.2.5 VLANs Appointed Sub-TLV...........................16 67 2.3 Sub-TLVs of the Router and MT Capability TLVs.......17 68 2.3.1 TRILL Version Sub-TLV.............................17 69 2.3.2 Nickname Sub-TLV..................................18 70 2.3.3 Trees Sub-TLV.....................................19 71 2.3.4 Tree Identifiers Sub-TLV..........................20 72 2.3.5 Trees Used Identifiers Sub-TLV....................21 73 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV..21 74 2.3.7 VLAN Group Sub-TLV................................24 75 2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV.24 76 2.3.9 RBridge Channel Protocols Sub-TLV.................26 77 2.3.10 Affinity Sub-TLV.................................28 78 2.3.11 Label Group Sub-TLV..............................30 79 2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs...30 80 2.5 TRILL Neighbor TLV..................................31 81 3. MTU PDUs...............................................34 82 4. Use of Existing PDUs and TLVs..........................35 83 4.1 TRILL IIH PDUs......................................35 84 4.2 Area Address........................................35 85 4.3 Protocols Supported.................................35 86 4.4 Link State PDUs (LSPs)..............................36 87 4.5 Originating LSP Buffer Size.........................36 88 5. IANA Considerations....................................37 89 5.1 TLVs................................................37 90 5.2 sub-TLVs............................................37 91 5.3 PDUs................................................39 92 5.4 Reserved and Capability Bits........................39 93 5.5 TRILL Neighbor Record Flags.........................39 94 6. Security Considerations................................41 95 7. Change from RFC 6326...................................42 97 8. Normative References...................................44 98 9. Informative References.................................45 99 Acknowledgements..........................................47 101 1. Introduction 103 The IETF TRILL (Transparent Interconnection of Lots of Links) 104 protocol [RFC6325] [RFC6327] provides transparent forwarding in 105 multi-hop networks with arbitrary topology and link technologies 106 using encapsulation with a hop count and link state routing. TRILL 107 provides optimal pair-wise forwarding without configuration, safe 108 forwarding even during periods of temporary loops, and support for 109 multipathing of both unicast and multicast traffic. Intermediate 110 Systems (ISs) implementing TRILL are called RBridges (Routing 111 Bridges) or TRILL Switches. 113 This document, in conjunction with [RFC6165], specifies the data 114 formats and code points for the IS-IS [ISO-10589] [RFC1195] 115 extensions to support TRILL. These data formats and code points may 116 also be used by technologies other than TRILL. 118 This document obsoletes [RFC6326], which generally corresponded to 119 the base TRILL protocol as the TRILL Working Group passed it up to 120 the IESG in 2009. There has been substantial development of TRILL 121 since them. The main changes from [RFC6326] are summarized below and 122 a full list is given in Section 7. 124 1. Addition of multicast group announcements by IPv4 and IPv6 125 address. 127 2. Addition of facilities for announcing capabilities supported. 129 3. Addition of a tree affinity sub-TLV whereby ISs can request 130 distribution tree association. 132 4. Addition of multi-topology support. 134 5. Addition of control plane support for TRILL Data frame fine- 135 grained labels. This support is independent of the data plane 136 representation. 138 6. Fix the reported errata [Err2869] in [RFC6326]. 140 Changes herein to TLVs and sub-TLVs specified in [RFC6326] are 141 backwards compatible. 143 1.1 Conventions Used in This Document 145 The terminology and acronyms defined in [RFC6325] are used herein 146 with the same meaning. 148 Additional acronyms and phrases used in this document are: 150 BVL - Bit Vector Length 152 BVO - Bit Vector Offset 154 IIH - IS-IS Hello 156 IS - Intermediate System. For this document, all relevant 157 intermediate systems are RBridges [RFC6325]. 159 NLPID - Network Layer Protocol Identifier 161 SNPA - SubNetwork Point of Attachment (MAC Address) 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. TLV and Sub-TLV Extensions to IS-IS for TRILL 169 This section, in conjunction with [RFC6165], specifies the data 170 formats and code points for the TLVs and sub-TLVs for IS-IS to 171 support the IETF TRILL protocol. Information as to the number of 172 occurrences allowed, such as for a TLV in a PDU or set of PDUs or for 173 a sub-TLV in a TLV, is summarized in Section 5. 175 2.1 Group Address TLV 177 The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an 178 LSP PDU and carries sub-TLVs that in turn advertise multicast group 179 listeners. The sub-TLVs that advertises listeners are specified 180 below. The sub-TLVs under GADDR constitute a new series of sub-TLV 181 types (see Section 5.2). 183 GADDR has the following format: 185 +-+-+-+-+-+-+-+-+ 186 |Type=GADDR-TLV | (1 byte) 187 +-+-+-+-+-+-+-+-+ 188 | Length | (1 byte) 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 190 | sub-TLVs... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 193 o Type: TLV Type, set to GADDR-TLV 142. 195 o Length: variable depending on the sub-TLVs carried. 197 o sub-TLVs: The Group Address TLV value consists of sub-TLVs 198 formatted as described in [RFC5305]. 200 2.1.1 Group MAC Address Sub-TLV 202 The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 203 within the GADDR TLV. In TRILL, it is used to advertise multicast 204 listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. 205 It has the following format: 207 +-+-+-+-+-+-+-+-+ 208 |Type=GMAC-ADDR | (1 byte) 209 +-+-+-+-+-+-+-+-+ 210 | Length | (1 byte) 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | RESV | Topology-ID | (2 bytes) 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | RESV | VLAN ID | (2 bytes) 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |Num Group Recs | (1 byte) 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | GROUP RECORDS (1) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | GROUP RECORDS (2) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | ................. | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | GROUP RECORDS (N) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 where each group record is of the following form with k=6: 229 +-+-+-+-+-+-+-+-+ 230 | Num of Sources| (1 byte) 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Group Address (k bytes) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Source 1 Address (k bytes) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Source 2 Address (k bytes) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ..... | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Source M Address (k bytes) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR). 245 o Length: 5 + m + k*n = 5 + m + 6*n where m is the number of group 246 records and n is the sum of the number of group and source 247 addresses. 249 o RESV: Reserved. 4-bit fields that MUST be sent as zero and 250 ignored on receipt. 252 o Topology-ID: This field carries a topology ID [RFC5120] or zero if 253 topologies are not in use. 255 o VLAN ID: This carries the 12-bit VLAN identifier for all 256 subsequent MAC addresses in this sub-TLV, or the value zero if no 257 VLAN is specified. 259 o Number of Group Records: A 1-byte unsigned integer that is the 260 number of group records in this sub-TLV. 262 o Group Record: Each group record carries the number of sources. If 263 this field is zero, it indicates a listener for (*,G), that is, a 264 listener not restricted by source. It then has a 6-byte (48-bit) 265 multicast MAC address followed by 6-byte source MAC addresses. If 266 the sources do not fit in a single sub-TLV, the same group address 267 may be repeated with different source addresses in another sub-TLV 268 of another instance of the Group Address TLV. 270 The GMAC-ADDR sub-TLV is carried only within a GADDR TLV. 272 2.1.2 Group IPv4 Address Sub-TLV 274 The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type TBD 275 [2 suggested] within the GADDR TLV. It has the same format as the 276 Group MAC Address sub-TLV described in Section 2.1.1 except that k=4. 277 The fields are as follows: 279 o Type: sub-TLV Type, set to TBD [2 suggested] (GIP-ADDR). 281 o Length: 5 + m + k*n = 5 + m + 4*n where m is the number of group 282 records and n is the sum of the number of group and source 283 addresses. 285 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 286 topologies are not in use. 288 o RESV: Must be sent as zero on transmission and is ignored on 289 receipt. 291 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 292 all subsequent addresses in this sub-TLV, or the value zero if no 293 VLAN is specified. 295 o Number of Group Records: This is of length 1 byte and lists the 296 number of group records in this sub-TLV. 298 o Group Record: Each group record carries the number of sources. If 299 this field is zero, it indicates a listener for (*,G), that is, a 300 listener not restricted by source. It then has a 4-byte (32-bit) 301 IPv4 Group Address followed by 4-byte source IPv4 addresses. If 302 the number of sources do not fit in a single sub-TLV, it is 303 permitted to have the same group address repeated with different 304 source addresses in another sub-TLV of another instance of the 305 Group Address TLV. 307 The GIP-ADDR sub-TLV is carried only within a GADDR TLV. 309 2.1.3 Group IPv6 Address Sub-TLV 311 The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type TBD 312 [3 suggested] within the GADDR TLV. It has the same format as the 313 Group MAC Address sub-TLV described in Section 2.1.1 except that 314 k=16. The fields are as follows: 316 o Type: sub-TLV Type, set to TBD [3 suggested] (GIPV6-ADDR). 318 o Length: 5 + m + k*n = 5 + m + 16*n where m is the number of group 319 records and n is the sum of the number of group and source 320 addresses. 322 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 323 topologies are not in use. 325 o RESV: Must be sent as zero on transmission and is ignored on 326 receipt. 328 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 329 all subsequent addresses in this sub-TLV, or the value zero if no 330 VLAN is specified. 332 o Number of Group Records: This is of length 1 byte and lists the 333 number of group records in this sub-TLV. 335 o Group Record: Each group record carries the number of sources. If 336 this field is zero, it indicates a listener for (*,G), that is, a 337 listener not restricted by source. It then has a 16-byte (128-bit) 338 IPv6 Group Address followed by 16-byte source IPv6 addresses. If 339 the number of sources do not fit in a single sub-TLV, it is 340 permitted to have the same group address repeated with different 341 source addresses in another sub-TLV of another instance of the 342 Group Address TLV. 344 The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV. 346 2.1.4 Group Labeled MAC Address Sub-TLV 348 The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in 349 Section 2.1.1 provides for a VLAN-ID. The Group Labeled MAC Address 350 sub-TLV, below, extends this to a fine-grained label. 352 +-+-+-+-+-+-+-+-+ 353 |Type=GLMAC-ADDR| (1 byte) 354 +-+-+-+-+-+-+-+-+ 355 | Length | (1 byte) 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | RESV | Topology-ID | (2 bytes) 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Fine-Grained Label | (3 bytes) 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |Num Group Recs | (1 byte) 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | GROUP RECORDS (1) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | GROUP RECORDS (2) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | ................. | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | GROUP RECORDS (N) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 where each group record is of the following form with k=6: 374 +-+-+-+-+-+-+-+-+ 375 | Num of Sources| (1 byte) 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Group Address (k bytes) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Source 1 Address (k bytes) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Source 2 Address (k bytes) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | ..... | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Source M Address (k bytes) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 o Type: GADDR sub-TLV Type, set to TBD [4 suggested] (GLMAC-ADDR). 390 o Length: 6 + m + k*n = 6 + m + 6*n where m is the number of group 391 records and n is the sum of the number of group and source 392 addresses. 394 o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored 395 on receipt. 397 o Topology-ID: This field carries a topology ID [RFC5120] or zero if 398 topologies are not in use. 400 o Label: This carries the fine-grained label identifier for all 401 subsequent MAC addresses in this sub-TLV, or the value zero if no 402 label is specified. 404 o Number of Group Records: A 1-byte unsigned integer that is the 405 number of group records in this sub-TLV. 407 o Group Record: Each group record carries the number of sources. If 408 this field is zero, it indicates a listener for (*,G), that is, a 409 listener not restricted by source. It then has a 6-byte (48-bit) 410 multicast address followed by 6-byte source MAC addresses. If the 411 sources do not fit in a single sub-TLV, the same group address may 412 be repeated with different source addresses in another sub-TLV of 413 another instance of the Group Address TLV. 415 The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV. 417 2.1.5 Group Labeled IPv4 Address Sub-TLV 419 The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV 420 type TBD [5 suggested] within the GADDR TLV. It has the same format 421 as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 422 except that k=4. The fields are as follows: 424 o Type: sub-TLV Type, set to TBD [5 suggested] (GLIP-ADDR). 426 o Length: 6 + m + k*n = 6 + m + 4*n where m is the number of group 427 records and n is the sum of the number of group and source 428 addresses. 430 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 431 topologies are not in use. 433 o RESV: Must be sent as zero on transmission and is ignored on 434 receipt. 436 o Label: This carries the fine-grained label identifier for all 437 subsequent IPv4 addresses in this sub-TLV, or the value zero if no 438 label is specified. 440 o Number of Group Records: This is of length 1 byte and lists the 441 number of group records in this sub-TLV. 443 o Group Record: Each group record carries the number of sources. If 444 this field is zero, it indicates a listener for (*,G), that is, a 445 listener not restricted by source. It then has a 4-byte (32-bit) 446 IPv4 Group Address followed by 4-byte source IPv4 addresses. If 447 the number of sources do not fit in a single sub-TLV, it is 448 permitted to have the same group address repeated with different 449 source addresses in another sub-TLV of another instance of the 450 Group Address TLV. 452 The GLIP-ADDR sub-TLV is carried only within a GADDR TLV. 454 2.1.6 Group Labeled IPv6 Address Sub-TLV 456 The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV 457 type TBD [6 suggested] within the GADDR TLV. It has the same format 458 as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 459 except that k=16. The fields are as follows: 461 o Type: sub-TLV Type, set to TBD [6 suggested] (GLIPV6-ADDR). 463 o Length: 6 + m + k*n = 6 + m + 16*n where m is the number of group 464 records and n is the sum of the number of group and source 465 addresses. 467 o Topology-Id: This field carries a topology ID [RFC5120] or zero if 468 topologies are not in use. 470 o RESV: Must be sent as zero on transmission and is ignored on 471 receipt. 473 o Label: This carries the fine-grained label identifier for all 474 subsequent IPv6 addresses in this sub-TLV, or the value zero if no 475 label is specified. 477 o Number of Group Records: This of length 1 byte and lists the 478 number of group records in this sub-TLV. 480 o Group Record: Each group record carries the number of sources. If 481 this field is zero, it indicates a listener for (*,G), that is, a 482 listener not restricted by source. It then has a 16-byte (128-bit) 483 IPv6 Group Address followed by 16-byte source IPv6 addresses. If 484 the number of sources do not fit in a single sub-TLV, it is 485 permitted to have the same group address repeated with different 486 source addresses in another sub-TLV of another instance of the 487 Group Address TLV. 489 The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV. 491 2.2 Multi-Topology-Aware Port Capability Sub-TLVs 493 TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT- 494 CAP) TLV as specified in [RFC6165]. The following subsections of 495 this Section 2.2 specify the sub-TLVs transported by the MT-PORT-CAP 496 TLV for TRILL. 498 2.2.1 Special VLANs and Flags Sub-TLV 500 In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried 501 in every IIH PDU. It has the following format: 503 +-+-+-+-+-+-+-+-+ 504 | Type | (1 byte) 505 +-+-+-+-+-+-+-+-+ 506 | Length | (1 byte) 507 +---------------+---------------+ 508 | Port ID | (2 bytes) 509 +-------------------------------+ 510 | Sender Nickname | (2 bytes) 511 +--+--+--+--+-------------------+ 512 |AF|AC|VM|BY| Outer.VLAN | (2 bytes) 513 +--+--+--+--+-------------------+ 514 |TR|R |R |R | Desig.VLAN | (2 bytes) 515 +--+--+--+--+-------------------+ 517 o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1. 519 o Length: 8. 521 o Port ID: An ID for the port on which the enclosing TRILL IIH 522 PDU is being sent as specified in [RFC6325], Section 4.4.2. 524 o Sender Nickname: If the sending IS is holding any nicknames as 525 discussed in [RFC6325], Section 3.7, one MUST be included here. 526 Otherwise, the field is set to zero. This field is to support 527 intelligent end stations that determine the egress IS (RBridge) 528 for unicast data through a directory service or the like and 529 that need a nickname for their first hop to insert as the 530 ingress nickname to correctly format a TRILL Data frame (see 531 [RFC6325], Section 4.6.2, point 8). It is also referenced in 532 connection with the VLANs Appointed Sub-TLV (see Section 533 2.2.5). 535 o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH 536 frame containing this sub-TLV, as specified in [RFC6325], 537 Section 4.4.5. 539 o Desig.VLAN: The 12-bit ID of the Designated VLAN for the link, 540 as specified in [RFC6325], Section 4.2.4.2. 542 o AF, AC, VM, BY, and TR: These flag bits have the following 543 meanings when set to one, as specified in the listed section of 544 [RFC6325]: 546 RFC 6325 547 Bit Section Meaning if bit is one 548 -------------------------------------- 550 AF 4.4.2 Originating IS believes it is appointed 551 forwarder for the VLAN and port on which the 552 containing IIH PDU was sent. 554 AC 4.9.1 Originating port configured as an access port 555 (TRILL traffic disabled). 557 VM 4.4.5 VLAN mapping detected on this link. 559 BY 4.4.2 Bypass pseudonode. 561 TR 4.9.1 Originating port configured as a trunk port 562 (end-station service disabled). 564 o R: Reserved bit. MUST be sent as zero and ignored on receipt. 566 2.2.2 Enabled-VLANs Sub-TLV 568 The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the 569 port of the originating IS on which the containing Hello was sent, as 570 specified in [RFC6325], Section 4.4.2. It has the following format: 572 +-+-+-+-+-+-+-+-+ 573 | Type | (1 byte) 574 +-+-+-+-+-+-+-+-+ 575 | Length | (1 byte) 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | RESV | Start VLAN ID | (2 bytes) 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | VLAN bit-map.... 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 o Type: sub-TLV type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2. 584 o Length: Variable, minimum 3. 586 o RESV: 4 reserved bits that MUST be sent as zero and ignored on 587 receipt. 589 o Start VLAN ID: The 12-bit VLAN ID that is represented by the high 590 order bit of the first byte of the VLAN bit-map. 592 o VLAN bit-map: The highest order bit indicates the VLAN equal to 593 the start VLAN ID, the next highest bit indicates the VLAN equal 594 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 595 field. 597 If this sub-TLV occurs more than once in a Hello, the set of enabled 598 VLANs is the union of the sets of VLANs indicated by each of the 599 Enabled-VLAN sub-TLVs in the Hello. 601 2.2.3 Appointed Forwarders Sub-TLV 603 The DRB on a link uses the Appointed Forwarders sub-TLV to inform 604 other ISs on the link that they are the designated VLAN-x forwarder 605 for one or more ranges of VLAN IDs as specified in [RFC6439]. It has 606 the following format: 608 +-+-+-+-+-+-+-+-+ 609 | Type | (1 byte) 610 +-+-+-+-+-+-+-+-+ 611 | Length | (1 byte) 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Appointment Information (1) | (6 bytes) 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Appointment Information (2) | (6 bytes) 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ................. | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Appointment Information (N) | (6 bytes) 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 where each appointment is of the form: 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Appointee Nickname | (2 bytes) 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | RESV | Start.VLAN | (2 bytes) 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | RESV | End.VLAN | (2 bytes) 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 o Type: sub-TLV type, set to MT-PORT-CAP AppointedFwrdrs sub-TLV 3. 634 o Length: 6*n bytes, where there are n appointments. 636 o Appointee Nickname: The nickname of the IS being appointed a 637 forwarder. 639 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 641 o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 642 appointment range, inclusive. To specify a single VLAN, the VLAN's 643 ID appears as both the start and end VLAN. As specified in 644 [RFC6439], appointing an IS forwarder on a port for a VLAN not 645 enabled on that port has no effect. If the range specified is or 646 includes the value 0x000 or 0xFFF, such values are ignored as they 647 are not valid VLAN numbers and a port cannot be enabled for them. 649 An IS's nickname may occur as appointed forwarder for multiple VLAN 650 ranges by occurrences of this sub-TLV within the same or different MT 651 Port Capability TLVs within an IIH PDU. See [RFC6439]. 653 2.2.4 Port TRILL Version Sub-TLV 655 The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum 656 version of the TRILL standard supported and the support of optional 657 hop-by-hop capabilities. By implication, lower versions are also 658 supported. If this sub-TLV is missing from an IIH, it is assumed that 659 the originating IS only supports the base version (version zero) of 660 the protocol [RFC6325] and supports no optional capabilities 661 indicated by this sub-TLV. 663 +-+-+-+-+-+-+-+-+ 664 | Type | (1 byte) 665 +-+-+-+-+-+-+-+-+ 666 | Length | (1 byte) 667 +-+-+-+-+-+-+-+-+ 668 | Max-version | (1 byte) 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 670 | Capabilities and Header Flags Supported | (4 bytes) 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 672 0 1 3 673 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 675 o Type: MT-PORT-CAP sub-TLV type, set to TBD [7 suggested] (PORT- 676 TRILL-VER). 678 o Length: 5. 680 o Max-version: A one byte unsigned integer set to maximum version 681 supported. 683 o Capabilities and Header Flags Supported: A bit vector of 32 bits 684 numbered 0 through 31 in network order. Bits 3 through 13 indicate 685 that the corresponding TRILL Header hop-by-hop extended flags 686 [ExtendHeader] are supported. Bits 0 through 2 and 14 to 31 are 687 reserved to indicate support of optional capabilities. A one bit 688 indicates that the flag or capability is supported by the sending 689 IS. Bits in this field MUST be set to zero except as permitted for 690 a capability being advertised or if a hop-by-hop extended header 691 flag is supported. 693 This sub-TLV, if present, MUST occur in an MT-PORT-CAP TLV in a TRILL 694 IIH. If there is more than one occurrence, the minimum of the 695 supported versions is assumed to be correct and a capability or 696 header flag is assumed to be supported only if indicated by all 697 occurrences. The flags and capabilities for which support can be 698 indicated in this sub-TLV are disjoint from those in the TRILL-VER 699 sub-TLV (Section 2.3.1) so they cannot conflict. The flags and 700 capabilities indicated in this sub-TLV relate to hop-by-hop 701 processing that can differ between the ports of an IS (RBridge), and 702 thus must be advertised in IIHs. For example, a capability requiring 703 cryptographic hardware assist might be supported on some ports and 704 not others. However, the TRILL version is the same as that in the 705 PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of 706 TRILL version sub-TLV(s) uses the TRILL version it received in PORT- 707 TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- 708 TLV(s). 710 2.2.5 VLANs Appointed Sub-TLV 712 The optional VLANs sub-TLV specifies the VLANs for which the port of 713 the originating IS on which the containing Hello was sent is 714 appointed forwarder. It has the following format: 716 +-+-+-+-+-+-+-+-+ 717 | Type | (1 byte) 718 +-+-+-+-+-+-+-+-+ 719 | Length | (1 byte) 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | RESV | Start VLAN ID | (2 bytes) 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | VLAN bit-map.... 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 o Type: sub-TLV type, set to MT-PORT-CAP VLANS-Appointed sub-TLV TBD 727 [8 suggested]. 729 o Length: Variable, minimum 3. 731 o RESV: 4 reserved bits that MUST be sent as zero and ignored on 732 receipt. 734 o Start VLAN ID: The 12-bit VLAN ID that is represented by the high 735 order bit of the first byte of the VLAN bit-map. 737 o VLAN bit-map: The highest order bit indicates the VLAN equal to 738 the start VLAN ID, the next highest bit indicates the VLAN equal 739 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 740 field. 742 If this sub-TLV occurs more than once in a Hello, the originating IS 743 is declaring it believes itself to be appointed forwarder on the port 744 on which the enclosing IIH was sent for the union of the sets of 745 VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello. 747 2.3 Sub-TLVs of the Router and MT Capability TLVs 749 The Router Capability TLV is specified in [RFC4971] and the MT 750 Capability TLV in [RFC6329]. All of the sub-sections of this Section 751 2.3 below specify sub-TLVs that can be carried in the Router 752 Capability TLV (#242) and the MT (multi-topology) Capability TLV 753 (#144) with the same sub-TLV number for both TLVs. These TLVs are in 754 turn carried only by LSPs. 756 2.3.1 TRILL Version Sub-TLV 758 The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version 759 of the TRILL standard supported and the support of optional 760 capabilities by the originating IS. By implication, lower versions 761 are also supported. If this sub-TLV is missing, it is assumed that 762 the originating IS only supports the base version (version zero) of 763 the protocol [RFC6325] and no optional capabilities indicated by this 764 sub-TLV are supported. 766 +-+-+-+-+-+-+-+-+ 767 | Type | (1 byte) 768 +-+-+-+-+-+-+-+-+ 769 | Length | (1 byte) 770 +-+-+-+-+-+-+-+-+ 771 | Max-version | (1 byte) 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 773 | Capabilities and Header Flags Supported | (4 bytes) 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 775 0 1 3 776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 778 o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). 780 o Length: 5. 782 o Max-version: A one byte unsigned integer set to maximum version 783 supported. 785 o Capabilities and Header Flags Supported: A bit vector of 32 bits 786 numbered 0 through 31 in network order. Bits 14 through 31 787 indicate that the corresponding TRILL Header extended flags 788 [ExtendHeader] are supported. Bits 0 through 13 are reserved to 789 indicate support of optional capabilities. A one bit indicates 790 that the originating IS supports the flag or capability. For 791 example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in 792 this field MUST be set to zero except as permitted for a 793 capability being advertised or an extended header flag supported. 795 This sub-TLV, if present, MUST occur in a Router Capabilities TLV in 796 the LSP number zero for the originating IS. If found in other 797 fragments, it is ignored. If there is more than one occurrence in LSP 798 number zero, the minimum of the supported versions is assumed to be 799 correct and an extended header flag or capability is assumed to be 800 supported only if indicated by all occurrences. The flags and 801 capabilities supported bits in this sub-TLV are disjoint from those 802 in the PORT-TRILL-VER sub-TLV (Section 2.2.4) so they cannot 803 conflict. However, the TRILL version is the same as that in the PORT- 804 TRILL-VER sub-TLV and an IS that is adjacent to the originating IS of 805 TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT- 806 TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- 807 TLV(s). 809 For multi-topology aware TRILL switches, the TRILL version and 810 capabilities announced for the base topology are assumed to apply to 811 all topologies for which a separate TRILL version announcement does 812 not occur. Such announcements for non-zero topologies need not occur 813 in fragment zero. 815 2.3.2 Nickname Sub-TLV 817 The Nickname (NICKNAME) Router Capability sub-TLV carries information 818 about the nicknames of the originating IS, along with information 819 about its priority to hold those nicknames as specified in [RFC6325], 820 Section 3.7.3. Multiple instances of this sub-TLV may occur. 822 +-+-+-+-+-+-+-+-+ 823 |Type = NICKNAME| (1 byte) 824 +-+-+-+-+-+-+-+-+ 825 | Length | (1 byte) 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | NICKNAME RECORDS (1) | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | NICKNAME RECORDS (2) | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | ................. | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | NICKNAME RECORDS (N) | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 where each nickname record is of the form: 838 +-+-+-+-+-+-+-+-+ 839 | Nickname.Pri | (1 byte) 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Tree Root Priority | (2 byte) 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Nickname | (2 bytes) 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 o Type: Router and MT Capability sub-TLV type, set to 6 (NICKNAME). 848 o Length: 5*n, where n is the number of nickname records present. 850 o Nickname.Pri: An 8-bit unsigned integer priority to hold a 851 nickname as specified in Section 3.7.3 of [RFC6325]. 853 o Tree Root Priority: This is an unsigned 16-bit integer priority to 854 be a tree root as specified in Section 4.5 of [RFC6325]. 856 o Nickname: This is an unsigned 16-bit integer as specified in 857 Section 3.7 of [RFC6325]. 859 2.3.3 Trees Sub-TLV 861 Each IS providing TRILL service uses the TREES sub-TLV to announce 862 three numbers related to the computation of distribution trees as 863 specified in Section 4.5 of [RFC6325]. Its format is as follows: 865 +-+-+-+-+-+-+-+-+ 866 |Type = TREES | (1 byte) 867 +-+-+-+-+-+-+-+-+ 868 | Length | (1 byte) 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Number of trees to compute | (2 byte) 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Maximum trees able to compute | (2 byte) 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Number of trees to use | (2 byte) 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 o Type: Router and MT Capability sub-TLV type, set to 7 (TREES). 879 o Length: 6. 881 o Number of trees to compute: An unsigned 16-bit integer as 882 specified in Section 4.5 of [RFC6325]. 884 o Maximum trees able to compute: An unsigned 16-bit integer as 885 specified in Section 4.5 of [RFC6325]. 887 o Number of trees to use: An unsigned 16-bit integer as specified in 888 Section 4.5 of [RFC6325]. 890 2.3.4 Tree Identifiers Sub-TLV 892 The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of 893 nicknames. When originated by the IS that has the highest priority to 894 be a tree root, it lists the distribution trees that the other ISs 895 are required to compute as specified in Section 4.5 of [RFC6325]. If 896 this information is spread across multiple sub-TLVs, the starting 897 tree number is used to allow the ordered lists to be correctly 898 concatenated. The sub-TLV format is as follows: 900 +-+-+-+-+-+-+-+-+ 901 |Type=TREE-RT-IDs| (1 byte) 902 +-+-+-+-+-+-+-+-+ 903 | Length | (1 byte) 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 |Starting Tree Number | (2 bytes) 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Nickname (K-th root) | (2 bytes) 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Nickname (K+1 - th root) | (2 bytes) 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Nickname (...) | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 o Type: Router and MT Capability sub-TLV type, set to 8 (TREE-RT- 915 IDs). 917 o Length: 2 + 2*n, where n is the number of nicknames listed. 919 o Starting Tree Number: This identifies the starting tree number of 920 the nicknames that are trees for the domain. This is set to 1 for 921 the sub-TLV containing the first list. Other Tree-Identifiers sub- 922 TLVs will have the number of the starting list they contain. In 923 the event the same tree identifier can be computed from two such 924 sub-TLVs and they are different, then it is assumed that this is a 925 transient condition that will get cleared. During this transient 926 time, such a tree SHOULD NOT be computed unless such computation 927 is indicated by all relevant sub-TLVs present. 929 o Nickname: The nickname at which a distribution tree is rooted. 931 2.3.5 Trees Used Identifiers Sub-TLV 933 This Router Capability sub-TLV has the same structure as the Tree 934 Identifiers sub-TLV specified in Section 2.3.4. The only difference 935 is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees 936 listed are those that the originating IS wishes to use as specified 937 in [RFC6325], Section 4.5. 939 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV 941 The value of this sub-TLV consists of a VLAN range and information in 942 common to all of the VLANs in the range for the originating IS. This 943 information consists of flags, a variable length list of spanning 944 tree root bridge IDs, and an appointed forwarder status lost counter, 945 all as specified in the sections of [RFC6325] listed with the 946 respective information items below. 948 In the set of LSPs originated by an IS, the union of the VLAN ranges 949 in all occurrences of this sub-TLV MUST be the set of VLANs for which 950 the originating IS is appointed forwarder on at least one port, and 951 the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap 952 unless the information provided about a VLAN is the same in every 953 instance. However, as a transient state these conditions may be 954 violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, 955 that IS is assumed to be uninterested in receiving traffic for that 956 VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS 957 with different information in the different instances, the following 958 apply: 960 - If those sub-TLVs provide different nicknames, it is unspecified 961 which nickname takes precedence. 962 - The largest appointed forwarder status lost counter, using serial 963 number arithmetic [RFC1982], is used. 964 - The originating IS is assumed to be attached to a multicast IPv4 965 router for that VLAN if any of the INT-VLAN sub-TLVs assert that 966 it is so connected and similarly for IPv6 multicast router 967 attachment. 968 - The root bridge lists from all of the instances of the VLAN for 969 the originating IS are merged. 971 To minimize such occurrences, wherever possible, an implementation 972 SHOULD advertise the update to an interested VLAN and Spanning Tree 973 Roots sub-TLV in the same LSP fragment as the advertisement that it 974 replaces. Where this is not possible, the two affected LSP fragments 975 should be flooded as an atomic action. An IS that receives an update 976 to an existing interested VLAN and Spanning Tree Roots sub-TLV can 977 minimize the potential disruption associated with the update by 978 employing a hold-down timer prior to processing the update so as to 979 allow for the receipt of multiple LSP fragments associated with the 980 same update prior to beginning processing. 982 The sub-TLV layout is as follows: 984 +-+-+-+-+-+-+-+-+ 985 |Type = INT-VLAN| (1 byte) 986 +-+-+-+-+-+-+-+-+ 987 | Length | (1 byte) 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Nickname | (2 bytes) 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ 991 | Interested VLANS | (4 bytes) 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ 993 | Appointed Forwarder Status Lost Counter | (4 bytes) 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+ 995 | Root Bridges | (6*n bytes) 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 998 o Type: Router and MT Capability sub-TLV type, set to 10 (INT-VLAN). 1000 o Length: 10 + 6*n, where n is the number of root bridge IDs. 1002 o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field 1003 may be used to associate a nickname held by the originating IS 1004 with the VLAN range indicated. When not used in this way, it is 1005 set to zero. 1007 o Interested VLANS: The Interested VLANs field is formatted as shown 1008 below. 1010 0 1 2 3 4 - 15 16 - 19 20 - 31 1011 +----+----+----+----+------------+----------+------------+ 1012 | M4 | M6 | R | R | VLAN.start | RESV | VLAN.end | 1013 +----+----+----+----+------------+----------+------------+ 1015 - M4, M6: These bits indicate, respectively, that there is an 1016 IPv4 or IPv6 multicast router on a link for which the 1017 originating IS is appointed forwarder for every VLAN in the 1018 indicated range as specified in [RFC6325], Section 4.2.4.4, 1019 item 5.1. 1021 - R, RESV: These reserved bits MUST be sent as zero and are 1022 ignored on receipt. 1024 - VLAN.start and VLAN.end: This VLAN ID range is inclusive. 1025 Setting both VLAN.start and VLAN.end to the same value 1026 indicates a range of one VLAN ID. If VLAN.start is not equal to 1027 VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as 1028 if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end 1029 and VLAN.end is 0xFFF, the sub-TVL is interpreted as if 1030 VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the 1031 sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 1032 or both are 0xFFF, the sub-TLV is ignored. 1034 o Appointed Forwarder Status Lost Counter: This is a count of how 1035 many times a port that was appointed forwarder for the VLANs in 1036 the range given has lost the status of being an appointed 1037 forwarder for some port as discussed in Section 4.8.3 of 1038 [RFC6325]. It is initialized to zero at an IS when the zeroth LSP 1039 sequence number is initialized. No special action need be taken at 1040 rollover; the counter just wraps around. 1042 o Root Bridges: The list of zero or more spanning tree root bridge 1043 IDs is the set of root bridge IDs seen for all ports for which the 1044 IS is appointed forwarder for the VLANs in the specified range as 1045 discussed in [RFC6325], Section 4.9.3.2. While, of course, at most 1046 one spanning tree root could be seen on any particular port, there 1047 may be multiple ports in the same VLANs connected to different 1048 bridged LANs with different spanning tree roots. 1050 An INT-VLAN sub-TLV asserts that the information provided (multicast 1051 router attachment, appointed forwarder status lost counter, and root 1052 bridges) is the same for all VLANs in the range specified. If this is 1053 not the case, the range MUST be split into subranges meeting this 1054 criteria. It is always safe to use sub-TLVs with a "range" of one 1055 VLAN ID, but this may be too verbose. 1057 2.3.7 VLAN Group Sub-TLV 1059 The VLAN Group sub-TLV consists of two or more VLAN IDs as specified 1060 in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN 1061 learning is occurring at the originating IS between the listed VLANs. 1062 It is structured as follows: 1064 +-+-+-+-+-+-+-+-+ 1065 |Type=VLAN-GROUP| (1 byte) 1066 +-+-+-+-+-+-+-+-+ 1067 | Length | (1 byte) 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | RESV | Primary VLAN ID | (2 bytes) 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | RESV | Secondary VLAN ID | (2 bytes) 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | more Secondary VLAN IDs ... (2 bytes each) 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 o Type: Router and MT Capability sub-TLV type, set to 14 (VLAN- 1077 GROUP). 1079 o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields 1080 beyond the first. n MAY be zero. 1082 o RESV: a 4-bit field that MUST be sent as zero and ignored on 1083 receipt. 1085 o Primary VLAN ID: This identifies the primary VLAN ID. 1087 o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN 1088 Group. 1090 o more Secondary VLAN IDs: zero or more byte pairs, each with the 1091 top 4 bits as a RESV field and the low 12 bits as a VLAN ID. 1093 2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV 1095 An IS that can handle fine-grained labeling announces its fine- 1096 grained label connectivity and related information in the "Interested 1097 Labels and Bridge Spanning Tree Roots sub-TLV" (INT-LABEL) which is a 1098 variation of the "Interested VLANs and Spanning Tree Roots sub-TLV" 1099 (INT-VLAN) structured as below. 1101 +-+-+-+-+-+-+-+-+ 1102 |Type= INT-LABEL| (1 byte) 1103 +-+-+-+-+-+-+-+-+ 1104 | Length | (1 byte) 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Nickname | (2 bytes) 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 1108 | Interested Labels | (7 bytes) 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 1110 | Appointed Forwarder Status Lost Counter | (4 bytes) 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 1112 | Root Bridges | (6*n bytes) 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 1115 o Type: Router and MT Capability sub-TLV Type, set to TBD [15 1116 suggested] (INT-LABEL). 1118 o Length: 11 + 6*n where n is the number of root bridge IDs. 1120 o Nickname: This field may be used to associate a nickname held by 1121 the originating IS with the Labels indicated. When not used in 1122 this way, it is set to zero. 1124 o Interested Labels: The Interested Labels field is seven bytes long 1125 and formatted as shown below. 1127 0 1 2 3 4 5 6 7 1128 +--+--+--+--+--+--+--+--+ 1129 |M4|M6|BM| R| R| R| R| R| . . 1130 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Label.start - 24 bits | 1132 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Label.end or Bit Map - 24 bits | 1134 +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 0 1 2 1136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1138 - M4, M6: These bits indicate, respectively, that there is an 1139 IPv4 or IPv6 multicast router on a link to which the 1140 originating IS is appointed forwarder for the VLAN 1141 corresponding to every label in the indicated range. 1143 - BM: If the BM (Bit Map) bit is zero, the last three bytes of 1144 the Interested Labels is a Label.end label number. If the BM 1145 bit is one, those bytes are a bit map as described below. 1147 - R: These reserved bits MUST be sent as zero and are ignored on 1148 receipt. 1150 - Label.start and Label.end: If the BM bit is zero: This fine- 1151 grained label ID range is inclusive. These fields are treated 1152 as unsigned integers. Setting them both to that same label ID 1153 value indicates a range of one label ID. If Label.end is less 1154 than Label.start, the sub-TLV is ignored. 1156 - Label.start and Bit Map: If the BM bit is one: The fine-grained 1157 labels that the IS is interested in are indicated by a 24-bit 1158 bit map. The interested labels are the Label.start number plus 1159 the bit number of each one bit in the bit map. So, if bit zero 1160 of the bit map is a one, the IS in interested in the label with 1161 value Label.start and if bit 23 of the bit map is a one, the IS 1162 is interested in the label with value Label.start+23. 1164 o Appointed Forwarder Status Lost Counter: This is a count of how 1165 many times a port that was appointed forwarder for a VLAN mapping 1166 to the fine-grained label in the range or bit map given has lost 1167 the status of being an appointed forwarder as discussed in Section 1168 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the 1169 zeroth LSP sequence number is initialized. No special action need 1170 be taken at rollover; the counter just wraps around. 1172 o Root Bridges: The list of zero or more spanning tree root bridge 1173 IDs is the set of root bridge IDs seen for all ports for which the 1174 IS is appointed forwarder for a VLAN mapping to the fine-grained 1175 label in the specified range or bit map. (See [RFC6325], Section 1176 4.9.3.2.) While, of course, at most one spanning tree root could 1177 be seen on any particular port, there may be multiple relevant 1178 ports connected to different bridged LANs with different spanning 1179 tree roots. 1181 An INT-LABEL sub-TLV asserts that the information provided (multicast 1182 router attachment, appointed forwarder status lost counter, and root 1183 bridges) is the same for all labels specified. If this is not the 1184 case, the sub-TLV MUST be split into subranges and/or separate bit 1185 maps meeting this criteria. It is always safe to use sub-TLVs with a 1186 "range" of one VLAN ID, but this may be too verbose. 1188 2.3.9 RBridge Channel Protocols Sub-TLV 1190 An IS announces the RBridge Channel protocols [Channel] it supports 1191 through use of this sub-TLV. 1193 +-+-+-+-+-+-+-+-+ 1194 |Type=RBCHANNELS| (1 byte) 1195 +-+-+-+-+-+-+-+-+ 1196 | Length | (1 byte) 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1198 | Zero or more bit vectors (variable) 1199 +-+-+-+-... 1201 o Type: Router and MT Capabilities RBridge Channel Protocols sub- 1202 TLV, set to TBD [16 suggested] (RBCHANNELS). 1204 o Length: variable. 1206 o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit 1207 indicates support of a particular RBridge Channel protocol. Each 1208 byte-aligned bit vector is formatted as follows: 1210 | 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15| 1211 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1212 | Bit Vector Length | Bit Vector Offset | 1213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1214 | bits 1215 +--+--+--... 1217 The bit vector length (BVL) is a seven bit unsigned integer field 1218 giving the number of bytes of bit vector. The bit vector offset (BVO) 1219 is a nine bit unsigned integer field. 1221 The bits in each bit vector are numbered in network order, the high 1222 order bit of the first byte of bits being bit 0 + 8*BVO, the low 1223 order bit of that byte being 7 + 8*BVO, the high order bit of the 1224 second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge 1225 Channel protocols-supported bit vector MUST NOT extend beyond the end 1226 of the value in the sub-TLV in which it occurs. If it does, it is 1227 ignored. If multiple byte-aligned bit vectors are present in one such 1228 sub-TLV, their representations are contiguous, the BVL field for the 1229 next starting immediately after the last byte of bits for the 1230 previous bit vector. The one or more bit vectors present MUST exactly 1231 fill the sub-TLV value. If there are one or two bytes of value left 1232 over, they are ignored; if more than two, an attempt is made to parse 1233 them as one or more bit vectors. 1235 If different bit vectors overlap in the protocol number space they 1236 refer to and they have inconsistent bit values for a channel 1237 protocol, support for the protocol is assumed if any of these bit 1238 vectors has a 1 for that protocol. 1240 The absence of any occurrences of this sub-TLV in the LSP for an IS 1241 implies that that IS does not support the RBridge Channel facility. 1243 To avoid wasted space, trailing bit vector zero bytes SHOULD be 1244 eliminated by reducing BVL, any null bit vectors (ones with BVL equal 1245 to zero) eliminated, and generally the most compact encoding used. 1246 For example, support for channel protocols 1 and 32 could be encoded 1247 as 1249 BVL = 5 1250 BVO = 0 1251 0b01000000 1252 0b00000000 1253 0b00000000 1254 0b00000000 1255 0b10000000 1257 or as 1259 BVL = 1 1260 BVO = 0 1261 0b01000000 1262 BLV = 1 1263 BVO = 4 1264 0b1000000 1266 The first takes 7 bytes while the second takes only 6 and thus the 1267 second would be preferred. 1269 In multi-topology aware RBridges, RBridge channel protocols for which 1270 support is announced in the base topology are assumed to be supported 1271 in all topologies for which there is no separate RBridge channel 1272 protocol support announcement. 1274 2.3.10 Affinity Sub-TLV 1276 Association of an IS to a multi-destination distribution tree through 1277 a specific path is accomplished by using the tree Affinity sub-TLV. 1278 The announcement of an Affinity sub-TLV by RB1 with the nickname of 1279 RB2 as the first part of an Affinity Record in the sub-TLV value is a 1280 request by RB1 that all ISes in the campus connect RB2 as a child of 1281 RB1 when calculating any of the trees listed in that Affinity Record. 1282 Examples of use include [Affinity] and [Resilient]. 1284 The structure of the AFFINITY sub-TLV is shown below. 1286 +-+-+-+-+-+-+-+-+ 1287 | Type=AFFINITY | (1 byte) 1288 +-+-+-+-+-+-+-+-+ 1289 | Length | (1 byte) 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | AFFINITY RECORD 1 | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | AFFINITY RECORD 2 | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | .......... 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | AFFINITY RECORD N | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 Where each AFFINITY RECORD is structured as follows: 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Nickname | (2 bytes) 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 |Affinity Flags | (1 byte 1306 +-+-+-+-+-+-+-+-+ 1307 |Number of trees| (1 byte) 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Tree-num of 1st root | (2 bytes) 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Tree-num of 2nd root | (2 bytes) 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | .......... | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Tree-num of Nth root | (2 bytes) 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 o Type: Router and MT Capability sub-TLV type, set to TBD [17 1319 suggested] (AFFINITY). 1321 o Length: 1 + size of all Affinity Records included, where an 1322 Affinity Record listing n tree roots is 3+2*n bytes long. 1324 o Nickname: 16-bit nickname of the IS whose associations to the 1325 multi-destination trees listed in the Affinity Record are through 1326 the originating IS. 1328 o Affinity Flags: 8 bits reserved for future needs to provide 1329 additional information about the affinity being announced. MUST be 1330 sent as zero and ignored on receipt. 1332 o Number of trees: A one byte unsigned integer giving the number of 1333 trees for which affinity is being announced by this Affinity 1334 Record. 1336 o Tree-num of roots: The tree numbers of the distribution trees this 1337 Affinity Record is announcing. 1339 There is no need for a field giving the number of Affinity Records as 1340 this can be determined by processing those records. 1342 2.3.11 Label Group Sub-TLV 1344 The Label Group sub-TLV consists of two or more Label IDs. This sub- 1345 TLV indicates that shared Label MAC address learning is occurring at 1346 the announcing IS between the listed Labels. It is structured as 1347 follows: 1349 +-+-+-+-+-+-+-+-+ 1350 |Typ=LABEL-GROUP| (1 byte) 1351 +-+-+-+-+-+-+-+-+ 1352 | Length | (1 byte) 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Primary Label ID | (3 bytes) 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Secondary Label ID | (3 bytes) 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | more Secondary Label IDs ... (3 bytes each) 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 o Type: Router and MT Capability sub-TLV type, set to TBD [18 1362 suggested] (LABEL-GROUP). 1364 o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields 1365 beyond the first. n MAY be zero. 1367 o Primary Label ID: This identifies the primary Label ID. 1369 o Secondary Label ID: This identifies a secondary Label in the Label 1370 Group. 1372 o more Secondary Label IDs: zero or more byte triples, each with a 1373 Label ID. 1375 2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs 1377 The MTU sub-TLV is used to optionally announce the MTU of a link as 1378 specified in [RFC6325], Section 4.2.4.4. It occurs within the 1379 Extended Reachability (#22) and MT (multi-topology) ISN (Intermediate 1380 System Neighbors) (#222) TLVs. 1382 +-+-+-+-+-+-+-+-+ 1383 | Type = MTU | (1 byte) 1384 +-+-+-+-+-+-+-+-+ 1385 | Length | (1 byte) 1386 +-+-+-+-+-+-+-+-+ 1387 |F| RESV | (1 byte) 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | MTU | (2 bytes) 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 o Type: Extended Reachability and MT IS sub-TLV type, set to MTU 1393 sub-TLV 28. 1395 o Length: 3. 1397 o F: Failed. This bit is a one if MTU testing failed on this link at 1398 the required campus-wide MTU. 1400 o RESV: 7 bits that MUST be sent as zero and ignored on receipt. 1402 o MTU: This field is set to the largest successfully tested MTU size 1403 for this link, or zero if it has not been tested, as specified in 1404 Section 4.3.2 of [RFC6325]. 1406 2.5 TRILL Neighbor TLV 1408 The TRILL Neighbor TLV is used in TRILL IIH PDUs (see Section 4.1 1409 below) in place of the IS Neighbor TLV, as specified in Section 1410 4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the TRILL 1411 Neighbor TLV is as follows: 1413 +-+-+-+-+-+-+-+-+ 1414 | Type | (1 byte) 1415 +-+-+-+-+-+-+-+-+ 1416 | Length | (1 byte) 1417 +-+-+-+-+-+-+-+-+ 1418 |S|L|R| SIZE | (1 byte) 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Neighbor RECORDS (1) | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Neighbor RECORDS (2) | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | ................. | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | Neighbor RECORDS (N) | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 The information present for each neighbor is as follows: 1431 +-+-+-+-+-+-+-+-+ 1432 |F|O| RESV | (1 bytes) 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | MTU | (2 bytes) 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ 1436 | SNPA (MAC Address) | (SIZE bytes) 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ 1439 o Type: TLV Type, set to TRILL Neighbor TLV 145. 1441 o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records, 1442 which may be zero. 1444 o S: Smallest flag. If this bit is a one, then the list of neighbors 1445 includes the neighbor with the smallest MAC address considered as 1446 an unsigned integer. 1448 o L: Largest flag. If this bit is a one, then the list of neighbors 1449 includes the neighbor with the largest MAC address considered as 1450 an unsigned integer. 1452 o R, RESV: These bits are reserved and MUST be sent as zero and 1453 ignored on receipt. 1455 o SIZE: The SNPA size as an unsigned integer in bytes except that 6 1456 is encoded as zero. An actual size of zero is meaningless and 1457 cannot be encoded. The meaning of the value 6 in this field is 1458 reserved and TRILL Neighbor TLVs received with a SIZE of 6 are 1459 ignored. The SIZE is inherent to the technology of a link and is 1460 fixed for all TRILL Neighbor TLVs on that link but may vary 1461 between different links in the campus if those links are different 1462 technologies. For example, 6 for EUI-48 SNPAs or 8 for EUI-64 1463 SNPAs [RFC5342]. (The SNPA size on the various links in a TRILL 1464 campus is independent of the System ID size.) 1466 o F: failed. This bit is a one if MTU testing to this neighbor 1467 failed at the required campus-wide MTU (see [RFC6325], Section 1468 4.3.1). 1470 o O: OOMF. This bit is a one if the IS sending the enclosing TRILL 1471 Neighbor TLV is willing to offer the Overload Originated Multi- 1472 destination Frame (OOMF) service [ClearCorrect] to the IS whose 1473 port has the SNPA in the enclosing Neighbor RECORD. 1475 o MTU: This field is set to the largest successfully tested MTU size 1476 for this neighbor or to zero if it has not been tested. 1478 o SNPA: Sub-Network Point of Attachment (MAC address) of the 1479 neighbor. 1481 As specified in [RFC6327] and Section 4.4.2.1 of [RFC6325], all MAC 1482 addresses may fit into one TLV, in which case both the S and L flags 1483 would be set to one in that TLV. If the MAC addresses don't fit into 1484 one TLV, the highest MAC address in a TRILL Neighbor TLV with the L 1485 flag zero MUST also appear as a MAC address in some other TRILL 1486 Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the 1487 lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST 1488 also appear in some other TRILL Neighbor TLV (possibly in a different 1489 TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a 1490 TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will 1491 have both the S and L bits on. 1493 3. MTU PDUs 1495 The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine 1496 the MTU on a link between ISs as specified in Section 4.3.2 of 1497 [RFC6325] and in [RFC6327]. 1499 The MTU PDUs have the IS-IS PDU common header (up through the Maximum 1500 Area Addresses byte) with PDU Type numbers as indicated in Section 5. 1501 They also have a common fixed MTU PDU header as shown below that is 8 1502 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes 1503 System IDs. 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | PDU Length | (2 bytes) 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1508 | Probe ID (6 bytes) | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1510 | Probe Source ID (ID Length bytes) | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1512 | Ack Source ID (ID Length bytes) | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 1515 As with other IS-IS PDUs, the PDU length gives the length of the 1516 entire IS-IS packet starting with and including the IS-IS common 1517 header. 1519 The Probe ID field is an opaque 48-bit quantity set by the IS issuing 1520 an MTU-probe and copied by the responding IS into the corresponding 1521 MTU-ack. For example, an IS creating an MTU-probe could compose this 1522 quantity from a port identifier and probe sequence number relative to 1523 that port. 1525 The Probe Source ID is set by an IS issuing an MTU-probe to its 1526 System ID and copied by the responding IS into the corresponding MTU- 1527 ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored 1528 on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to 1529 its System ID. The System ID length is usually 6 bytes but could be a 1530 different value as indicated by the ID Length field in the IS-IS PDU 1531 Header. 1533 The TLV area follows the MTU PDU header area. This area MAY contain 1534 an Authentication TLV and MUST be padded to the exact size being 1535 tested with the Padding TLV. Since the minimum size of the Padding 1536 TLV is 2 bytes, it would be impossible to pad to exact size if the 1537 total length of the required information bearing fixed fields and 1538 TLVs added up to 1 byte less than the desired length. However, the 1539 length of the fixed fields and substantive TLVs for MTU PDUs is 1540 expected to be quite small compared with their minimum length 1541 (minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this 1542 should not be a problem. 1544 4. Use of Existing PDUs and TLVs 1546 The sub-sections below provide details of TRILL use of existing PDUs 1547 and TLVs. 1549 4.1 TRILL IIH PDUs 1551 The TRILL IIH PDU is the variation of the LAN IIH PDU used by the 1552 TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and 1553 [RFC6327] specify the contents of the TRILL IIH and how its use in 1554 TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state 1555 machinery for TRILL neighbors is specified in detail in [RFC6327]. 1557 In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header 1558 are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses 1559 octet in the common header MUST be set to 0x01. 1561 The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored 1562 if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor 1563 TLV (see Section 2.5). 1565 4.2 Area Address 1567 TRILL uses a fixed zero Area Address as specified in [RFC6325], 1568 Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) 1569 as follows: 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | 0x01, Area Address Type | (1 byte) 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | 0x02, Length of Value | (1 byte) 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | 0x01, Length of Address | (1 byte) 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | 0x00, zero Area Address | (1 byte) 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 4.3 Protocols Supported 1583 NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL 1584 [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that 1585 value MUST appear in TRILL IIH PDUs and LSP number zero PDUs. 1587 4.4 Link State PDUs (LSPs) 1589 A number zero LSP MUST NOT be originated larger than 1470 bytes but a 1590 larger number zero LSP successfully received MUST be processed and 1591 forwarded normally. 1593 4.5 Originating LSP Buffer Size 1595 The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; 1596 however, if found in other LSP fragments, it is processed normally. 1597 Should there be more than one originatingLSPBufferSize TLV for an IS, 1598 the minimum size, but not less than 1470, is used. 1600 5. IANA Considerations 1602 This section give IANA Considerations for the TLVs, sub-TLVs, and 1603 PDUs specified herein. 1605 5.1 TLVs 1607 This document specifies two IS-IS TLV types -- namely, the Group 1608 Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type 1609 145). The PDUs in which these TLVs are permitted for TRILL are shown 1610 in the table below along with the section of this document where they 1611 are discussed. The final "NUMBER" column indicates the permitted 1612 number of occurrences of the TLV in their PDU, or set of PDUs in the 1613 case of LSP, which in these two cases is "*" indicating that the TLV 1614 MAY occur 0, 1, or more times. 1616 IANA has registered these two code points in the IANA IS-IS TLV 1617 registry (ignoring the "Section" and "NUMBER" columns, which are 1618 irrelevant to that registry). 1620 Section TLV IIH LSP SNP Purge NUMBER 1621 ======= === === === === ===== ====== 1622 GADDR-TLV 2.1 142 - X - - * 1623 TRILL Neighbor TLV 2.5 145 X - - - * 1625 5.2 sub-TLVs 1627 This document specifies a number of sub-TLVs. The TLVs in which these 1628 sub-TLVs occur are shown in the second table below along with the 1629 section of this document where they are discussed. The TLVs within 1630 which these sub-TLVs can occur are determined by the presence of an 1631 "X" in the relevant column and the column header as shown in the 1632 first table below. In some cases, the column header corresponds to 1633 two different TLVs in which the sub-TLV can occur. 1635 Column Head TLV RFCref TLV Name 1636 =========== ===== ======== ============== 1637 Grp. Adr. 142 This doc Group Address 1639 MT Port 143 6165 MT-PORT-CAP 1641 MT Cap. 242 4971 Router CAPABILITY 1642 144 6329 MT-Capability 1644 Ext. Reach 22 5305 Extended IS Reachability 1645 222 5120 MT ISN 1647 The final "NUMBER" column below indicates the permitted number of 1648 occurrences of the sub-TLV cumulatively within all occurrences of 1649 their TLV(s) in those TLVs' carrying PDU (or set of PDUs in the case 1650 of LSP), as follows: 1652 0-1 = MAY occur zero or one times. 1653 1 = MUST occur exactly once. If absent, the PDU is ignored. If it 1654 occurs more than once, results are unspecified. 1655 * = MAY occur 0, 1, or more times. 1657 The values in the "Section" and "NUMBER" columns are irrelevant to 1658 the IANA sub-registries. The numbers in square brackets are suggested 1659 values. 1661 sub- Grp. MT MT Ext. 1662 Name Section TLV# Adr. Port Cap. Reach NUMBER 1663 ================================================================ 1664 GMAC-ADDR 2.1.1 1 X - - - * 1665 GIP-ADDR 2.1.2 TBD[2] X - - - * 1666 GIPV6-ADDR 2.1.3 TBD[3] X - - - * 1667 GLMAC-ADDR 2.1.4 TBD[4] X - - - * 1668 GLIP-ADDR 2.1.5 TBD[5] X - - - * 1669 GLIPV6-ADDR 2.1.6 TBD[6] X - - - * 1670 VLAN-FLAGS 2.2.1 1 - X - - 1 1671 Enabled-VLANs 2.2.2 2 - X - - * 1672 AppointedFwrdrs 2.2.3 3 - X - - * 1673 PORT-TRILL-VER 2.2.4 TBD[7] - X - - 0-1 1674 VLANs-Appointed 2.2.5 TBD[8] - X - - * 1675 NICKNAME 2.3.2 6 - - X - * 1676 TREES 2.3.3 7 - - X - 0-1 1677 TREE-RT-IDs 2.3.4 8 - - X - * 1678 TREE-USE-IDs 2.3.5 9 - - X - * 1679 INT-VLAN 2.3.6 10 - - X - * 1680 TRILL-VER 2.3.1 13 - - X - 0-1 1681 VLAN-GROUP 2.3.7 14 - - X - * 1682 INT-LABEL 2.3.8 TBD[15] - - X - * 1683 RBCHANNELS 2.3.9 TBD[16] - - X - * 1684 AFFINITY 2.3.10 TBD[17] - - X - * 1685 LABEL-GROUP 2.3.11 TBD[18] - - X - * 1686 MTU 2.4 28 - - - X 0-1 1687 ================================================================ 1688 Name Section sub- Grp. MT MT Ext. NUMBER 1689 TLV# Adr. Port Cap. Reach 1691 5.3 PDUs 1693 The IS-IS PDUs registry remains as established in [RFC6326] except 1694 that the references to [RFC6326] are updated to reference this 1695 document. 1697 5.4 Reserved and Capability Bits 1699 Any reserved bits (R) or bits in reserved fields (RESV) or the 1700 capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which 1701 are specified herein as "MUST be sent as zero and ignored on receipt" 1702 or the like, are allocated based on IETF Review [RFC5226]. 1704 Two sub-registries are created within the TRILL Parameters Registry 1705 as follows: 1707 Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags 1708 Registration Procedures: IETF Review 1709 Reference: (This document) 1711 Bit Description Reference 1712 ===== ============= =========== 1713 0 Affinity sub-TLV support. [Affinity] 1714 1-13 Available 1715 14-31 Extended header flag support. [ExtendHeader] 1717 Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags 1718 Registration Procedures: IETF Review 1719 Reference: (This document) 1721 Bit Description Reference 1722 ===== ============= =========== 1723 0 Hello reduction support. [ClearCorrect] 1724 1-2 Available 1725 3-13 Hop-by-hop extended flag support. [ExtendHeader] 1726 14-31 Available 1728 5.5 TRILL Neighbor Record Flags 1730 A sub-registry is created within the TRILL Parameters Registry as 1731 follows: 1733 Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags 1734 Registration Procedures: Standards Action 1735 Reference: (This document) 1737 Bit Short Name Description Reference 1738 ============== ============= =========== 1739 0 Fail Failed MTU test. [RFC6325] 1740 1 OOMF Offering OOMF service. [ClearCorrect] 1741 2-7 - Available. 1743 6. Security Considerations 1745 For general TRILL protocol security considerations, see the TRILL 1746 base protocol standard [RFC6325]. 1748 This document raises no new security issues for IS-IS. IS-IS security 1749 may be used to secure the IS-IS messages discussed here. See 1750 [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, 1751 replays of Hello packets can create denial-of-service conditions; see 1752 [RFC6039] for details. These issues are similar in scope to those 1753 discussed in Section 6.2 of [RFC6325], and the same mitigations may 1754 apply. 1756 7. Change from RFC 6326 1758 Non-editorial changes from [RFC6326] are summarized in the list 1759 below: 1761 1. Additional of five sub-TLVs under the Group Address (GADDR) TLV 1762 covering VLAN labeled IPv4 and IPv6 addresses and fine-grained 1763 labeled MAC, IPv4, and IPv6 addresses. (Sections 2.1.2, 2.1.3, 1764 2.1.4, 2.1.5, and 2.1.6). 1766 2. Addition of the PORT-TRILL-VER sub-TLV. (Section 2.2.4) 1768 3. Addition of the VLANs-Appointed sub-TLV. (Section 2.2.5) 1770 4. Change the TRILL-VER sub-TLV as listed below. 1772 4.a Addition of 4 bytes of TRILL Header extended flags and 1773 capabilities supported information. 1775 4.b Require that the TRILL-VER sub-TLV appear in LSP number zero. 1777 The above changes to TRILL-VER are backwards compatible because 1778 the [RFC6326] conformant implementations of TRILL thus far have 1779 only supported version zero and not supported any optional 1780 capabilities or extended flags, the level of support indicated by 1781 the absence of the TRILL-VER sub-TLV. Thus, if an [RFC6326] 1782 conformant implementation of TRILL rejects this sub-TLV due to 1783 the changes specified in this document, it will, at worst, decide 1784 that support of version zero and no extended flags or 1785 capabilities is indicated, which is the best an [RFC6326] 1786 conformant implementation of TRILL can do anyway. Similarly, a 1787 TRILL implementation that supports TRILL-VER as specified herein 1788 and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL 1789 implementation because they are not in LSP number zero will 1790 decide that that implementation supports only version zero with 1791 no extended flag or capabilities support, which will be correct. 1792 (Section 2.3.1) 1794 5. Clarification of the use of invalid VLAN IDs in the Appointed 1795 Forwarders sub-TLV and the Interested VLANs and Spanning Tree 1796 Roots sub-TLV. (Sections 2.2.3 and 2.3.6) 1798 6. Addition of the Interested Labels and Spanning Tree Roots sub-TLV 1799 to indicate attachment of an IS to a fine-grained label analogous 1800 to the existing Interested VLANs and Spanning Tree Roots sub-TLV 1801 for VLANs. (Section 2.3.8) 1803 7. Addition of the RBridge Channel Protocols sub-TLV so ISs can 1804 announce the RBridge Channel protocols they support. (Section 1805 2.3.9) 1807 8. Permit specification of the length of the link SNPA field in 1808 TRILL Neighbor TLVs. This change is backwards compatible because 1809 the size of 6 bytes is specially encoded as zero, the previous 1810 value of the bits in the new SIZE field. (Section 2.5) 1812 9. Make the size of the MTU PDU Header Probe Source ID and Ack 1813 Source ID fields be the ID Length from the IS-IS PDU Header 1814 rather than the fixed value 6. (Section 3) 1816 10. For robustness, require LSP number zero PDUs be originated as no 1817 larger than 1470 bytes but processed regardless of size. (Section 1818 4.4) 1820 11. Require that the originatingLSPBufferSize TLV, if present, appear 1821 in LSP number zero. (Section 4.5) 1823 12. Create sub-registries for and specify the IANA Considerations 1824 policy for reserved and capability bits in the TRILL version sub- 1825 TLVs. (Section 5.4) 1827 13. Addition of the distribution tree Affinity sub-TLV so ISs can 1828 request distribution tree attachments. (Section 2.3.10) 1830 14. Add LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV. 1831 (Section 2.3.11) 1833 15. Add multi-topology: permit sub-TLVs previously only in Router 1834 Capabilities TLV to also appear in MT Capabilities TLV; permit 1835 MTU sub-TLV previously limited to Extended Reachability TLV to 1836 also appear in MT ISN TLV. 1838 16. Addition of a sub-registry for Neighbor TLV Neighbor RECORD flag 1839 bits. (Section 5.5) 1841 17. Explicitly state that if the number of sources in a GADDR-TLV 1842 sub-TLV is zero, it indicates a listener for (*,G), that is, a 1843 listener not restricted by source. (Section 2.1) 1845 8. Normative References 1847 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 1848 System to Intermediate System Intra-Domain Routing Exchange 1849 Protocol for use in Conjunction with the Protocol for Providing 1850 the Connectionless-mode Network Service (ISO 8473)", 2002. 1852 [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1853 Dual Environments", 1990. 1855 [RFC1982] - Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1856 1982, August 1996. 1858 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1859 Requirement Levels", BCP 14, RFC 2119, March 1997. 1861 [RFC4971] - Vasseur, JP. and N. Shen, "Intermediate System to 1862 Intermediate System (IS-IS) Extensions for Advertising Router 1863 Information", 2007. 1865 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1866 Topology (MT) Routing in Intermediate System to Intermediate 1867 Systems (IS-ISs)", RFC 5120, February 2008. 1869 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 1870 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1871 2008. 1873 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1874 Engineering", 2008. 1876 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1877 Layer-2 Systems", RFC 6165, April 2011. 1879 [RFC6325] - Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 1880 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 1881 June 2011. 1883 [RFC6327] - Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. 1884 Manral, "RBridges: Adjacency", RFC 6327, July 2011. 1886 [RFC6328] - Eastlake, D., "IANA Considerations for Network Layer 1887 Protocol Identifiers", RFC 6328, June 2011. 1889 [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, 1890 A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 1891 Shortest Path Bridging", RFC 6329, April 2012. 1893 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1894 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1895 6439, November 2011. 1897 [Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, 1898 draft-ietf-trill-rbridge-channel, in RFC Editor's queue. 1900 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. 1901 Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's 1902 queue. 1904 [ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. 1905 Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's 1906 queue. 1908 9. Informative References 1910 [802.1D-2004] - "IEEE Standard for Local and metropolitan area 1911 networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9 1912 June 2004. 1914 [802.1Q-2011] - "IEEE Standard for Local and metropolitan area 1915 networks / Virtual Bridged Local Area Networks", 802.1Q-2011, 1916 31 August 2011. 1918 [Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc- 1919 editor.org. 1921 [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1922 Authentication", RFC 5304, October 2008. 1924 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1925 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1926 5310, February 2009. 1928 [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol 1929 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 1930 2008. 1932 [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, 1933 "Issues with Existing Cryptographic Protection Methods for 1934 Routing Protocols", RFC 6039, October 2010. 1936 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 1937 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 1938 Use of IS-IS", RFC 6326, July 2011. 1940 [Affinity] - draft-ietf-trill-cmt, work in progress. 1942 [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in 1943 progress. 1945 [Resilient] - draft-zhang-trill-resilient-trees, work in progress. 1947 Acknowledgements 1949 The authors gratefully acknowledge the contributions and review by 1950 the following: 1952 Adrian Farrel, Radia Perlman, Joe Touch. 1954 And the contributions by the following to [RFC6326]: 1956 Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam 1957 Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, 1958 thanks to Mike Shand for the detailed and helpful comments. 1960 This document was produced with raw nroff. All macros used were 1961 defined in the source files. 1963 Authors' Addresses 1965 Donald Eastlake 1966 Huawei Technologies 1967 155 Beaver Street 1968 Milford, MA 01757 USA 1970 Phone: +1-508-333-2270 1971 EMail: d3e3e3@gmail.com 1973 Tissa Senevirathne 1974 Cisco Systems 1975 375 East Tasman Drive, 1976 San Jose, CA 95134 1978 Phone: +1-408-853-2291 1979 EMail: tsenevir@cisco.com 1981 Anoop Ghanwani 1982 Dell 1983 350 Holger Way 1984 San Jose, CA 95134 USA 1986 Phone: +1-408-571-3500 1987 EMail: anoop@alumni.duke.edu 1989 Dinesh Dutt 1990 Cumulus Networks 1991 1089 West Evelyn Avenue 1992 Sunnyvale, CA 94086 USA 1994 EMail: ddutt.ietf@hobbesdutt.com 1996 Ayan Banerjee 1997 Cumulus Networks 1998 1089 West Evelyn Avenue 1999 Sunnyvale, CA 94086 USA 2001 EMail: ayabaner@gmail.com 2003 Copyright, Disclaimer, and Additional IPR Provisions 2005 Copyright (c) 2012 IETF Trust and the persons identified as the 2006 document authors. All rights reserved. 2008 This document is subject to BCP 78 and the IETF Trust's Legal 2009 Provisions Relating to IETF Documents 2010 (http://trustee.ietf.org/license-info) in effect on the date of 2011 publication of this document. Please review these documents 2012 carefully, as they describe your rights and restrictions with respect 2013 to this document. Code Components extracted from this document must 2014 include Simplified BSD License text as described in Section 4.e of 2015 the Trust Legal Provisions and are provided without warranty as 2016 described in the Simplified BSD License. The definitive version of 2017 an IETF Document is that published by, or under the auspices of, the 2018 IETF. Versions of IETF Documents that are published by third parties, 2019 including those that are translated into other languages, should not 2020 be considered to be definitive versions of IETF Documents. The 2021 definitive version of these Legal Provisions is that published by, or 2022 under the auspices of, the IETF. Versions of these Legal Provisions 2023 that are published by third parties, including those that are 2024 translated into other languages, should not be considered to be 2025 definitive versions of these Legal Provisions. For the avoidance of 2026 doubt, each Contributor to the IETF Standards Process licenses each 2027 Contribution that he or she makes as part of the IETF Standards 2028 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 2029 language to the contrary, or terms, conditions or rights that differ 2030 from or are inconsistent with the rights and licenses granted under 2031 RFC 5378, shall have any effect and shall be null and void, whether 2032 published or posted by such Contributor, or included with or in such 2033 Contribution.