idnits 2.17.1 draft-ietf-trill-rfc7180bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 (November 13, 2014) is 3449 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:May 12, 2015 November 13, 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 144 Authors' Addresses........................................51 146 1. Introduction (Changed) 148 Since the TRILL base protocol [RFC6325] was published in 2011, active 149 development of TRILL has revealed errors in the specification 150 [RFC6325] and several areas that could use clarifications or updates. 152 [RFC7177], [RFC7357], and [rfc6439bis] provide clarifications and 153 updates with respect to Adjacency, the TRILL ESADI (End Station 154 Address Distribution Information) protocol, and Appointed Forwarders. 155 This document provides other known clarifications, corrections, and 156 updates to [RFC6325], [RFC7177], and [RFC7179]. This document 157 obsoletes [RFC7180], the previous TRILL clarifications, corrections, 158 and updates document. 160 Sections of this document are annotated as to whether they are "New" 161 technical material, material that has been technically "Changed", or 162 material that is technically "Unchanged" by the appearance of one of 163 these three words in parenthesis at the end of the section header. A 164 section with only editorial changes is annotated as "(Unchanged)". If 165 no such notation appears, then the first notation encountered on 166 going to successively higher-level headers applies. Appendix C 167 describes changes, summarizes material added, and lists material 168 deleted. 170 1.1 Precedence (Changed) 172 In case of conflict between this document and [RFC6325], [RFC7177], 173 or [RFC7179] this document takes precedence. In addition, Section 174 1.2 (Normative Content and Precedence) of [RFC6325] is updated to 175 provide a more complete precedence ordering of the sections of 176 [RFC6325] as following, where sections to the left take precedence 177 over sections to their right: 179 4 > 3 > 7 > 5 > 2 > 6 > 1 181 1.2 Changes That Are Not Backward Compatible (Unchanged) 183 The change made by Section 3.4 below, which was also present in 184 [RFC7180], is not backward compatible with [RFC6325] but has 185 nevertheless been adopted to reduce distribution tree changes 186 resulting from topology changes. 188 The several other changes herein that are fixes to errata for 189 [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] 190 [Err3508] -- may not be backward compatible with previous 191 implementations that conformed to errors in the specification. 193 1.3 Terminology and Acronyms (Changed) 195 This document uses the acronyms defined in [RFC6325], some of which 196 are repeated below for convenience, along with some additional 197 acronyms and terms as follows: 199 CFI - Canonical Format Indicator [802]. 201 DEI - Drop Eligibility Indicator [802.1Q-2011]. 203 EISS - Enhanced Internal Sublayer Service. 205 OOMF - Overload Originated Multi-destination Frame. 207 RBridge - An alternative name for a TRILL Switch. 209 RPFC - Reverse Path Forwarding Check. 211 SNPA - SubNetwork Point of Attachment (for example, MAC address). 213 TRILL - Transparent Interconnection of Lots of Links (or Tunneled 214 Routing in the Link Layer). 216 TRILL Switch - A device implementing the TRILL protocol. An 217 alternative name for an RBridge. 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 221 "OPTIONAL" in this document are to be interpreted as described in 222 [RFC2119]. 224 2. Overloaded and/or Unreachable RBridges (Unchanged) 226 In this Section 2, the term "neighbor" refers only to actual RBridges 227 and ignores pseudonodes. 229 RBridges may be in overload as indicated by the [IS-IS] overload flag 230 in their LSPs (Link State PDUs). This means that either (1) they are 231 incapable of holding the entire link-state database and thus do not 232 have a view of the entire topology or (2) they have been configured 233 to have the overload bit set. Although networks should be engineered 234 to avoid actual link-state overload, it might occur under various 235 circumstances. For example, if a large campus included one or more 236 low-end TRILL Switches. 238 It is a common operational practice to set the overload bit in an 239 [IS-IS] router (such as a TRILL Switch) when performing maintenance 240 on that router that might affect its ability to correctly forward 241 packets; this will usually leave the router reachable for maintenance 242 traffic, but transit traffic will not be routed through it. (Also, 243 in some cases, TRILL provides for setting the overload bit in the 244 pseudonode of a link to stop TRILL Data traffic on an access link 245 (see Section 4.9.1 of [RFC6325]).) 247 [IS-IS] and TRILL make a reasonable effort to do what they can even 248 if some TRILL Switches/routers are in overload. They can do 249 reasonably well if a few scattered nodes are in overload. However, 250 actual least-cost paths are no longer assured if any TRILL Switches 251 are in overload. 253 For the effect of overload on the appointment of forwarders, see 254 [rfc6439bis]. 256 2.1 Reachability 258 Packets are not least-cost routed through an overloaded TRILL Switch, 259 although they may originate or terminate at an overloaded TRILL 260 Switch. In addition, packets will not be least-cost routed over 261 links with cost 2**24 - 1 [RFC5305]; such links are reserved for 262 traffic- engineered packets, the handling of which is beyond the 263 scope of this document. 265 As a result, a portion of the campus may be unreachable for least- 266 cost routed TRILL Data because all paths to it would be through 267 either a link with cost 2**24 - 1 or through an overloaded RBridge. 268 For example, an RBridge (TRILL Switch) RB1 is not reachable by TRILL 269 Data if all of its neighbors are connected to RB1 by links with cost 270 2**24 - 1. Such RBridges are called "data unreachable". 272 The link-state database at an RBridge RB1 can also contain 273 information on TRILL Switches that are unreachable by IS-IS link- 274 state flooding due to link or RBridge failures. When such failures 275 partition the campus, the TRILL Switches adjacent to the failure and 276 on the same side of the failure as RB1 will update their LSPs to show 277 the lack of connectivity, and RB1 will receive those updates. As a 278 result, RB1 will be aware of the partition. Nodes on the far side of 279 the partition are both IS-IS unreachable and data unreachable. 280 However, LSPs held by RB1 for TRILL Switches on the far side of the 281 failure will not be updated and may stay around until they time out, 282 which could be tens of minutes or longer. (The default in [IS-IS] is 283 twenty minutes.) 285 2.2 Distribution Trees 287 An RBridge in overload cannot be trusted to correctly calculate 288 distribution trees or correctly perform the RPFC (Reverse-Path 289 Forwarding Check). Therefore, it cannot be trusted to forward multi- 290 destination TRILL Data packets. It can only appear as a leaf node in 291 a TRILL multi-destination distribution tree. Furthermore, if all the 292 immediate neighbors of an RBridge are overloaded, then it is omitted 293 from all trees in the campus and is unreachable by multi-destination 294 packets. 296 When an RBridge determines what nicknames to use as the roots of the 297 distribution trees it calculates, it MUST ignore all nicknames held 298 by TRILL Switches that are in overload or are data unreachable. When 299 calculating RPFCs for multi-destination packets, an RBridge RB1 MAY, 300 to avoid calculating unnecessary RPFC state, ignore any trees that 301 cannot reach to RB1 even if other RBridges list those trees as trees 302 that other TRILL Switches might use. (But see Section 3.) 304 2.3 Overloaded Receipt of TRILL Data Packets 306 The receipt of TRILL Data packets by overloaded RBridge RB2 is 307 discussed in the subsections below. In all cases, the normal Hop 308 Count decrement is performed, and the TRILL Data packets is discarded 309 if the result is less than one or if the egress nickname is illegal. 311 2.3.1 Known Unicast Receipt 313 RB2 will not usually receive unicast TRILL Data packets unless it is 314 the egress, in which case it egresses and delivers the data normally. 315 If RB2 receives a unicast TRILL Data packet for which it is not the 316 egress, perhaps because a neighbor does not yet know it is in 317 overload, RB2 MUST NOT discard the packet because the egress is an 318 unknown nickname as it might not know about all nicknames due to its 319 overloaded condition. If any neighbor, other than the neighbor from 320 which it received the packet, is not overloaded, it MUST attempt to 321 forward the packet to one of those neighbors selected at random 322 [RFC4086]. If there is no such neighbor, the packet is discarded. 324 2.3.2 Multi-Destination Receipt 326 If RB2 in overload receives a multi-destination TRILL Data packet, 327 RB2 MUST NOT apply an RPFC since, due to overload, it might not do so 328 correctly. RB2 egresses and delivers the frame locally where it is 329 Appointed Forwarder for the frame's VLAN, subject to any multicast 330 pruning. But since, as stated above, RB2 can only be the leaf of a 331 distribution tree, it MUST NOT forward a multi-destination TRILL Data 332 packet (except as an egressed native frame where RB2 is Appointed 333 Forwarder). 335 2.4 Overloaded Origination of TRILL Data Packets 337 Overloaded origination of unicast TRILL Data packets with known 338 egress and of multi-destination packets is discussed in the 339 subsections below. 341 2.4.1 Known Unicast Origination 343 When an overloaded RBridge RB2 ingresses or creates a known 344 destination unicast data packet, it delivers it locally if the 345 destination is local. Otherwise, RB2 unicasts it to any neighbor 346 TRILL Switch that is not overloaded. It MAY use what routing 347 information it has to help select the neighbor. 349 2.4.2 Multi-Destination Origination 351 Overloaded RBridge RB2 ingressing or creating a multi-destination 352 data packet is more complex than for the known unicast case as 353 discussed below. 355 2.4.2.1 An Example Network 357 For example, consider the network below in which, for simplicity, end 358 stations and any bridges are not shown. There is one distribution 359 tree of which RB4 is the root, as represented by double lines. Only 360 RBridge RB2 is overloaded. 362 +-----+ +-----+ +-----+ +-----+ 363 | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 | 364 +-----+ +--+--+ +-++--+ +--+--| 365 | || | 366 +---+---+ || | 367 +------+RB2(ov)|======++ | 368 | +-------+ || | 369 | || | 370 +--+--+ +-----+ ++==++=++ +--+--+ 371 | RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 | 372 +-----+ +-----+ ++=====++ +-----+ 374 Since RB2 is overloaded, it does not know what the distribution tree 375 or trees are for the network. Thus, there is no way it can provide 376 normal TRILL Data service for multi-destination native frames. So 377 RB2 tunnels the frame to a neighbor that is not overloaded if it has 378 such a neighbor that has signaled that it is willing to offer this 379 service. RBridges indicate this in their Hellos as described below. 380 This service is called OOMF (Overload Originated Multi- destination 381 Frame) service. 383 - The multi-destination frame MUST NOT be locally distributed in 384 native form at RB2 before tunneling to a neighbor because this 385 would cause the frame to be delivered twice. For example, if RB2 386 locally distributed a multicast native frame and then tunneled it 387 to RB5, RB2 would get a copy of the frame when RB3 transmitted it 388 as a TRILL Data packet on the multi-access RB2-RB3-RB4 link. 389 Since RB2 would, in general, not be able to tell that this was a 390 frame it had tunneled for distribution, RB2 would decapsulate it 391 and locally distribute it a second time. 393 - On the other hand, if there is no neighbor of RB2 offering RB2 the 394 OOMF service, RB2 cannot tunnel the frame to a neighbor. In this 395 case, RB2 MUST locally distribute the frame where it is Appointed 396 Forwarder for the frame's VLAN and optionally subject to multicast 397 pruning. 399 2.4.2.2 Indicating OOMF Support 401 An RBridge RB3 indicates its willingness to offer the OOMF service to 402 RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit 403 associated with the SNPA (SubNetwork Point of Attachment, also known 404 as MAC address) of RB2 on the link (see IANA Considerations). 405 Overloaded RBridge RB2 can only distribute multi-destination TRILL 406 Data packets to the campus if a neighbor of RB2 not in overload 407 offers RB2 the OOMF service. If RB2 does not have OOMF service 408 available to it, RB2 can still receive multi-destination packets from 409 non-overloaded neighbors and, if RB2 should originate or ingress such 410 a frame, it distributes it locally in native form. 412 2.4.2.3 Using OOMF Service 414 If RB2 sees this OOMF (Overload Originated Multi-destination Frame) 415 service advertised for it by any of its neighbors on any link to 416 which RB2 connects, it selects one such neighbor by a means beyond 417 the scope of this document. Assuming RB2 selects RB3 to handle 418 multi-destination packets it originates, RB2 MUST advertise in its 419 LSP that it might use any of the distribution trees that RB3 420 advertises so that the RPFC will work in the rest of the campus. 421 Thus, notwithstanding its overloaded state, RB2 MUST retain this 422 information from RB3 LSPs, which it will receive as it is directly 423 connected to RB3. 425 RB2 then encapsulates such frames as TRILL Data packets to RB3 as 426 follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held 427 by RB2, and, since RB2 cannot tell what distribution tree RB3 will 428 use, egress nickname = a special nickname indicating an OOMF packet 429 (see IANA Considerations). RB2 then unicasts this TRILL Data packet 430 to RB3. (Implementation of Item 4 in Section 4 below provides 431 reasonable assurance that, notwithstanding its overloaded state, the 432 ingress nickname used by RB2 will be unique within at least the 433 portion of the campus that is IS-IS reachable from RB2.) 435 On receipt of such a packet, RB3 does the following: 437 - changes the Egress Nickname field to designate a distribution tree 438 that RB3 normally uses, 439 - sets the M bit to one, 440 - changes the Hop Count to the value it would normally use if it 441 were the ingress, and 442 - forwards the packet on that tree. 444 RB3 MAY rate limit the number of packets for which it is providing 445 this service by discarding some such packets from RB2. The provision 446 of even limited bandwidth for OOMFs by RB3, perhaps via the slow 447 path, may be important to the bootstrapping of services at RB2 or at 448 end stations connected to RB2, such as supporting DHCP and ARP/ND 449 (Address Resolution Protocol / Neighbor Discovery). (Everyone 450 sometimes needs a little OOMF (pronounced "oomph") to get off the 451 ground.) 453 3. Distribution Trees and RPF Check (Changed) 455 Two corrections, a clarification, and two updates related to 456 distribution trees appear in the subsections below along with an 457 alternative, stronger RPF (Reverse Path Forwarding) Check. See also 458 Section 2.2. 460 3.1 Number of Distribution Trees (Unchanged) 462 In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the 463 parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. 464 It should read "(up to k if j is zero or the minimum of (j, k) if j 465 is non-zero)". 467 3.2 Distribution Tree Update Clarification (Unchanged) 469 When a link-state database change causes a change in the distribution 470 tree(s), there are several possibilities. If a tree root remains a 471 tree root but the tree changes, then local forwarding and RPFC 472 entries for that tree should be updated as soon as practical. 473 Similarly, if a new nickname becomes a tree root, forwarding and RPFC 474 entries for the new tree should be installed as soon as practical. 475 However, if a nickname ceases to be a tree root and there is 476 sufficient room in local tables, the forwarding and RPFC entries for 477 the former tree MAY be retained so that any multi-destination TRILL 478 Data packets already in flight on that tree have a higher probability 479 of being delivered. 481 3.3 Multicast Pruning Based on IP Address (Unchanged) 483 The TRILL base protocol specification [RFC6325] provides for and 484 recommends the pruning of multi-destination packet distribution trees 485 based on the location of IP multicast routers and listeners; however, 486 multicast listening is identified by derived MAC addresses as 487 communicated in the Group MAC Address sub-TLV [RFC7176]. 489 TRILL Switches MAY communicate multicast listeners and prune 490 distribution trees based on the actual IPv4 or IPv6 multicast 491 addresses involved. Additional Group Address sub-TLVs are provided 492 in [RFC7176] to carry this information. A TRILL Switch that is only 493 capable of pruning based on derived MAC address SHOULD calculate and 494 use such derived MAC addresses from multicast listener IPv4/IPv6 495 address information it receives. 497 3.4 Numbering of Distribution Trees (Unchanged) 499 Section 4.5.1 of [RFC6325] specifies that, when building distribution 500 tree number j, node (RBridge) N that has multiple possible parents in 501 the tree is attached to possible parent number j mod p. Trees are 502 numbered starting with 1, but possible parents are numbered starting 503 with 0. As a result, if there are two trees and two possible 504 parents, in tree 1, parent 1 will be selected, and in tree 2, parent 505 0 will be selected. 507 This is changed so that the selected parent MUST be (j-1) mod p. As 508 a result, in the case above, tree 1 will select parent 0, and tree 2 509 will select parent 1. This change is not backward compatible with 510 [RFC6325]. If all RBridges in a campus do not determine distribution 511 trees in the same way, then for most topologies, the RPFC will drop 512 many multi-destination packets before they have been properly 513 delivered. 515 3.5 Link Cost Directionality (Unchanged) 517 Distribution tree construction, like other least-cost aspects of 518 TRILL, works even if link costs are asymmetric, so the cost of the 519 hop from RB1 to RB2 is different from the cost of the hop from RB2 to 520 RB1. However, it is essential that all RBridges calculate the same 521 distribution trees, and thus, all must either use the cost away from 522 the tree root or the cost towards the tree root. As corrected in 523 [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It 524 says: 526 In other words, the set of potential parents for N, for the tree 527 rooted at R, consists of those that give equally minimal cost 528 paths from N to R and ... 530 but the text should say "from R to N": 532 In other words, the set of potential parents for N, for the tree 533 rooted at R, consists of those that give equally minimal cost 534 paths from R to N and ... 536 3.6 Alternative RPF Check (New) 538 [RFC6325] mandates a Reverse Path Forwarding (RPF) Check on multi- 539 destination TRILL data packets to avoid possible multiplication 540 and/or looping of multi-destination traffic during TRILL campus 541 topology transients. This check is logically performed at each TRILL 542 switch input port and determines, based on where the packet started 543 (the ingress nickname) and the tree on which it is being distributed, 544 whether it is arriving on the expected port. If not, the packet is 545 silently discarded. This check is fine for point-to-point links; 546 however, there are rare circumstances involving multi-access 547 ("broadcast") links where a packet can be duplicated despite this RPF 548 Check and other checks performed by TRILL. 550 Section 3.6.1 gives an example of the potential problem and Section 551 3.6.2 specifies a solution. This solution is an alternative stronger 552 RPF Check that TRILL Switches can implemented in place of the RFF 553 Check in [RFC6325]. 555 3.6.1 Example of the Potential Problem 557 Consider this network: 559 F--A--B--C--o--D 561 All the links except the link between C and D are point-to-point 562 links. C and D are connected over a broadcast link represented by 563 the pseudonode "o". For example, C and D could be connected by a 564 bridged LAN. (Bridged LANs are transparent to TRILL.) 566 Although the choice of root is unimportant here, assume that D or F 567 is chosen as the root of a distribution tree so it is obvious the 568 tree looks just like the diagram above. 570 Now assume a link comes up from A to the same bridged LAN. The 571 network then looks like this: 573 +--------+ 574 | | 575 F--A--B--C--o--D 577 Let's say the resulting tree in steady state includes all links 578 except the B-C link. After the network has converged, a packet that 579 starts out from F will go F->A. Then A will send one copy on the A-B 580 link and another copy into the bridge LAN from which it will be 581 received by C and D. 583 Now consider a transition stage where A and D have acted on the new 584 LSPs and programmed their forwarding plane, while B and C have not 585 yet done so. This means that B and C both consider the link between 586 them to still be part of the tree. In this case, a packet that starts 587 out from F and reaches A will be copied by A into the A-B link and to 588 the bridge LAN. D's RPF check says to accept packets on this tree 589 coming from F over its port on the bridged LAN, so it gets accepted. 590 D is also adjacent to A on the tree, so the tree adjacency check, a 591 separate check mandated by [RFC6325] also passes. 593 However, the packet that gets to B gets sent out by B to C. C's RPF 594 check still has the old state, and it thinks the packet is OK. C 595 sends the packet along the old tree, which is into the bridge LAN. D 596 receives one more packet, but the tree adjacency check passes at D 597 because C is adjacent to D in the new tree as well. The RPF Check 598 also passes at D because D's port on the bridged LAN is OK for 599 receiving packets from F. 601 So, during this transient state, D gets duplicates of every multi- 602 destination packet ingressed at F (unless the packet gets pruned) 603 until B and C act on the new LSPs and program their hardware tables. 605 3.6.2 Solution and Discussion 607 The problem stems from the RPF Check in [RFC6325] depending only on 608 the port at which a TRILL data packet is received, the ingress 609 nickname, and the tree being used, that is, a check if {ingress 610 nickname, tree, input port} is a valid combination according to the 611 receiving TRILL switch's view of the campus topology. A multi-access 612 link actually has multiple adjacencies overlaid on one physical link 613 and to avoid the problem shown in Section 3.6.1, a stronger check is 614 needed that includes the Layer 2 source address of the TRILL Data 615 packet being received. (TRILL is a Layer 3 protocol and TRILL 616 switches are true routers that logically strip the Layer 2 header 617 from any arriving TRILL data packets and add the appropriate new 618 Layer 2 header to any outgoing TRILL Data packet to get it to the 619 next TRILL switch, so the Layer 2 source address in a TRILL Data 620 packet identifies the immediately previous TRILL Switch that 621 forwarded the packet.) 623 What is needed, instead of checking the validity of the triplet 624 {ingress nickname, tree, input port} is to check that the quadruplet 625 {ingress nickname, source SNPA, tree, input port} is valid (where 626 "source SNPA" (Sub-Network Point of Access) is the Outer.MacSA for an 627 Ethernet link). Although it is true that [RFC6325] also requires a 628 check that a multi-destination TRILL Data packet is from a TRILL 629 switch that is adjacent in the distribution tree being used, this is 630 a separate check from the RPF Check and these two independent checks 631 are not as powerful as the single unified check for a valid 632 quadruplet. 634 However, this stronger RPF Check is not without cost. In the simple 635 case of a multi-access link where each TRILL switch has only one port 636 on the link, it merely increases the size of validity entries by 637 adding the source SNPA (Outer.MacSA). However, assume some TRILL 638 Switch RB1 has N ports attached to a multi-access link. RB1 is 639 permitted to load split multi-destination traffic it is sending into 640 the multi-access link across those ports (Section 4.4.4 [RFC6325]). 641 Assume RB2 is another TRILL Switch on the link and RB2 is 642 distribution tree adjacent to RB1. The number of validity quadruplets 643 at RB2 for ingress nicknames whose multi-destination traffic would 644 arrive through RB1 is multiplied by N because RB2 has to accept such 645 traffic from any of the ports RB1 has on the access-link. Although 646 such instances seem to be very rare in practice, N could in principle 647 be tens or even a hundred or more ports, vastly increasing the RPF 648 check state at RB2 when this stronger RPF check is used. 650 Another potential cost of the stronger RPF Check is increased 651 transient loss of multi-destination TRILL data packets during a 652 topology change. For TRILL switch D, the new stronger RPF Check is 653 (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1) while the old 654 one was ( tree->A, Outer.MacSA=C, ingress=A, arrival port=if1). 655 Suppose both A and B have switched to the new tree for multicast 656 forwarding while D has not updated its RPF Check yet, then the 657 multicast packet will be dropped at D's if1. Since D still expects 658 packet from "Outer.MacSA=C". But we do not have this packet loss 659 issue if the weaker triplet check (tree->A, ingress=A, arrival 660 port=if1) is used. Thus, the stronger check can increase the RPF 661 Check discard of multi-destination packets during topology 662 transients. 664 Because of these potential costs, implementation of this stronger RPF 665 Check is optional; however, the TRILL protocol is updated to provide 666 that TRILL Switches MUST, for multi-destination packets, either 667 implement the RPF and other checks in [RFC6325] or implement this 668 stronger RPF Check as a substitute for the [RFC6325] RPF and tree 669 adjacency checks. 671 4. Nicknames Selection (Unchanged) 673 Nickname selection is covered by Section 3.7.3 of [RFC6325]. 674 However, the following should be noted: 676 1. The second sentence in the second bullet item in Section 3.7.3 of 677 [RFC6325] on page 25 is erroneous [Err3002] and is corrected as 678 follows: 680 o The occurrence of "IS-IS ID (LAN ID)" is replaced with 681 "priority". 683 o The occurrence of "IS-IS System ID" is replaced with "seven- 684 byte IS-IS ID (LAN ID)". 686 The resulting corrected sentence in [RFC6325] reads as follows: 688 "If RB1 chooses nickname x, and RB1 discovers, through receipt 689 of an LSP for RB2 at any later time, that RB2 has also chosen 690 x, then the RBridge or pseudonode with the numerically higher 691 priority keeps the nickname, or if there is a tie in priority, 692 the RBridge with the numerically higher seven-byte IS-IS ID 693 (LAN ID) keeps the nickname, and the other RBridge MUST select 694 a new nickname." 696 2. In examining the link-state database for nickname conflicts, 697 nicknames held by IS-IS unreachable TRILL Switches MUST be 698 ignored, but nicknames held by IS-IS reachable TRILL Switches MUST 699 NOT be ignored even if they are data unreachable. 701 3. An RBridge may need to select a new nickname, either initially 702 because it has none or because of a conflict. When doing so, the 703 RBridge MUST consider as available all nicknames that do not 704 appear in its link-state database or that appear to be held by IS- 705 IS unreachable TRILL Switches; however, it SHOULD give preference 706 to selecting new nicknames that do not appear to be held by any 707 TRILL Switch in the campus, reachable or unreachable, so as to 708 minimize conflicts if IS-IS unreachable TRILL Switches later 709 become reachable. 711 4. An RBridge, even after it has acquired a nickname for which there 712 appears to be no conflicting claimant, MUST continue to monitor 713 for conflicts with the nickname or nicknames it holds. It does so 714 by checking in LSP PDUs it receives that should update its link- 715 state database for the following: any occurrence of any of its 716 nicknames held with higher priority by some other TRILL Switch 717 that is IS-IS reachable from it. If it finds such a conflict, it 718 MUST select a new nickname, even when in overloaded state. (It is 719 possible to receive an LSP that should update the link-state 720 database but does not do so due to overload.) 722 5. In the very unlikely case that an RBridge is unable to obtain a 723 nickname because all valid RBridge nicknames (0x0001 through 724 0xFFBF inclusive) are in use with higher priority by IS-IS 725 reachable TRILL Switches, it will be unable to act as an ingress, 726 egress, or tree root but will still be able to function as a 727 transit TRILL Switch. Although it cannot be a tree root, such an 728 RBridge is included in distribution trees computed for the campus 729 unless all its neighbors are overloaded. It would not be possible 730 to send a unicast RBridge Channel message specifically to such a 731 TRILL Switch [RFC7178]; however, it will receive unicast RBridge 732 Channel messages sent by a neighbor to the Any-RBridge egress 733 nickname and will receive appropriate multi-destination RBridge 734 Channel messages. 736 5. MTU (Maximum Transmission Unit) (Unchanged) 738 MTU values in TRILL key off the originatingL1LSPBufferSize value 739 communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The 740 campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is 741 the minimum value of originatingL1LSPBufferSize for the RBridges in a 742 campus, but not less than 1470. The MTU testing mechanism and 743 limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and 744 thus that IS-IS can operate properly. 746 If nothing is known about the MTU of the links or the 747 originatingL1LSPBufferSize of other RBridges in a campus, the 748 originatingL1LSPBufferSize for an RBridge should default to the 749 minimum of the LSP size that its TRILL IS-IS software can handle and 750 the minimum MTU of the ports that it might use to receive or transmit 751 LSPs. If an RBridge does have knowledge of link MTUs or other 752 RBridge originatingL1LSPBufferSize, then, to avoid the necessity to 753 regenerate the local LSPs using a different maximum size, the 754 RBridge's originatingL1LSPBufferSize SHOULD be configured to the 755 minimum of (1) the smallest value that other RBridges are or will be 756 announcing as their originatingL1LSPBufferSize and (2) a value small 757 enough that the campus will not partition due to a significant number 758 of links with limited MTU. However, as provided in [RFC6325], in no 759 case can originatingL1LSPBufferSize be less than 1470. In a well- 760 configured campus, to minimize any LSP regeneration due to re-sizing, 761 all RBridges will be configured with the same 762 originatingL1LSPBufferSize. 764 Section 5.1 below corrects errata in [RFC6325], and Section 5.2 765 clarifies the meaning of various MTU limits for TRILL Ethernet links. 767 5.1 MTU-Related Errata in RFC 6325 769 Three MTU-related errata in [RFC6325] are corrected in the 770 subsections below. 772 5.1.1 MTU PDU Addressing 774 Section 4.3.2 of [RFC6325] incorrectly states that multi-destination 775 MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links 776 with the All-RBridges multicast address as the Outer.MacDA [Err3004]. 777 As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be 778 sent to the All-IS-IS-RBridges multicast address. 780 5.1.2 MTU PDU Processing 782 As discussed in [RFC6325] and, in more detail, in [RFC7177], MTU- 783 probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of 784 [RFC6325] erroneously does not allow for this possibility [Err3003]. 785 It is corrected by replacing Item numbered "1" in Section 4.6.2 of 786 [RFC6325] with the following quoted text to which TRILL Switches MUST 787 conform: 789 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All- 790 IS-IS-RBridges or the unicast MAC address of the receiving 791 RBridge port, the frame is handled as described in Section 792 4.6.2.1" 794 The reference to "Section 4.6.2.1" in the above quoted text is to 795 that section in [RFC6325]. 797 5.1.3 MTU Testing 799 The last two sentences of Section 4.3.2 of [RFC6325] have errors 800 [Err3053]. They currently read: 802 "If X is not greater than Sz, then RB1 sets the "failed minimum 803 MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X 804 > Sz, then RB1 advertises the largest tested X for each adjacency 805 in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise 806 X as an attribute of the link to RB2 in RB1's LSP." 808 They should read: 810 "If X is not greater than or equal to Sz, then RB1 sets the 811 "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X 812 succeeds, and X >= Sz, then RB1 advertises the largest tested X 813 for each adjacency in the TRILL Hellos RB1 sends on that link, and 814 RB1 MAY advertise X as an attribute of the link to RB2 in RB1's 815 LSP." 817 5.2 Ethernet MTU Values 819 originatingL1LSPBufferSize is the maximum permitted size of LSPs 820 starting with the 0x83 Intradomain Routeing Protocol Discriminator 821 byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 822 bytes. (This is because, in its previous life as DECnet Phase V, IS- 823 IS was encoded using the SNAP SAP (Sub-Network Access Protocol 824 Service Access Point) [RFC7042] format, which takes 8 bytes of 825 overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When 826 standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) 827 encoding, this default could have been increased by a few bytes but 828 was not.) 830 In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This 831 allows 27 bytes of headroom or safety margin to accommodate legacy 832 devices with the classic Ethernet maximum MTU despite headers such as 833 an Outer.VLAN. 835 Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet 836 links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of 837 the PDU starting just after the L2-IS-IS Ethertype and ending just 838 before the Ethernet Frame Check Sequence (FCS)) does not to exceed 839 Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 840 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded by an 841 amount that depends on the size being tested (which may exceed Sz). 843 Sz does not limit TRILL Data packets. They are only limited by the 844 MTU of the devices and links that they actually pass through; 845 however, links that can accommodate IS-IS PDUs up to Sz would 846 accommodate, with a generous safety margin, TRILL Data packet 847 payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending 848 just before the FCS. 850 Most modern Ethernet equipment has ample headroom for frames with 851 extensive headers and is sometimes engineered to accommodate 9K byte 852 jumbo frames. 854 6. TRILL Port Modes (Unchanged) 856 Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports 857 but may not be completely clear on the effects of various 858 combinations of bits. 860 The table below explicitly indicates the effect of all possible 861 combinations of the TRILL port mode bits. "*" in one of the first 862 four columns indicates that the bit can be either zero or one. The 863 following columns indicate allowed frame types. The Disable bit 864 normally disables all frames, but, as an implementation choice, some 865 or all low-level Layer 2 control message can still be sent or 866 received. Examples of Layer 2 control messages are those control 867 frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP 868 link negotiation messages [RFC6361]. 870 +-+-+-+-+--------+-------+-------+-------+-------+ 871 |D| | | | | | | | | 872 |i| |A| | | | TRILL | | | 873 |s| |c|T| |native | Data | | | 874 |a| |c|r| |ingress| | | | 875 |b|P|e|u| | | LSP | | | 876 |l|2|s|n|Layer 2 |native | SNP | TRILL | P2P | 877 |e|P|s|k|Control |egress | MTU | Hello | Hello | 878 +-+-+-+-+--------+-------+-------+-------+-------+ 879 |0|0|0|0| Yes | Yes | Yes | Yes | No | 880 +-+-+-+-+--------+-------+-------+-------+-------+ 881 |0|0|0|1| Yes | No | Yes | Yes | No | 882 +-+-+-+-+--------+-------+-------+-------+-------+ 883 |0|0|1|0| Yes | Yes | No | Yes | No | 884 +-+-+-+-+--------+-------+-------+-------+-------+ 885 |0|0|1|1| Yes | No | No | Yes | No | 886 +-+-+-+-+--------+-------+-------+-------+-------+ 887 |0|1|0|*| Yes | No | Yes | No | Yes | 888 +-+-+-+-+--------+-------+-------+-------+-------+ 889 |0|1|1|*| Yes | No | No | No | Yes | 890 +-+-+-+-+--------+-------+-------+-------+-------+ 891 |1|*|*|*|Optional| No | No | No | No | 892 +-+-+-+-+--------+-------+-------+-------+-------+ 894 The formal name of the "access bit" above is the "TRILL traffic 895 disable bit". The formal name of the "trunk bit" is the "end-station 896 service disable bit" [RFC6325]. 898 7. The CFI/DEI Bit (Unchanged) 900 In May 2011, the IEEE promulgated [802.1Q-2011], which changed the 901 meaning of the bit between the priority and VLAN ID bits in the 902 payload of C-VLAN tags. Previously, this bit was called the CFI 903 (Canonical Format Indicator) bit [802] and had a special meaning in 904 connection with IEEE 802.5 (Token Ring) frames. Now, under 905 [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar 906 to that bit in S-VLAN/B-VLAN tags where this bit has always been a 907 DEI bit. 909 The TRILL base protocol specification [RFC6325] assumed, in effect, 910 that the link by which end stations are connected to TRILL Switches 911 and the restricted virtual link provided by the TRILL Data packet are 912 IEEE 802.3 Ethernet links on which the CFI bit is always zero. 913 Should an end station be attached by some other type of link, such as 914 a Token Ring link, [RFC6325] implicitly assumed that such frames 915 would be canonicalized to 802.3 frames before being ingressed, and 916 similarly, on egress, such frames would be converted from 802.3 to 917 the appropriate frame type for the link. Thus, [RFC6325] required 918 that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in 919 Section 4.1.1 of [RFC6325], always be zero. 921 However, for TRILL Switches with ports conforming to the change 922 incorporated in the IEEE 802.1Q-2011 standard, the bit in the 923 Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by 924 the EISS (Enhanced Internal Sublayer Service) interface on ingressing 925 a native frame. Similarly, this bit MUST be provided to the EISS 926 when transiting or egressing a TRILL Data packet. As with the 3-bit 927 Priority field, the DEI bit to use in forwarding a transit packet 928 MUST be taken from the Inner.VLAN. The exact effect on the 929 Outer.VLAN DEI and priority bits and whether or not an Outer.VLAN 930 appears at all on the wire for output frames may depend on output 931 port configuration. 933 TRILL campuses with a mixture of ports, some compliant with 934 [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards, 935 especially if they have actual Token Ring links, may operate 936 incorrectly and may corrupt data, just as a bridged LAN with such 937 mixed ports and links would. 939 8. Other IS-IS Considerations (Changed) 941 This section covers E-L1FS Support, Control Packet Priorities, 942 Unknown PDUs, the Nickname Flags APPsub-TLV, and Graceful Restart. 944 8.1 E-L1FS Support (New) 946 TRILL switches MUST support Extended Level 1 Flooding Scope PDUs (E- 947 L1FS) [RFC7356] and MUST include a Scoped Flooding Support TLV 948 [RFC7356] in all TRILL Hellos they send indicating support for this 949 scope and any other FS-LSP scopes that they support. This support 950 increases the number of fragments available for link state 951 information by over two orders of magnitude. (See Section 9 for 952 further information on support of the Scoped Flooding Support TLV.) 954 In addition, TRILL switches MUST advertise their support of E-L1FS 955 flooding in a TRILL Version sub-TLV capability bit (see [RFC7176] and 956 Section 11.2). This bit is used by a TRILL switch, say RB1, to 957 determine support for E-L1FS by some remote RBx. The alternative of 958 simply looking for an E-L1FS FS-LSP originated by RBx fails because 959 (1) RBx might support E-L1FS flooding but not be originating any E- 960 L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs there 961 might, due to legacy TRILL switches in the campus, be no path between 962 RBx and RB1 through TRILL switches supporting E-L1FS flooding. If 963 that were the case, no E-L1FS FS-LSP originated by RBx could get to 964 RB1. 966 8.1.1 Backward Compatibility 968 A TRILL campus might contain TRILL switches supporting E-L1FS 969 flooding and legacy TRILL switches that do not support E-L1FS or 970 perhaps do not support any [RFC7356] scopes. 972 A TRILL switch conformant to this document can always tell which 973 adjacent TRILL switches support E-L1FS flooding from the adjacency 974 table entries on its ports (see Section 9). In addition, such a TRILL 975 switch can tell which remote TRILL switches in a campus support E- 976 L1FS by the presence of a TRILL Version sub-TLV in that TRILL 977 switch's LSP with the E-L1FS support bit set in the Capabilities 978 field; this capability bit is ignored for adjacent TRILL switches for 979 which only the adjacency table entry is consulted to determine E-L1FS 980 support. 982 TRILL specifications making use of E-L1FS MUST specify how situations 983 involving mixed TRILL campus of TRILL switches will be handled. 985 8.1.2 E-L1FS Use for Existing (sub)TLVs 987 In a campus where all TRILL switches support E-L1FS, all TRILL sub- 988 TLVs listed in Section 2.3 of [RFC7176], except the TRILL Version 989 sub-TLV, MAY be advertised by inclusion in Router Capability or MT- 990 Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL Version sub- 991 TLV still MUST appear in an LSP fragment zero.) 993 In a mixed campus where some TRILL switches support E-L1FS and some 994 do not, then only the following four sub-TLVs of those listed in 995 Section 2.3 of [RFC7176] can appear in E-L1FS and then only under the 996 conditions discussed below. In the following list, each sub-TLV is 997 preceded by an abbreviated acronym used only in this Section 8.1.2: 999 IV: Interested VLANs and Spanning Tree Roots sub-TLV 1000 VG: VLAN Groups sub-TLV 1001 IL: Interested Labels and Spanning Tree Roots sub-TLV 1002 LG: Label Groups sub-TLV 1004 An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an 1005 E-L1FS FS-LSP and MUST be advertised in an LSP unless the following 1006 conditions are met: 1007 - E-L1FS is supported by all of the TRILL switches that are data 1008 reachable from RB1 and are interested in the VLANs mentioned in 1009 the IV or VG sub-TLV, and 1010 - there is E-L1FS connectivity between all such TRILL switches in 1011 the campus interested in the VLANs mentioned in the IV or VG sub- 1012 TLV (connectivity involving only intermediate TRILL switches that 1013 also support E-L1FS). 1015 Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS 1016 LSP by any TRILL switch that has enough room in its LSPs. 1018 The conditions for using E-L1FS for the IL and LG sub-TLVs are the 1019 same as for IV and VG but with Fine Grained Labels [RFC7172] 1020 substituted for VLANs. 1022 Note, for example, that the above would permit a contiguous subset 1023 of the campus that supported Fine Grained Labels and E-L1FS to use 1024 E-L1FS to advertise IL and LG sub-TLVs even if the remainder of 1025 the campus did not support Fine Grained Labels or E-L1FS. 1027 8.2 Control Packet Priorities (New) 1029 When deciding what packet to send out a port, control packets used to 1030 establish and maintain adjacency between TRILL switches SHOULD be 1031 treated as being in the highest priority category. This includes 1032 TRILL IS-IS Hello and MTU PDUs and possibly other adjacency [RFC7177] 1033 or link technology specific packets. Other control and data packets 1034 SHOULD be given lower priority so that a flood of such other packets 1035 cannot lead to loss of or inability to establish adjacency. Loss of 1036 adjacency causes a topology transient that can result in reduced 1037 throughput, reordering, increased probability of loss of multi- 1038 destination data, and, if the adjacency is a cut point, network 1039 partitioning. 1041 Other important control packets should be given second highest 1042 priority. Lower priorities should be given to data or less important 1043 control packets. 1045 Control packets can be ordered into priority classes as shown below. 1046 Although few implementations will actually treat all of these classes 1047 differently, higher numbered classes SHOULD NOT be treated as higher 1048 priority than lower numbered class. There may be additional control 1049 packets, not specifically listed in any category below, that SHOULD 1050 be handled as being in the most nearly analogous category. 1052 1. Hello, MTU-probe, MTU-ack, and other packets critical to 1053 establishing and maintaining adjacency. 1055 2. LSPs, CSNP/PSNPs, and other important control packets, 1057 3. Circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1059 4. Non-circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1061 8.3 Unknown PDUs (New) 1063 TRILL switches MUST silently discard [IS-IS] PDUs they receive with 1064 PDU numbers they do not understand, just as they ignore TLVs and sub- 1065 TLVs they receive that have unknown Types and sub-Types; however, 1066 they SHOULD maintain a counter of how many such PDUs have been 1067 received, on a per PDU number basis. (This is not burdensome as the 1068 PDU number is only a 5-bit field.) 1070 Note: The set of valid [IS-IS] PDUs was stable for so long that 1071 some IS-IS implementations may treat PDUs with unknown PDU 1072 numbers as a serious error and, for example, an indication that 1073 other valid PDUs from the sender are not to be trusted or that 1074 they should drop adjacency to the sender if it was adjacent. 1075 However, the MTU-probe and MTU-ack PDUs were added by [RFC7176] 1076 and now [RFC7356] has added three more new PDUs. While the 1077 authors of this document are not aware of any Internet drafts 1078 calling for further PDUs, the eventual addition of further new 1079 PDUs should not be surprising. 1081 8.4 Nickname Flags APPsub-TLV (New) 1083 An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV 1084 [RFC7357] is specified below. 1086 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1087 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1088 | Type = NickFlags (#tbd2) | 1089 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1090 | Length = 4*K | 1091 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1092 | NICKFLAG RECORD 1 | 1093 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1094 ... 1095 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1096 | NICKFLAG RECORD K | 1097 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1099 Where each NICKFLAG RECORD has the following format: 1101 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1102 | Nickname | 1103 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1104 |IN| RESV | 1105 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1107 o Type: NickFlags TRILL APPsub-TLV, set to tbd2 (NICKFLAGS) 1109 o Length: 4 times the number of NICKFLAG RECORDS present. 1111 o Nickname: A 16-bit TRILL nickname held by the advertising TRILL 1112 switch ([RFC6325] and Section 4). 1114 o IN: Ingress. If this flag is one, it indicates the advertising 1115 TRILL switch may use the nickname in the NICKFLAG RECORD as the 1116 ingress nickname of TRILL Headers it creates. If the flag is 1117 zero, that nickname will not be used for that purpose. 1119 o RESV: Reserved for additional flags to be specified in the 1120 future. MUST be sent as zero and ignored on receipt. 1122 A NICKFLAG RECORD is ignored if the nickname it lists is not a 1123 nickname owned by the TRILL switch advertising the enclosing 1124 NickFlags APPsub-TLV. 1126 If a TRILL switch intends to use a nickname in the ingress nickname 1127 field of TRILL Headers it constructs, it can advertise this through 1128 E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry 1129 with the IN flag set. If it owns only one nickname, there is no 1130 reason to do this because, if a TRILL switch advertises no NickFlags 1131 APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed 1132 that the TRILL switch might use any or all nicknames it owns as the 1133 ingress nickname in TRILL Headers it constructs. 1135 Every reasonable effort should be made to be sure that Nickname sub- 1136 TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync. If all TRILL 1137 switches in a campus support E-L1FS, so that Nickname sub-TLVs can be 1138 advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any 1139 NickFlags APP-subTLVs for any particular nickname should be 1140 advertised in the same fragment. If they are not in the same fragment 1141 then, to the extent practical, all fragments involving those sub-TLVs 1142 for the same nickname should be propagated as an atomic action. If a 1143 TRILL switch sees multiple NickFlags APPsub-TLV entries for the same 1144 nickname, it assumes that nickname might be used as the ingress in a 1145 TRILL Header if any of the NickFlags APPsub-TLV entries have the IN 1146 bit set. 1148 It is possible that a NickFlags APPsub-TLV would not be propagated 1149 throughout the TRILL campus due to legacy TRILL switches not 1150 supporting E-L1FS. In that case, Nickname sub-TLVs must be advertised 1151 in LSPs and TRILL switches not receiving NickFlags APPsub-TLVs having 1152 entries with the IN flag set will simply assume that the source TRILL 1153 switch might use any of its nicknames as ingress in constructing 1154 TRILL Headers. Thus the use of this optional APPsub-TLV is backwards 1155 compatible with legacy lack of E-L!FS support. 1157 Additional flags may be assigned for other purposes out of the RESV 1158 field for other purposes in the future. 1160 8.5 Graceful Restart (Unchanged) 1162 TRILL Switches SHOULD support the features specified in [RFC5306], 1163 which describes a mechanism for a restarting IS-IS router to signal 1164 to its neighbors that it is restarting, allowing them to reestablish 1165 their adjacencies without cycling through the down state, while still 1166 correctly initiating link-state database synchronization. If this 1167 feature is not supported, it may increase the number of topology 1168 transients cause by a TRILL switch rebooting due to errors or 1169 maintenance. 1171 9. Updates to [RFC7177] (Adjacency) [Changed) 1173 To support the E-L1FS flooding scope [RFC7356] mandated by Section 1174 8.1 and backwards compatibility with legacy RBridges not supporting 1175 E-L1FS flooding, the following updates are made to [RFC7177]: 1177 1. The list in the second paragraph of [RFC7177] Section 3.1 has the 1178 following item added: 1180 - The Scoped Flooding Support TLV. 1182 In addition, the sentence immediately after that list is modified to 1183 read as follows: 1185 Of course, the priority, Desired Designated VLAN, Scoped Flooding 1186 Support TLV, and possibly the inclusion or value of the PORT- 1187 TRILL-VER sub-TLV, and/or BFD-Enabled TLV can change on occasion, 1188 but then the new value(s) must similarly be used in all TRILL 1189 Hellos on the LAN port, regardless of VLAN. 1191 2. An additional bullet item is added to the end of Section 3.2 of 1192 [RFC7177] as follows: 1194 o The value from the Scoped Flooding Support TLV or a null string 1195 if none was included. 1197 3. Near the bottom of Section 3.3 of [RFC7177] a bullet item as 1198 follows is added: 1200 o The variable length value part of the Scoped Flooding Support 1201 TLV in the Hello or a null string if that TLV does not occur in 1202 the Hello. 1204 4. At the beginning of Section 4 of [RFC7177], a bullet item is added 1205 to the list as follows: 1207 o The variable length value part of the Scoped Flooding Support 1208 TLV used in TRILL Hellos sent on the port. 1210 10. TRILL Header Update (New) 1212 The TRILL header has been updated from its original specification in 1213 [RFC6325] by [TRILL-OAM-FM] and [RFC7179] and is further updated by 1214 this document. The TRILL header is now as show below and is followed 1215 by references for all of the fields. Those fields for which the 1216 reference is only to [RFC6325] are unchanged from that RFC. 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | V |A|C|M| RESV |F| Hop Count | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Egress Nickname | Ingress Nickname | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 : Optional Flag Word : 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 In calculating a TRILL data packet hash as part of equal-cost multi- 1227 path selection, a TRILL switch MUST ignore the value of the "A" and 1228 "C" bits. In [RFC6325] and [RFC7179] the RESV and F fields above 1229 together constituted the "Ex-Length" or TRILL Header Extensions 1230 Length field. 1232 o V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325]. 1234 o A (Alert): 1 bit. See [TRILL-OAM-FM]. 1236 o C (Color): 1 bit. See Section 10.1. 1238 o M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325]. 1240 o RESV: 4 bits. These bits are reserved and MUST be sent as zero. 1241 They SHOULD be ignored on receipt; however, due to their previous 1242 use as specified in [RFC6325], some TRILL fast path harware 1243 implementations trap and do not forward TRILL Data packets with 1244 these bits non-zero. 1246 o F: 1 bit. If this field is non-zero, then the optional Flag Word 1247 described in Section 10.2 is present. If it is zero, the Flag Word 1248 is not prsent. 1250 o Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 1251 below. 1253 o Egress Nickname. See Section 3.7.1 of [RFC6325]. 1255 o Ingress Nickname. See Section 3.7.2 of [RFC6325]. 1257 o Optional Flag Word: See [RFC7179] and Section 10.2. 1259 10.1 Color Bit 1261 The Color bit provides an optional way by which ingress TRILL 1262 switches MAY mark TRILL Data packets for implementation specific 1263 purposes. Transit TRILL switches MUST NOT change this bit. Transit 1264 and egress TRILL switches MAY use the Color bit for implementation 1265 dependent traffic labeling or statistical or other traffic study or 1266 analysis. 1268 10.2 Flag Word Changes (update to [RFC7179]) 1270 When the extension length field is non-zero, the first 32 bits after 1271 the Ingress nickname field provides additional flags. These bits are 1272 as specified in [RFC7179] except as changed by the subsections below 1273 that provide extended Hop Count and extended Color fields. See 1274 Section 10.3 for a diagram and summary of these fields. 1276 10.2.1 Extended Hop Count 1278 The TRILL base protocol [RFC6325] specifies the Hop Count field in 1279 the header, to avoid packets persisting in the network due to looping 1280 or the like. However, the Hop Count field size (6 bits) limits the 1281 maximum hops a TRILL data packet can traverse to 64. Optionally, 1282 TRILL switches can use a field composed of bits 14 through 16 in the 1283 Flag Word, as specified below. to extend this field to 9 bits. This 1284 increases the maximum Hop Count to 512. Use of Hop Counts in excess 1285 of 64 requires support of this optional capability at all TRILL 1286 switches along the path of a TRILL Data packet. 1288 10.2.1.1 Advertising Support 1290 In case of a TRILL campus such that the unicast calculated path, plus 1291 a reasonable allowance for alternate pathing, or the distribution 1292 tree calculated path, traverse more than 64 hops, it may be that not 1293 all the TRILL switches support the extended Hop Count mechanism. As 1294 such it is required that TRILL switches advertise their support by 1295 setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header 1296 Flags Supported field [RFC7176]; bits 15 and 16 of that field are now 1297 specified as Unassigned (see Section 11.2.5). 1299 10.2.1.2 Ingress Behavior 1301 If an ingress TRILL switch determines it should set the hop count for 1302 a TRILL Data packet to 63 or less, then behavior is as specified in 1303 the TRILL base protocol [RFC6325]. If hop count for a TRILL Data 1304 packet should be set to some value greater than 63 but less than 512 1305 and all TRILL switches that the packet is reasonably likely to 1306 encounter support extended Hop Count, then the resulting TRILL Header 1307 has the Flag Word extension present, the high order three bits of the 1308 desired hop count are stored in the extended Hop Count field in the 1309 Flag Word, the five low order bits are stored in the Hop Count filed 1310 in the first word of the TRILL Header, and bit two (the Critical 1311 Reserved bit of the Critical Summary Bits) in the Flag Word is set. 1313 For known unicast traffic (TRILL Header M bit zero), when an ingress 1314 TRILL switch determines that the least cost path to the egress is 1315 more than 64 hops but not all TRILL switches on that path support the 1316 extended Hop Count feature, the frame is discarded. 1318 For multi-destination traffic, when a TRILL switch determines that 1319 one or more tree path from the ingress it more than 64 hops but not 1320 all TRILL switches in the campus support the extended Hop Count 1321 feature, the encapsulation uses a total Hop Count of 63 to obtain at 1322 least partial distribution of the traffic. 1324 10.2.1.3 Transit Behavior 1326 A transit TRILL switch supporting extended Hop Count behaves like a 1327 base protocol [RFC6325] TRILL switch in decrementing the hop count 1328 except that it considers the hop count to be a 9 bit file where the 1329 extended Hop Count field consistutes the high order three bits. 1331 To be more precise: a TRILL switch supporting extended Hop Count 1332 takes the first of the following actions that is applicable: 1334 1. If both the Hop Count and extended Hop Count fields are zero, the 1335 packet is discarded. 1337 2. If the Hop Count is non-zero, it is decremented. As long as the 1338 extended Hop Count is non-zero, no special action is taken if the 1339 result of this decrement is zero and the packet is processed 1340 normally. 1342 3. If the Hop Count is zero, it is set to the maximum value of 63 and 1343 the extended Hop Count is decremented. 1345 10.2.1.4 Egress Behavior 1347 No special behavior is required when egressing a TRILL Data packet 1348 that uses the extended Hop Count. The Flag Word, if present, is 1349 removed along with the rest of the TRILL Header during decapsulation. 1351 10.2.2 Extended Color Field 1353 Flag Word bits 27 and 28 are specified to be a two-bit Extended Color 1354 field (see Section 10.3). These bits are in the non-critical ingress- 1355 to-egress region of the Flag Word. 1357 The Extended Color field provides an optional way by which ingress 1358 TRILL switches MAY mark TRILL Data packets for implementation 1359 specific purposes. Transit TRILL switches MUST NOT change this bit. 1360 Transit and egress TRILL switches MAY use the Color bit for 1361 implementation dependent traffic labeling or statistical or other 1362 traffic study or analysis. 1364 As provided in Section 2.3.1 of [RFC7176], support for these bits is 1365 indicated by the same bits (27 and 28) in the Capabilities and Header 1366 Flags Supported field of the TRILL Version Sub-TLV. In the spirit of 1367 indicating support, a TRILL switch that sets or senses the Extended 1368 Color field SHOULD set the corresponding 2-bit field in the TRILL 1369 Version Sub-TLV non-zero. The meaning of the possible non-zero values 1370 (1, 2 or 3) is implementation dependent. 1372 10.3 Updated Flag Word Summary 1374 With the changes above, the 32-bit Flag Word extension to the TRILL 1375 Header [RFC7179], appearing as the "TRILL Extended Header Flags" 1376 registry on the TRILL Parameters IANA web page, is now as follows: 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 1382 |.....|.........|...........|.....|.......|...........|.........| 1383 |C|C|C| |C|N| | Ext | | |Ext| | 1384 |R|R|R| |R|C| | Hop | | |Clr| | 1385 |H|I|R| |C|C| | Cnt | | | | | 1386 |b|t|s| |A|A| | | | | | | 1387 |H|E|v| |F|F| | | | | | | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Bit 0 to 2 are the Critical Summary bits as specified in [RFC7179] 1391 consisting of the Critical Hop-by-Hop, Critical Ingres-to-Egress, and 1392 Critical Reserved bits, respectively. The next two fields are 1393 specific Critical and Non-Critical Hop-by-Hop bits, CHbH and NCHbH, 1394 respectively, containing the Critical and Non-Critical Channel Alert 1395 flags as specified in [RFC7179]. The next field is the Critical 1396 Reserved bits (CRSV) that are specified herein to be the Extended Hop 1397 Count. Then the Non-Critical Reserved Bits (NCRSV) and the Critical 1398 Ingress-to-Egress bits (CITE) as specified in [RFC7179]. Finally, 1399 there is the Non-Critical Ingress-to-Egress field, the top two bits 1400 of which are specified herein as the Extended Color field. 1402 11. IANA Considerations (Changed) 1404 This section give IANA actions previously completed and newly 1405 requested IANA actions. 1407 11.1 Previously Completed IANA Actions (Unchanged) 1409 The following IANA actions were completed as part of [RFC7180] and 1410 are included here for completeness, since this document obsoletes 1411 [RFC7180]. 1413 1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated 1414 for use in the TRILL Header Egress Nickname field to indicate an 1415 OOMF (Overload Originated Multi-destination Frame). 1417 2. Bit 1 from the seven previously reserved (RESV) bits in the per- 1418 neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is 1419 allocated to indicate that the RBridge sending the TRILL Hello 1420 volunteers to provide the OOMF forwarding service described in 1421 Section 2.4.2 to such frames originated by the TRILL Switch whose 1422 SNPA (MAC address) appears in that Neighbor RECORD. The 1423 description of this bit is "Offering OOMF service". 1425 3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER 1426 sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub- 1427 TLV [RFC7176] and the VLAN inhibition setting mechanisms specified 1428 in [rfc6439bis]. The description of this bit is "Hello reduction 1429 support". 1431 11.2 New IANA Considerations (New) 1433 The following are new IANA actions for this document: 1435 11.2.1 Reference Updated 1437 All references to [RFC7180] in the TRILL Parameters Registry are 1438 replaced with references to this document except that the Reference 1439 for bit 0 in the PORT-TRILL-VER Sub-TLV Capapbilty Flags is changed 1440 to [rfc6439bis]. 1442 11.2.2 The 'E' Capability Bit 1444 IANA is requested to allocate a previously reserved capability bit in 1445 the TRILL Version sub-TLV carried in the Router Capability and MT 1446 Capability TLVs (#242, #144) to indicate support of the [RFC7356] E- 1447 L1FS flooding scope. This capability bit is referred to as the "E" 1448 bit. The following is the addition to the 1450 Bit Description References 1451 ---- --------------------- --------------- 1452 tbd1 E-L1FS FS-LSP support [this document][RFC7356] 1454 11.2.3 NickFlags APPsub-TLV Number 1456 IANA is requested to allocate an APPsub-TLV number under the TRILL 1457 GENINFO TLV from the range less than 255. 1459 Type Name References 1460 ---- --------- ----------- 1461 tbd2 NICKFLAGS [this document] 1463 11.2.4 Update TRILL Extended Header Flags 1465 Update the "TRILL Extended Header Flags" registry as follows: 1467 Bits Purpose References 1468 ----- ---------------------------------------------- ---------- 1470 14-16 Extended Hop Count [this document] 1472 27-28 Extended Color [this document] 1474 29-31 Available non-critical ingress-to-egress flags 1475 [RFC7179] [this document] 1477 11.2.5 TRILL-VER Sub-TLV Capability Flags 1479 Update the "TRILL-VER Sub-TLV Capapbility Flags" registry as follows: 1481 Bit Description Reference 1482 ----- -------------------------- ---------------- 1484 14 Extended Hop Count support [this document] 1486 15-16 Unassigned [this document] 1488 27-28 Extended Color support [this document] 1490 29-31 Extended header flag support [RFC7179] [this document] 1492 12. Security Considerations (Changed) 1494 This memo improves the documentation of the TRILL protocol, corrects 1495 five errata in [RFC6325], updates [RFC6325], [RFC7177], and [RFC7179] 1496 and obsoletes [RFC7180]. 1498 It does not change the Security Considerations of these RFCs to which 1499 the reader is referred. {{ Probably need to say more than this. }} 1501 Acknowledgements 1503 The contributions of the following individuals to this document are 1504 gratefully acknowledged: 1506 Santosh Rajagopalan 1508 The contributions of the following, listed in alphabetic order, to 1509 the preceding version of this document, [RFC7180], are gratefully 1510 acknowledged: 1512 Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia 1513 Perlman, Mike Shand, Meral Shirazipour, and Varun Shah. 1515 Normative References 1517 [802.1Q-2011] - IEEE, "IEEE Standard for Local and metropolitan area 1518 networks -- Media Access Control (MAC) Bridges and Virtual 1519 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 1520 2011. 1522 [IS-IS] - International Organization for Standardization, 1523 "Intermediate System to Intermediate System intra-domain 1524 routeing information exchange protocol for use in conjunction 1525 with the protocol for providing the connectionless-mode network 1526 service (ISO 8473)", Second Edition, November 2002. 1528 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1529 Requirement Levels", BCP 14, RFC 2119, March 1997. 1531 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1532 Engineering", RFC 5305, October 2008. 1534 [RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 1535 RFC 5306, October 2008. 1537 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1538 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1539 Specification", RFC 6325, July 2011. 1541 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1542 Interconnection of Lots of Links (TRILL) Protocol Control 1543 Protocol", RFC 6361, August 2011. 1545 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1546 and D. Dutt, "Transparent Interconnection of Lots of Links 1547 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1549 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1550 D., and A. Banerjee, "Transparent Interconnection of Lots of 1551 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 1553 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1554 and V. Manral, "Transparent Interconnection of Lots of Links 1555 (TRILL): Adjacency", RFC 7177, May 2014. 1557 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 1558 C. Bestler, "Transparent Interconnection of Lots of Links 1559 (TRILL): Header Extension", RFC 7179, May 2014, 1560 . 1562 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1563 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 1564 . 1566 Informative References 1568 [802] - IEEE 802, "IEEE Standard for Local and metropolitan area 1569 networks: Overview and Architecture", IEEE Std 802.1-2001, 8 1570 March 2002. 1572 [Err3002] - RFC Errata, Errata ID 3002, RFC 6325, . 1575 [Err3003] - RFC Errata, Errata ID 3003, RFC 6325, . 1578 [Err3004] - RFC Errata, Errata ID 3004, RFC 6325, . 1581 [Err3052] - RFC Errata, Errata ID 3052, RFC 6325, . 1584 [Err3053] - RFC Errata, Errata ID 3053, RFC 6325, . 1587 [Err3508] - RFC Errata, Errata ID 3508, RFC 6325, . 1590 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1591 "Randomness Requirements for Security", BCP 106, RFC 4086, June 1592 2005, . 1594 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 1595 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 1596 6327, July 2011, . 1598 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1599 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1600 6439, November 2011, . 1602 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1603 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1604 BCP 141, RFC 7042, October 2013. 1606 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1607 "Transparent Interconnection of Lots of Links (TRILL): 1608 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1609 May 2014. 1611 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1612 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1613 RBridge Channel Support", RFC 7178, May 2014. 1615 [RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., 1616 and A. Banerjee, "Transparent Interconnection of Lots of Links 1617 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1618 May 2014. 1620 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1621 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1622 End Station Address Distribution Information (ESADI) Protocol", 1623 RFC 7357, September 2014, . 1626 [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1627 "Problem Statement and Goals for Active-Active Connection at 1628 the Transparent Interconnection of Lots of Links (TRILL) Edge", 1629 RFC 7379, October 2014, . 1632 [TRILL-OAM-FM] - Senevirathen, T., "TRILL Fault Management", draft- 1633 ietf-trill-oam-fm, work in progress. 1635 [rfc6439bis] - Eastlake, D., et al., "TRILL: Appointed Forwarders", 1636 draft-eastlake-trill-rfc6439bis, work in progress. 1638 Appendix A: Life Cycle of a TRILL Switch Port (New) 1640 The contents of this informational Appendix are based on 1641 http://www.ietf.org/mail-archive/web/trill/current/msg06355.html 1643 Question: Suppose we are developing a TRILL implementation to run on 1644 different machines. Then what happens 1st? Is LSP or ESADI 1645 started first? -> Link state database creation -> Designated 1646 RBridge election (How to set priority? any fixed process that 1647 depends on user settings? ) -> etc. ? 1649 Answer: 1651 The first thing that happens on a port/link is any link set-up 1652 that is needed. For example, on a PPP link [RFC6361], you need to 1653 negotiate that you will be using TRILL. However, if you have 1654 Ethernet links [RFC6325], which are probably the most common type, 1655 there isn't any link set-up needed. 1657 Then TRILL IS-IS Hellos get sent out the port to be exchanged on 1658 the link [RFC7177]. Optionally, you might also exchange MTU- 1659 probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test 1660 packets. But all these other things are optional. Only Hellos are 1661 required. 1663 TRILL doesn't send anything else on the link until the link gets 1664 out of the Down or Detect states [RFC7177]. 1666 If a link is configured as a point-to-point link, there is no 1667 Designated RBridge (DRB) election. By default, an Ethernet link is 1668 considered a LAN link and the DRB election occurs when the link is 1669 in any state other than Down. You don't have to configure 1670 priorities for each TRILL switch (RBridge) to be Designated 1671 RBridge (DRB). Things will work fine with all the RBridges on a 1672 link using default priority. But if the network manager wants to 1673 control this, they should be a way for them to configure the 1674 priority to be DRB of the TRILL switch ports on the link. 1676 (To avoid complexity, this appendix generally describes things for 1677 a link that only has two TRILL switches on it. But TRILL works 1678 fine as currently specified on a broadcast link with multiple 1679 TRILL switches on it - actually multiple TRILL switch ports since 1680 a TRILL switch can have multiple ports connected to the same link. 1681 The most likely way to get such a multi-access link with current 1682 technology and the existing TRILL standards is to have more than 2 1683 TRILL switch Ethernet ports connected to a bridged LAN. Since the 1684 TRILL protocol operates above all bridging, to the first 1685 approximation the bridge LAN looks like a transparent broadcast 1686 link to TRILL.) 1687 When a link gets to the 2-Way or Report state, then LSP, CSNP, and 1688 PSNP PDUs start to flow on the link (as well as FS-LSPs, FS-CSNPs, 1689 and FS-PSNPs for E-L1FS (see Section 8.1)). 1691 When a link gets to the Report state, then there is adjacency. The 1692 existence of that adjacency is flooded (reported) to the campus in 1693 LSPs. TRILL data packets can then start to flow on the link as 1694 TRILL switches recalculate the least cost paths and distribution 1695 trees to take the new adjacency into account. Until it gets to the 1696 Report state, there is no adjacency and no TRILL data packets can 1697 flow over that link (with the minor corner case exception that an 1698 RBridge Channel message can, for its first hop only, be sent on a 1699 port where there is no adjacency (Section 2.4 of [RFC7178]). 1700 (Although this paragraph seems to be talking about link state, it 1701 is actually port state. It is possible for different TRILL switch 1702 ports on the same link to temporarily be in different states. The 1703 adjacency state machinery runs independently on each port.) 1705 ESADI [RFC7357] is built on top of the regular TRILL Data routing. 1706 Since ESADI PDUs look, to transit TRILL switches, like regular 1707 TRILL data packets, no ESADI PDUs can flow until adjacencies are 1708 established and TRILL data is flowing. Of course, ESADI is 1709 optional and is not used unless configured... 1711 Question: Does it require TRILL Full headers at the time TRILL-LSPs 1712 start being broadcast on a link? Because at that time it's not 1713 defined Egress and Ingress nicknames. 1715 Answer: 1717 TRILL Headers are only for TRILL Data packets. TRILL IS-IS 1718 packets, such as TRILL-LSPs, are sent in a different way that does 1719 not use a TRILL Header and does not depend on nicknames. 1721 Probably, in most implementations, a TRILL switch will start up 1722 using the same nickname it had when it shut down or last got 1723 disconnected from a campus. If you want, you can implement TRILL 1724 to come up initially not reporting any nickname (by not including 1725 an Nickname sub-TLV in its LSPs) until you get the link state 1726 database or most of the link state database, and then choose a 1727 nickname no other TRILL switch in the campus is using. Of course, 1728 if a TRILL switch does not have a nickname, then it cannot ingress 1729 data, cannot egress known unicast data, and cannot be a tree root. 1731 TRILL IS-IS and LSPs and the link state database all work based on 1732 the 7-byte IS-IS System-ID (sometimes called the LAN ID). System- 1733 IDs always have to be unique across the campus so there is no 1734 problem determining topology regardless of nickname state. The 1735 Nickname system is built on top of that. 1737 Appendix B: Example TRILL PDUs (New) 1739 [Three for four example PDUs to be included here to help answer any 1740 questions about bit ordering or the like.] 1742 Appendix C: Appointed Forwarder Status Lost Couter (New) 1744 This appendix is derived from http://www.ietf.org/mail- 1745 archive/web/trill/current/msg05279.html. 1747 Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on 1748 the value of the Appointed Forwarder Status Lost Counter can result 1749 in splitting of Interested VLANs and Spanning Tree Roots sub-TLVs 1750 [RFC7176], or the corresponding Interested Lables sub-TLVs, due to 1751 minor/accidental differences in the counter value for different VLANs 1752 or FGLs. 1754 This counter is a mechanism to optimize data plane learning by 1755 trimming the expiration timer for learned addresses on a per VLAN/FGL 1756 basis under some circumstances. Note the following: 1758 (1) If an implementer don't care about that optimization and don't 1759 mind some time outs being longer than they otherwise would be, 1760 you can just not bother changing the counter, even if you are 1761 using data plane learning. On the other hand, if you don't care 1762 about sone time outs being shortened when they otherwise 1763 wouldn't, you could increment the counter for multiple VLANs even 1764 you don't lose AF status on a port for all those VLANS but, for 1765 example, only one of them. 1767 (2) If you are relying on ESADI [RFC7357] or Directory Assist 1768 [RFC7379] and not learning from the data plane, the counter 1769 doesn't matter and there really isn't any need to increment it. 1771 (3) If an RBridge port has been configured with the "disable end 1772 station traffic" bit on (also known as the trunk bit), then it 1773 makes no difference if that port is appointed forwarder or not 1774 even though, according to the standard, the Appointed Forwarder 1775 selection mechanism continues to operate. So, under such 1776 circumstances, there is no reason to increment the counter if 1777 such a port loses Appointed Forwarder status. 1779 (4) If you are updating the counter, incrementing it by more than one 1780 (even up to incrementing it by a couple of hundred), so that it 1781 matches the counter for some adjacent VLAN for the same RBridge 1782 would have an extremely small probability of causing any sub- 1783 optimization and, if it did, that sub-optimization would just be 1784 to occasionally fail to specially decrease the time out for some 1785 learned addresses. 1787 Appendix D: Changes from [RFC7180] 1789 This informational Appendix summarizes the changes, augmentations, 1790 and excisions this document makes to [RFC7180]. 1792 D.1 Changes 1794 For each heading in this document ending with "(Changed)", this 1795 section summarizes how it was changed: 1797 Section 1, Introduction: numerous changes to reflect the overall 1798 changes in contents. 1800 Section 1.1, Precedence: changed to add mention of [RFC7179]. 1802 Section 1.3, Terminology and Acronyms: numerous terms added. 1804 Section 3, Distribution Trees and RPF Check: changed by the addition 1805 of the new material in Section 3.6. See C.2 item 1. 1807 Section 8, Other IS-IS Considerations: Changed by the addition of 1808 Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.2 items 2, 3, 4, 1809 and 5 respectively. 1811 Section 9, Updates to [RFC7177] (Adjacency): Changes and additions to 1812 [RFC7177] to support E-L1FS. See Appendix C.2, item 2. 1814 Section 11, IANA Considerations: changed by the addition of material 1815 in Section 11.2. See Appendix C.2, item 7. 1817 Section 12, Security Considerations: minor changes in the RFCs 1818 listed. 1820 D.2 Additions 1822 The following material was added to [RFC7180] in producing this 1823 document: 1825 1. Addition of support for an alternative Reverse Path Forwarding 1826 Check (RPFC) along with considerations for deciding between the 1827 original [RFC6325] RPFC and this alternative RPFC. This 1828 alternative RPFC was originally discussed on the TRILL WG mailing 1829 list in http://www.ietf.org/mail- 1830 archive/web/trill/current/msg01852.html and subsequent messages. 1831 (Section 3.6) 1833 2. Addition of mandatory E-L1FS [RFC7356] support (Section 8.1, 1834 Section 9). 1836 3. Recommendations concerning control packet priorities. (Section 1837 8.2) 1839 4. Implementation requirements concerning unknown IS-IS PDU types 1840 (Section 8.3). 1842 5. Specification of an optional Nickname Flags APPsub-TLV and an 1843 ingress flag within that APPsub-TLV. (Section 8.4) 1845 6. Update TRILL Header to allocate a Color bit (Section 10.1) and 1846 update the optional TRILL Header Extension Flag Word to allocate a 1847 two-bit Extended Color field (Section 10.2). 1849 7. Some new IANA Considerations in Section 11.2. 1851 8. Informative Appendix A and C on the Lifecycle of a TRILL Port and 1852 the Appointed Forwarder Status Lost Counter, respectively. 1854 9. Appendix B with example TRILL PDUs. 1856 D.3 Deletions 1858 The following material was deleted from [RFC7180] in producing this 1859 document: 1861 1. Removal of all updates to [RFC6327] that occurred in [RFC7180]. 1862 These have been rolled into [RFC7177] that obsoletes [RFC6327]. 1863 However, new updates to [RFC7177] are included (see Item 1 in 1864 Section A.1). 1866 2. Removal of all updates to [RFC6439]. These have been rolled into 1867 [rfc6439bis] that will obsolete [RFC6439]. 1869 Appendix Z: Change History 1871 This appendix lists version changes in this document. 1873 Authors' Addresses 1875 Donald Eastlake 3rd 1876 Huawei Technology 1877 155 Beaver Street 1878 Milford, MA 01757 USA 1880 Phone: +1-508-333-2270 1881 EMail: d3e3e3@gmail.com 1883 Mingui Zhang 1884 Huawei Technologies 1885 No. 156 Beiqing Rd. Haidian District, 1886 Beijing 100095 1887 P.R. China 1889 EMail: zhangmingui@huawei.com 1891 Radia Perlman 1892 EMC 1893 2010 256th Avenue NE, #200 1894 Bellevue, WA 98007 USA 1896 Email: radia@alum.mit.edu 1898 Ayan Banerjee 1899 Cisco 1901 EMail: ayabaner@cisco.com 1903 Anoop Ghanwani 1904 Dell 1905 5450 Great America Parkway 1906 Santa Clara, CA 95054 USA 1908 EMail: anoop@alumni.duke.edu 1910 Sujay Gupta 1911 IP Infusion, 1912 RMZ Centennial 1913 Mahadevapura Post 1914 Bangalore - 560048 India 1916 EMail: sujay.gupta@ipinfusion.com 1918 Copyright and IPR Provisions 1920 Copyright (c) 2014 IETF Trust and the persons identified as the 1921 document authors. All rights reserved. 1923 This document is subject to BCP 78 and the IETF Trust's Legal 1924 Provisions Relating to IETF Documents 1925 (http://trustee.ietf.org/license-info) in effect on the date of 1926 publication of this document. Please review these documents 1927 carefully, as they describe your rights and restrictions with respect 1928 to this document. Code Components extracted from this document must 1929 include Simplified BSD License text as described in Section 4.e of 1930 the Trust Legal Provisions and are provided without warranty as 1931 described in the Simplified BSD License.