idnits 2.17.1 draft-ietf-isis-layer2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... MUST contain only unicast addresses...' RFC 2119 keyword, line 189: '...rried within the GADDR TLV and MUST be...' RFC 2119 keyword, line 240: '...thin the GADDR TLV and MUST be carried...' RFC 2119 keyword, line 292: '...rried within the GADDR TLV and MUST be...' RFC 2119 keyword, line 316: '...ags (VLAN & Flags) sub-TLV MUST appear...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 789 has weird spacing: '...d-Vlans sub...' == Line 790 has weird spacing: '...dFwrdrs sub-t...' == Line 797 has weird spacing: '...-Groups sub-...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2009) is 5534 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) == Missing Reference: 'RFC1195' is mentioned on line 67, but not defined == Missing Reference: 'TBD' is mentioned on line 663, but not defined == Unused Reference: 'RFC 1195' is defined on line 851, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3847 (Obsoleted by RFC 5306) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Banerjee, Ed. 3 Internet-Draft Cisco Systems 4 Expires: September 3, 2009 March 2, 2009 6 Extensions to IS-IS for Layer-2 Systems 7 draft-ietf-isis-layer2-00 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may contain material 13 from IETF Documents or IETF Contributions published or made publicly 14 available before November 10, 2008. The person(s) controlling the 15 copyright in some of this material may not have granted the IETF 16 Trust the right to allow modifications of such material outside the 17 IETF Standards Process. Without obtaining an adequate license from 18 the person(s) controlling the copyright in such materials, this 19 document may not be modified outside the IETF Standards Process, and 20 derivative works of it may not be created outside the IETF Standards 21 Process, except to format it for publication as an RFC or to 22 translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 3, 2009. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 This draft specifies the IS-IS extensions necessary to support multi- 56 link IPv4 and IPv6 networks, as well as to provide true link state 57 routing to any protocols running directly over layer 2. While 58 supporting this concept involves several pieces, this document only 59 describes extensions to IS-IS. We leave it to the systems using 60 these IS-IS extensions to explain how the information carried in 61 IS-IS is used. 63 1. Overview 65 There are a number of systems (for example, [RBRIDGES]) which have 66 proposed using layer 2 addresses carried in a link state routing 67 protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 68 2 routing in specific environments. This draft proposes a set of 69 TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new 70 PDU types, to support these proposed systems. 72 This draft does not propose new forwarding mechanisms using this 73 additional information carried within IS-IS. There is a short 74 section included on two possible ways to build a shortest path first 75 tree including this information, to illustrate how this information 76 might be used. 78 2. Proposed Enhancements to IS-IS 80 This draft proposes additional TLVs, to carry unicast and multicast 81 attached address information. It also proposes additional sub-tlvs 82 to carry information regarding building trees for Layer 2 networks. 83 This draft proposes three new IS-IS PDUs, the Multicast Group 84 (MGROUP) PDU, for carrying a list of attached or joined multicast 85 groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) 86 PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU 87 packets are also defined to be used with the new MGROUP-PDU to 88 perform database exchange on the MGROUP PDU packets. 90 2.1. The MAC-Reachability TLV 92 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the 93 following format: 95 0 1 2 3 96 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Type= MAC-RI | Length | Vlan-Id | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | MAC (1) | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | MAC (1) | MAC (2) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | MAC (2) | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | ................. | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | MAC (N) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 o Type: TLV Type, set to 141 (MAC-RI). 112 o Length: Total number of octets contained in the TLV. 113 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 114 all subsequent MAC addresses in this TLV. 115 o MAC(i): This is the 48-bit MAC address reachable from the IS that 116 is announcing this TLV. 118 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 119 MUST contain only unicast addresses. 121 2.2. The Group Address TLV 123 The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the 124 following format: 125 0 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |Type = GADDRTLV| Length | sub-tlvs | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 132 o Length: Total number of octets contained in the TLV, including the 133 length of the sub-tlvs carried in this TLV. 134 o sub-tlvs: The following sub-TLVs are defined. 136 The GADDR TLV is carried within Multicast Group Level 1 link state 137 PDU. 139 2.2.1. The Group MAC Address sub-TLV 141 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS TLV type 1 and has 142 the following format: 144 +-+-+-+-+-+-+-+-+ 145 | Type=GMAC-ADDR| (1 byte) 146 +-+-+-+-+-+-+-+-+ 147 | Length | (1 byte) 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Vlan-Id | (2 byte) 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |Num Group Recs | (1 byte) 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | GROUP RECORDS (1) | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | ................. | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | GROUP RECORDS (N) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 where each group record is of the form: 162 +-+-+-+-+-+-+-+-+ 163 | RESERVED | (1 byte) 164 +-+-+-+-+-+-+-+-+ 165 | Num of Sources| (1 byte) 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Group Address (6 bytes) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Source 1 Address (6 bytes) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Source 2 Address (6 bytes) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Source M Address (6 bytes) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 o Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. 177 o Length: Total number of octets contained in the TLV. 178 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 179 all subsequent MAC addresses in this TLV. 180 o Number of Group Records: This is of length 1 byte and lists the 181 number of group records in this TLV. 182 o Group Record: Each group record has a reserved space and followed 183 by the number of sources, each of length 1 byte. It then has a 184 48-bit multicast Group Address followed by 48-bit source MAC 185 addresses. An address being a group multicast address or unicast 186 source address can be checked using the multicast bit in the 187 address. 189 The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be 190 carried in a standard Level 1 link state MGROUP PDU. 192 2.2.2. The Group IP Address sub-TLV 194 The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has 195 the following format: 197 +-+-+-+-+-+-+-+-+ 198 | Type=GIP-ADDR | 199 +-+-+-+-+-+-+-+-+ 200 | Length | (1 byte) 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Vlan-Id | (2 byte) 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |Num Group Recs | (1 byte) 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | GROUP RECORDS (1) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | ................. | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | GROUP RECORDS (N) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 where each group record is of the form: 215 +-+-+-+-+-+-+-+-+ 216 | RESERVED | (1 byte) 217 +-+-+-+-+-+-+-+-+ 218 | Num of Sources| (1 byte) 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Group Address (4 bytes) | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Source 1 Address (4 bytes) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Source 2 Address (4 bytes) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Source M Address (4 bytes) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 o Type: TLV Type, set to 2 (GIP-ADDR). 230 o Length: Total number of octets contained in the TLV. 231 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 232 all subsequent IPv4 source or group addresses in this TLV. 233 o Number of Group Records: This is of length 1 byte and lists the 234 number of group records in this TLV. 235 o Group Record: Each group record has a reserved space and followed 236 by the number of sources, each of length 1 byte. It is followed 237 by a 32-bit IPv4 Group Address followed by 32-bit source IPv4 238 addresses. 240 The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried 241 in a standard Level 1 link state MGROUP PDU. 243 2.2.3. The Group IPv6 Address sub-TLV 245 The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and 246 has the following format: 248 +-+-+-+-+-+-+-+-+ 249 |Type=GIPv6-ADDR| 250 +-+-+-+-+-+-+-+-+ 251 | Length | (1 byte) 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Vlan-Id | (2 byte) 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |Num Group Recs | (1 byte) 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | GROUP RECORDS (1) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | ................. | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | GROUP RECORDS (N) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 where each group record is of the form: 266 +-+-+-+-+-+-+-+-+ 267 | RESERVED | (1 byte) 268 +-+-+-+-+-+-+-+-+ 269 | Num of Sources| (1 byte) 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Group Address (16 bytes) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Source 1 Address (16 bytes) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Source 2 Address (16 bytes) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Source M Address (16 bytes) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 o Type: TLV Type, set to 3 (GIPV6-ADDR). 281 o Length: Total number of octets contained in the TLV. 282 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 283 all subsequent IPv6 source or group addresses in this TLV. 284 o Number of Group Records: This of length 1 byte and lists the 285 number of group records in this TLV. 287 o Group Record: Each group record has a reserved space and followed 288 by the number of sources, each of length 1 byte. It is followed 289 by a 128-bit multicast IPv6 Group Address followed by 128-bit 290 source IPv6 addresses. 292 The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be 293 carried in a standard Level 1 link state MGROUP PDU. 295 2.3. Link Capability TLV 297 The Link Capability (LINK-CAP) is an optional IS-IS TLV type 143 298 [TBD], that may be generated by the originating IS and has the 299 following format: 300 0 1 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |Type=LINKCAPTLV| Length | sub-tlvs | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 o Type: TLV Type, set to LINK-CAP TLV 143 [TBD]. 307 o Length: Total number of octets contained in the TLV, including the 308 length of the sub-tlvs carried in this TLV. 309 o sub-tlvs: The following sub-TLVs are defined. 311 The LINK-CAP-TLV is carried within a LAN IIH PDU, or within a P2P IIH 312 PDU. 314 2.3.1. The Special VLANs and Flags sub-TLV 316 The Special VLANs and Flags (VLAN & Flags) sub-TLV MUST appear 317 exactly once in a Port Information TLV in every TRILL Hello PDU. It 318 has the following format: 319 0 1 2 3 4 - 15 16 - 19 20 - 31 320 +----+----+----+----+------------+----------+------------+ 321 | AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN | 322 +----+----+----+----+------------+----------+------------+ 324 o Type: TLV Type, set to VLAN & Flags sub-TLV 1 [TBD]. 325 o Length: 4 - Number of octets contained in the TLV. 326 o The first and second octets have a copy of the Outer VLAN ID 327 associated with the Hello frame when it was sent. The lower 4 328 bits of the first octet give the upper ID bits of the VLAN ID and 329 the second octet gives the lower VLAN ID bits. 330 o The upper 4 bits of the first octet are flag bits as shown. The 331 AF bit, if one, indicates that the sending RBridge believes it is 332 Appointed Forwarder for the VLAN and port on which the Hellos was 333 sent. The AC bit, if one, indicates that the sending port is 334 configured as an access port. The VM flag, if a one, indicates 335 that the sending RBridge has detected VLAN mapping within the 336 link. The R bit is reserved and MUST be sent as zero and ignored 337 on receipt. 338 o The third and forth octets give the Designated VLAN for the link. 339 The lower 4 bits of the third octet give the upper ID bits of the 340 Designated VLAN and the forth octet gives the lower VLAN ID bits. 341 The upper 4 bits of the third octet are reserved and MUST be sent 342 as zero and ignored on receipt. 344 The VLAN & Flags sub-TLV is carried within the LINK-CAP TLV and MUST 345 be carried in IIH PDU. 347 2.3.2. Enabled VLANs sub-TLV 349 The Enabled VLAN sub-TLV specifies the VLANs enabled for end station 350 service at the port on which the Hello was sent. 352 o Type: TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. 353 o Length: variable, depending on contents described next. 354 o The minimum size of the value is 3 octets. The third and 355 subsequent octets provide a bit map of enabled VLANs starting at 356 the VLAN ID indicated in the first two octets. The lower order 357 four bits of the first octet give the upper bits of the starting 358 VLAN ID and the second octet gives the lower bits of that VLAN ID. 359 The upper four bits of the first octet are reserved and MUST be 360 sent as zero and ignored on receipt. The highest order bit of the 361 third octet indicates the VLAN equal to the starting ID while the 362 lowest order bit of the third octet indicated that ID plus 7. For 363 example, VLANs 1 and 14 being enabled for end station service 364 could be encoded in 4-octets value 0x00 0x01 0x80 0x04 or, 365 alternatively, as 0x00 0x00 0x40 0x02. 367 This sub-TLV may occur more than once in a TRILL Hello and a VLAN is 368 enabled for end station service on the port where the Hellos was sent 369 if this is indicated by any occurrence in the Hello. For example, a 370 receiver could allocate a 512-octet buffer and, with appropriate 371 shifting operations, OR in the enabled bits for each subTLV of this 372 type it finds in a Hello to derive the complete bit map of these 373 VLANs. 375 The Enabled VLAN sub-TLV is carried within the LINK-CAP TLV and MUST 376 be carried in IIH PDU. 378 2.3.3. Appointed Forwarders sub-TLV 380 The Appointed Forwarder sub-TLV provides the mechanism by which the 381 DRB can inform other RBridges on the link that they are the 382 designated VLAN-x forwarder for that link for one or more ranges of 383 VLAN IDs. 385 o Type: TLV Type, set to Enabled VLANs sub-TLV 3 [TBD]. 386 o Length: The size of the value is 6*n octets where there are n 387 appointments. Each 6 octet part of the value is formatted as 388 follows: 390 +----------------+-----+-----+---------+-----+----+---------+ 391 | octet 1 - 2 | octet 3 | octet 4 | octet 5 | octet 6 | 392 +----------------+-----+-----+---------+-----+----+---------+ 393 | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID | 394 +----------------+-----+-----+---------+-----+----+---------+ 395 o The appointed forwarder RBridge is specified by its nickname in 396 the first two octets. 397 o The "Res" fields of 4 bits each are reserved and MUST be sent as 398 zero and ignored on reciept. 400 The VLAN range given is inclusive. To specify a single VLAN, that 401 VLAN ID appears as both the start and end VLAN. The RBridge whose 402 nickname is given is appointed forwarder for those VLANs for which it 403 has end station service enabled (see item 2 above) in the inclusive 404 range. For example, assume an RBridge with end station service 405 enabled on VLANs 100, 101, 199, and 200 (and possibly other VLANs 406 less than 100 or greater than 200), but not enabled for VLANS 102 407 through 198. It could be appointed forwarder for these four VLANs 408 through either (1) a single 6-octet value sequence with start and end 409 VLAN IDs of 100 and 200, or (2) a 12-octet value sequence with start 410 and end VLAN IDs of 100 and 101 in the first part and 199 and 200 in 411 the second part. 413 An RBridge's nickname may occur as appointed forwarder for multiple 414 VLAN ranges within the same or different Link Capability TLVs within 415 a DRB's Hello. In the absence of appointed forwarder subTLVs 416 referring to a VLAN, the DRB acts as the appointed forwarder for that 417 VLAN if end station service is enabled. 419 The Appointed Forwarder sub-TLV is carried within the LINK-CAP TLV 420 and MUST be carried in IIH PDU. 422 2.4. Sub-TLVs for the Capability TLV 424 The Capability TLV is an optional TLV [RFC 4971] that may be 425 generated by the originating IS. We introduce these additional sub- 426 TLVs that are carried within it. These sub-tlvs announce the 427 capabilities of the router for the entire IS-IS routing domain. 429 2.4.1. The TRILL Version sub-TLV 431 The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL 432 Versions. The device announces the maximum version of TRILL, it is 433 capable of supporting, including lower versions. In the event, this 434 sub-tlv is missing, this implies that the node can only support the 435 base version of the protocol. 436 0 1 2 3 437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | Reserved | Max-version | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 o Type: TLV Type, set to 5 (TRILL-VER). 443 o Length: 2 - Total number of octets contained in the TLV. 444 o Reserved: Set to 0. 445 o Max-version: Set to application dependent values. 447 2.4.2. The Device ID sub-TLV 449 The Device ID (DEVID) sub-TLV carries information about the identity 450 of the advertising device, along with information about device 451 priority. The Device-Id sub-TLV MUST be carried within the 452 CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the 453 originating IS. 454 0 1 2 3 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | Reserved | Priority | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Reserved | Device Id | 460 +---------------------------------------------------------------+ 462 o Type: TLV Type, set to 6 (DEVID). 463 o Length: Total number of octets contained in the TLV. 464 o Reserved: Set to 0. 465 o Priority: Set to application dependent values. 466 o Device ID: Left padded device ID or alias. 468 2.4.3. The Root Priority sub-TLV 470 The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV 471 in a level-1 non-pseudo-node LSP generated by the originating IS. 472 Each device announces a broadcast root-priority and the number of 473 trees it expects all other nodes to compute if it does become the 474 broadcast root. Once a node receives a new LSP, it runs an election 475 algorithm, independently of the other nodes in the network, to 476 determine the broadcast root. The node that announced the lowest 477 broadcast priority becomes the root of the broadcast tree. If two 478 devices advertise the same broadcast priority, the device with the 479 lower system ID becomes the root of the broadcast tree. The elected 480 broadcast-root decides on the multicast-roots to be used in the 481 network domain and their roots. This announcement takes place in the 482 roots identifier sub-TLV. 484 +-+-+-+-+-+-+-+-+ 485 |Type = ROOT-PRI| 486 +-+-+-+-+-+-+-+-+ 487 | Length | (1 byte) 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Broadcast Root Pri | (2 byte) 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |Num of multi-destination trees | (2 byte) 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 o Type: TLV Type, set to 7 (ROOT-PRI). 495 o Length: Total number of octets contained in the TLV. 496 o Br Root Pri: This gives the value of the priority with which this 497 node wants to be the broadcast root node in the Layer-2 domain. 498 o Num of multi-destination trees: This gives the number of 499 distribution trees for multi-destination frames that will be in 500 use in the Layer-2 domain, excluding the broadcast tree rooted at 501 itself, if this device becomes the broadcast root in the domain. 503 2.4.4. The Root Identifier Sub-tlv 505 The root identifier sub-tlv is populated by the root of the broadcast 506 tree. If this is also announced by other nodes in the network, it 507 implies that the specific node that is advertising it will only 508 restrict traffic to the common set of the trees in its announcement 509 and the ones announced by the broadcast root. It is carried within 510 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: 512 0 1 2 3 513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |Type= ROOT-IDs | Length | RESERVED | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Multi-destination Tree Num | Broadcast Root System Id... | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | ... Broadcast Root System Id | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Multi-destination Tree Num | Multicast Root System Id ... | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | ... Multicast Root System Id | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | ... | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 o Type: TLV Type, set to 8 (ROOT-IDs). 529 o Length: Total number of octets contained in the TLV. 530 o Multi-destination Tree Num: This identifies the trees being used 531 by the specific nodes. 532 o Broadcast Root System Id: The Broadcast Root System ID at which a 533 broadcast tree is rooted. It is of length 6 bytes. 534 o Multicast Root System Id: The Multicast Root System ID at which a 535 multicast tree is rooted. It is of length 6 bytes. 536 A locally significant hash is used by edge devices to determine which 537 multicast root (or set of multicast roots) is used to send traffic 538 for a specific multicast group. If there is a discrepancy between 539 the number of multi-destination trees the broadcast-root has 540 announced, and the number of roots the root-identifier sub-tlv 541 carries, nodes MUST compute trees on the additional roots. 543 2.4.5. Interested Vlans and Spanning Tree Roots sub-TLV 545 The value of this subTLV consists of a VLAN range, flags, and a 546 variable length list of spanning tree root bridge IDs. This subTLV 547 may appear zero, one, or many times. The union of the VLAN ranges in 548 all occurrences MUST be precisely the set of VLANs for which the 549 originating RBridge is appointed forwarder on at least one port and 550 the VLAN ranges in multiple VLANs subTLVs for an RBridge MUST NOT 551 overlap. That is, the intersection of the VLAN ranges for any pair 552 of these subTLVs originated by an RBridge must be null. The value 553 length is 4 + 6*n where n is the number of root bridge IDs.The 554 initial 4 octets of value are as follows: 556 +-+-+-+-+-+-+-+-+ 557 |Type = INT-VLAN| 558 +-+-+-+-+-+-+-+-+ 559 | Length | (1 byte) 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Interested VLANS | (4 bytes) 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Multi-destination tree roots | (6*n bytes) 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 o Type: TLV Type, set to 9 (INT-VLAN). 567 o Length: Total number of octets contained in the TLV. 568 o Interested VLANS: The M4 bit indicates that there is an IPv4 569 multicast router on a link for which the originating RBridge is 570 appointed forwarder for every VLAN in the indicated range. The M6 571 bit indicates the same for an IPv6 multicast router. The OM bit 572 indicates that this RBridge requests that all non-IP derived 573 multicast traffic in the indicated VLAN range be sent to it. The 574 R and Reserved bits MUST be sent as zero and are ignored on 575 receipt. The VLAN start and end IDs are inclusive. A range of 576 one VLAN ID is indicated by setting them both to that VLAN ID 577 value. It has the following format: 578 0 1 2 3 4 - 15 16 - 19 20 - 31 579 +----+----+----+----+------------+----------+------------+ 580 | AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN | 581 +----+----+----+----+------------+----------+------------+ 582 o Multi-destination tree roots: The list of zero or more spanning 583 tree root bridge IDs is the set of root bridge IDs seen for all 584 ports for which the RBridge is appointed forwarder for the VLANs 585 in the range. This information is learned from BPDUs heard by the 586 RBridge. If MSTP is in use on a link, the root bridge referred to 587 is the CIST (common and internal spanning tree) root bridge. 588 (While, of course, only one spanning tree root should be seen on 589 any particular port, there may be multiple ports in the same VLAN 590 connected to differed bridged LANs with different spanning tree 591 roots.) If no spanning tree roots can be seen on any of the links 592 in any of the VLANs in the range indicated for which the RBridge 593 is appointed forwarder (for example all such links are point-to- 594 point links to other RBridges or to end stations so no BPDUs are 595 received) then the listed set of spanning tree root IDs will be 596 null. 598 If there are any two VLANs in the range indicated for which the value 599 of the M4, M6, or OM bits are different, the subTLV is incorrect and 600 must be split into multiple subTLVs each indicating only VLANs with 601 the same M4, M6, and OM values. If there are any two VLANs in the 602 range indicated for which the set of root bridge IDs see on all links 603 for which the RBridge is appointed forwarder for the VLAN are not the 604 same, the subTLV is incorrect and must be split into multiple subTLVs 605 each indicating only VLANs with the same set of DRB seen root bridge 606 IDs. It is always safe to use subTLVs with a "range" of one VLAN ID 607 but this may be too verbose. 609 This sub-tlv is carried within the CAPABILITY TLV in a level-1 non- 610 pseudo-node LSP. 612 2.4.6. The Vlan Group Sub-tlv 614 The Vlan Group sub-tlv consists of two or more 16-bit fields each of 615 which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be 616 sent as zero and ignored on receipt. The first such VLAN ID is the 617 primary, or may be zero if there is no primary. It is carried within 618 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: 619 0 1 2 3 620 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |Type=VLAN-GROUP| Length | RESERVED | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Primary Vlan-Id | Secondary Vlan Id | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | ... | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 o Type: TLV Type, set to 10 (VLAN-GROUPs). 630 o Length: Total number of octets contained in the TLV. 631 o Primary Vlan-id: This identifies the primary Vlan-id. 632 o Secondary Vlan-id: This identifies the secondary Vlan-id, address 633 learning is shared at the Rbridge that announces this sub-tlv. 634 This sub-tlv may appear zero, one, or multiple times. 636 3. The Multicast Group PDU 638 The systems that this draft is concerned with want to carry not only 639 layer-2 unicast information in the link state protocols, but also 640 multicast information. This draft has defined a new Multicast Group 641 (MGROUP) PDU that can be used to advertise a set of attached, or 642 joined, multicast groups. Accordingly, it has also introduced a 643 couple more PDUs as described in the next sections for the flooding 644 and update process to work seamlessly. 646 In the Layer-2 environment, it is expected the join/leave frequency 647 of the multicast members will be much higher than unicast topology 648 changes. It is efficient to separate the updates for the group 649 membership change information from the remainder of the information 650 by placing this information in a separate PDU. This enables 651 reachability information, that would trigger an SPF, to be not 652 impacted at all. Furthermore, during SPF runs, TLVs being on 653 different PDUs which do not affect SPF need not be inspected during 654 processing. 656 The choice of a different PDU also opens the LSP-space to another 256 657 fragments to carry a large number of groups. This additional space 658 can be used judiciously to carry only multicast information. 660 The Multicast Group (MGROUP) PDU can be used to advertise a set of 661 attached, or joined, multicast groups. The MGROUP PDU is formatted 662 identical to a Level 1 Link State PDU, as described in Section 9.3 of 663 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify 664 this PDU is carrying multicast group information, rather than unicast 665 reachability information. 667 The Multicast Group PDU carries TLVs indicating multicast membership 668 information. There are three sub-TLVs of the GADDR TLV defined in 669 this document, that MAY be present in this PDU, namely, GMAC-ADDR, 670 GIP-ADDR, and GIPV6-ADDR TLVs. 672 One or more TLVs MAY be carried in a single MGROUP PDU. Future 673 multicast address TLVs MAY be defined using other type codes, and be 674 carried in an MGROUP PDU. 676 The information carried in this PDU is processed in a similar fashion 677 as described in [RFC 1584]. 679 3.1. The Multicast Group Partial Sequence Number PDU 681 The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used 682 to reliably flood the MGROUP PDU following the base protocol 683 specifications. 685 3.2. The Multicast Group Complete Sequence Number PDU 687 The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is 688 used to reliably flood the MGROUP PDU following the base protocol 689 specifications. 691 3.3. Enhancements to the flooding process 693 This draft proposes that the information contained in the MGROUP-PDU 694 is in a parallel database and its update mechanisms mimic that of the 695 regular database. Nodes running IS-IS in an L2 domain MUST support 696 these additional MGROUP PDUs defined in this draft. In general, the 697 flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP- 698 CSNP PDUs uses the same update procedures as defined for the regular 699 LSP, PSNP, and CSNP PDUs. 701 For example, on P2P links CSNP is exchanged on the formation of an 702 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged 703 between the neighbors at the same time. This gets the initial 704 MGROUP-database synchronization going. After this similar actions of 705 the base protocol specifications for the regular database 706 synchronization will be maintained to keep the MGROUP-database 707 synchronized. 709 Similarly, on LAN links the DIS is responsible for sending periodic 710 CSNP transmissions. The DIS in the L2 IS-IS network domain will also 711 be responsible for sending periodic MGROUP-CSNP transmissions. The 712 update and flooding process will work in parallel for the two 713 databases and there is no further synchronization between them. 715 In general, the database synchronization is performed in parallel 716 with no interactions between the messages. However, the initial 717 triggers that start a CSNP exchange are correlated, in the sense it 718 also triggers a MGROUP-CSNP exchange. For example, during graceful 719 restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange 720 and update process will be run for the MGROUP-PDUs and restart 721 process completes after both databases have been received. 723 4. Considerations for Using L2 Information in IS-IS 725 While this document does not specify the way in which addresses 726 carried in these TLVs is used in IS-IS, two general areas of concern 727 are considered in this section: building the SPF tree when using this 728 information, and the election of designated intermediate systems 729 (DIS) in an environment using this information. 731 4.1. Building SPF Trees with Layer 2 Information 733 Each IS which is part of a single broadcast domain from a layer 2 734 perspective will build multiple SPF trees (SPT) for every IS that is 735 announced by the IS deemed to be the broadcast root. 737 We assume some mechanism for forwarding traffic to these attached 738 addresses added to the SPT is provided for in the mechanism proposing 739 the use of these extension TLVs. 741 4.2. Designated Intermediate Routers 743 A single DIS SHOULD be elected as described in [IS-IS] for each layer 744 2 broadcast domain (VLAN) for which information is being carried in 745 IS-IS. This reduces the amount of work required to flood and 746 maintain synchronized databases over the underlying media on which 747 IS-IS is running and providing layer 2 forwarding information for. 749 5. Acknowledgements 751 The authors would like to thank Les Ginsberg for his useful comments. 753 6. Security Considerations 755 This document adds no additional security risks to IS-IS, nor does it 756 provide any additional security for IS-IS. 758 7. IANA Considerations 760 This document creates three new PDU types, namely the MCAST PDU, 761 MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU 762 type to the level-1 PDUs described above and reflect it in the PDU 763 registry. 765 MCAST-PDU Level-1 PDU Type: 19 766 MCAST-CSNP-PDU Level-1 PDU Type: 22 767 MCAST-PSNP-PDU Level-1 PDU Type: 29 769 This document requires the definition a set of new ISIS TLVs, the 770 MAC-Reachability TLV (type 141), the Group Address TLV (type 142), 771 and the Link-Capability TLV (type 143), that needs to be reflected in 772 the ISIS TLV code-point registry. 774 This document creates a number of new sub-TLV in the numbering space 775 for the Group Address TLV, the Link Capability TLV, and the 776 Capability TLV. The TLV and sub-TLVs are given below: 778 IIH LSP SNP MCAST MCAST 779 LSP SNP 780 MAC-RI TLV (141) - X - - - 782 GADDR-TLV (142) - - - X - 783 GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - 784 GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - 785 GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - 787 Link-Cap-TLV (143) X - - - - 788 LinkCap.Vlan & Flags sub-tlv 1 X - - - - 789 LinkCap.Enabled-Vlans sub-tlv 2 X - - - - 790 LinkCap.AppointedFwrdrs sub-tlv 3 X - - - - 792 CAPABILITY.Trill-Version sub-tlv 5 - X - - - 793 CAPABILITY.Device ID sub-tlv 6 - X - X - 794 CAPABILITY.Root Priority sub-tlv 7 - X - - - 795 CAPABILITY.Roots sub-tlv 8 - X - - - 796 CAPABILITY.Int-Vlans sub-tlv 9 - X - - - 797 CAPABILITY.Vlan-Groups sub-tlv 10 - X - - - 799 IANA SHOULD manage the remaining space using the consensus method. 801 8. Contributors 803 David Ward 804 Cisco Systems 805 170 W Tasman Drive 806 San Jose, CA 95138 807 US 809 Email: wardd@cisco.com 811 Russ White 812 Cisco Systems 813 170 W Tasman Drive 814 San Jose, CA 95138 815 US 817 Email: riw@cisco.com 819 Dino Farinacci 820 Cisco Systems 821 170 W Tasman Drive 822 San Jose, CA 95138 823 US 825 Email: dino@cisco.com 827 Radia Perlman 828 Sun Microsystems 829 16 Network Circle 830 Menlo Park, CA 94025 831 US 833 Email: Radia.Perlman@Sun.com 835 Donald E. Eastlake 3rd 836 Eastlake Enterprises 837 155 Beaver Street 838 Milford, MA 07157 839 US 841 Email: d3e3e3@gmail.com 843 9. References 844 9.1. Normative References 846 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 847 Intra-Domain Routing Exchange Protocol for use in 848 Conjunction with the Protocol for Providing the 849 Connectionless-mode Network Service (ISO 8473)", 2005. 851 [RFC 1195] 852 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 853 Dual Environments", 1990. 855 [RFC 3847] 856 Shand, M. and L. Ginsberg, "Restart Signaling for 857 Intermediate System to Intermediate System (IS-IS)", 2004. 859 [RFC 4971] 860 Vasseur, JP. and N. Shen, "Intermediate System to 861 Intermediate System (IS-IS) Extensions for Advertising 862 Router Information", 2007. 864 9.2. Informative References 866 [RBRIDGES] 867 Perlman, R. and J. Touch, "Transparent Interconnection of 868 Lots of Links (TRILL): Problem and Applicability 869 Statement", 2008. 871 [RFC 1584] 872 Moy, J., "Multicast Extensions to OSPF", March 1994. 874 Author's Address 876 Ayan Banerjee (editor) 877 Cisco Systems 878 170 W Tasman Drive 879 San Jose, CA 95138 880 US 882 Email: ayabaner@cisco.com