idnits 2.17.1 draft-eastlake-trill-rfc7180bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- 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 (October 22, 2014) is 3474 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) -- Duplicate reference: RFC6325, mentioned in 'Err3002', was also mentioned in 'RFC6325'. -- Duplicate reference: RFC6325, mentioned in 'Err3003', was also mentioned in 'Err3002'. -- Duplicate reference: RFC6325, mentioned in 'Err3004', was also mentioned in 'Err3003'. -- Duplicate reference: RFC6325, mentioned in 'Err3052', was also mentioned in 'Err3004'. -- Duplicate reference: RFC6325, mentioned in 'Err3053', was also mentioned in 'Err3052'. -- Duplicate reference: RFC6325, mentioned in 'Err3508', was also mentioned in 'Err3053'. -- Obsolete informational reference (is this intentional?): RFC 6327 (Obsoleted by RFC 7177) -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) -- Obsolete informational reference (is this intentional?): RFC 7180 (Obsoleted by RFC 7780) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Mingui Zhang 3 Intended status: Proposed Standard Huawei 4 Obsoletes: 7180 Radia Perlman 5 Updates: 6325, 7177, 7179 EMC 6 Ayan Banerjee 7 Cisco 8 Anoop Ghanwani 9 Dell 10 Sujay Gupta 11 IP Infusion 12 Expires: April 21, 2015 October 22, 2014 14 TRILL: Clarifications, Corrections, and Updates 15 17 Abstract 19 Since publication of the TRILL (Transparent Interconnection of Lots 20 of Links) base protocol in 2011, active development of TRILL has 21 revealed errata in RFC 6325 and areas that could use clarifications 22 or updates. RFCs 7177, 7357, and [rfc6439bis] provide clarifications 23 and updates with respect to Adjacency, the TRILL ESADI (End Station 24 Address Distribution Information) protocol, and Appointed Forwarders 25 respectively. This document provides other known clarifications, 26 corrections, and updates. It obsoletes RFC 7180 (the previous TRILL 27 clarifications, corrections), updates RFC 7177, updates RFC 7179, and 28 updates RFC 6325. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Distribution of this document is unlimited. Comments should be sent 36 to the TRILL working group mailing list: . 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 49 Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents 54 1. Introduction (Changed)..................................5 55 1.1 Precedence (Changed)...................................5 56 1.2 Changes That Are Not Backward Compatible (Unchanged)...5 57 1.3 Terminology and Acronyms (Changed).....................6 59 2. Overloaded and/or Unreachable RBridges (Unchanged)......7 60 2.1 Reachability...........................................7 61 2.2 Distribution Trees.....................................8 62 2.3 Overloaded Receipt of TRILL Data Packets...............8 63 2.3.1 Known Unicast Receipt................................8 64 2.3.2 Multi-Destination Receipt............................9 65 2.4 Overloaded Origination of TRILL Data Packets...........9 66 2.4.1 Known Unicast Origination............................9 67 2.4.2 Multi-Destination Origination........................9 68 2.4.2.1 An Example Network................................10 69 2.4.2.2 Indicating OOMF Support...........................10 70 2.4.2.3 Using OOMF Service................................11 72 3. Distribution Trees and RPF Check (Changed).............13 73 3.1 Number of Distribution Trees (Unchanged)..............13 74 3.2 Distribution Tree Update Clarification (Unchanged)....13 75 3.3 Multicast Pruning Based on IP Address (Unchanged).....13 76 3.4 Numbering of Distribution Trees (Unchanged)...........14 77 3.5 Link Cost Directionality (Unchanged)..................14 78 3.6 Alternative RPF Check (New)...........................14 79 3.6.1 Example of the Potential Problem....................15 80 3.6.2 Solution and Discussion.............................16 82 4. Nicknames Selection (Unchanged)........................18 84 5. MTU (Maximum Transmission Unit) (Unchanged)............20 85 5.1 MTU-Related Errata in RFC 6325........................20 86 5.1.1 MTU PDU Addressing..................................20 87 5.1.2 MTU PDU Processing..................................21 88 5.1.3 MTU Testing.........................................21 89 5.2 Ethernet MTU Values...................................21 91 6. TRILL Port Modes (Unchanged)...........................23 92 7. The CFI/DEI Bit (Unchanged)............................24 94 8. Other IS-IS Considerations (Changed)...................25 95 8.1 E-L1FS Support (New)..................................25 96 8.1.1 Backward Compatibility..............................25 97 8.1.2 E-L1FS Use for Existing (sub)TLVs...................26 98 8.2 Control Packet Priorities (New).......................26 99 8.3 Unknown PDUs (New)....................................27 100 8.4 Nickname Flags APPsub-TLV (New).......................28 101 8.5 Graceful Restart (Unchanged)..........................29 103 Table of Contents (continued) 105 9. Updates to [RFC7177] (Adjacency) [Changed).............30 107 10. TRILL Header Update (New).............................31 108 10.1 Color Bit............................................32 109 10.2 Flag Word Changes (update to [RFC7179])..............32 110 10.2.1 Extended Hop Count.................................32 111 10.2.1.1 Advertising Support..............................32 112 10.2.1.2 Ingress Behavior.................................33 113 10.2.1.3 Transit Behavior.................................33 114 10.2.1.4 Egress Behavior..................................34 115 10.2.2 Extended Color Field...............................34 116 10.3 Updated Flag Word Summary............................34 118 11. IANA Considerations (Changed).........................36 119 11.1 Previously Completed IANA Actions (Unchanged)........36 120 11.2 New IANA Considerations (New)........................36 121 11.2.1 Reference Updated..................................36 122 11.2.2 The 'E' Capability Bit.............................37 123 11.2.3 NickFlags APPsub-TLV Number........................37 124 11.2.4 Update TRILL Extended Header Flags.................37 125 11.2.5 TRILL-VER Sub-TLV Capability Flags.................37 127 12. Security Considerations (Changed).....................39 129 Acknowledgements..........................................40 130 Normative References......................................41 131 Informative References....................................42 133 Appendix A: Life Cycle of a TRILL Switch Port (New).......44 134 Appendix B: Example TRILL PDUs (New)......................46 135 Appendix C: Appointed Forwarder Status Lost Couter (New)..47 137 Appendix D: Changes from [RFC7180]........................48 138 D.1 Changes...............................................48 139 D.2 Additions.............................................48 140 D.3 Deletions.............................................49 142 Appendix Z: Change History................................50 143 Authors' Addresses........................................51 145 1. Introduction (Changed) 147 Since the TRILL base protocol [RFC6325] was published in 2011, active 148 development of TRILL has revealed errors in the specification 149 [RFC6325] and several areas that could use clarifications or updates. 151 [RFC7177], [RFC7357], and [rfc6439bis] provide clarifications and 152 updates with respect to Adjacency, the TRILL ESADI (End Station 153 Address Distribution Information) protocol, and Appointed Forwarders. 154 This document provides other known clarifications, corrections, and 155 updates to [RFC6325], [RFC7177], and [RFC7179]. This document 156 obsoletes [RFC7180], the previous TRILL clarifications, corrections, 157 and updates document. 159 Sections of this document are annotated as to whether they are "New" 160 technical material, material that has been technically "Changed", or 161 material that is technically "Unchanged" by the appearance of one of 162 these three words in parenthesis at the end of the section header. A 163 section with only editorial changes is annotated as "(Unchanged)". If 164 no such notation appears, then the first notation encountered on 165 going to successively higher-level headers applies. Appendix C 166 describes changes, summarizes material added, and lists material 167 deleted. 169 1.1 Precedence (Changed) 171 In case of conflict between this document and [RFC6325], [RFC7177], 172 or [RFC7179] this document takes precedence. In addition, Section 173 1.2 (Normative Content and Precedence) of [RFC6325] is updated to 174 provide a more complete precedence ordering of the sections of 175 [RFC6325] as following, where sections to the left take precedence 176 over sections to their right: 178 4 > 3 > 7 > 5 > 2 > 6 > 1 180 1.2 Changes That Are Not Backward Compatible (Unchanged) 182 The change made by Section 3.4 below, which was also present in 183 [RFC7180], is not backward compatible with [RFC6325] but has 184 nevertheless been adopted to reduce distribution tree changes 185 resulting from topology changes. 187 The several other changes herein that are fixes to errata for 188 [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] 189 [Err3508] -- may not be backward compatible with previous 190 implementations that conformed to errors in the specification. 192 1.3 Terminology and Acronyms (Changed) 194 This document uses the acronyms defined in [RFC6325], some of which 195 are repeated below for convenience, along with some additional 196 acronyms and terms as follows: 198 CFI - Canonical Format Indicator [802]. 200 DEI - Drop Eligibility Indicator [802.1Q-2011]. 202 EISS - Enhanced Internal Sublayer Service. 204 OOMF - Overload Originated Multi-destination Frame. 206 RBridge - An alternative name for a TRILL Switch. 208 RPFC - Reverse Path Forwarding Check. 210 SNPA - SubNetwork Point of Attachment (for example, MAC address). 212 TRILL - Transparent Interconnection of Lots of Links (or Tunneled 213 Routing in the Link Layer). 215 TRILL Switch - A device implementing the TRILL protocol. An 216 alternative name for an RBridge. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in 221 [RFC2119]. 223 2. Overloaded and/or Unreachable RBridges (Unchanged) 225 In this Section 2, the term "neighbor" refers only to actual RBridges 226 and ignores pseudonodes. 228 RBridges may be in overload as indicated by the [IS-IS] overload flag 229 in their LSPs (Link State PDUs). This means that either (1) they are 230 incapable of holding the entire link-state database and thus do not 231 have a view of the entire topology or (2) they have been configured 232 to have the overload bit set. Although networks should be engineered 233 to avoid actual link-state overload, it might occur under various 234 circumstances. For example, if a large campus included one or more 235 low-end TRILL Switches. 237 It is a common operational practice to set the overload bit in an 238 [IS-IS] router (such as a TRILL Switch) when performing maintenance 239 on that router that might affect its ability to correctly forward 240 packets; this will usually leave the router reachable for maintenance 241 traffic, but transit traffic will not be routed through it. (Also, 242 in some cases, TRILL provides for setting the overload bit in the 243 pseudonode of a link to stop TRILL Data traffic on an access link 244 (see Section 4.9.1 of [RFC6325]).) 246 [IS-IS] and TRILL make a reasonable effort to do what they can even 247 if some TRILL Switches/routers are in overload. They can do 248 reasonably well if a few scattered nodes are in overload. However, 249 actual least-cost paths are no longer assured if any TRILL Switches 250 are in overload. 252 For the effect of overload on the appointment of forwarders, see 253 [rfc6439bis]. 255 2.1 Reachability 257 Packets are not least-cost routed through an overloaded TRILL Switch, 258 although they may originate or terminate at an overloaded TRILL 259 Switch. In addition, packets will not be least-cost routed over 260 links with cost 2**24 - 1 [RFC5305]; such links are reserved for 261 traffic- engineered packets, the handling of which is beyond the 262 scope of this document. 264 As a result, a portion of the campus may be unreachable for least- 265 cost routed TRILL Data because all paths to it would be through 266 either a link with cost 2**24 - 1 or through an overloaded RBridge. 267 For example, an RBridge (TRILL Switch) RB1 is not reachable by TRILL 268 Data if all of its neighbors are connected to RB1 by links with cost 269 2**24 - 1. Such RBridges are called "data unreachable". 271 The link-state database at an RBridge RB1 can also contain 272 information on TRILL Switches that are unreachable by IS-IS link- 273 state flooding due to link or RBridge failures. When such failures 274 partition the campus, the TRILL Switches adjacent to the failure and 275 on the same side of the failure as RB1 will update their LSPs to show 276 the lack of connectivity, and RB1 will receive those updates. As a 277 result, RB1 will be aware of the partition. Nodes on the far side of 278 the partition are both IS-IS unreachable and data unreachable. 279 However, LSPs held by RB1 for TRILL Switches on the far side of the 280 failure will not be updated and may stay around until they time out, 281 which could be tens of minutes or longer. (The default in [IS-IS] is 282 twenty minutes.) 284 2.2 Distribution Trees 286 An RBridge in overload cannot be trusted to correctly calculate 287 distribution trees or correctly perform the RPFC (Reverse-Path 288 Forwarding Check). Therefore, it cannot be trusted to forward multi- 289 destination TRILL Data packets. It can only appear as a leaf node in 290 a TRILL multi-destination distribution tree. Furthermore, if all the 291 immediate neighbors of an RBridge are overloaded, then it is omitted 292 from all trees in the campus and is unreachable by multi-destination 293 packets. 295 When an RBridge determines what nicknames to use as the roots of the 296 distribution trees it calculates, it MUST ignore all nicknames held 297 by TRILL Switches that are in overload or are data unreachable. When 298 calculating RPFCs for multi-destination packets, an RBridge RB1 MAY, 299 to avoid calculating unnecessary RPFC state, ignore any trees that 300 cannot reach to RB1 even if other RBridges list those trees as trees 301 that other TRILL Switches might use. (But see Section 3.) 303 2.3 Overloaded Receipt of TRILL Data Packets 305 The receipt of TRILL Data packets by overloaded RBridge RB2 is 306 discussed in the subsections below. In all cases, the normal Hop 307 Count decrement is performed, and the TRILL Data packets is discarded 308 if the result is less than one or if the egress nickname is illegal. 310 2.3.1 Known Unicast Receipt 312 RB2 will not usually receive unicast TRILL Data packets unless it is 313 the egress, in which case it egresses and delivers the data normally. 314 If RB2 receives a unicast TRILL Data packet for which it is not the 315 egress, perhaps because a neighbor does not yet know it is in 316 overload, RB2 MUST NOT discard the packet because the egress is an 317 unknown nickname as it might not know about all nicknames due to its 318 overloaded condition. If any neighbor, other than the neighbor from 319 which it received the packet, is not overloaded, it MUST attempt to 320 forward the packet to one of those neighbors selected at random 321 [RFC4086]. If there is no such neighbor, the packet is discarded. 323 2.3.2 Multi-Destination Receipt 325 If RB2 in overload receives a multi-destination TRILL Data packet, 326 RB2 MUST NOT apply an RPFC since, due to overload, it might not do so 327 correctly. RB2 egresses and delivers the frame locally where it is 328 Appointed Forwarder for the frame's VLAN, subject to any multicast 329 pruning. But since, as stated above, RB2 can only be the leaf of a 330 distribution tree, it MUST NOT forward a multi-destination TRILL Data 331 packet (except as an egressed native frame where RB2 is Appointed 332 Forwarder). 334 2.4 Overloaded Origination of TRILL Data Packets 336 Overloaded origination of unicast TRILL Data packets with known 337 egress and of multi-destination packets is discussed in the 338 subsections below. 340 2.4.1 Known Unicast Origination 342 When an overloaded RBridge RB2 ingresses or creates a known 343 destination unicast data packet, it delivers it locally if the 344 destination is local. Otherwise, RB2 unicasts it to any neighbor 345 TRILL Switch that is not overloaded. It MAY use what routing 346 information it has to help select the neighbor. 348 2.4.2 Multi-Destination Origination 350 Overloaded RBridge RB2 ingressing or creating a multi-destination 351 data packet is more complex than for the known unicast case as 352 discussed below. 354 2.4.2.1 An Example Network 356 For example, consider the network below in which, for simplicity, end 357 stations and any bridges are not shown. There is one distribution 358 tree of which RB4 is the root, as represented by double lines. Only 359 RBridge RB2 is overloaded. 361 +-----+ +-----+ +-----+ +-----+ 362 | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 | 363 +-----+ +--+--+ +-++--+ +--+--| 364 | || | 365 +---+---+ || | 366 +------+RB2(ov)|======++ | 367 | +-------+ || | 368 | || | 369 +--+--+ +-----+ ++==++=++ +--+--+ 370 | RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 | 371 +-----+ +-----+ ++=====++ +-----+ 373 Since RB2 is overloaded, it does not know what the distribution tree 374 or trees are for the network. Thus, there is no way it can provide 375 normal TRILL Data service for multi-destination native frames. So 376 RB2 tunnels the frame to a neighbor that is not overloaded if it has 377 such a neighbor that has signaled that it is willing to offer this 378 service. RBridges indicate this in their Hellos as described below. 379 This service is called OOMF (Overload Originated Multi- destination 380 Frame) service. 382 - The multi-destination frame MUST NOT be locally distributed in 383 native form at RB2 before tunneling to a neighbor because this 384 would cause the frame to be delivered twice. For example, if RB2 385 locally distributed a multicast native frame and then tunneled it 386 to RB5, RB2 would get a copy of the frame when RB3 transmitted it 387 as a TRILL Data packet on the multi-access RB2-RB3-RB4 link. 388 Since RB2 would, in general, not be able to tell that this was a 389 frame it had tunneled for distribution, RB2 would decapsulate it 390 and locally distribute it a second time. 392 - On the other hand, if there is no neighbor of RB2 offering RB2 the 393 OOMF service, RB2 cannot tunnel the frame to a neighbor. In this 394 case, RB2 MUST locally distribute the frame where it is Appointed 395 Forwarder for the frame's VLAN and optionally subject to multicast 396 pruning. 398 2.4.2.2 Indicating OOMF Support 400 An RBridge RB3 indicates its willingness to offer the OOMF service to 401 RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit 402 associated with the SNPA (SubNetwork Point of Attachment, also known 403 as MAC address) of RB2 on the link (see IANA Considerations). 404 Overloaded RBridge RB2 can only distribute multi-destination TRILL 405 Data packets to the campus if a neighbor of RB2 not in overload 406 offers RB2 the OOMF service. If RB2 does not have OOMF service 407 available to it, RB2 can still receive multi-destination packets from 408 non-overloaded neighbors and, if RB2 should originate or ingress such 409 a frame, it distributes it locally in native form. 411 2.4.2.3 Using OOMF Service 413 If RB2 sees this OOMF (Overload Originated Multi-destination Frame) 414 service advertised for it by any of its neighbors on any link to 415 which RB2 connects, it selects one such neighbor by a means beyond 416 the scope of this document. Assuming RB2 selects RB3 to handle 417 multi-destination packets it originates, RB2 MUST advertise in its 418 LSP that it might use any of the distribution trees that RB3 419 advertises so that the RPFC will work in the rest of the campus. 420 Thus, notwithstanding its overloaded state, RB2 MUST retain this 421 information from RB3 LSPs, which it will receive as it is directly 422 connected to RB3. 424 RB2 then encapsulates such frames as TRILL Data packets to RB3 as 425 follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held 426 by RB2, and, since RB2 cannot tell what distribution tree RB3 will 427 use, egress nickname = a special nickname indicating an OOMF packet 428 (see IANA Considerations). RB2 then unicasts this TRILL Data packet 429 to RB3. (Implementation of Item 4 in Section 4 below provides 430 reasonable assurance that, notwithstanding its overloaded state, the 431 ingress nickname used by RB2 will be unique within at least the 432 portion of the campus that is IS-IS reachable from RB2.) 434 On receipt of such a packet, RB3 does the following: 436 - changes the Egress Nickname field to designate a distribution tree 437 that RB3 normally uses, 438 - sets the M bit to one, 439 - changes the Hop Count to the value it would normally use if it 440 were the ingress, and 441 - forwards the packet on that tree. 443 RB3 MAY rate limit the number of packets for which it is providing 444 this service by discarding some such packets from RB2. The provision 445 of even limited bandwidth for OOMFs by RB3, perhaps via the slow 446 path, may be important to the bootstrapping of services at RB2 or at 447 end stations connected to RB2, such as supporting DHCP and ARP/ND 448 (Address Resolution Protocol / Neighbor Discovery). (Everyone 449 sometimes needs a little OOMF (pronounced "oomph") to get off the 450 ground.) 452 3. Distribution Trees and RPF Check (Changed) 454 Two corrections, a clarification, and two updates related to 455 distribution trees appear in the subsections below along with an 456 alternative, stronger RPF (Reverse Path Forwarding) Check. See also 457 Section 2.2. 459 3.1 Number of Distribution Trees (Unchanged) 461 In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the 462 parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. 463 It should read "(up to k if j is zero or the minimum of (j, k) if j 464 is non-zero)". 466 3.2 Distribution Tree Update Clarification (Unchanged) 468 When a link-state database change causes a change in the distribution 469 tree(s), there are several possibilities. If a tree root remains a 470 tree root but the tree changes, then local forwarding and RPFC 471 entries for that tree should be updated as soon as practical. 472 Similarly, if a new nickname becomes a tree root, forwarding and RPFC 473 entries for the new tree should be installed as soon as practical. 474 However, if a nickname ceases to be a tree root and there is 475 sufficient room in local tables, the forwarding and RPFC entries for 476 the former tree MAY be retained so that any multi-destination TRILL 477 Data packets already in flight on that tree have a higher probability 478 of being delivered. 480 3.3 Multicast Pruning Based on IP Address (Unchanged) 482 The TRILL base protocol specification [RFC6325] provides for and 483 recommends the pruning of multi-destination packet distribution trees 484 based on the location of IP multicast routers and listeners; however, 485 multicast listening is identified by derived MAC addresses as 486 communicated in the Group MAC Address sub-TLV [RFC7176]. 488 TRILL Switches MAY communicate multicast listeners and prune 489 distribution trees based on the actual IPv4 or IPv6 multicast 490 addresses involved. Additional Group Address sub-TLVs are provided 491 in [RFC7176] to carry this information. A TRILL Switch that is only 492 capable of pruning based on derived MAC address SHOULD calculate and 493 use such derived MAC addresses from multicast listener IPv4/IPv6 494 address information it receives. 496 3.4 Numbering of Distribution Trees (Unchanged) 498 Section 4.5.1 of [RFC6325] specifies that, when building distribution 499 tree number j, node (RBridge) N that has multiple possible parents in 500 the tree is attached to possible parent number j mod p. Trees are 501 numbered starting with 1, but possible parents are numbered starting 502 with 0. As a result, if there are two trees and two possible 503 parents, in tree 1, parent 1 will be selected, and in tree 2, parent 504 0 will be selected. 506 This is changed so that the selected parent MUST be (j-1) mod p. As 507 a result, in the case above, tree 1 will select parent 0, and tree 2 508 will select parent 1. This change is not backward compatible with 509 [RFC6325]. If all RBridges in a campus do not determine distribution 510 trees in the same way, then for most topologies, the RPFC will drop 511 many multi-destination packets before they have been properly 512 delivered. 514 3.5 Link Cost Directionality (Unchanged) 516 Distribution tree construction, like other least-cost aspects of 517 TRILL, works even if link costs are asymmetric, so the cost of the 518 hop from RB1 to RB2 is different from the cost of the hop from RB2 to 519 RB1. However, it is essential that all RBridges calculate the same 520 distribution trees, and thus, all must either use the cost away from 521 the tree root or the cost towards the tree root. As corrected in 522 [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It 523 says: 525 In other words, the set of potential parents for N, for the tree 526 rooted at R, consists of those that give equally minimal cost 527 paths from N to R and ... 529 but the text should say "from R to N": 531 In other words, the set of potential parents for N, for the tree 532 rooted at R, consists of those that give equally minimal cost 533 paths from R to N and ... 535 3.6 Alternative RPF Check (New) 537 [RFC6325] mandates a Reverse Path Forwarding (RPF) Check on multi- 538 destination TRILL data packets to avoid possible multiplication 539 and/or looping of multi-destination traffic during TRILL campus 540 topology transients. This check is logically performed at each TRILL 541 switch input port and determines, based on where the packet started 542 (the ingress nickname) and the tree on which it is being distributed, 543 whether it is arriving on the expected port. If not, the packet is 544 silently discarded. This check is fine for point-to-point links; 545 however, there are rare circumstances involving multi-access 546 ("broadcast") links where a packet can be duplicated despite this RPF 547 Check and other checks performed by TRILL. 549 Section 3.6.1 gives an example of the potential problem and Section 550 3.6.2 specifies a solution. This solution is an alternative stronger 551 RPF Check that TRILL Switches can implemented in place of the RFF 552 Check in [RFC6325]. 554 3.6.1 Example of the Potential Problem 556 Consider this network: 558 F--A--B--C--o--D 560 All the links except the link between C and D are point-to-point 561 links. C and D are connected over a broadcast link represented by 562 the pseudonode "o". For example, C and D could be connected by a 563 bridged LAN. (Bridged LANs are transparent to TRILL.) 565 Although the choice of root is unimportant here, assume that D or F 566 is chosen as the root of a distribution tree so it is obvious the 567 tree looks just like the diagram above. 569 Now assume a link comes up from A to the same bridged LAN. The 570 network then looks like this: 572 +--------+ 573 | | 574 F--A--B--C--o--D 576 Let's say the resulting tree in steady state includes all links 577 except the B-C link. After the network has converged, a packet that 578 starts out from F will go F->A. Then A will send one copy on the A-B 579 link and another copy into the bridge LAN from which it will be 580 received by C and D. 582 Now consider a transition stage where A and D have acted on the new 583 LSPs and programmed their forwarding plane, while B and C have not 584 yet done so. This means that B and C both consider the link between 585 them to still be part of the tree. In this case, a packet that starts 586 out from F and reaches A will be copied by A into the A-B link and to 587 the bridge LAN. D's RPF check says to accept packets on this tree 588 coming from F over its port on the bridged LAN, so it gets accepted. 589 D is also adjacent to A on the tree, so the tree adjacency check, a 590 separate check mandated by [RFC6325] also passes. 592 However, the packet that gets to B gets sent out by B to C. C's RPF 593 check still has the old state, and it thinks the packet is OK. C 594 sends the packet along the old tree, which is into the bridge LAN. D 595 receives one more packet, but the tree adjacency check passes at D 596 because C is adjacent to D in the new tree as well. The RPF Check 597 also passes at D because D's port on the bridged LAN is OK for 598 receiving packets from F. 600 So, during this transient state, D gets duplicates of every multi- 601 destination packet ingressed at F (unless the packet gets pruned) 602 until B and C act on the new LSPs and program their hardware tables. 604 3.6.2 Solution and Discussion 606 The problem stems from the RPF Check in [RFC6325] depending only on 607 the port at which a TRILL data packet is received, the ingress 608 nickname, and the tree being used, that is, a check if {ingress 609 nickname, tree, input port} is a valid combination according to the 610 receiving TRILL switch's view of the campus topology. A multi-access 611 link actually has multiple adjacencies overlaid on one physical link 612 and to avoid the problem shown in Section 3.6.1, a stronger check is 613 needed that includes the Layer 2 source address of the TRILL Data 614 packet being received. (TRILL is a Layer 3 protocol and TRILL 615 switches are true routers that logically strip the Layer 2 header 616 from any arriving TRILL data packets and add the appropriate new 617 Layer 2 header to any outgoing TRILL Data packet to get it to the 618 next TRILL switch, so the Layer 2 source address in a TRILL Data 619 packet identifies the immediately previous TRILL Switch that 620 forwarded the packet.) 622 What is needed, instead of checking the validity of the triplet 623 {ingress nickname, tree, input port} is to check that the quadruplet 624 {ingress nickname, source SNPA, tree, input port} is valid (where 625 "source SNPA" (Sub-Network Point of Access) is the Outer.MacSA for an 626 Ethernet link). Although it is true that [RFC6325] also requires a 627 check that a multi-destination TRILL Data packet is from a TRILL 628 switch that is adjacent in the distribution tree being used, this is 629 a separate check from the RPF Check and these two independent checks 630 are not as powerful as the single unified check for a valid 631 quadruplet. 633 However, this stronger RPF Check is not without cost. In the simple 634 case of a multi-access link where each TRILL switch has only one port 635 on the link, it merely increases the size of validity entries by 636 adding the source SNPA (Outer.MacSA). However, assume some TRILL 637 Switch RB1 has N ports attached to a multi-access link. RB1 is 638 permitted to load split multi-destination traffic it is sending into 639 the multi-access link across those ports (Section 4.4.4 [RFC6325]). 640 Assume RB2 is another TRILL Switch on the link and RB2 is 641 distribution tree adjacent to RB1. The number of validity quadruplets 642 at RB2 for ingress nicknames whose multi-destination traffic would 643 arrive through RB1 is multiplied by N because RB2 has to accept such 644 traffic from any of the ports RB1 has on the access-link. Although 645 such instances seem to be very rare in practice, N could in principle 646 be tens or even a hundred or more ports, vastly increasing the RPF 647 check state at RB2 when this stronger RPF check is used. 649 Another potential cost of the stronger RPF Check is increased 650 transient loss of multi-destination TRILL data packets during a 651 topology change. For TRILL switch D, the new stronger RPF Check is 652 (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1) while the old 653 one was ( tree->A, Outer.MacSA=C, ingress=A, arrival port=if1). 654 Suppose both A and B have switched to the new tree for multicast 655 forwarding while D has not updated its RPF Check yet, then the 656 multicast packet will be dropped at D's if1. Since D still expects 657 packet from "Outer.MacSA=C". But we do not have this packet loss 658 issue if the weaker triplet check (tree->A, ingress=A, arrival 659 port=if1) is used. Thus, the stronger check can increase the RPF 660 Check discard of multi-destination packets during topology 661 transients. 663 Because of these potential costs, implementation of this stronger RPF 664 Check is optional; however, the TRILL protocol is updated to provide 665 that TRILL Switches MUST, for multi-destination packets, either 666 implement the RPF and other checks in [RFC6325] or implement this 667 stronger RPF Check as a substitute for the [RFC6325] RPF and tree 668 adjacency checks. 670 4. Nicknames Selection (Unchanged) 672 Nickname selection is covered by Section 3.7.3 of [RFC6325]. 673 However, the following should be noted: 675 1. The second sentence in the second bullet item in Section 3.7.3 of 676 [RFC6325] on page 25 is erroneous [Err3002] and is corrected as 677 follows: 679 o The occurrence of "IS-IS ID (LAN ID)" is replaced with 680 "priority". 682 o The occurrence of "IS-IS System ID" is replaced with "seven- 683 byte IS-IS ID (LAN ID)". 685 The resulting corrected sentence in [RFC6325] reads as follows: 687 "If RB1 chooses nickname x, and RB1 discovers, through receipt 688 of an LSP for RB2 at any later time, that RB2 has also chosen 689 x, then the RBridge or pseudonode with the numerically higher 690 priority keeps the nickname, or if there is a tie in priority, 691 the RBridge with the numerically higher seven-byte IS-IS ID 692 (LAN ID) keeps the nickname, and the other RBridge MUST select 693 a new nickname." 695 2. In examining the link-state database for nickname conflicts, 696 nicknames held by IS-IS unreachable TRILL Switches MUST be 697 ignored, but nicknames held by IS-IS reachable TRILL Switches MUST 698 NOT be ignored even if they are data unreachable. 700 3. An RBridge may need to select a new nickname, either initially 701 because it has none or because of a conflict. When doing so, the 702 RBridge MUST consider as available all nicknames that do not 703 appear in its link-state database or that appear to be held by IS- 704 IS unreachable TRILL Switches; however, it SHOULD give preference 705 to selecting new nicknames that do not appear to be held by any 706 TRILL Switch in the campus, reachable or unreachable, so as to 707 minimize conflicts if IS-IS unreachable TRILL Switches later 708 become reachable. 710 4. An RBridge, even after it has acquired a nickname for which there 711 appears to be no conflicting claimant, MUST continue to monitor 712 for conflicts with the nickname or nicknames it holds. It does so 713 by checking in LSP PDUs it receives that should update its link- 714 state database for the following: any occurrence of any of its 715 nicknames held with higher priority by some other TRILL Switch 716 that is IS-IS reachable from it. If it finds such a conflict, it 717 MUST select a new nickname, even when in overloaded state. (It is 718 possible to receive an LSP that should update the link-state 719 database but does not do so due to overload.) 721 5. In the very unlikely case that an RBridge is unable to obtain a 722 nickname because all valid RBridge nicknames (0x0001 through 723 0xFFBF inclusive) are in use with higher priority by IS-IS 724 reachable TRILL Switches, it will be unable to act as an ingress, 725 egress, or tree root but will still be able to function as a 726 transit TRILL Switch. Although it cannot be a tree root, such an 727 RBridge is included in distribution trees computed for the campus 728 unless all its neighbors are overloaded. It would not be possible 729 to send a unicast RBridge Channel message specifically to such a 730 TRILL Switch [RFC7178]; however, it will receive unicast RBridge 731 Channel messages sent by a neighbor to the Any-RBridge egress 732 nickname and will receive appropriate multi-destination RBridge 733 Channel messages. 735 5. MTU (Maximum Transmission Unit) (Unchanged) 737 MTU values in TRILL key off the originatingL1LSPBufferSize value 738 communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The 739 campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is 740 the minimum value of originatingL1LSPBufferSize for the RBridges in a 741 campus, but not less than 1470. The MTU testing mechanism and 742 limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and 743 thus that IS-IS can operate properly. 745 If nothing is known about the MTU of the links or the 746 originatingL1LSPBufferSize of other RBridges in a campus, the 747 originatingL1LSPBufferSize for an RBridge should default to the 748 minimum of the LSP size that its TRILL IS-IS software can handle and 749 the minimum MTU of the ports that it might use to receive or transmit 750 LSPs. If an RBridge does have knowledge of link MTUs or other 751 RBridge originatingL1LSPBufferSize, then, to avoid the necessity to 752 regenerate the local LSPs using a different maximum size, the 753 RBridge's originatingL1LSPBufferSize SHOULD be configured to the 754 minimum of (1) the smallest value that other RBridges are or will be 755 announcing as their originatingL1LSPBufferSize and (2) a value small 756 enough that the campus will not partition due to a significant number 757 of links with limited MTU. However, as provided in [RFC6325], in no 758 case can originatingL1LSPBufferSize be less than 1470. In a well- 759 configured campus, to minimize any LSP regeneration due to re-sizing, 760 all RBridges will be configured with the same 761 originatingL1LSPBufferSize. 763 Section 5.1 below corrects errata in [RFC6325], and Section 5.2 764 clarifies the meaning of various MTU limits for TRILL Ethernet links. 766 5.1 MTU-Related Errata in RFC 6325 768 Three MTU-related errata in [RFC6325] are corrected in the 769 subsections below. 771 5.1.1 MTU PDU Addressing 773 Section 4.3.2 of [RFC6325] incorrectly states that multi-destination 774 MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links 775 with the All-RBridges multicast address as the Outer.MacDA [Err3004]. 776 As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be 777 sent to the All-IS-IS-RBridges multicast address. 779 5.1.2 MTU PDU Processing 781 As discussed in [RFC6325] and, in more detail, in [RFC7177], MTU- 782 probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of 783 [RFC6325] erroneously does not allow for this possibility [Err3003]. 784 It is corrected by replacing Item numbered "1" in Section 4.6.2 of 785 [RFC6325] with the following quoted text to which TRILL Switches MUST 786 conform: 788 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All- 789 IS-IS-RBridges or the unicast MAC address of the receiving 790 RBridge port, the frame is handled as described in Section 791 4.6.2.1" 793 The reference to "Section 4.6.2.1" in the above quoted text is to 794 that section in [RFC6325]. 796 5.1.3 MTU Testing 798 The last two sentences of Section 4.3.2 of [RFC6325] have errors 799 [Err3053]. They currently read: 801 "If X is not greater than Sz, then RB1 sets the "failed minimum 802 MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X 803 > Sz, then RB1 advertises the largest tested X for each adjacency 804 in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise 805 X as an attribute of the link to RB2 in RB1's LSP." 807 They should read: 809 "If X is not greater than or equal to Sz, then RB1 sets the 810 "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X 811 succeeds, and X >= Sz, then RB1 advertises the largest tested X 812 for each adjacency in the TRILL Hellos RB1 sends on that link, and 813 RB1 MAY advertise X as an attribute of the link to RB2 in RB1's 814 LSP." 816 5.2 Ethernet MTU Values 818 originatingL1LSPBufferSize is the maximum permitted size of LSPs 819 starting with the 0x83 Intradomain Routeing Protocol Discriminator 820 byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 821 bytes. (This is because, in its previous life as DECnet Phase V, IS- 822 IS was encoded using the SNAP SAP (Sub-Network Access Protocol 823 Service Access Point) [RFC7042] format, which takes 8 bytes of 824 overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When 825 standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) 826 encoding, this default could have been increased by a few bytes but 827 was not.) 829 In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This 830 allows 27 bytes of headroom or safety margin to accommodate legacy 831 devices with the classic Ethernet maximum MTU despite headers such as 832 an Outer.VLAN. 834 Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet 835 links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of 836 the PDU starting just after the L2-IS-IS Ethertype and ending just 837 before the Ethernet Frame Check Sequence (FCS)) does not to exceed 838 Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 839 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded by an 840 amount that depends on the size being tested (which may exceed Sz). 842 Sz does not limit TRILL Data packets. They are only limited by the 843 MTU of the devices and links that they actually pass through; 844 however, links that can accommodate IS-IS PDUs up to Sz would 845 accommodate, with a generous safety margin, TRILL Data packet 846 payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending 847 just before the FCS. 849 Most modern Ethernet equipment has ample headroom for frames with 850 extensive headers and is sometimes engineered to accommodate 9K byte 851 jumbo frames. 853 6. TRILL Port Modes (Unchanged) 855 Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports 856 but may not be completely clear on the effects of various 857 combinations of bits. 859 The table below explicitly indicates the effect of all possible 860 combinations of the TRILL port mode bits. "*" in one of the first 861 four columns indicates that the bit can be either zero or one. The 862 following columns indicate allowed frame types. The Disable bit 863 normally disables all frames, but, as an implementation choice, some 864 or all low-level Layer 2 control message can still be sent or 865 received. Examples of Layer 2 control messages are those control 866 frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP 867 link negotiation messages [RFC6361]. 869 +-+-+-+-+--------+-------+-------+-------+-------+ 870 |D| | | | | | | | | 871 |i| |A| | | | TRILL | | | 872 |s| |c|T| |native | Data | | | 873 |a| |c|r| |ingress| | | | 874 |b|P|e|u| | | LSP | | | 875 |l|2|s|n|Layer 2 |native | SNP | TRILL | P2P | 876 |e|P|s|k|Control |egress | MTU | Hello | Hello | 877 +-+-+-+-+--------+-------+-------+-------+-------+ 878 |0|0|0|0| Yes | Yes | Yes | Yes | No | 879 +-+-+-+-+--------+-------+-------+-------+-------+ 880 |0|0|0|1| Yes | No | Yes | Yes | No | 881 +-+-+-+-+--------+-------+-------+-------+-------+ 882 |0|0|1|0| Yes | Yes | No | Yes | No | 883 +-+-+-+-+--------+-------+-------+-------+-------+ 884 |0|0|1|1| Yes | No | No | Yes | No | 885 +-+-+-+-+--------+-------+-------+-------+-------+ 886 |0|1|0|*| Yes | No | Yes | No | Yes | 887 +-+-+-+-+--------+-------+-------+-------+-------+ 888 |0|1|1|*| Yes | No | No | No | Yes | 889 +-+-+-+-+--------+-------+-------+-------+-------+ 890 |1|*|*|*|Optional| No | No | No | No | 891 +-+-+-+-+--------+-------+-------+-------+-------+ 893 The formal name of the "access bit" above is the "TRILL traffic 894 disable bit". The formal name of the "trunk bit" is the "end-station 895 service disable bit" [RFC6325]. 897 7. The CFI/DEI Bit (Unchanged) 899 In May 2011, the IEEE promulgated [802.1Q-2011], which changed the 900 meaning of the bit between the priority and VLAN ID bits in the 901 payload of C-VLAN tags. Previously, this bit was called the CFI 902 (Canonical Format Indicator) bit [802] and had a special meaning in 903 connection with IEEE 802.5 (Token Ring) frames. Now, under 904 [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar 905 to that bit in S-VLAN/B-VLAN tags where this bit has always been a 906 DEI bit. 908 The TRILL base protocol specification [RFC6325] assumed, in effect, 909 that the link by which end stations are connected to TRILL Switches 910 and the restricted virtual link provided by the TRILL Data packet are 911 IEEE 802.3 Ethernet links on which the CFI bit is always zero. 912 Should an end station be attached by some other type of link, such as 913 a Token Ring link, [RFC6325] implicitly assumed that such frames 914 would be canonicalized to 802.3 frames before being ingressed, and 915 similarly, on egress, such frames would be converted from 802.3 to 916 the appropriate frame type for the link. Thus, [RFC6325] required 917 that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in 918 Section 4.1.1 of [RFC6325], always be zero. 920 However, for TRILL Switches with ports conforming to the change 921 incorporated in the IEEE 802.1Q-2011 standard, the bit in the 922 Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by 923 the EISS (Enhanced Internal Sublayer Service) interface on ingressing 924 a native frame. Similarly, this bit MUST be provided to the EISS 925 when transiting or egressing a TRILL Data packet. As with the 3-bit 926 Priority field, the DEI bit to use in forwarding a transit packet 927 MUST be taken from the Inner.VLAN. The exact effect on the 928 Outer.VLAN DEI and priority bits and whether or not an Outer.VLAN 929 appears at all on the wire for output frames may depend on output 930 port configuration. 932 TRILL campuses with a mixture of ports, some compliant with 933 [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards, 934 especially if they have actual Token Ring links, may operate 935 incorrectly and may corrupt data, just as a bridged LAN with such 936 mixed ports and links would. 938 8. Other IS-IS Considerations (Changed) 940 This section covers E-L1FS Support, Control Packet Priorities, 941 Unknown PDUs, the Nickname Flags APPsub-TLV, and Graceful Restart. 943 8.1 E-L1FS Support (New) 945 TRILL switches MUST support Extended Level 1 Flooding Scope PDUs (E- 946 L1FS) [RFC7356] and MUST include a Scoped Flooding Support TLV 947 [RFC7356] in all TRILL Hellos they send indicating support for this 948 scope and any other FS-LSP scopes that they support. This support 949 increases the number of fragments available for link state 950 information by over two orders of magnitude. (See Section 9 for 951 further information on support of the Scoped Flooding Support TLV.) 953 In addition, TRILL switches MUST advertise their support of E-L1FS 954 flooding in a TRILL Version sub-TLV capability bit (see [RFC7176] and 955 Section 11.2). This bit is used by a TRILL switch, say RB1, to 956 determine support for E-L1FS by some remote RBx. The alternative of 957 simply looking for an E-L1FS FS-LSP originated by RBx fails because 958 (1) RBx might support E-L1FS flooding but not be originating any E- 959 L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs there 960 might, due to legacy TRILL switches in the campus, be no path between 961 RBx and RB1 through TRILL switches supporting E-L1FS flooding. If 962 that were the case, no E-L1FS FS-LSP originated by RBx could get to 963 RB1. 965 8.1.1 Backward Compatibility 967 A TRILL campus might contain TRILL switches supporting E-L1FS 968 flooding and legacy TRILL switches that do not support E-L1FS or 969 perhaps do not support any [RFC7356] scopes. 971 A TRILL switch conformant to this document can always tell which 972 adjacent TRILL switches support E-L1FS flooding from the adjacency 973 table entries on its ports (see Section 9). In addition, such a TRILL 974 switch can tell which remote TRILL switches in a campus support E- 975 L1FS by the presence of a TRILL Version sub-TLV in that TRILL 976 switch's LSP with the E-L1FS support bit set in the Capabilities 977 field; this capability bit is ignored for adjacent TRILL switches for 978 which only the adjacency table entry is consulted to determine E-L1FS 979 support. 981 TRILL specifications making use of E-L1FS MUST specify how situations 982 involving mixed TRILL campus of TRILL switches will be handled. 984 8.1.2 E-L1FS Use for Existing (sub)TLVs 986 In a campus where all TRILL switches support E-L1FS, all TRILL sub- 987 TLVs listed in Section 2.3 of [RFC7176], except the TRILL Version 988 sub-TLV, MAY be advertised by inclusion in Router Capability or MT- 989 Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL Version sub- 990 TLV still MUST appear in an LSP fragment zero.) 992 In a mixed campus where some TRILL switches support E-L1FS and some 993 do not, then only the following four sub-TLVs of those listed in 994 Section 2.3 of [RFC7176] can appear in E-L1FS and then only under the 995 conditions discussed below. In the following list, each sub-TLV is 996 preceded by an abbreviated acronym used only in this Section 8.1.2: 998 IV: Interested VLANs and Spanning Tree Roots sub-TLV 999 VG: VLAN Groups sub-TLV 1000 IL: Interested Labels and Spanning Tree Roots sub-TLV 1001 LG: Label Groups sub-TLV 1003 An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an 1004 E-L1FS FS-LSP and MUST be advertised in an LSP unless the following 1005 conditions are met: 1006 - E-L1FS is supported by all of the TRILL switches that are data 1007 reachable from RB1 and are interested in the VLANs mentioned in 1008 the IV or VG sub-TLV, and 1009 - there is E-L1FS connectivity between all such TRILL switches in 1010 the campus interested in the VLANs mentioned in the IV or VG sub- 1011 TLV (connectivity involving only intermediate TRILL switches that 1012 also support E-L1FS). 1014 Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS 1015 LSP by any TRILL switch that has enough room in its LSPs. 1017 The conditions for using E-L1FS for the IL and LG sub-TLVs are the 1018 same as for IV and VG but with Fine Grained Labels [RFC7172] 1019 substituted for VLANs. 1021 Note, for example, that the above would permit a contiguous subset 1022 of the campus that supported Fine Grained Labels and E-L1FS to use 1023 E-L1FS to advertise IL and LG sub-TLVs even if the remainder of 1024 the campus did not support Fine Grained Labels or E-L1FS. 1026 8.2 Control Packet Priorities (New) 1028 When deciding what packet to send out a port, control packets used to 1029 establish and maintain adjacency between TRILL switches SHOULD be 1030 treated as being in the highest priority category. This includes 1031 TRILL IS-IS Hello and MTU PDUs and possibly other adjacency [RFC7177] 1032 or link technology specific packets. Other control and data packets 1033 SHOULD be given lower priority so that a flood of such other packets 1034 cannot lead to loss of or inability to establish adjacency. Loss of 1035 adjacency causes a topology transient that can result in reduced 1036 throughput, reordering, increased probability of loss of multi- 1037 destination data, and, if the adjacency is a cut point, network 1038 partitioning. 1040 Other important control packets should be given second highest 1041 priority. Lower priorities should be given to data or less important 1042 control packets. 1044 Control packets can be ordered into priority classes as shown below. 1045 Although few implementations will actually treat all of these classes 1046 differently, higher numbered classes SHOULD NOT be treated as higher 1047 priority than lower numbered class. There may be additional control 1048 packets, not specifically listed in any category below, that SHOULD 1049 be handled as being in the most nearly analogous category. 1051 1. Hello, MTU-probe, MTU-ack, and other packets critical to 1052 establishing and maintaining adjacency. 1054 2. LSPs, CSNP/PSNPs, and other important control packets, 1056 3. Circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1058 4. Non-circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1060 8.3 Unknown PDUs (New) 1062 TRILL switches MUST silently discard [IS-IS] PDUs they receive with 1063 PDU numbers they do not understand, just as they ignore TLVs and sub- 1064 TLVs they receive that have unknown Types and sub-Types; however, 1065 they SHOULD maintain a counter of how many such PDUs have been 1066 received, on a per PDU number basis. (This is not burdensome as the 1067 PDU number is only a 5-bit field.) 1069 Note: The set of valid [IS-IS] PDUs was stable for so long that 1070 some IS-IS implementations may treat PDUs with unknown PDU 1071 numbers as a serious error and, for example, an indication that 1072 other valid PDUs from the sender are not to be trusted or that 1073 they should drop adjacency to the sender if it was adjacent. 1074 However, the MTU-probe and MTU-ack PDUs were added by [RFC7176] 1075 and now [RFC7356] has added three more new PDUs. While the 1076 authors of this document are not aware of any Internet drafts 1077 calling for further PDUs, the eventual addition of further new 1078 PDUs should not be surprising. 1080 8.4 Nickname Flags APPsub-TLV (New) 1082 An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV 1083 [RFC7357] is specified below. 1085 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1086 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1087 | Type = NickFlags (#tbd2) | 1088 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1089 | Length = 4*K | 1090 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1091 | NICKFLAG RECORD 1 | 1092 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1093 ... 1094 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1095 | NICKFLAG RECORD K | 1096 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1098 Where each NICKFLAG RECORD has the following format: 1100 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1101 | Nickname | 1102 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1103 |IN| RESV | 1104 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1106 o Type: NickFlags TRILL APPsub-TLV, set to tbd2 (NICKFLAGS) 1108 o Length: 4 times the number of NICKFLAG RECORDS present. 1110 o Nickname: A 16-bit TRILL nickname held by the advertising TRILL 1111 switch ([RFC6325] and Section 4). 1113 o IN: Ingress. If this flag is one, it indicates the advertising 1114 TRILL switch may use the nickname in the NICKFLAG RECORD as the 1115 ingress nickname of TRILL Headers it creates. If the flag is 1116 zero, that nickname will not be used for that purpose. 1118 o RESV: Reserved for additional flags to be specified in the 1119 future. MUST be sent as zero and ignored on receipt. 1121 A NICKFLAG RECORD is ignored if the nickname it lists is not a 1122 nickname owned by the TRILL switch advertising the enclosing 1123 NickFlags APPsub-TLV. 1125 If a TRILL switch intends to use a nickname in the ingress nickname 1126 field of TRILL Headers it constructs, it can advertise this through 1127 E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry 1128 with the IN flag set. If it owns only one nickname, there is no 1129 reason to do this because, if a TRILL switch advertises no NickFlags 1130 APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed 1131 that the TRILL switch might use any or all nicknames it owns as the 1132 ingress nickname in TRILL Headers it constructs. 1134 Every reasonable effort should be made to be sure that Nickname sub- 1135 TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync. If all TRILL 1136 switches in a campus support E-L1FS, so that Nickname sub-TLVs can be 1137 advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any 1138 NickFlags APP-subTLVs for any particular nickname should be 1139 advertised in the same fragment. If they are not in the same fragment 1140 then, to the extent practical, all fragments involving those sub-TLVs 1141 for the same nickname should be propagated as an atomic action. If a 1142 TRILL switch sees multiple NickFlags APPsub-TLV entries for the same 1143 nickname, it assumes that nickname might be used as the ingress in a 1144 TRILL Header if any of the NickFlags APPsub-TLV entries have the IN 1145 bit set. 1147 It is possible that a NickFlags APPsub-TLV would not be propagated 1148 throughout the TRILL campus due to legacy TRILL switches not 1149 supporting E-L1FS. In that case, Nickname sub-TLVs must be advertised 1150 in LSPs and TRILL switches not receiving NickFlags APPsub-TLVs having 1151 entries with the IN flag set will simply assume that the source TRILL 1152 switch might use any of its nicknames as ingress in constructing 1153 TRILL Headers. Thus the use of this optional APPsub-TLV is backwards 1154 compatible with legacy lack of E-L!FS support. 1156 Additional flags may be assigned for other purposes out of the RESV 1157 field for other purposes in the future. 1159 8.5 Graceful Restart (Unchanged) 1161 TRILL Switches SHOULD support the features specified in [RFC5306], 1162 which describes a mechanism for a restarting IS-IS router to signal 1163 to its neighbors that it is restarting, allowing them to reestablish 1164 their adjacencies without cycling through the down state, while still 1165 correctly initiating link-state database synchronization. If this 1166 feature is not supported, it may increase the number of topology 1167 transients cause by a TRILL switch rebooting due to errors or 1168 maintenance. 1170 9. Updates to [RFC7177] (Adjacency) [Changed) 1172 To support the E-L1FS flooding scope [RFC7356] mandated by Section 1173 8.1 and backwards compatibility with legacy RBridges not supporting 1174 E-L1FS flooding, the following updates are made to [RFC7177]: 1176 1. The list in the second paragraph of [RFC7177] Section 3.1 has the 1177 following item added: 1179 - The Scoped Flooding Support TLV. 1181 In addition, the sentence immediately after that list is modified to 1182 read as follows: 1184 Of course, the priority, Desired Designated VLAN, Scoped Flooding 1185 Support TLV, and possibly the inclusion or value of the PORT- 1186 TRILL-VER sub-TLV, and/or BFD-Enabled TLV can change on occasion, 1187 but then the new value(s) must similarly be used in all TRILL 1188 Hellos on the LAN port, regardless of VLAN. 1190 2. An additional bullet item is added to the end of Section 3.2 of 1191 [RFC7177] as follows: 1193 o The value from the Scoped Flooding Support TLV or a null string 1194 if none was included. 1196 3. Near the bottom of Section 3.3 of [RFC7177] a bullet item as 1197 follows is added: 1199 o The variable length value part of the Scoped Flooding Support 1200 TLV in the Hello or a null string if that TLV does not occur in 1201 the Hello. 1203 4. At the beginning of Section 4 of [RFC7177], a bullet item is added 1204 to the list as follows: 1206 o The variable length value part of the Scoped Flooding Support 1207 TLV used in TRILL Hellos sent on the port. 1209 10. TRILL Header Update (New) 1211 The TRILL header has been updated from its original specification in 1212 [RFC6325] by [TRILL-OAM-FM] and [RFC7179] and is further updated by 1213 this document. The TRILL header is now as show below and is followed 1214 by references for all of the fields. Those fields for which the 1215 reference is only to [RFC6325] are unchanged from that RFC. 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | V |A|C|M| RESV |F| Hop Count | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Egress Nickname | Ingress Nickname | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 : Optional Flag Word : 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 In calculating a TRILL data packet hash as part of equal-cost multi- 1226 path selection, a TRILL switch MUST ignore the value of the "A" and 1227 "C" bits. In [RFC6325] and [RFC7179] the RESV and F fields above 1228 together constituted the "Ex-Length" or TRILL Header Extensions 1229 Length field. 1231 o V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325]. 1233 o A (Alert): 1 bit. See [TRILL-OAM-FM]. 1235 o C (Color): 1 bit. See Section 10.1. 1237 o M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325]. 1239 o RESV: 4 bits. These bits are reserved and MUST be sent as zero. 1240 They SHOULD be ignored on receipt; however, due to their previous 1241 use as specified in [RFC6325], some TRILL fast path harware 1242 implementations trap and do not forward TRILL Data packets with 1243 these bits non-zero. 1245 o F: 1 bit. If this field is non-zero, then the optional Flag Word 1246 described in Section 10.2 is present. If it is zero, the Flag Word 1247 is not prsent. 1249 o Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 1250 below. 1252 o Egress Nickname. See Section 3.7.1 of [RFC6325]. 1254 o Ingress Nickname. See Section 3.7.2 of [RFC6325]. 1256 o Optional Flag Word: See [RFC7179] and Section 10.2. 1258 10.1 Color Bit 1260 The Color bit provides an optional way by which ingress TRILL 1261 switches MAY mark TRILL Data packets for implementation specific 1262 purposes. Transit TRILL switches MUST NOT change this bit. Transit 1263 and egress TRILL switches MAY use the Color bit for implementation 1264 dependent traffic labeling or statistical or other traffic study or 1265 analysis. 1267 10.2 Flag Word Changes (update to [RFC7179]) 1269 When the extension length field is non-zero, the first 32 bits after 1270 the Ingress nickname field provides additional flags. These bits are 1271 as specified in [RFC7179] except as changed by the subsections below 1272 that provide extended Hop Count and extended Color fields. See 1273 Section 10.3 for a diagram and summary of these fields. 1275 10.2.1 Extended Hop Count 1277 The TRILL base protocol [RFC6325] specifies the Hop Count field in 1278 the header, to avoid packets persisting in the network due to looping 1279 or the like. However, the Hop Count field size (6 bits) limits the 1280 maximum hops a TRILL data packet can traverse to 64. Optionally, 1281 TRILL switches can use a field composed of bits 14 through 16 in the 1282 Flag Word, as specified below. to extend this field to 9 bits. This 1283 increases the maximum Hop Count to 512. Use of Hop Counts in excess 1284 of 64 requires support of this optional capability at all TRILL 1285 switches along the path of a TRILL Data packet. 1287 10.2.1.1 Advertising Support 1289 In case of a TRILL campus such that the unicast calculated path, plus 1290 a reasonable allowance for alternate pathing, or the distribution 1291 tree calculated path, traverse more than 64 hops, it may be that not 1292 all the TRILL switches support the extended Hop Count mechanism. As 1293 such it is required that TRILL switches advertise their support by 1294 setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header 1295 Flags Supported field [RFC7176]; bits 15 and 16 of that field are now 1296 specified as Unassigned (see Section 11.2.5). 1298 10.2.1.2 Ingress Behavior 1300 If an ingress TRILL switch determines it should set the hop count for 1301 a TRILL Data packet to 63 or less, then behavior is as specified in 1302 the TRILL base protocol [RFC6325]. If hop count for a TRILL Data 1303 packet should be set to some value greater than 63 but less than 512 1304 and all TRILL switches that the packet is reasonably likely to 1305 encounter support extended Hop Count, then the resulting TRILL Header 1306 has the Flag Word extension present, the high order three bits of the 1307 desired hop count are stored in the extended Hop Count field in the 1308 Flag Word, the five low order bits are stored in the Hop Count filed 1309 in the first word of the TRILL Header, and bit two (the Critical 1310 Reserved bit of the Critical Summary Bits) in the Flag Word is set. 1312 For known unicast traffic (TRILL Header M bit zero), when an ingress 1313 TRILL switch determines that the least cost path to the egress is 1314 more than 64 hops but not all TRILL switches on that path support the 1315 extended Hop Count feature, the frame is discarded. 1317 For multi-destination traffic, when a TRILL switch determines that 1318 one or more tree path from the ingress it more than 64 hops but not 1319 all TRILL switches in the campus support the extended Hop Count 1320 feature, the encapsulation uses a total Hop Count of 63 to obtain at 1321 least partial distribution of the traffic. 1323 10.2.1.3 Transit Behavior 1325 A transit TRILL switch supporting extended Hop Count behaves like a 1326 base protocol [RFC6325] TRILL switch in decrementing the hop count 1327 except that it considers the hop count to be a 9 bit file where the 1328 extended Hop Count field consistutes the high order three bits. 1330 To be more precise: a TRILL switch supporting extended Hop Count 1331 takes the first of the following actions that is applicable: 1333 1. If both the Hop Count and extended Hop Count fields are zero, the 1334 packet is discarded. 1336 2. If the Hop Count is non-zero, it is decremented. As long as the 1337 extended Hop Count is non-zero, no special action is taken if the 1338 result of this decrement is zero and the packet is processed 1339 normally. 1341 3. If the Hop Count is zero, it is set to the maximum value of 63 and 1342 the extended Hop Count is decremented. 1344 10.2.1.4 Egress Behavior 1346 No special behavior is required when egressing a TRILL Data packet 1347 that uses the extended Hop Count. The Flag Word, if present, is 1348 removed along with the rest of the TRILL Header during decapsulation. 1350 10.2.2 Extended Color Field 1352 Flag Word bits 27 and 28 are specified to be a two-bit Extended Color 1353 field (see Section 10.3). These bits are in the non-critical ingress- 1354 to-egress region of the Flag Word. 1356 The Extended Color field provides an optional way by which ingress 1357 TRILL switches MAY mark TRILL Data packets for implementation 1358 specific purposes. Transit TRILL switches MUST NOT change this bit. 1359 Transit and egress TRILL switches MAY use the Color bit for 1360 implementation dependent traffic labeling or statistical or other 1361 traffic study or analysis. 1363 As provided in Section 2.3.1 of [RFC7176], support for these bits is 1364 indicated by the same bits (27 and 28) in the Capabilities and Header 1365 Flags Supported field of the TRILL Version Sub-TLV. In the spirit of 1366 indicating support, a TRILL switch that sets or senses the Extended 1367 Color field SHOULD set the corresponding 2-bit field in the TRILL 1368 Version Sub-TLV non-zero. The meaning of the possible non-zero values 1369 (1, 2 or 3) is implementation dependent. 1371 10.3 Updated Flag Word Summary 1373 With the changes above, the 32-bit Flag Word extension to the TRILL 1374 Header [RFC7179], appearing as the "TRILL Extended Header Flags" 1375 registry on the TRILL Parameters IANA web page, is now as follows: 1377 0 1 2 3 1378 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 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 1381 |.....|.........|...........|.....|.......|...........|.........| 1382 |C|C|C| |C|N| | Ext | | |Ext| | 1383 |R|R|R| |R|C| | Hop | | |Clr| | 1384 |H|I|R| |C|C| | Cnt | | | | | 1385 |b|t|s| |A|A| | | | | | | 1386 |H|E|v| |F|F| | | | | | | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Bit 0 to 2 are the Critical Summary bits as specified in [RFC7179] 1390 consisting of the Critical Hop-by-Hop, Critical Ingres-to-Egress, and 1391 Critical Reserved bits, respectively. The next two fields are 1392 specific Critical and Non-Critical Hop-by-Hop bits, CHbH and NCHbH, 1393 respectively, containing the Critical and Non-Critical Channel Alert 1394 flags as specified in [RFC7179]. The next field is the Critical 1395 Reserved bits (CRSV) that are specified herein to be the Extended Hop 1396 Count. Then the Non-Critical Reserved Bits (NCRSV) and the Critical 1397 Ingress-to-Egress bits (CITE) as specified in [RFC7179]. Finally, 1398 there is the Non-Critical Ingress-to-Egress field, the top two bits 1399 of which are specified herein as the Extended Color field. 1401 11. IANA Considerations (Changed) 1403 This section give IANA actions previously completed and newly 1404 requested IANA actions. 1406 11.1 Previously Completed IANA Actions (Unchanged) 1408 The following IANA actions were completed as part of [RFC7180] and 1409 are included here for completeness, since this document obsoletes 1410 [RFC7180]. 1412 1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated 1413 for use in the TRILL Header Egress Nickname field to indicate an 1414 OOMF (Overload Originated Multi-destination Frame). 1416 2. Bit 1 from the seven previously reserved (RESV) bits in the per- 1417 neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is 1418 allocated to indicate that the RBridge sending the TRILL Hello 1419 volunteers to provide the OOMF forwarding service described in 1420 Section 2.4.2 to such frames originated by the TRILL Switch whose 1421 SNPA (MAC address) appears in that Neighbor RECORD. The 1422 description of this bit is "Offering OOMF service". 1424 3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER 1425 sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub- 1426 TLV [RFC7176] and the VLAN inhibition setting mechanisms specified 1427 in [rfc6439bis]. The description of this bit is "Hello reduction 1428 support". 1430 11.2 New IANA Considerations (New) 1432 The following are new IANA actions for this document: 1434 11.2.1 Reference Updated 1436 All references to [RFC7180] in the TRILL Parameters Registry are 1437 replaced with references to this document except that the Reference 1438 for bit 0 in the PORT-TRILL-VER Sub-TLV Capapbilty Flags is changed 1439 to [rfc6439bis]. 1441 11.2.2 The 'E' Capability Bit 1443 IANA is requested to allocate a previously reserved capability bit in 1444 the TRILL Version sub-TLV carried in the Router Capability and MT 1445 Capability TLVs (#242, #144) to indicate support of the [RFC7356] E- 1446 L1FS flooding scope. This capability bit is referred to as the "E" 1447 bit. The following is the addition to the 1449 Bit Description References 1450 ---- --------------------- --------------- 1451 tbd1 E-L1FS FS-LSP support [this document][RFC7356] 1453 11.2.3 NickFlags APPsub-TLV Number 1455 IANA is requested to allocate an APPsub-TLV number under the TRILL 1456 GENINFO TLV from the range less than 255. 1458 Type Name References 1459 ---- --------- ----------- 1460 tbd2 NICKFLAGS [this document] 1462 11.2.4 Update TRILL Extended Header Flags 1464 Update the "TRILL Extended Header Flags" registry as follows: 1466 Bits Purpose References 1467 ----- ---------------------------------------------- ---------- 1469 14-16 Extended Hop Count [this document] 1471 27-28 Extended Color [this document] 1473 29-31 Available non-critical ingress-to-egress flags 1474 [RFC7179] [this document] 1476 11.2.5 TRILL-VER Sub-TLV Capability Flags 1478 Update the "TRILL-VER Sub-TLV Capapbility Flags" registry as follows: 1480 Bit Description Reference 1481 ----- -------------------------- ---------------- 1483 14 Extended Hop Count support [this document] 1485 15-16 Unassigned [this document] 1487 27-28 Extended Color support [this document] 1489 29-31 Extended header flag support [RFC7179] [this document] 1491 12. Security Considerations (Changed) 1493 This memo improves the documentation of the TRILL protocol, corrects 1494 five errata in [RFC6325], updates [RFC6325], [RFC7177], and [RFC7179] 1495 and obsoletes [RFC7180]. 1497 It does not change the Security Considerations of these RFCs to which 1498 the reader is referred. {{ Probably need to say more than this. }} 1500 Acknowledgements 1502 The contributions of the following individuals to this document are 1503 gratefully acknowledged: 1505 Santosh Rajagopalan 1507 The contributions of the following, listed in alphabetic order, to 1508 the preceding version of this document, [RFC7180], are gratefully 1509 acknowledged: 1511 Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia 1512 Perlman, Mike Shand, Meral Shirazipour, and Varun Shah. 1514 Normative References 1516 [802.1Q-2011] - IEEE, "IEEE Standard for Local and metropolitan area 1517 networks -- Media Access Control (MAC) Bridges and Virtual 1518 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 1519 2011. 1521 [IS-IS] - International Organization for Standardization, 1522 "Intermediate System to Intermediate System intra-domain 1523 routeing information exchange protocol for use in conjunction 1524 with the protocol for providing the connectionless-mode network 1525 service (ISO 8473)", Second Edition, November 2002. 1527 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1528 Requirement Levels", BCP 14, RFC 2119, March 1997. 1530 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1531 Engineering", RFC 5305, October 2008. 1533 [RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 1534 RFC 5306, October 2008. 1536 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1537 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1538 Specification", RFC 6325, July 2011. 1540 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1541 Interconnection of Lots of Links (TRILL) Protocol Control 1542 Protocol", RFC 6361, August 2011. 1544 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1545 and D. Dutt, "Transparent Interconnection of Lots of Links 1546 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1548 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1549 D., and A. Banerjee, "Transparent Interconnection of Lots of 1550 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 1552 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1553 and V. Manral, "Transparent Interconnection of Lots of Links 1554 (TRILL): Adjacency", RFC 7177, May 2014. 1556 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 1557 C. Bestler, "Transparent Interconnection of Lots of Links 1558 (TRILL): Header Extension", RFC 7179, May 2014, 1559 . 1561 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1562 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 1563 . 1565 Informative References 1567 [802] - IEEE 802, "IEEE Standard for Local and metropolitan area 1568 networks: Overview and Architecture", IEEE Std 802.1-2001, 8 1569 March 2002. 1571 [Err3002] - RFC Errata, Errata ID 3002, RFC 6325, . 1574 [Err3003] - RFC Errata, Errata ID 3003, RFC 6325, . 1577 [Err3004] - RFC Errata, Errata ID 3004, RFC 6325, . 1580 [Err3052] - RFC Errata, Errata ID 3052, RFC 6325, . 1583 [Err3053] - RFC Errata, Errata ID 3053, RFC 6325, . 1586 [Err3508] - RFC Errata, Errata ID 3508, RFC 6325, . 1589 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1590 "Randomness Requirements for Security", BCP 106, RFC 4086, June 1591 2005, . 1593 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 1594 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 1595 6327, July 2011, . 1597 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1598 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1599 6439, November 2011, . 1601 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1602 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1603 BCP 141, RFC 7042, October 2013. 1605 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1606 "Transparent Interconnection of Lots of Links (TRILL): 1607 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1608 May 2014. 1610 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1611 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1612 RBridge Channel Support", RFC 7178, May 2014. 1614 [RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., 1615 and A. Banerjee, "Transparent Interconnection of Lots of Links 1616 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1617 May 2014. 1619 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1620 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1621 End Station Address Distribution Information (ESADI) Protocol", 1622 RFC 7357, September 2014, . 1625 [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1626 "Problem Statement and Goals for Active-Active Connection at 1627 the Transparent Interconnection of Lots of Links (TRILL) Edge", 1628 RFC 7379, October 2014, . 1631 [TRILL-OAM-FM] - Senevirathen, T., "TRILL Fault Management", draft- 1632 ietf-trill-oam-fm, work in progress. 1634 [rfc6439bis] - Eastlake, D., et al., "TRILL: Appointed Forwarders", 1635 draft-eastlake-trill-rfc6439bis, work in progress. 1637 Appendix A: Life Cycle of a TRILL Switch Port (New) 1639 The contents of this informational Appendix are based on 1640 http://www.ietf.org/mail-archive/web/trill/current/msg06355.html 1642 Question: Suppose we are developing a TRILL implementation to run on 1643 different machines. Then what happened 1st? Is LSP or ESADI 1644 started first? -> Link state database creation -> Designated 1645 RBridge election (How to set priority? any fixed process that 1646 depends on user settings? ) -> etc. ? 1648 Answer: 1649 The first thing that happens on a port/link is any link set-up 1650 that is needed. For example, on a PPP link [RFC6361], you need to 1651 negotiate that you will be using TRILL. However, if you have 1652 Ethernet links [RFC6325], which are probably the most common type, 1653 there isn't any link set-up needed. 1655 Then TRILL IS-IS Hellos get sent out the port to be exchanged on 1656 the link [RFC7177]. Optionally, you might also exchange MTU- 1657 probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test 1658 packets. But all these other things are optional. Only Hellos are 1659 required. 1661 TRILL doesn't send anything else on the link until the link gets 1662 out of the Down or Detect states [RFC7177]. 1664 If a link is configured as a point-to-point link, there is no 1665 Designated RBridge (DRB) election. By default, an Ethernet link is 1666 considered a LAN link and the DRB election occurs when the link is 1667 in any state other than Down. You don't have to configure 1668 priorities for each TRILL switch (RBridge) to be Designated 1669 RBridge (DRB). Things will work fine with all the RBridges on a 1670 link using default priority. But if the network manager wants to 1671 control this, they should be a way for them to configure the 1672 priorities to be DRB. 1674 (To avoid complexity, this appendix generally describes things for 1675 a link that only has two TRILL switches on it. But TRILL works 1676 fine as currently specified on a broadcast link with multiple 1677 TRILL switches on it - actually multiple TRILL switch ports since 1678 a TRILL switch can have multiple ports connected to the same link. 1679 The most likely way to get such a multi-access link with current 1680 technology is to have more than 2 TRILL switch Ethernet ports 1681 connected to a bridged LAN. Since the TRILL protocol operates 1682 above all bridging, to the first approximation, the bridge LAN 1683 looks like a transparent broadcast link to TRILL.) 1685 When a link gets to the 2-Way or Report state, then LSP, CSNP, and 1686 PSNP start to flow on the link (as well as FS-LSPs, FS-CSNPs, and 1687 FS-PSNPs if the TRILL switch is using E-L1FS (see Section 8.1)). 1689 When a link gets to the Report state, then there is adjacency. The 1690 existence of that adjacency is flooded (reported) to the campus in 1691 LSPs. TRILL data packets can then start to flow on the link as 1692 TRILL switches recalculate the least cost paths and distribution 1693 trees to take the new adjacency into account. (Until it gets to 1694 the Report state, there is no adjacency and no TRILL data packets 1695 can flow over that link (with the minor corner case exception that 1696 an RBridge Channel message can, for its first hop only, be sent on 1697 a port where there is no adjacency (Section 2.4 of [RFC7178]).) 1698 (Although this paragraph seems to be talking about link state, it 1699 is actually port state. It is possible for different TRILL switch 1700 ports on the same link to temporarily be in different states. The 1701 adjacency state machinery runs independently on each port.) 1703 ESADI [RFC7357] is built on top of the regular TRILL routing. 1704 Since ESADI PDUs look, to transit TRILL switches, like regular 1705 TRILL data packets, no ESADI PDUs can flow until adjacencies are 1706 established and TRILL data is flowing. Of course, ESADI is 1707 optional and is not used unless configured... 1709 Question: Does it require TRILL Full headers at the time TRILL-LSPs 1710 start being broadcast on a link? Because at that time it's not 1711 defined Egress and Ingress nicknames. 1713 Answer: 1714 TRILL Headers are only for TRILL Data packets. TRILL IS-IS 1715 packets, such as TRILL-LSPs, are sent in a different way that does 1716 not use a TRILL Header and does not depend on nicknames. 1718 Probably, in most implementations, a TRILL switch will start up 1719 using the same nickname it had when it shut down or last got 1720 disconnected from a campus. If you want, you can implement TRILL 1721 to come up initially not reporting any nickname (by not including 1722 an Nickname sub-TLV in its LSPs) until you get the link state 1723 database or most of the link state database, and then choose a 1724 nickname no other TRILL switch in the campus is using. Of course, 1725 if a TRILL switch does not have a nickname, then it cannot ingress 1726 data, cannot egress known unicast data, and cannot be a tree root. 1728 TRILL IS-IS and LSPs and the link state database all work based on 1729 the 7-byte IS-IS System-ID (sometimes called the LAN ID). System- 1730 IDs always have to be unique across the campus so there is no 1731 problem determining topology regardless of nickname state. The 1732 Nickname system is built on top of that. 1734 Appendix B: Example TRILL PDUs (New) 1736 [Three for four example PDUs to be included here to help answer any 1737 questions about bit ordering or the like.] 1739 Appendix C: Appointed Forwarder Status Lost Couter (New) 1741 This appendix is derived from http://www.ietf.org/mail- 1742 archive/web/trill/current/msg05279.html. 1744 Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on 1745 the value of the Appointed Forwarder Status Lost Counter can result 1746 in splitting of Interested VLANs and Spanning Tree Roots sub-TLVs 1747 [RFC7176], or the corresponding Interested Lables sub-TLVs, due to 1748 minor/accidental differences in the counter value for different VLANs 1749 or FGLs. 1751 This counter is a mechanism to optimize data plane learning by 1752 trimming the expiration timer for learned addresses on a per VLAN/FGL 1753 basis under some circumstances. Note the following: 1755 (1) If an implementer don't care about that optimization and don't 1756 mind some time outs being longer than they otherwise would be, 1757 you can just not bother changing the counter, even if you are 1758 using data plane learning. On the other hand, if you don't care 1759 about sone time outs being shortened when they otherwise 1760 wouldn't, you could increment the counter for multiple VLANs even 1761 you don't lose AF status on a port for all those VLANS but, for 1762 example, only one of them. 1764 (2) If you are relying on ESADI [RFC7357] or Directory Assist 1765 [RFC7379] and not learning from the data plane, the counter 1766 doesn't matter and there really isn't any need to increment it. 1768 (3) If an RBridge port has been configured with the "disable end 1769 station traffic" bit on (also known as the trunk bit), then it 1770 makes no difference if that port is appointed forwarder or not 1771 even though, according to the standard, the Appointed Forwarder 1772 selection mechanism continues to operate. So, under such 1773 circumstances, there is no reason to increment the counter if 1774 such a port loses Appointed Forwarder status. 1776 (4) If you are updating the counter, incrementing it by more than one 1777 (even up to incrementing it by a couple of hundred), so that it 1778 matches the counter for some adjacent VLAN for the same RBridge 1779 would have an extremely small probability of causing any sub- 1780 optimization and, if it did, that sub-optimization would just be 1781 to occasionally fail to specially decrease the time out for some 1782 learned addresses. 1784 Appendix D: Changes from [RFC7180] 1786 This informational Appendix summarizes the changes, augmentations, 1787 and excisions this document makes to [RFC7180]. 1789 D.1 Changes 1791 For each heading in this document ending with "(Changed)", this 1792 section summarizes how it was changed: 1794 Section 1, Introduction: numerous changes to reflect the overall 1795 changes in contents. 1797 Section 1.1, Precedence: changed to add mention of [RFC7179]. 1799 Section 1.3, Terminology and Acronyms: numerous terms added. 1801 Section 3, Distribution Trees and RPF Check: changed by the addition 1802 of the new material in Section 3.6. See C.2 item 1. 1804 Section 8, Other IS-IS Considerations: Changed by the addition of 1805 Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.2 items 2, 3, 4, 1806 and 5 respectively. 1808 Section 9, Updates to [RFC7177] (Adjacency): Changes and additions to 1809 [RFC7177] to support E-L1FS. See Appendix C.2, item 2. 1811 Section 11, IANA Considerations: changed by the addition of material 1812 in Section 11.2. See Appendix C.2, item 7. 1814 Section 12, Security Considerations: minor changes in the RFCs 1815 listed. 1817 D.2 Additions 1819 The following material was added to [RFC7180] in producing this 1820 document: 1822 1. Addition of support for an alternative Reverse Path Forwarding 1823 Check (RPFC) along with considerations for deciding between the 1824 original [RFC6325] RPFC and this alternative RPFC. This 1825 alternative RPFC was originally discussed on the TRILL WG mailing 1826 list in http://www.ietf.org/mail- 1827 archive/web/trill/current/msg01852.html and subsequent messages. 1828 (Section 3.6) 1830 2. Addition of mandatory E-L1FS [RFC7356] support (Section 8.1, 1831 Section 9). 1833 3. Recommendations concerning control packet priorities. (Section 1834 8.2) 1836 4. Implementation requirements concerning unknown IS-IS PDU types 1837 (Section 8.3). 1839 5. Specification of an optional Nickname Flags APPsub-TLV and an 1840 ingress flag within that APPsub-TLV. (Section 8.4) 1842 6. Update TRILL Header to allocate a Color bit (Section 10.1) and 1843 update the optional TRILL Header Extension Flag Word to allocate a 1844 two-bit Extended Color field (Section 10.2). 1846 7. Some new IANA Considerations in Section 11.2. 1848 8. Informative Appendix A and C on the Lifecycle of a TRILL Port and 1849 the Appointed Forwarder Status Lost Counter, respectively. 1851 9. Appendix B with example TRILL PDUs. 1853 D.3 Deletions 1855 The following material was deleted from [RFC7180] in producing this 1856 document: 1858 1. Removal of all updates to [RFC6327] that occurred in [RFC7180]. 1859 These have been rolled into [RFC7177] that obsoletes [RFC6327]. 1860 However, new updates to [RFC7177] are included (see Item 1 in 1861 Section A.1). 1863 2. Removal of all updates to [RFC6439]. These have been rolled into 1864 [rfc6439bis] that will obsolete [RFC6439]. 1866 Appendix Z: Change History 1868 This appendix lists version changes in this document. 1870 From -00 to -01 1872 1. Update Author Addresses. 1874 2. Add Appendix C moving previous Appendix C to D. 1876 3. Change the upper four bits of the former Ex-Length field in the 1877 TRILL Header to be reserved. 1879 4. Minor editorial changes. 1881 Authors' Addresses 1883 Donald Eastlake 3rd 1884 Huawei Technology 1885 155 Beaver Street 1886 Milford, MA 01757 USA 1888 Phone: +1-508-333-2270 1889 EMail: d3e3e3@gmail.com 1891 Mingui Zhang 1892 Huawei Technologies 1893 No. 156 Beiqing Rd. Haidian District, 1894 Beijing 100095 1895 P.R. China 1897 EMail: zhangmingui@huawei.com 1899 Radia Perlman 1900 EMC 1901 2010 256th Avenue NE, #200 1902 Bellevue, WA 98007 USA 1904 Email: radia@alum.mit.edu 1906 Ayan Banerjee 1907 Cisco 1909 EMail: ayabaner@cisco.com 1911 Anoop Ghanwani 1912 Dell 1913 5450 Great America Parkway 1914 Santa Clara, CA 95054 USA 1916 EMail: anoop@alumni.duke.edu 1918 Sujay Gupta 1919 IP Infusion, 1920 RMZ Centennial 1921 Mahadevapura Post 1922 Bangalore - 560048 India 1924 EMail: sujay.gupta@ipinfusion.com 1926 Copyright and IPR Provisions 1928 Copyright (c) 2014 IETF Trust and the persons identified as the 1929 document authors. All rights reserved. 1931 This document is subject to BCP 78 and the IETF Trust's Legal 1932 Provisions Relating to IETF Documents 1933 (http://trustee.ietf.org/license-info) in effect on the date of 1934 publication of this document. Please review these documents 1935 carefully, as they describe your rights and restrictions with respect 1936 to this document. Code Components extracted from this document must 1937 include Simplified BSD License text as described in Section 4.e of 1938 the Trust Legal Provisions and are provided without warranty as 1939 described in the Simplified BSD License.