idnits 2.17.1 draft-ward-l2isis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 103: '... MUST contain only unicast addresses...' RFC 2119 keyword, line 172: '...rried within the GADDR TLV and MUST be...' RFC 2119 keyword, line 223: '...thin the GADDR TLV and MUST be carried...' RFC 2119 keyword, line 274: '...rried within the GADDR TLV and MUST be...' RFC 2119 keyword, line 288: '...evice-Id sub-TLV MUST be carried withi...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5653 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 53, but not defined == Missing Reference: 'TBD' is mentioned on line 400, but not defined == Unused Reference: 'RFC 1195' is defined on line 534, 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ward 3 Internet-Draft R. White 4 Expires: May 3, 2009 D. Farinacci 5 A. Banerjee 6 Cisco Systems 7 R. Perlman 8 Sun Microsystems 9 November 3, 2008 11 Carrying Attached Addresses in IS-IS 12 draft-ward-l2isis-04 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 3, 2009. 39 Abstract 41 This draft specifies the IS-IS extensions necessary to support multi- 42 link IPv4 and IPv6 networks, as well as to provide true link state 43 routing to any protocols running directly over layer 2. While 44 supporting this concept involves several pieces, this document only 45 describes extensions to IS-IS. We leave it to the systems using 46 these IS-IS extensions to explain how the information carried in 47 IS-IS is used. 49 1. Overview 51 There are a number of systems (for example, [RBRIDGES]) which have 52 proposed using layer 2 addresses carried in a link state routing 53 protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 54 2 routing in specific environments. This draft proposes a set of 55 TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new 56 PDU types, to support these proposed systems. 58 This draft does not propose new forwarding mechanisms using this 59 additional information carried within IS-IS. There is a short 60 section included on two possible ways to build a shortest path first 61 tree including this information, to illustrate how this information 62 might be used. 64 2. Proposed Enhancements to IS-IS 66 This draft proposes additional TLVs, to carry unicast and multicast 67 attached address information. It also proposes additional sub-tlvs 68 to carry information regarding building trees for Layer 2 networks. 69 This draft proposes three new IS-IS PDUs, the Multicast Group 70 (MGROUP) PDU, for carrying a list of attached or joined multicast 71 groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) 72 PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU 73 packets are also defined to be used with the new MGROUP-PDU to 74 perform database exchange on the MGROUP PDU packets. 76 2.1. The MAC-Reachability TLV 78 The MAC-Reachability (MAC-RI) sub-TLV is IS-IS TLV type 141 and has 79 the following format: 80 0 1 2 3 81 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 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Type= MAC-RI | Length | Vlan-Id | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | MAC (1) | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | MAC (1) | MAC (2) | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | MAC (2) | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | ................. | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | MAC (N) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 o Type: TLV Type, set to 141 (MAC-RI). 96 o Length: Total number of octets contained in the TLV. 97 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 98 all subsequent MAC addresses in this TLV. 99 o MAC(i): This is the 48-bit MAC address reachable from the IS that 100 is announcing this TLV. 102 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 103 MUST contain only unicast addresses. 105 2.2. The Group Address TLV 107 The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the 108 following format: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 |Type = GADDRTLV| Length | sub-tlvs | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 116 o Length: Total number of octets contained in the TLV, including the 117 length of the sub-tlvs carried in this TLV. 118 o sub-tlvs: The following sub-TLVs are defined. 120 The GADDR TLV is carried within Multicast Group Level 1 link state 121 PDU. 123 2.2.1. The Group MAC Address sub-TLV 125 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS TLV type 1 and has 126 the following format: 128 +-+-+-+-+-+-+-+-+ 129 | Type=GMAC-ADDR| (1 byte) 130 +-+-+-+-+-+-+-+-+ 131 | Length | (1 byte) 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Vlan-Id | (2 byte) 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |Num Group Recs | (1 byte) 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | GROUP RECORDS (1) | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | ................. | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | GROUP RECORDS (N) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 where each group record is of the form: 145 +-+-+-+-+-+-+-+-+ 146 | RESERVED | (1 byte) 147 +-+-+-+-+-+-+-+-+ 148 | Num of Sources| (1 byte) 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Group Address (6 bytes) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Source 1 Address (6 bytes) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Source 2 Address (6 bytes) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Source M Address (6 bytes) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 o Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. 160 o Length: Total number of octets contained in the TLV. 161 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 162 all subsequent MAC addresses in this TLV. 163 o Number of Group Records: This is of length 1 byte and lists the 164 number of group records in this TLV. 165 o Group Record: Each group record has a reserved space and followed 166 by the number of sources, each of length 1 byte. It then has a 167 48-bit multicast Group Address followed by 48-bit source MAC 168 addresses. An address being a group multicast address or unicast 169 source address can be checked using the multicast bit in the 170 address. 172 The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be 173 carried in a standard Level 1 link state MGROUP PDU. 175 2.2.2. The Group IP Address sub-TLV 177 The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has 178 the following format: 180 +-+-+-+-+-+-+-+-+ 181 | Type=GIP-ADDR | 182 +-+-+-+-+-+-+-+-+ 183 | Length | (1 byte) 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Vlan-Id | (2 byte) 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |Num Group Recs | (1 byte) 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | GROUP RECORDS (1) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | ................. | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | GROUP RECORDS (N) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 where each group record is of the form: 198 +-+-+-+-+-+-+-+-+ 199 | RESERVED | (1 byte) 200 +-+-+-+-+-+-+-+-+ 201 | Num of Sources| (1 byte) 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Group Address (4 bytes) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Source 1 Address (4 bytes) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Source 2 Address (4 bytes) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Source M Address (4 bytes) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 o Type: TLV Type, set to 2 (GIP-ADDR). 213 o Length: Total number of octets contained in the TLV. 214 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 215 all subsequent IPv4 source or group addresses in this TLV. 216 o Number of Group Records: This is of length 1 byte and lists the 217 number of group records in this TLV. 218 o Group Record: Each group record has a reserved space and followed 219 by the number of sources, each of length 1 byte. It is followed 220 by a 32-bit IPv4 Group Address followed by 32-bit source IPv4 221 addresses. 223 The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried 224 in a standard Level 1 link state MGROUP PDU. 226 2.2.3. The Group IPv6 Address sub-TLV 228 The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and 229 has the following format: 231 +-+-+-+-+-+-+-+-+ 232 |Type=GIPv6-ADDR| 233 +-+-+-+-+-+-+-+-+ 234 | Length | (1 byte) 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Vlan-Id | (2 byte) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 |Num Group Recs | (1 byte) 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | GROUP RECORDS (1) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | ................. | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | GROUP RECORDS (N) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 where each group record is of the form: 249 +-+-+-+-+-+-+-+-+ 250 | RESERVED | (1 byte) 251 +-+-+-+-+-+-+-+-+ 252 | Num of Sources| (1 byte) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Group Address (16 bytes) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Source 1 Address (16 bytes) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Source 2 Address (16 bytes) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Source M Address (16 bytes) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 o Type: TLV Type, set to 3 (GIPV6-ADDR). 264 o Length: Total number of octets contained in the TLV. 265 o Vlan-id: This carries a 16 bit VLAN identifier that is valid for 266 all subsequent IPv6 source or group addresses in this TLV. 267 o Number of Group Records: This of length 1 byte and lists the 268 number of group records in this TLV. 269 o Group Record: Each group record has a reserved space and followed 270 by the number of sources, each of length 1 byte. It is followed 271 by a 128-bit multicast IPv6 Group Address followed by 128-bit 272 source IPv6 addresses. 274 The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be 275 carried in a standard Level 1 link state MGROUP PDU. 277 2.3. Sub-TLVs for the Capability TLV 279 The Capability TLV is an optional TLV [RFC 4971] that may be 280 generated by the originating IS. We introduce these additional sub- 281 TLVs that are carried within it. These sub-tlvs announce the 282 capabilities of the router for the entire IS-IS routing domain. 284 2.3.1. The Device ID sub-TLV 286 The Device ID (DEVID) sub-TLV carries information about the identity 287 of the advertising device, along with information about device 288 priority. The Device-Id sub-TLV MUST be carried within the 289 CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the 290 originating IS. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Reserved | Priority | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Reserved | Device Id | 297 +---------------------------------------------------------------+ 299 o Type: TLV Type, set to 5 (DEVID). 300 o Length: Total number of octets contained in the TLV. 301 o Reserved: Set to 0. 302 o Priority: Set to application dependent values. 303 o Device ID: Left padded device ID or alias. 305 2.3.2. The Root Priority sub-TLV 307 The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV 308 in a level-1 non-pseudo-node LSP generated by the originating IS. 309 Each device announces a broadcast root-priority and the number of 310 trees it expects all other nodes to compute if it does become the 311 broadcast root. Once a node receives a new LSP, it runs an election 312 algorithm, independently of the other nodes in the network, to 313 determine the broadcast root. The node that announced the lowest 314 broadcast priority becomes the root of the broadcast tree. If two 315 devices advertise the same broadcast priority, the device with the 316 lower system ID becomes the root of the broadcast tree. The elected 317 broadcast-root decides on the multicast-roots to be used in the 318 network domain and their roots. This announcement takes place in the 319 roots identifier sub-TLV. 321 +-+-+-+-+-+-+-+-+ 322 |Type = ROOT-PRI| 323 +-+-+-+-+-+-+-+-+ 324 | Length | (1 byte) 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Broadcast Root Pri | (2 byte) 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |Num of multi-destination trees | (2 byte) 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 o Type: TLV Type, set to 6 (ROOT-PRI). 332 o Length: Total number of octets contained in the TLV. 333 o Br Root Pri: This gives the value of the priority with which this 334 node wants to be the broadcast root node in the Layer-2 domain. 335 o Num of multi-destination trees: This gives the number of 336 distribution trees for multi-destination frames that will be in 337 use in the Layer-2 domain, excluding the broadcast tree rooted at 338 itself, if this device becomes the broadcast root in the domain. 340 2.3.3. The Root Identifier Sub-tlv 342 The root identifier sub-tlv is populated by the root of the broadcast 343 tree. If this is also announced by other nodes in the network, it 344 implies that the specific node that is advertising it will only 345 restrict traffic to the common set of the trees in its announcement 346 and the ones announced by the broadcast root. It is carried within 347 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |Type= ROOT-IDs | Length | Broadcast Root System Id... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | ... Broadcast Root System Id | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Multicast Root System Id ... | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | ... Multicast Root System Id | ... 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 o Type: TLV Type, set to 7 (ROOT-IDs). 361 o Length: Total number of octets contained in the TLV. 362 o Broadcast Root System Id: The Broadcast Root System ID at which a 363 broadcast tree is rooted. It is of length 6 bytes. 364 o Multicast Root System Id: The Multicast Root System ID at which a 365 multicast tree is rooted. It is of length 6 bytes. 366 A locally significant hash is used by edge devices to determine which 367 multicast root (or set of multicast roots) is used to send traffic 368 for a specific multicast group. If there is a discrepancy between 369 the number of multi-destination trees the broadcast-root has 370 announced, and the number of roots the root-identifier carries, nodes 371 should compute trees on the additional roots. 373 3. The Multicast Group PDU 375 The systems that this draft is concerned with want to carry not only 376 layer-2 unicast information in the link state protocols, but also 377 multicast information. This draft has defined a new Multicast Group 378 (MGROUP) PDU that can be used to advertise a set of attached, or 379 joined, multicast groups. Accordingly, it has also introduced a 380 couple more PDUs as described in the next sections for the flooding 381 and update process to work seamlessly. 383 In the Layer-2 environment, it is expected the join/leave frequency 384 of the multicast members will be much higher than unicast topology 385 changes. It is efficient to separate the updates for the group 386 membership change information from the remainder of the information 387 by placing this information in a separate PDU. This enables 388 reachability information, that would trigger an SPF, to be not 389 impacted at all. Furthermore, during SPF runs, TLVs being on 390 different PDUs which do not affect SPF need not be inspected during 391 processing. 393 The choice of a different PDU also opens the LSP-space to another 256 394 fragments to carry a large number of groups. This additional space 395 can be used judiciously to carry only multicast information. 397 The Multicast Group (MGROUP) PDU can be used to advertise a set of 398 attached, or joined, multicast groups. The MGROUP PDU is formatted 399 identical to a Level 1 Link State PDU, as described in Section 9.3 of 400 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify 401 this PDU is carrying multicast group information, rather than unicast 402 reachability information. 404 The Multicast Group PDU carries TLVs indicating multicast membership 405 information. There are three sub-TLVs of the GADDR TLV defined in 406 this document, that MAY be present in this PDU, namely, GMAC-ADDR, 407 GIP-ADDR, and GIPV6-ADDR TLVs. 409 One or more TLVs MAY be carried in a single MGROUP PDU. Future 410 multicast address TLVs MAY be defined using other type codes, and be 411 carried in an MGROUP PDU. 413 3.1. The Multicast Group Partial Sequence Number PDU 415 The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used 416 to reliably flood the MGROUP PDU following the base protocol 417 specifications. 419 3.2. The Multicast Group Complete Sequence Number PDU 421 The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is 422 used to reliably flood the MGROUP PDU following the base protocol 423 specifications. 425 3.3. Enhancements to the flooding process 427 This draft proposes that the information contained in the MGROUP-PDU 428 is in a parallel database and its update mechanisms mimic that of the 429 regular database. Nodes running IS-IS in an L2 domain MUST support 430 these additional MGROUP PDUs defined in this draft. In general, the 431 flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP- 432 CSNP PDUs uses the same update procedures as defined for the regular 433 LSP, PSNP, and CSNP PDUs. 435 For example, on P2P links CSNP is exchanged on the formation of an 436 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged 437 between the neighbors at the same time. This gets the initial 438 MGROUP-database synchronization going. After this similar actions of 439 the base protocol specifications for the regular database 440 synchronization will be maintained to keep the MGROUP-database 441 synchronized. 443 Similarly, on LAN links the DIS is responsible for sending periodic 444 CSNP transmissions. The DIS in the L2 IS-IS network domain will also 445 be responsible for sending periodic MGROUP-CSNP transmissions. The 446 update and flooding process will work in parallel for the two 447 databases and there is no further synchronization between them. 449 In general, the database synchronization is performed in parallel 450 with no interactions between the messages. However, the initial 451 triggers that start a CSNP exchange are correlated, in the sense it 452 also triggers a MGROUP-CSNP exchange. For example, during graceful 453 restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange 454 and update process will be run for the MGROUP-PDUs and restart 455 process completes after both databases have been received. 457 4. Considerations for Using L2 Information in IS-IS 459 While this document does not specify the way in which addresses 460 carried in these TLVs is used in IS-IS, two general areas of concern 461 are considered in this section: building the SPF tree when using this 462 information, and the election of designated intermediate systems 463 (DIS) in an environment using this information. 465 4.1. Building SPF Trees with Layer 2 Information 467 Each IS which is part of a single broadcast domain from a layer 2 468 perspective will build multiple SPF trees (SPT) for every IS that is 469 announced by the IS deemed to be the broadcast root. 471 We assume some mechanism for forwarding traffic to these attached 472 addresses added to the SPT is provided for in the mechanism proposing 473 the use of these extension TLVs. 475 4.2. Designated Intermediate Routers 477 A single DIS SHOULD be elected as described in [IS-IS] for each layer 478 2 broadcast domain (VLAN) for which information is being carried in 479 IS-IS. This reduces the amount of work required to flood and 480 maintain synchronized databases over the underlying media on which 481 IS-IS is running and providing layer 2 forwarding information for. 483 5. Acknowledgements 485 The authors would like to thank Les Ginsberg for his useful comments. 487 6. Security Considerations 489 This document adds no additional security risks to IS-IS, nor does it 490 provide any additional security for IS-IS. 492 7. IANA Considerations 494 This document creates three new PDU types, namely the MCAST PDU, 495 MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU 496 type to the level-1 PDUs described above and reflect it in the PDU 497 registry. 499 MCAST-PDU Level-1 PDU Type: 19 500 MCAST-CSNP-PDU Level-1 PDU Type: 22 501 MCAST-PSNP-PDU Level-1 PDU Type: 29 503 This document requires the definition a set of new ISIS TLVs, the 504 MAC-Reachability TLV (type 141), and the Group Address TLV (type 142) 505 that needs to be reflected in the ISIS TLV code-point registry. 507 This document creates a number of new sub-TLV in the numbering space 508 for the Group Address TLV and the Capability TLV. The TLV and sub- 509 TLVs are given below: 511 IIH LSP SNP MCAST MCAST 512 LSP SNP 513 MAC-RI TLV (141) - X - - - 515 GADDR-TLV (142) - - - X - 516 GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - 517 GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - 518 GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - 520 CAPABILITY.Device ID sub-tlv 5 - X - X - 521 CAPABILITY.Root Priority sub-tlv 6 - X - - - 522 CAPABILITY.Roots sub-tlv 7 - X - - - 523 IANA SHOULD manage the remaining space using the consensus method. 525 8. References 527 8.1. Normative References 529 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 530 Intra-Domain Routing Exchange Protocol for use in 531 Conjunction with the Protocol for Providing the 532 Connectionless-mode Network Service (ISO 8473)", 2005. 534 [RFC 1195] 535 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 536 Dual Environments", 1990. 538 [RFC 3847] 539 Shand, M. and L. Ginsberg, "Restart Signaling for 540 Intermediate System to Intermediate System (IS-IS)", 2004. 542 [RFC 4971] 543 Vasseur, JP. and N. Shen, "Intermediate System to 544 Intermediate System (IS-IS) Extensions for Advertising 545 Router Information", 2007. 547 8.2. Informative References 549 [RBRIDGES] 550 Perlman, R. and J. Touch, "Transparent Interconnection of 551 Lots of Links (TRILL): Problem and Applicability 552 Statement", 2008. 554 Authors' Addresses 556 David Ward 557 Cisco Systems 559 Email: wardd@cisco.com 561 Russ White 562 Cisco Systems 564 Email: riw@cisco.com 566 Dino Farinacci 567 Cisco Systems 569 Email: dino@cisco.com 571 Ayan Banerjee 572 Cisco Systems 574 Email: ayabaner@cisco.com 576 Radia Perlman 577 Sun Microsystems 579 Email: Radia.Perlman@Sun.com 581 Full Copyright Statement 583 Copyright (C) The IETF Trust (2008). 585 This document is subject to the rights, licenses and restrictions 586 contained in BCP 78, and except as set forth therein, the authors 587 retain all their rights. 589 This document and the information contained herein are provided on an 590 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 591 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 592 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 593 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 594 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 595 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 597 Intellectual Property 599 The IETF takes no position regarding the validity or scope of any 600 Intellectual Property Rights or other rights that might be claimed to 601 pertain to the implementation or use of the technology described in 602 this document or the extent to which any license under such rights 603 might or might not be available; nor does it represent that it has 604 made any independent effort to identify any such rights. Information 605 on the procedures with respect to rights in RFC documents can be 606 found in BCP 78 and BCP 79. 608 Copies of IPR disclosures made to the IETF Secretariat and any 609 assurances of licenses to be made available, or the result of an 610 attempt made to obtain a general license or permission for the use of 611 such proprietary rights by implementers or users of this 612 specification can be obtained from the IETF on-line IPR repository at 613 http://www.ietf.org/ipr. 615 The IETF invites any interested party to bring to its attention any 616 copyrights, patents or patent applications, or other proprietary 617 rights that may cover technology that may be required to implement 618 this standard. Please address the information to the IETF at 619 ietf-ipr@ietf.org.