idnits 2.17.1 draft-ietf-isis-trill-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 935 has weird spacing: '...Section sub- ...' -- The document date (February 2, 2011) is 4831 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 737, but not defined -- 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) == Outdated reference: A later version (-11) exists of draft-ietf-isis-layer2-09 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 Ayan Banerjee 4 Dinesh Dutt 5 Cisco 6 Radia Perlman 7 Intel 8 Anoop Ghanwani 9 Brocade 10 Expires: August 1, 2011 February 2, 2011 12 TRILL Use of IS-IS 13 15 Abstract 17 The IETF has standardized the TRILL protocol, which provides 18 transparent Layer 2 forwarding using encapsulation with a hop count 19 and IS-IS link state routing. This document specifies the data 20 formats and code points for the IS-IS extensions to support TRILL. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the ISIS and TRILL working group mailing lists: 29 and . 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Conventions used in this document......................3 52 2. TLV and sub-TLV Extensions to IS-IS for TRILL...........4 53 2.1 The Group Address TLV..................................4 54 2.1.1 The Group MAC Address sub-TLV........................4 55 2.2 Multi-Topology Aware Port Capability sub-TLVs..........6 56 2.2.1 The Special VLANs and Flags sub-TLV..................6 57 2.2.2 Enabled-VLANs sub-TLV................................7 58 2.2.3 Appointed Forwarders sub-TLV.........................8 59 2.3 Sub-TLVs for the Router Capability TLV.................9 60 2.3.1 The TRILL Version sub-TLV............................9 61 2.3.2 The Nickname sub-TLV................................10 62 2.3.3 The Trees sub-TLV...................................11 63 2.3.4 The Tree Identifiers Sub-TLV........................11 64 2.3.5 The Trees Used Identifiers Sub-TLV..................12 65 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV....12 66 2.3.7 The VLAN Group sub-TLV..............................15 67 2.4 MTU sub-TLV of the Extended Reachability TLV..........16 68 2.5 TRILL Neighbor TLV....................................16 70 3. The MTU PDUs...........................................19 72 4. Use of Existing PDUs and TLVs..........................20 73 4.1 TRILL IIH PDUs........................................20 74 4.2 Area Address..........................................20 75 4.3 Protocols Supported...................................20 77 5. Acknowledgements.......................................21 79 6. IANA Considerations....................................22 80 6.1 Allocations From Existing Registries..................22 81 6.2 New Sub-Registries Created............................23 83 7. Security Considerations................................25 85 8. References.............................................26 86 8.1 Normative References..................................26 87 8.2 Informative References................................27 89 Appendix A: Initial IS-IS PDU Registry....................28 91 1. Introduction 93 The IETF has standardized the TRILL protocol [RFCtrill], which 94 provides transparent Layer 2 forwarding using encapsulation with a 95 hop count and link state routing. TRILL provides optimal pair-wise 96 forwarding without configuration, safe forwarding even during periods 97 of temporary loops, and support for multipathing of both unicast and 98 multicast traffic as well as supporting VLANs. Intermediate Systems 99 (ISs) implementing TRILL can incrementally replace IEEE [802.1Q-2005] 100 bridges. 102 This document, in conjunction with [RFCisisLayer2], specifies the 103 data formats and code points for the IS-IS [ISO-10589] [RFC1195] 104 extensions to support TRILL. 106 1.1 Conventions used in this document 108 The terminology and acronyms defined in [RFCtrill] are used herein 109 with the same meaning. 111 Additional acronyms used in this document: 113 IIH - IS-IS Hello 115 IS - Intermediate System (for this document, all relevant 116 intermediate systems are RBridges) 118 NLPID - Network Layer Protocol Identifier 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. TLV and sub-TLV Extensions to IS-IS for TRILL 126 This section, in conjunction with [RFCisisLayer2], specifies the data 127 formats and code points for the TLVs and sub-TLVs added to IS-IS to 128 support the TRILL standard. Information as to the number of 129 occurrences allowed, such as for a TLV in a PDU or set of PDUs or for 130 a sub-TLV in a TLV, is provided in Section 6. 132 2.1 The Group Address TLV 134 The Group Address (GADDR) TLV, IS-IS TLV type 142 [TBD], is carried 135 only in an LSP PDU and carries sub-TLVs that in turn advertise 136 multicast group listeners. Section 2.1.1 below specifies a sub-TLV 137 advertising listeners by MAC address. It is anticipated that 138 additional sub-TLVS for additional address types such as IP addresses 139 will be specified in other documents. The sub-TLVs under GADDR 140 constitute a new series of sub-TLV types (see Section 6.2). 142 GADDR has the following format: 144 +-+-+-+-+-+-+-+-+ 145 |Type=GADDR-TLV | (1 byte) 146 +-+-+-+-+-+-+-+-+ 147 | Length | (1 byte) 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | sub-TLVs... 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 154 o Length: variable depending on the sub-TLVs carried. 156 o sub-TLVs: The Group Address TLV value consists of sub-TLVs 157 formatted as described in [RFC5305]. 159 2.1.1 The Group MAC Address sub-TLV 161 The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 162 within the GADDR TLV. In TRILL, it is used to advertise multicast 163 listeners as specified in Section 4.5.5 of [RFCtrill]. It has the 164 following format: 166 +-+-+-+-+-+-+-+-+ 167 |Type=GMAC-ADDR | (1 byte) 168 +-+-+-+-+-+-+-+-+ 169 | Length | (1 byte) 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | RESV | Topology-ID | (2 bytes) 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | RESV | VLAN-ID | (2 bytes) 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |Num Group Recs | (1 byte) 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | GROUP RECORDS (1) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | ................. | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | GROUP RECORDS (N) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 where each group record is of the form: 186 +-+-+-+-+-+-+-+-+ 187 | Num of Sources| (1 byte) 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Group Address (6 bytes) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Source 1 Address (6 bytes) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Source 2 Address (6 bytes) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | ..... | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Source M Address (6 bytes) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 o Type: GADDR sub-TLV Type, set to 1 (GMAC-ADDR). 202 o Length: Variable, minimum 5. 204 o RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored 205 on receipt. 207 o Topology-ID: This field is not used in TRILL, where it is sent as 208 zero and ignored on receipt, but is included for use by other 209 technologies. 211 o VLAN-ID: This carries the 12-bit VLAN identifier for all 212 subsequent MAC addresses in this sub-TLV, or the value zero if no 213 VLAN is specified. 215 o Number of Group Records: A 1-byte integer that is the number of 216 group records in this sub-TLV. 218 o Group Record: Each group record carries the number of sources. It 219 then has a 48-bit multicast address followed by 48-bit source MAC 220 addresses. If the sources do not fit in a single sub-TLV, the 221 same group address may be repeated with different source addresses 222 in another sub-TLV of another instance of the Group Address TLV. 224 2.2 Multi-Topology Aware Port Capability sub-TLVs 226 TRILL makes use of the Multi-Topology aware Port Capability (MT-PORT- 227 CAP) TLV as specified in [RFCisisLayer2]. The remainder of this 228 section specifies the sub-TLVs that TRILL uses the MT-PORT-CAP TLV to 229 transport. 231 2.2.1 The Special VLANs and Flags sub-TLV 233 In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried 234 in every IIH PDU. It has the following format: 236 +-+-+-+-+-+-+-+-+ 237 |Type=VLAN Flags| (1 byte) 238 +-+-+-+-+-+-+-+-+ 239 | Length | (1 byte) 240 +---------------+---------------+ 241 | Port ID | (2 bytes) 242 +-------------------------------+ 243 | Sender Nickname | (2 bytes) 244 +--+--+--+--+-------------------+ 245 |AF|AC|VM|BY| Outer.VLAN | (2 bytes) 246 +--+--+--+--+-------------------+ 247 |TR|R |R |R | Desig.VLAN | (2 bytes) 248 +--+--+--+--+-------------------+ 250 o Type: sub-TLV Type, set to MT-PORT-CAP VLAN-Flags sub-TLV 1 [TBD]. 252 o Length: 8. 254 o Port ID: An ID for the port on which the enclosing TRILL IIH PDU 255 is being sent as specified in [RFCtrill] Section 4.4.2. 257 o Sender nickname: If the sending IS is holding any nicknames as 258 discussed in [RFCtrill] Section 3.7, one MUST be included here. 259 Otherwise, the field is set to zero. This field is to support 260 intelligent end stations that determine the egress IS (RBridge) 261 for unicast data through a directory service or the like and need 262 a nickname for their first hop to insert as the ingress nickname 263 to correctly format a TRILL encapsulated data frame. See 264 [RFCtrill] Section 4.6.2 point #8. 266 o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH 267 frame containing this sub-TLV when that frame was sent, as 268 specified in [RFCtrill] Section 4.4.5. 270 o Desig.VLAN: The 12-bit ID of the designated VLAN for the link as 271 specified in [RFCtrill] Section 4.2.4.2. 273 o AF, AC, VM, BY, and TR: These flag bits have the following meaning 274 each, if set to one, as specified in the listed section of 275 [RFCtrill]: 277 RFCtrill 278 Bit Section Meaning if bit is one 279 -------------------------------------- 281 AF 4.4.2 Originating IS believes it is Appointed Forwarder 282 for the VLAN and port on which the containing IIH 283 PDU was sent. 285 AC 4.9.1 Originating port configured as an access port 286 (TRILL traffic disabled). 288 VM 4.4.5 VLAN Mapping detected on this link. 290 BY 4.4.2 Bypass pseudonode. 292 TR 4.9.1 Originating port configured as a trunk port (end 293 station service disabled). 295 o R: Reserved bit. MUST be sent as zero and ignored on receipt. 297 2.2.2 Enabled-VLANs sub-TLV 299 The optional Enabled-VLANs sub-TLV specifies the VLANs enabled for 300 end station service at the port of the originating IS on which the 301 Hello was sent as specified in [RFCtrill] Section 4.4.2. It has the 302 following format: 304 +-+-+-+-+-+-+-+-+ 305 |Type=EnabledVLAN| (1 byte) 306 +-+-+-+-+-+-+-+-+ 307 | Length | (1 byte) 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | RESV | Start VLAN ID | (2 bytes) 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | VLAN bit-map.... 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 o Type: sub-TLV Type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2 315 [TBD]. 317 o Length: Variable, minimum 3. 319 o RESV: 4 reserved bits that MUST be sent as zero and ignored on 320 receipt. 322 o Start VLAN ID: The 12 bit VLAN ID that is represented by the high 323 order bit of the first byte of the VLAN bit-map. 325 o VLAN bit-map: The highest order bit indicates the VLAN equal to 326 the start VLAN ID, the next highest bit indicates the VLAN equal 327 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 328 field 330 If this sub-TLV occurs more than once in a Hello, the set of enabled 331 VLANs is the union of the sets of VLANs indicated by each of the 332 Enabled-VLAN sub-TLVs in the Hello. 334 2.2.3 Appointed Forwarders sub-TLV 336 The DRB on a link uses the Appointed Forwarders sub-TLV to inform 337 other ISs on the link that they are the designated VLAN-x forwarder 338 for one or more ranges of VLAN IDs as specified in Section 4.2.4 of 339 [RFCtrill]. It has the following format: 341 +-+-+-+-+-+-+-+-+ 342 |Type=ApptFwrdrs| (1 byte) 343 +-+-+-+-+-+-+-+-+ 344 | Length | (1 byte) 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Appointment Information (1) | (6 bytes) 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | ................. | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Appointment Information (N) | (6 bytes) 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 where each appointment is of the form: 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Appointee Nickname | (2 bytes) 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | RESV | Start.VLAN | (2 bytes) 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | RESV | End.VLAN | (2 bytes) 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 o Type: sub-TLV Type, set to MT-PORT-CAP Appointed Forwarders sub- 363 TLV 3 [TBD]. 365 o Length: 6*n bytes where there are n appointments. 367 o Appointee Nickname: The nickname of the IS being appointed a 368 forwarder. 370 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 372 o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 373 appointment range, inclusive. A VLAN's ID appears as both the 374 start and end VLAN to specify that single VLAN. As specified in 375 Section 4.4 of [RFCtrill], appointing an IS forwarder on a port 376 for a VLAN not enabled on that port has no effect. 378 An IS's nickname may occur as appointed forwarder for multiple VLAN 379 ranges by occurrences of this sub-TLV within the same or different MT 380 Port Capability TLVs within an IIH PDU. 382 2.3 Sub-TLVs for the Router Capability TLV 384 The Router Capability TLV is specified in [RFC4971]. All of the sub- 385 sections of this Section 2.3 below specify sub-TLVs that can be 386 carried in the Router Capability TLV for TRILL. 388 2.3.1 The TRILL Version sub-TLV 390 The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version 391 of the TRILL standard supported. By implication, lower versions are 392 also supported. If this sub-TLV is missing, the originating IS only 393 supports the base version of the protocol [RFCtrill]. 395 +-+-+-+-+-+-+-+-+ 396 | Type | (1 byte) 397 +-+-+-+-+-+-+-+-+ 398 | Length | (1 byte) 399 +-+-+-+-+-+-+-+-+ 400 | Max-version | (1 byte) 401 +-+-+-+-+-+-+-+-+ 403 o Type: Router Capability sub-TLV Type, set to 12 (TRILL-VER). 405 o Length: 1. 407 o Max-version: Set to maximum version supported. 409 2.3.2 The Nickname sub-TLV 411 The Nickname (NICKNAME) Router Capability sub-TLV carries information 412 about the nicknames of the originating IS, along with information 413 about its priority to hold those nicknames as specified in [RFCtrill] 414 Section 3.7.3. Multiple instances of this sub-TLV may be carried. 416 +-+-+-+-+-+-+-+-+ 417 |Type = NICKNAME| (1 byte) 418 +-+-+-+-+-+-+-+-+ 419 | Length | (1 byte) 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | NICKNAME RECORDS (1) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | ................. | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | NICKNAME RECORDS (N) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 where each nickname record is of the form: 430 +-+-+-+-+-+-+-+-+ 431 | Nickname.Pri | (1 byte) 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Tree Root Priority | (2 byte) 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Nickname | (2 bytes) 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 o Type: Router Capability sub-TLV Type, set to 6 (NICKNAME). 440 o Length: 5*N, where N is the number of nickname records present. 442 o Nickname.Pri: An 8-bit unsigned integer priority to hold a 444 nickname as specified in Section 3.7.3 of [RFCtrill]. 446 o Tree Root Priority: This is an unsigned 16-bit integer priority to 447 be a tree root as specified in Section 4.5 of [RFCtrill]. 449 o Nickname: This is an unsigned 16-bit integer as specified in 450 Section 3.7 of [RFCtrill]. 452 2.3.3 The Trees sub-TLV 454 Each IS providing TRILL service uses the TREES sub-TLV to announce 455 three numbers related to the computation of distribution trees as 456 specified in Section 4.5 of [RFCtrill]. Its format is as follows: 458 +-+-+-+-+-+-+-+-+ 459 |Type = TREES | (1 byte) 460 +-+-+-+-+-+-+-+-+ 461 | Length | (1 byte) 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Number of trees to compute | (2 byte) 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Maximum trees able to compute | (2 byte) 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Number of trees to use | (2 byte) 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 o Type: Router Capability sub-TLV Type, set to 7 (TREES). 472 o Length: 6. 474 o Number of trees to compute: An unsigned 16-bit integer as 475 specified in Section 4.5 of [RFCtrill]. 477 o Maximum trees able to compute: An unsigned 16-bit integer as 478 specified in Section 4.5 of [RFCtrill]. 480 o Number of trees to use: An unsigned 16-bit integer as specified in 481 Section 4.5 of [RFCtrill]. 483 2.3.4 The Tree Identifiers Sub-TLV 485 The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of 486 nicknames. When originated by the IS that has the highest priority 487 tree root, it lists the distribution trees that the other ISs are 488 required to compute as specified in Section 4.5 of [RFCtrill]. If 489 this information is spread across multiple sub-TLVs, the starting 490 tree number is used to allow the ordered lists to be correctly 491 concatenated. The sub-TLV format is as follows: 493 +-+-+-+-+-+-+-+-+ 494 |Type=TREE-RT-IDs| (1 byte) 495 +-+-+-+-+-+-+-+-+ 496 | Length | (1 byte) 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |Starting Tree Number | (2 bytes) 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Nickname (K-th root) | (2 bytes) 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Nickname (K+1 - th root) | (2 bytes) 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Nickname (...) | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 o Type: Router Capability sub-TLV Type, set to 8 (TREE-RT-IDs). 509 o Length: 2 + 2*n where n is the number of nicknames listed. 511 o Starting Tree Number: This identifies the starting tree number of 512 the nicknames that are trees for the domain. This is set to 1 for 513 the sub-TLV containing the first list. Other Tree-Identifiers 514 sub-TLVs will have the number of the starting list they contain. 515 In the event a tree identifier can be computed from two such sub- 516 TLVs and they are different, then it is assumed that this is a 517 transient condition that will get cleared. During this transient 518 time, such a tree SHOULD NOT be computed unless such computation 519 is indicated by all relevant sub-TLVs present. 521 o Nickname: The nickname at which a distribution tree is rooted. 523 2.3.5 The Trees Used Identifiers Sub-TLV 525 This Router Capability sub-TLV has the same structure as the Tree 526 Identifiers sub-TLV specified in Section 2.3.4. The only difference 527 is that its sub-TLV type is set to 9 [TBD] (TREE-USE-IDs) and the 528 trees listed are those that the originating IS wishes to use as 529 specified in [RFCtrill] Section 4.5. 531 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV 533 The value of this Router Capability sub-TLV consists of a VLAN range 534 and information in common to all of the VLANs in the range for the 535 originating IS. This information consists of flags, a variable 536 length list of spanning tree root bridge IDs, and an appointed 537 forwarder status lost counter, all as specified in the sections of 538 [RFCtrill] listed with the respective information items below. 540 In the set of LSPs originated by an IS, the union of the VLAN ranges 541 in all occurrences of this sub-TLV MUST be precisely the set of VLANs 542 for which the originating IS is appointed forwarder on at least one 543 port and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST 544 NOT overlap unless the information provided about a VLAN is the same 545 in every instance. However, as a transient state these conditions may 546 be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an 547 IS, that IS is assumed to be uninterested in receiving traffic for 548 that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an 549 IS with different information in the different instances, the 550 following apply: 551 If those sub-TLVs provide different nicknames it is unspecified 552 which nickname takes precedence, 553 The largest appointed forwarder status lost counter is used, 554 The originating IS is assumed to be attached to a multicast IPv4 555 router for that VLAN if any of the INT-VLAN sub-TLVs assert 556 that it is so connected and similarly for IPv6 multicast router 557 attachment, and 558 The root bridge lists from all of the instances of the VLAN for 559 the originating IS are merged. 561 To minimize such occurrences, wherever possible, an implementation 562 SHOULD advertise the update to a interested VLAN and spanning tree 563 roots sub-TLV in the same LSP fragment as the advertisement that it 564 replaces. Where this is not possible, the two affected LSP fragments 565 should be flooded as an atomic action. An IS that receives an update 566 to an existing interested VLAN and spanning tree roots sub-TLV can 567 minimize the potential disruption associated with the update by 568 employing a hold-down timer prior to processing the update so as to 569 allow for the receipt of multiple LSP fragments associated with the 570 same update prior to beginning processing. 572 The sub-TLV layout is as follows: 574 +-+-+-+-+-+-+-+-+ 575 |Type = INT-VLAN| (1 byte) 576 +-+-+-+-+-+-+-+-+ 577 | Length | (1 byte) 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Nickname | (2 bytes) 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 581 | Interested VLANS | (4 bytes) 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ 583 | Appointed Forwarder Status Lost Counter | (4 bytes) 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 585 | Root Bridges | (6*n bytes) 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 588 o Type: Router Capability sub-TLV Type, set to 10 (INT-VLAN). 590 o Length: 10 + 6*n where n is the number of root bridge IDs. 592 o Nickname: As specified in [RFCtrill] Section 4.2.4.4, this field 593 may be used to associate a nickname held by the originating IS 594 with the VLAN range indicated. When not so used, it is set to 595 zero. 597 o Interested VLANS: The Interested VLANs field is formatted as shown 598 below. 600 0 1 2 3 4 - 15 16 - 19 20 - 31 601 +----+----+----+----+------------+----------+------------+ 602 | M4 | M6 | R | R | VLAN.start | RESV | VLAN.end | 603 +----+----+----+----+------------+----------+------------+ 605 - M4, M6: These bits indicate, respectively, that there is an 606 IPv4 or IPv6 multicast router on a link for which the 607 originating IS is appointed forwarder for every VLAN in the 608 indicated range as specified in [RFCtrill] Section 4.2.4.4 item 609 5.1. 611 - R, RESV: These reserved bits MUST be sent as zero and are 612 ignored on receipt. 614 - VLAN.start and VLAN.end: This VLAN ID range is inclusive. A 615 range of one VLAN ID is indicated by setting them both to that 616 VLAN ID value. 618 o Appointed Forwarder Status Lost Counter: This is a count of how 619 many times a port that was appointed forwarder for the VLANs in 620 the range given has lost the status of being an appointed 621 forwarder as discussed in Section 4.8.3 of [RFCtrill]. It is 622 initialized to zero at an IS when the zeroth LSP sequence number 623 is initialized. No special action need be taken at rollover, the 624 counter just wraps around. 626 o Root Bridges: The list of zero or more spanning tree root bridge 627 IDs is the set of root bridge IDs seen for all ports for which the 628 IS is appointed forwarder for the VLANs in the specified range as 629 discussed in [RFCtrill] Section 4.9.3.2. While, of course, only 630 one spanning tree root could be seen on any particular port, there 631 may be multiple ports in the same VLAN connected to differed 632 bridged LANs with different spanning tree roots. 634 An INT-VLAN sub-TLV asserts that the information provided (multicast 635 router attachment, appointed forwarder status lost counter, and root 636 bridges), is the same for all VLANs in the range specified. If this 637 is not the case, the range MUST be split into subranges meeting this 638 criteria. It is always safe to use sub-TLVs with a "range" of one 639 VLAN ID but this may be too verbose. 641 2.3.7 The VLAN Group sub-TLV 643 The VLAN Group Router Capability sub-TLV consists of two or more VLAN 644 IDs as specified in [RFCtrill] Section 4.8.4. This sub-TLV indicates 645 that shared VLAN learning is occurring at the announcing IS between 646 the listed VLANs. It is structured as follows: 648 +-+-+-+-+-+-+-+-+ 649 |Type=VLAN-GROUP| (1 byte) 650 +-+-+-+-+-+-+-+-+ 651 | Length | (1 byte) 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | RESV | Primary VLAN ID | (2 bytes) 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | RESV | Secondary VLAN ID | (2 bytes) 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | more Secondary VLAN IDs ... (2 bytes each) 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 o Type: Router Capability sub-TLV Type, set to 13 (VLAN-GROUP). 662 o Length: 4 + 2*n, where n is the number of secondary VLAN ID 663 fields, which may be zero. 665 o RESV: a 4-bit field that MUST be sent as zero and ignored on 666 receipt. 668 o Primary VLAN-ID: This identifies the primary VLAN-ID. 670 o Secondary VLAN-ID: This identifies a secondary VLAN in the VLAN 671 Group. 673 o more Secondary VLAN IDs: zero or more bytes pairs with the top 674 four bits an RESV field and the low 12 bits a VLAN-ID. 676 2.4 MTU sub-TLV of the Extended Reachability TLV 678 The MTU sub-TLV is used to optionally announce the MTU of a link as 679 specified in [RFCtrill] Section 4.2.4.4. It occurs within the 680 Extended Reachability TLV (type #22). 682 +-+-+-+-+-+-+-+-+ 683 | Type = MTU | (1 byte) 684 +-+-+-+-+-+-+-+-+ 685 | Length | (1 byte) 686 +-+-+-+-+-+-+-+-+ 687 |F| Reserved | (1 byte) 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | MTU | (2 bytes) 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 o Type: Extended Reachability sub-TLV Type, set to MTU sub-TLV 28 693 [TBD]. 695 o Length: 3. 697 o F: Failed. This bit is a one if MTU testing failed on this link at 698 the required campus-wide MTU. 700 o Reserved: 7 bits that MUST be sent as zero and ignored on receipt. 702 o MTU: This field is set to the largest successfully tested MTU size 703 for this link, or zero if it has not been tested, as specified in 704 Section 4.3.2 of [RFCtrill]. 706 2.5 TRILL Neighbor TLV 708 The TRILL Neighbor TLV is used in TRILL IIH PDUs (see Section 4.1 709 below) in place of the IS Neighbor TLV, as specified in Section 710 4.4.2.1 of [RFCtrill] and [RFCadj]. The structure of the TRILL 711 Neighbor TLV is as follows: 713 +-+-+-+-+-+-+-+-+ 714 |Type=TRILLNeigh| (1 byte) 715 +-+-+-+-+-+-+-+-+ 716 | Length | (1 byte) 717 +-+-+-+-+-+-+-+-+ 718 |S|L| RESV | (1 byte) 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Neighbor RECORDS (1) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | ................. | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Neighbor RECORDS (N) | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 The information present for each neighbor is as follows: 729 +-+-+-+-+-+-+-+-+ 730 |F| RESV | (1 bytes) 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | MTU | (2 bytes) 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+ 734 | MAC Address | (6 bytes) 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+ 737 o Type: TLV Type, set to TRILL Neighbor TLV 145 [TBD]. 739 o Length: 1 + 9*n, where n is the number of neighbor records which 740 may be zero. 742 o S: Smallest flag. If this bit is a one, then the list of 743 neighbors includes the neighbor with the smallest MAC address 744 considered as an unsigned integer. 746 o L: Largest flag. If this bit is a one, then the list of neighbors 747 includes the neighbor with the largest MAC address considered as 748 an unsigned integer. 750 o RESV: These seven bits are reserved use and MUST be sent as zero 751 and ignored on receipt. 753 o F: failed. This bit is a one if MTU testing to this neighbor 754 failed at the required campus-wide MTU (see [RFCtrill] Section 755 4.3.1). 757 o MTU: This field is set to the largest successfully tested MTU size 758 for this neighbor or zero if it has not been tested. 760 o MAC Address: The MAC address of the neighbor as in the IS Neighbor 761 TLV (#6). 763 As specified in [RFCtrill] Section 4.4.2.1 and [RFCadj], all MAC 764 address may fit into one TLV, in which case both the S and L flags 765 would be set to one in that TLV. Otherwise, the highest MAC address 766 in a TRILL Neighbor TLV with the L flag zero MUST also appear as a 767 MAC address in some other TRILL Neighbor TLV (possibly in a different 768 TRILL IIH PDU). And the lowest MAC address in a TRILL Neighbor TLV 769 with the S flag zero MUST also appear in some other TRILL Neighbor 770 TLV (possibly in a different TRILL IIH PDU). If an RBridge believes 771 it has no neighbors, it MUST send a TRILL Neighbor TLV with an empty 772 list of neighbor RECORDSs, which will have both the S and L bits on. 774 3. The MTU PDUs 776 Two PDUs are added to IS-IS, the MTU-probe and MTU-ack PDUs. They 777 are used to optionally determine the MTU on a link between ISs as 778 specified in [RFCtrill] Section 4.3.2. 780 The MTU PDUs have the IS-IS PDU common header (up through the Maximum 781 Area Addresses byte) with two new PDU Type numbers, one each, as 782 listed in Section 6. They also have a 20-byte common fixed MTU PDU 783 header as shown below. 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | PDU Length | (2 bytes) 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 788 | Probe ID (6 bytes) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 790 | Probe Source ID (6 bytes) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 792 | Ack Source ID (6 bytes) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ 795 As with other IS-IS PDUs, the PDU length gives the length of the 796 entire IS-IS packet starting with and including the IS-IS common 797 header. 799 The Probe ID field is an arbitrary 48-bit quantity set by the IS 800 issuing an MTU-probe and copied by the responding IS into the 801 corresponding MTU-ack. For example, an IS creating an MTU-probe 802 could compose this quantity from a port identifier and probe sequence 803 number relative to that port. 805 The Probe Source ID is set by an IS issuing an MTU-probe to its 806 System ID and copied by the responding IS into the corresponding MTU- 807 ack. 809 The Ack Source ID is set to zero in MTU-probe PDUs. An IS issuing an 810 MTU-ack sets this field to its System ID. 812 The TLV area follows the MTU PDU header area. This area MAY contain 813 an Authentication TLV and MUST be padded to the exact size being 814 tested with the Padding TLV. Since the minimum size of the Padding 815 TLV is 2 bytes, it would be impossible to pad to exact size if the 816 total length of the required information bearing fixed fields and 817 TLVs added up to 1 byte less than the desired length; however, the 818 length of the fixed fields and substantive TLVs for MTU PDUs will be 819 quite small compared with their minimum length (minimum 1470 byte MTU 820 on an 802.3 link for example), so this will not be a problem. 822 4. Use of Existing PDUs and TLVs 824 The sub-sections below provide details of TRILL use of existing PDUs 825 and TLVs. 827 4.1 TRILL IIH PDUs 829 The TRILL IIH PDU is the variation of the LAN IIH PDU used by the 830 TRILL protocol. Section 4.4 of the TRILL standard [RFCtrill] 831 specifies the contents of the TRILL IIH and how its use differs in 832 TRILL from Layer 3 LAN IIH PDU use. The adjacency state machinery for 833 TRILL neighbors is specified in Section 4.4 of [RFCtrill] and in 834 [RFCadj]. 836 In a TRILL IIH PDU the IS-IS Common Header and the fixed PDU Header 837 are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses 838 octet in the Common Header MUST be set to 0x01. 840 The IS-IS Neighbor TLV (#6) is not used in a TRILL IIH and is ignored 841 if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor 842 TLV (see Section 2.6). 844 4.2 Area Address 846 TRILL uses a fixed zero Area Address as specified in [RFCtrill] 847 Section 4.2.3. This is encoded in a four byte Area Address TLV (TLV 848 #1) as follows: 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | 0x01, Area Address Type | (1 byte) 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | 0x02, Length of Value | (1 byte) 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | 0x01, Length of Address | (1 byte) 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | 0x00, zero Area Address | (1 byte) 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 4.3 Protocols Supported 862 NLPID 0xC0 has been assigned to TRILL [RFCnlpid]. A Protocols 863 Supported TLV (#129, [RFC1195]) including that value MUST appear in 864 TRILL IIH PDUs and LSP number zero PDUs. 866 5. Acknowledgements 868 The authors gratefully acknowledge the contributions and review by 869 the following: Mike Shand, Stewart Bryant, Dino Farinacci, Les 870 Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White, 871 particularly the detailed and helpful comments by Mike Shand. 873 6. IANA Considerations 875 IANA is requested to allocate the existing registry code points 876 listed in Section 6.1 and create two new registries with their 877 initial contents as described in Section 6.2. 879 RFC Editor Note: In a number of cases in this draft, a specific code 880 point value appears followed by " [TBD]". This indicates that there 881 is a very small chance that the IANA / Expert process might change 882 the code point. The editing action of removing the " [TBD]" is 883 expected to be appropriate. Where a "[TBD]" appears without a sepcifc 884 code point value, it should be replaced by the allocated value. 885 Please remove this note prior to publication. 887 6.1 Allocations From Existing Registries 889 This document specifies two new IS-IS TLV types, namely the Group 890 Address TLV (GADDR, type 142) and the TRILL Neighbor TLV (type 145). 891 The PDUs in which these TLVs are permitted for TRILL are shown in the 892 table below along with the section of this document where they are 893 discussed. The final "NUMBER" column indicates the permitted number 894 of occurrences of the TLV in their PDU, or set of PDUs in the case of 895 LSP, which in these two cases is "*" indicating that the TLV MAY 896 occur 0, 1, or more times. 898 It is requested that these two code points be added to the IANA IS-IS 899 TLV registry (ignoring the "Section" and "NUMBER" columns that are 900 irrelevant to that registry). 902 Section TLV# IIH LSP SNP NUMBER 904 GADDR-TLV 2.1 142 - X - * 905 TRILL Neighbor TLV 2.5 145 X - - * 907 This document specifies eleven new sub-TLVs from existing sub-TLV 908 sequences, namely VLAN-FLAGS, Enabled-VLANs, AppointedFwrdrs, TRILL 909 Version (TRILL-VER), Nickname, TREES, TREE-RT-IDs, TREE-USE-IDs, INT- 910 VLAN, VLAN-GROUP, and MTU. The TLVs in which these sub-TLVs occur are 911 shown in the table below along with the Section of this document 912 where they are discussed. 914 Those sub-TLVs with an "X" in the column labeled "MT Port Capabil." 915 are sub-TLVs of TLV #TBD [RFCisisLayer2], the MT-PORT-CAP TLV. Those 916 sub-TLVs with an "X" in the column labeled "Router Capabil." are sub- 917 TLVs of TLV #242, IS-IS Router Capabilities TLV. Those sub-TLVs with 918 an "X" in the column labeled "Extended IS Reach" are sub-TLVs of TLV 919 #22, the Extended IS Reachability TLV. 921 The final "NUM" column indicates the permitted number of occurrences 922 of the sub-TLV cumulatively within all occurrences of their TLV in 923 that TLV's carrying PDU (or set of PDUs in the case of LSP), as 924 follows: 926 0-1 = MAY occur zero or one times. If it occurs more than once, 927 results are unspecified. 928 1 = MUST occur exactly once. If absent, the PDU is ignored. If 929 it occurs more than once, results are unspecified. 930 * = MAY occur 0, 1, or more times. 932 The values in the "Section" and "NUM" columns are irrelevant to the 933 IANA sub-registries. 935 Section sub- MT Port Router Extended NUM 936 TLV# Capabil. Capabil. IS Reach 937 VLAN-FLAGS 2.2.1 1 X - - 1 938 Enabled-VLANs 2.2.2 2 X - - * 939 AppointedFwrdrs 2.2.3 3 X - - * 940 NICKNAME 2.3.2 6 - X - * 941 TREES 2.3.3 7 - X - 0-1 942 TREE-RT-IDs 2.3.4 8 - X - * 943 TREE-USE-IDs 2.3.5 9 - X - * 944 INT-VLAN 2.3.6 10 - X - * 945 TRILL-VER 2.3.1 12 - X - 0-1 946 VLAN-GROUP 2.3.7 13 - X - * 947 MTU 2.4 28 - - X 0-1 949 6.2 New Sub-Registries Created 951 This document creates two new IS-IS PDUs, namely the MTU-PROBE-PDU, 952 and MTU-ACK-PDU, as described in Section 3. IANA will assign new PDU 953 types to these PDUs and reflect them in a newly created PDU registry 954 (see Appendix A). [suggested PDU values below] 956 MTU-PROBE-PDU PDU Number: TBD (23 suggested) 957 MTU-ACK-PDU PDU Number: TBD (28 suggested) 959 IANA is requested to create a new sub-TLV IS-IS sub-registry for sub- 960 TLVs within the Group Address (GADDR) TLV and specifies an initial 961 sub-TLV within that registry, namely Group MAC Address (GMAC-ADDR), 962 sub-TLV #1. The GMAC-ADDR sub-TLV may occur 0, 1, or more times in a 963 GADDR TLV. 965 The initial sub-registry is shown below. 967 Registry Name: IS-IS Group Address Type Codes for TLV 10 968 Reference: This document 969 Registration Procedures: Expert Review [RFC5226] 971 Registry: 972 Value Group Address Type Code Reference 973 ------- ----------------------------- --------- 974 0 Reserved This document 975 1 MAC Address This document 976 2-254 Unassigned This document 977 255 Reserved This document 979 7. Security Considerations 981 For general TRILL protocol security considerations, see the TRILL 982 base protocol standard [RFCtrill]. 984 This document raises no new security issues for IS-IS. IS-IS security 985 may be used to secure the IS-IS messages discussed here. See 986 [RFC5304] and [RFC5310]. Even when the IS-IS authentication is used, 987 replays of Hello packets can create denial-of-service conditions; see 988 [RFC6039] for details. These issues are similar in scope to those 989 discussed in Section 6.2 of [RFCtrill], and the same mitigations may 990 apply. 992 8. References 994 Normative and informative references for this document are given 995 below. 997 8.1 Normative References 999 [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate 1000 System to Intermediate System Intra-Domain Routing Exchange 1001 Protocol for use in Conjunction with the Protocol for Providing 1002 the Connectionless-mode Network Service (ISO 8473)", 2002. 1004 [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1005 Dual Environments", 1990. 1007 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1008 Requirement Levels", BCP 14, RFC 2119, March 1997. 1010 [RFC4971] - Vasseur, JP. and N. Shen, "Intermediate System to 1011 Intermediate System (IS-IS) Extensions for Advertising Router 1012 Information", 2007. 1014 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 1015 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1016 2008. 1018 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1019 Engineering", 2008. 1021 [RFCadj] - "RBridges: Adjacency", draft-ietf-trill-adj, work in 1022 progress. 1024 [RFCisisLayer2] - Banerjee, A., and D. Ward, "Extensions to IS-IS for 1025 Layer-2 Systems", draft-ietf-isis-layer2-09.txt, work in 1026 progress. 1028 [RFCnlpid] - Eastlake, D., "IANA Considerations for Network Layer 1029 Protocol Identifiers", draft-eastlake-nlpid-iana- 1030 considerations-04.txt, in RFC Editor's queue. 1032 [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 1033 Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- 1034 trill-rbridge-protocol-16.txt, in RFC Editor's queue. 1036 8.2 Informative References 1038 [802.1Q-2005] "IEEE Standard for Local and metropolitan area networks 1039 / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 1040 2006. 1042 [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1043 Authentication", RFC 5304, October 2008. 1045 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1046 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1047 5310, February 2009. 1049 [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, 1050 "Issues with Existing Cryptographic Protection Methods for 1051 Routing Protocols", RFC 6039, October 2010. 1053 Appendix A: Initial IS-IS PDU Registry 1055 The following is the suggested initial IS-IS PDU Registry before 1056 MTU-PROBE-PDU and MTU-ACK-PDU, which should be added with this 1057 document as REFERENCE: 1059 Registry Name: IS-IS PDUs 1060 Reference: This document 1061 Registration Procedures: IETF Review [RFC5226] 1063 MNEMONIC PDU# REFERENCE 1065 Unassigned 0-14 1066 L1-LAN-HELLO-PDU 15 [ISO-10589] 1067 L2-LAN-HELLO-PDU 16 [ISO-10589] 1068 P2P-HELLO-PDU 17 [ISO-10589] 1069 L1-LSP-PDU 18 [ISO-10589] 1070 Unassigned 19 1071 L2-LSP-PDU 20 [ISO-10589] 1072 Unassigned 21-23 1073 L1-CSNP-PDU 24 [ISO-10589] 1074 L2-CSNP-PDU 25 [ISO-10589] 1075 L1-PSNP-PDU 26 [ISO-10589] 1076 L2-PSNP-PDU 27 [ISO-10589] 1077 Unassigned 28-31 1079 Authors' Addresses 1081 Donald Eastlake 1082 Huawei 1083 155 Beaver Street 1084 Milford, MA 01757 USA 1086 Phone: +1-508-333-2270 1087 email: d3e3e3@gmail.com 1089 Ayan Banerjee 1090 Cisco Systems 1091 170 West Tasman Drive 1092 San Jose, CA 95134 USA 1094 Email: ayabaner@cisco.com 1096 Dinesh Dutt 1097 Cisco Systems 1098 170 West Tasman Drive 1099 San Jose, CA 95134-1706 USA 1101 Phone: +1-408-527-0955 1102 Email: ddutt@cisco.com 1104 Radia Perlman 1105 Intel Labs 1106 2200 Mission College Blvd. 1107 Santa Clara, CA 95054-1549 USA 1109 Phone: +1-408-765-8080 1110 Email: Radia@alum.mit.edu 1112 Anoop Ghanwani 1113 Brocade Communications Systems 1114 1745 Technology Drive 1115 San Jose, CA 95110 USA 1117 Phone: +1-408-333-7149 1118 Email: anoop@brocade.com 1120 Copyright and IPR Provisions 1122 Copyright (c) 2011 IETF Trust and the persons identified as the 1123 document authors. All rights reserved. 1125 This document is subject to BCP 78 and the IETF Trust's Legal 1126 Provisions Relating to IETF Documents 1127 (http://trustee.ietf.org/license-info) in effect on the date of 1128 publication of this document. Please review these documents 1129 carefully, as they describe your rights and restrictions with respect 1130 to this document. Code Components extracted from this document must 1131 include Simplified BSD License text as described in Section 4.e of 1132 the Trust Legal Provisions and are provided without warranty as 1133 described in the BSD License. The definitive version of an IETF 1134 Document is that published by, or under the auspices of, the IETF. 1135 Versions of IETF Documents that are published by third parties, 1136 including those that are translated into other languages, should not 1137 be considered to be definitive versions of IETF Documents. The 1138 definitive version of these Legal Provisions is that published by, or 1139 under the auspices of, the IETF. Versions of these Legal Provisions 1140 that are published by third parties, including those that are 1141 translated into other languages, should not be considered to be 1142 definitive versions of these Legal Provisions. For the avoidance of 1143 doubt, each Contributor to the IETF Standards Process licenses each 1144 Contribution that he or she makes as part of the IETF Standards 1145 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1146 language to the contrary, or terms, conditions or rights that differ 1147 from or are inconsistent with the rights and licenses granted under 1148 RFC 5378, shall have any effect and shall be null and void, whether 1149 published or posted by such Contributor, or included with or in such 1150 Contribution.