idnits 2.17.1 draft-ietf-trill-rfc7180bis-07.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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 2, 2015) is 3097 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 (==), 14 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 1, 2016 November 2, 2015 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 and deployment of 21 TRILL has revealed errata in RFC 6325 and areas that could use 22 clarifications or updates. RFCs 7177, 7357, and draft-eastlake-trill- 23 rfc6439bis provide clarifications and updates with respect to 24 Adjacency, the TRILL ESADI (End Station Address Distribution 25 Information) protocol, and Appointed Forwarders respectively. This 26 document provides other known clarifications, corrections, and 27 updates. It obsoletes RFC 7180 (the previous TRILL clarifications, 28 corrections, and updates RFC), updates RFC 7177, updates RFC 7179, 29 and updates RFC 6325. 31 Status of This Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Distribution of this document is unlimited. Comments should be sent 37 to the TRILL working group mailing list: . 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 50 Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Table of Contents 55 1. Introduction (Changed)..................................5 56 1.1 Precedence (Changed)...................................5 57 1.2 Changes That Are Not Backward Compatible (Unchanged)...6 58 1.3 Terminology and Acronyms (Changed).....................6 60 2. Overloaded and/or Unreachable RBridges (Unchanged)......8 61 2.1 Reachability...........................................8 62 2.2 Distribution Trees.....................................9 63 2.3 Overloaded Receipt of TRILL Data Packets...............9 64 2.3.1 Known Unicast Receipt...............................10 65 2.3.2 Multi-Destination Receipt...........................10 66 2.4 Overloaded Origination of TRILL Data Packets..........10 67 2.4.1 Known Unicast Origination...........................10 68 2.4.2 Multi-Destination Origination.......................11 69 2.4.2.1 An Example Network................................11 70 2.4.2.2 Indicating OOMF Support...........................12 71 2.4.2.3 Using OOMF Service................................12 73 3. Distribution Trees and RPF Check (Changed).............14 74 3.1 Number of Distribution Trees (Unchanged)..............14 75 3.2 Distribution Tree Update Clarification (Unchanged)....14 76 3.3 Multicast Pruning Based on IP Address (Unchanged).....14 77 3.4 Numbering of Distribution Trees (Unchanged)...........15 78 3.5 Link Cost Directionality (Unchanged)..................15 79 3.6 Alternative RPF Check (New)...........................15 80 3.6.1 Example of the Potential Problem....................16 81 3.6.2 Solution and Discussion.............................17 83 4. Nicknames Selection (Unchanged)........................19 85 5. MTU (Maximum Transmission Unit) (Unchanged)............21 86 5.1 MTU-Related Errata in RFC 6325........................21 87 5.1.1 MTU PDU Addressing..................................21 88 5.1.2 MTU PDU Processing..................................22 89 5.1.3 MTU Testing.........................................22 90 5.2 Ethernet MTU Values...................................22 92 6. TRILL Port Modes (Unchanged)...........................24 93 7. The CFI/DEI Bit (Unchanged)............................25 95 8. Other IS-IS Considerations (Changed)...................26 96 8.1 E-L1FS Support (New)..................................26 97 8.1.1 Backward Compatibility..............................26 98 8.1.2 E-L1FS Use for Existing (sub)TLVs...................27 99 8.2 Control Packet Priorities (New).......................28 100 8.3 Unknown PDUs (New)....................................29 101 8.4 Nickname Flags APPsub-TLV (New).......................29 102 8.5 Graceful Restart (Unchanged)..........................31 103 8.6 Purge Originator Identification (New).................31 105 Table of Contents (continued) 107 9. Updates to [RFC7177] (Adjacency) (Changed).............32 109 10. TRILL Header Update (New).............................33 110 10.1 Color Bit............................................34 111 10.2 Flag Word Changes (update to [RFC7179])..............34 112 10.2.1 Extended Hop Count.................................34 113 10.2.1.1 Advertising Support..............................34 114 10.2.1.2 Ingress Behavior.................................35 115 10.2.1.3 Transit Behavior.................................35 116 10.2.1.4 Egress Behavior..................................36 117 10.2.2 Extended Color Field...............................36 118 10.3 Updated Flag Word Summary............................36 120 11. Appointed Forwarder Status Lost Counter (New).........38 122 12. IANA Considerations (Changed).........................39 123 12.1 Previously Completed IANA Actions (Unchanged)........39 124 12.2 New IANA Actions (New)...............................39 125 12.2.1 Reference Updated..................................39 126 12.2.2 The 'E' Capability Bit.............................40 127 12.2.3 NickFlags APPsub-TLV Number and Registry...........40 128 12.2.4 Updated TRILL Extended Header Flags................40 129 12.2.5 TRILL-VER Sub-TLV Capability Flags.................41 130 12.2.6 Example Nicknames..................................41 132 13. Security Considerations (Changed).....................42 134 Normative References......................................43 135 Informative References....................................44 136 Acknowledgements..........................................46 138 Appendix A: Life Cycle of a TRILL Switch Port (New).......47 140 Appendix B: Example TRILL PDUs (New)......................50 141 B.1 LAN Hello over Ethernet...............................50 142 B.2 LSP Over PPP..........................................51 143 B.3 TRILL Data Over Ethernet..............................52 144 B.4 TRILL Data Over PPP...................................53 146 Appendix C: Changes to Previous RFCs (New)................55 147 C.1 Changes to Obsoleted [RFC7180]........................55 148 C.1.1 Changes.............................................55 149 C.1.2 Additions...........................................55 150 C.1.3 Deletions...........................................56 151 C.2 Changes to [RFC6325]..................................57 152 C.3 Changes to [RFC7177]..................................57 153 C.4 Changes to [RFC7179]..................................57 155 Appendix Z: Change History................................58 157 1. Introduction (Changed) 159 Since the TRILL base protocol [RFC6325] was published in 2011, active 160 development and deployment of TRILL has revealed errors in the 161 specification [RFC6325] and several areas that could use 162 clarifications or updates. 164 [RFC7177], [RFC7357], and [rfc6439bis] provide clarifications and 165 updates with respect to Adjacency, the TRILL ESADI (End Station 166 Address Distribution Information) protocol, and Appointed Forwarders 167 respectively. This document provides other known clarifications, 168 corrections, and updates to [RFC6325], [RFC7177], and [RFC7179]. This 169 document obsoletes [RFC7180], the previous TRILL clarifications, 170 corrections, and updates document, updates [RFC6325], updates 171 [RFC7177] as described in Section 9, and updates [rfc7179] as 172 described in Section 10.2 and 10.3. The charges to these RFCs are 173 summarized in Appendix C. 175 Sections of this document are annotated as to whether they are "New" 176 technical material, material that has been technically "Changed", or 177 material that is technically "Unchanged", by the appearance of one of 178 these three words in parenthesis at the end of the section header. A 179 section with only editorial changes is annotated as "(Unchanged)". If 180 no such notation appears, then the first notation encountered on 181 going to successively higher-level headers (those with shorter 182 numbers) applies. Appendix C describes changes, summarizes material 183 added, and lists material deleted. 185 1.1 Precedence (Changed) 187 In case of conflict between this document and [RFC6325], [RFC7177], 188 or [RFC7179] this document takes precedence. 190 In addition, Section 1.2 (Normative Content and Precedence) of 191 [RFC6325] is updated to provide a more complete precedence ordering 192 of the sections of [RFC6325] as show below, where sections to the 193 left take precedence over sections to their right. There are no known 194 conflicts between these sections but Sections 1 and 2 are less 195 detailed and do not mention every corner case while later sections of 196 [RFC6325] are more detailed. This precedence is specified as a fall 197 back in case some conflict is found in the future. 199 4 > 3 > 7 > 5 > 2 > 6 > 1 201 1.2 Changes That Are Not Backward Compatible (Unchanged) 203 The change made by Section 3.4 below, which was also present in 204 [RFC7180], is not backward compatible with [RFC6325] but has 205 nevertheless been adopted to reduce distribution tree changes 206 resulting from topology changes. 208 The several other changes herein that are fixes to errata for 209 [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] 210 [Err3508] -- may not be backward compatible with previous 211 implementations that conformed to errors in the specification. 213 1.3 Terminology and Acronyms (Changed) 215 This document uses the acronyms defined in [RFC6325], some of which 216 are repeated below for convenience, along with some additional 217 acronyms and terms as follows: 219 Campus - a TRILL network consisting of TRILL switches, links, and 220 possibly bridges bounded by end stations and IP routers. For 221 TRILL, there is no "academic" implication in the name "campus". 223 CFI - Canonical Format Indicator [802]. 225 DEI - Drop Eligibility Indicator [802.1Q-2014]. 227 FGL - Fine Grained Labeling [RFC7172] 229 OOMF - Overload Originated Multi-destination Frame. 231 PDU - Protocol Data Unit. 233 RBridge - Routing Bridge, an alternative name for a TRILL Switch. 235 RPFC - Reverse Path Forwarding Check. 237 SNPA - SubNetwork Point of Attachment (for example, MAC address). 239 TRILL - Transparent Interconnection of Lots of Links or Tunneled 240 Routing in the Link Layer. 242 TRILL Switch - A device implementing the TRILL protocol. An 243 alternative name for an RBridge. 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 247 "OPTIONAL" in this document are to be interpreted as described in 248 [RFC2119]. 250 In this document a "packet" usually refers to a TRILL Data packet or 251 TRILL IS-IS packet received from or sent to a TRILL switch while a 252 "frame" usually refers to a native frame being received from or sent 253 to an end station. (The word frame also occurs in other contexts such 254 as the "Frame Check Sequence" that is at the end of Ethernet 255 transmissions.) 257 2. Overloaded and/or Unreachable RBridges (Unchanged) 259 In this Section 2, the term "neighbor" refers only to actual RBridges 260 and ignores pseudonodes. 262 RBridges may be in overload as indicated by the [IS-IS] overload flag 263 in their LSPs (Link State PDUs). This means that either (1) they are 264 incapable of holding the entire link-state database and thus do not 265 have a view of the entire topology or (2) they have been configured 266 to have the overload bit set. Although networks should be engineered 267 to avoid actual link-state overload, it might occur under various 268 circumstances. For example, if a very large campus included one or 269 more low-end TRILL Switches. 271 It is a common operational practice to set the overload bit in an 272 [IS-IS] router (such as a TRILL Switch) when performing maintenance 273 on that router that might affect its ability to correctly forward 274 packets; this will usually leave the router reachable for maintenance 275 traffic, but transit traffic will not be routed through it. (Also, 276 in some cases, TRILL provides for setting the overload bit in the 277 pseudonode of a link to stop TRILL Data traffic on an access link 278 (see Section 4.9.1 of [RFC6325]).) 280 [IS-IS] and TRILL make a reasonable effort to do what they can even 281 if some TRILL Switches/routers are in overload. They can do 282 reasonably well if a few scattered nodes are in overload. However, 283 actual least-cost paths are no longer assured if any TRILL Switches 284 are in overload. 286 For the effect of overload on the appointment of forwarders, see 287 [rfc6439bis]. 289 2.1 Reachability 291 Packets are not least-cost routed through an overloaded TRILL Switch, 292 although they may originate or terminate at an overloaded TRILL 293 Switch. In addition, packets will not be least-cost routed over 294 links with cost 2**24 - 1 [RFC5305]; such links are reserved for 295 traffic- engineered packets, the handling of which is beyond the 296 scope of this document. 298 As a result, a portion of the campus may be unreachable for least- 299 cost routed TRILL Data because all paths to it would be through 300 either a link with cost 2**24 - 1 or through an overloaded RBridge. 301 For example, an RBridge (TRILL Switch) RB1 is not reachable by TRILL 302 Data if all of its neighbors are connected to RB1 by links with cost 303 2**24 - 1. Such RBridges are called "data unreachable". 305 The link-state database at an RBridge, for example RB1, can also 306 contain information on TRILL Switches that are unreachable by IS-IS 307 link-state flooding due to link or RBridge failures. When such 308 failures partition the campus, the TRILL Switches adjacent to the 309 failure and on the same side of the failure as RB1 will update their 310 LSPs to show the lack of connectivity, and RB1 will receive those 311 updates. As a result, RB1 will be aware of the partition. Nodes on 312 the far side of the partition are both IS-IS unreachable and data 313 unreachable from RB1. However, LSPs held by RB1 for TRILL Switches 314 on the far side of the failure will not be updated and may stay 315 around until they time out, which could be tens of minutes or longer. 316 (The default in [IS-IS] is twenty minutes.) 318 2.2 Distribution Trees 320 An RBridge in overload cannot be trusted to correctly calculate 321 distribution trees or correctly perform the RPFC (Reverse-Path 322 Forwarding Check). Therefore, it cannot be trusted to forward multi- 323 destination TRILL Data packets. It can only appear as a leaf node in 324 a TRILL multi-destination distribution tree. Furthermore, if all the 325 immediate neighbors of an RBridge are overloaded, then it is omitted 326 from all trees in the campus and is unreachable by multi-destination 327 packets. 329 When an RBridge determines what nicknames to use as the roots of the 330 distribution trees it calculates, it MUST ignore all nicknames held 331 by TRILL Switches that are in overload or are data unreachable. When 332 calculating RPFCs for multi-destination packets, an RBridge, such as 333 RB1 MAY, to avoid calculating unnecessary RPFC state information, 334 ignore any trees that cannot reach to RB1 even if other RBridges list 335 those trees as trees that other TRILL Switches might use. (But see 336 Section 3.) 338 2.3 Overloaded Receipt of TRILL Data Packets 340 The receipt of TRILL Data packets by overloaded RBridge RB2 is 341 discussed in the subsections below. In all cases, the normal Hop 342 Count decrement is performed, and the TRILL Data packets are 343 discarded if the result is less than one or if the egress nickname is 344 illegal. 346 2.3.1 Known Unicast Receipt 348 RB2 will not usually receive unicast TRILL Data packets unless it is 349 the egress, in which case it egresses and delivers the data normally. 350 If RB2 receives a unicast TRILL Data packet for which it is not the 351 egress, perhaps because a neighbor does not yet know it is in 352 overload, RB2 MUST NOT discard the packet because the egress is an 353 unknown nickname as it might not know about all nicknames due to its 354 overloaded condition. If any neighbor, other than the neighbor from 355 which it received the packet, is not overloaded, it MUST attempt to 356 forward the packet to one of those neighbors selected at random 357 [RFC4086]. If there is no such neighbor, the packet is discarded. 359 2.3.2 Multi-Destination Receipt 361 If RB2 in overload receives a multi-destination TRILL Data packet, 362 RB2 MUST NOT apply an RPFC since, due to overload, it might not do so 363 correctly. RB2 egresses and delivers the frame locally where it is 364 Appointed Forwarder for the frame's VLAN (or, if the packet is FGL, 365 for the VLAN that FGL maps to at the port), subject to any multicast 366 pruning. But since, as stated above, RB2 can only be the leaf of a 367 distribution tree, it MUST NOT forward a multi-destination TRILL Data 368 packet (except as an egressed native frame where RB2 is Appointed 369 Forwarder). 371 2.4 Overloaded Origination of TRILL Data Packets 373 Overloaded origination of unicast TRILL Data packets with known 374 egress and of multi-destination packets is discussed in the 375 subsections below. 377 2.4.1 Known Unicast Origination 379 When RB2, an overloaded RBridge, ingresses or creates a known 380 destination unicast data packet, it delivers it locally if the 381 destination is local. Otherwise, RB2 unicasts it to any neighbor 382 TRILL Switch that is not overloaded. It MAY use what routing 383 information it has to help select the neighbor. 385 2.4.2 Multi-Destination Origination 387 Overloaded RBridge RB2 ingressing or creating a multi-destination 388 data packet is more complex than for the known unicast case as 389 discussed below. 391 2.4.2.1 An Example Network 393 For example, consider the network below in which, for simplicity, end 394 stations and any bridges are not shown. There is one distribution 395 tree of which RB4 is the root, as represented by double lines. Only 396 RBridge RB2 is overloaded. 398 +-----+ +-----+ +-----+ +-----+ 399 | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 | 400 +-----+ +--+--+ +-++--+ +--+--| 401 | || | 402 +---+---+ || | 403 +------+RB2(ov)|======++ | 404 | +-------+ || | 405 | || | 406 +--+--+ +-----+ ++==++=++ +--+--+ 407 | RB8 +====+ RB6 +===++ RB4 ++=====+ RB9 | 408 +-----+ +-----+ ++=====++ +-----+ 410 Since RB2 is overloaded, it does not know what the distribution tree 411 or trees are for the network. Thus, there is no way it can provide 412 normal TRILL Data service for multi-destination native frames. So 413 RB2 tunnels the frame in a TRILL Data packet to a neighbor that is 414 not overloaded if it has such a neighbor that has signaled that it is 415 willing to offer this service. RBridges indicate this in their 416 Hellos as described below. This service is called OOMF (Overload 417 Originated Multi- destination Frame) service. 419 - The multi-destination frame MUST NOT be locally distributed in 420 native form at RB2 because this would cause the frame to be 421 delivered twice. Instead it is tunneling to a neighbor as provided 422 in this section. For example, if RB2 locally distributed a 423 multicast native frame and then tunneled it to RB5, RB2 would get 424 a copy of the frame when RB3 transmitted it as a TRILL Data packet 425 on the multi-access RB2-RB3-RB4 link. Since RB2 would, in 426 general, not be able to tell that this was a frame it had tunneled 427 for distribution, RB2 would decapsulate it and locally distribute 428 it a second time. 430 - On the other hand, if there is no neighbor of RB2 offering RB2 the 431 OOMF service, RB2 cannot tunnel the frame to a neighbor. In this 432 case, RB2 MUST locally distribute the frame where it is Appointed 433 Forwarder for the frame's VLAN and optionally subject to multicast 434 pruning. 436 2.4.2.2 Indicating OOMF Support 438 An RBridge RB3 indicates its willingness to offer the OOMF service to 439 RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit 440 associated with the SNPA (SubNetwork Point of Attachment, also known 441 as MAC address) of RB2 on the link (see IANA Considerations). 442 Overloaded RBridge RB2 can only distribute multi-destination TRILL 443 Data packets to the campus if a neighbor of RB2 not in overload 444 offers RB2 the OOMF service. If RB2 does not have OOMF service 445 available to it, RB2 can still receive multi-destination packets from 446 non-overloaded neighbors and, if RB2 should originate or ingress such 447 a frame, it distributes it locally in native form. 449 2.4.2.3 Using OOMF Service 451 If RB2 sees this OOMF (Overload Originated Multi-destination Frame) 452 service advertised for it by any of its neighbors on any link to 453 which RB2 connects, it selects one such neighbor by a means beyond 454 the scope of this document. Assuming RB2 selects RB3 to handle 455 multi-destination packets it originates, RB2 MUST advertise in its 456 LSP that it might use any of the distribution trees that RB3 457 advertises so that the RPFC will work in the rest of the campus. 458 Thus, notwithstanding its overloaded state, RB2 MUST retain this 459 information from RB3 LSPs, which it will receive as it is directly 460 connected to RB3. 462 RB2 then encapsulates such frames as TRILL Data packets to RB3 as 463 follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held 464 by RB2, and, since RB2 cannot tell what distribution tree RB3 will 465 use, egress nickname = a special nickname indicating an OOMF packet 466 (see IANA Considerations). RB2 then unicasts this TRILL Data packet 467 to RB3. (Implementation of Item 4 in Section 4 below provides 468 reasonable assurance that, notwithstanding its overloaded state, the 469 ingress nickname used by RB2 will be unique within at least the 470 portion of the campus that is IS-IS reachable from RB2.) 472 On receipt of such a packet, RB3 does the following: 474 - changes the Egress Nickname field to designate a distribution tree 475 that RB3 normally uses, 476 - sets the M bit to one, 477 - changes the Hop Count to the value it would normally use if it 478 were the ingress, and 480 - forwards the TRILL Data packet on that tree. 482 RB3 MAY rate limit the number of packets for which it is providing 483 this service by discarding some such packets from RB2. The provision 484 of even limited bandwidth for OOMFs by RB3, perhaps via the slow 485 path, may be important to the bootstrapping of services at RB2 or at 486 end stations connected to RB2, such as supporting DHCP and ARP/ND 487 (Address Resolution Protocol / Neighbor Discovery). (Everyone 488 sometimes needs a little OOMF (pronounced "oomph") to get off the 489 ground.) 491 3. Distribution Trees and RPF Check (Changed) 493 Two corrections, a clarification, and two updates related to 494 distribution trees appear in the subsections below along with an 495 alternative, stronger RPF (Reverse Path Forwarding) Check. See also 496 Section 2.2. 498 3.1 Number of Distribution Trees (Unchanged) 500 In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the 501 parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. 502 It should read "(up to k if j is zero or the minimum of (j, k) if j 503 is non-zero)". 505 3.2 Distribution Tree Update Clarification (Unchanged) 507 When a link-state database change causes a change in the distribution 508 tree(s), there are several possibilities. If a tree root remains a 509 tree root but the tree changes, then local forwarding and RPFC 510 entries for that tree should be updated as soon as practical. 511 Similarly, if a new nickname becomes a tree root, forwarding and RPFC 512 entries for the new tree should be installed as soon as practical. 513 However, if a nickname ceases to be a tree root and there is 514 sufficient room in local tables, the forwarding and RPFC entries for 515 the former tree MAY be retained so that any multi-destination TRILL 516 Data packets already in flight on that tree have a higher probability 517 of being delivered. 519 3.3 Multicast Pruning Based on IP Address (Unchanged) 521 The TRILL base protocol specification [RFC6325] provides for and 522 recommends the pruning of multi-destination packet distribution trees 523 based on the location of IP multicast routers and listeners; however, 524 multicast listening is identified by derived MAC addresses as 525 communicated in the Group MAC Address sub-TLV [RFC7176]. 527 TRILL Switches MAY communicate multicast listeners and prune 528 distribution trees based on the actual IPv4 or IPv6 multicast 529 addresses involved. Additional Group Address sub-TLVs are provided 530 in [RFC7176] to carry this information. A TRILL Switch that is only 531 capable of pruning based on derived MAC address SHOULD calculate and 532 use such derived MAC addresses from the multicast listener IPv4/IPv6 533 address information it receives. 535 3.4 Numbering of Distribution Trees (Unchanged) 537 Section 4.5.1 of [RFC6325] specifies that, when building distribution 538 tree number j, node (RBridge) N that has multiple possible parents in 539 the tree is attached to possible parent number j mod p. Trees are 540 numbered starting with 1, but possible parents are numbered starting 541 with 0. As a result, if there are two trees and two possible 542 parents, in tree 1, parent 1 will be selected, and in tree 2, parent 543 0 will be selected. 545 This is changed so that the selected parent MUST be (j-1) mod p. As 546 a result, in the case above, tree 1 will select parent 0, and tree 2 547 will select parent 1. This change is not backward compatible with 548 [RFC6325]. If all RBridges in a campus do not determine distribution 549 trees in the same way, then for most topologies, the RPFC will drop 550 many multi-destination packets before they have been properly 551 delivered. 553 3.5 Link Cost Directionality (Unchanged) 555 Distribution tree construction, like other least-cost aspects of 556 TRILL, works even if link costs are asymmetric, so the cost of the 557 hop from RB1 to RB2 is different from the cost of the hop from RB2 to 558 RB1. However, it is essential that all RBridges calculate the same 559 distribution trees, and thus, all must either use the cost away from 560 the tree root or the cost towards the tree root. As corrected in 561 [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It 562 says: 564 In other words, the set of potential parents for N, for the tree 565 rooted at R, consists of those that give equally minimal cost 566 paths from N to R and ... 568 but the text should say "from R to N": 570 In other words, the set of potential parents for N, for the tree 571 rooted at R, consists of those that give equally minimal cost 572 paths from R to N and ... 574 3.6 Alternative RPF Check (New) 576 [RFC6325] mandates a Reverse Path Forwarding (RPF) Check on multi- 577 destination TRILL Data packets to avoid possible multiplication 578 and/or looping of multi-destination traffic during TRILL campus 579 topology transients. This check is logically performed at each TRILL 580 switch input port and determines whether it is arriving on the 581 expected port based on where the packet started (the ingress 582 nickname) and the tree on which it is being distributed. If not, the 583 packet is silently discarded. This check is fine for point-to-point 584 links; however, there are rare circumstances involving multi-access 585 ("broadcast") links where a packet can be duplicated despite this RPF 586 Check and other checks performed by TRILL. 588 Section 3.6.1 gives an example of the potential problem and Section 589 3.6.2 specifies a solution. This solution is an alternative, stronger 590 RPF Check that TRILL Switches can be implemented in place of the RFF 591 Check in [RFC6325]. 593 3.6.1 Example of the Potential Problem 595 Consider this network: 597 F--A--B--C--o--D 598 | 599 E 601 All the links except the link between C, D, and E are point-to-point 602 links. C, D, and E are connected over a broadcast link represented 603 by the pseudonode "o". For example, they could be connected by a 604 bridged LAN. (Bridged LANs are transparent to TRILL.) 606 Although the choice of root is unimportant here, assume that D or F 607 is chosen as the root of a distribution tree so it is obvious the 608 tree looks just like the diagram above. 610 Now assume a link comes up from A to the same bridged LAN. The 611 network then looks like this: 613 +--------+ 614 | | 615 F--A--B--C--o--D 616 | 617 E 619 Let's say the resulting tree in steady state includes all links 620 except the B-C link. After the network has converged, a packet that 621 starts from F will go F->A. Then A will send one copy on the A-B link 622 and another copy into the bridge LAN from which it will be received 623 by C and D. 625 Now consider a transition stage where A and D have acted on the new 626 LSPs and programmed their forwarding plane, while B and C have not 627 yet done so. This means that B and C both consider the link between 628 them to still be part of the tree. In this case, a packet that starts 629 out from F and reaches A will be copied by A into the A-B link and to 630 the bridge LAN. D's RPF check says to accept packets on this tree 631 coming from F over its port on the bridged LAN, so it gets accepted. 632 D is also adjacent to A on the tree, so the tree adjacency check, a 633 separate check mandated by [RFC6325] also passes. 635 However, the packet that gets to B gets sent out by B to C. C's RPF 636 check still has the old state, and it thinks the packet is OK. C 637 sends the packet along the old tree, which is into the bridge LAN. D 638 receives one more packet, but the tree adjacency check passes at D 639 because C is adjacent to D in the new tree as well. The RPF Check 640 also passes at D because D's port on the bridged LAN is OK for 641 receiving packets from F. 643 So, during this transient state, D gets duplicates of every multi- 644 destination packet ingressed at F (unless the packet gets pruned) 645 until B and C act on the new LSPs and program their forwarding 646 tables. 648 3.6.2 Solution and Discussion 650 The problem stems from the RPF Check in [RFC6325] depending only on 651 the port at which a TRILL Data packet is received, the ingress 652 nickname, and the tree being used, that is, a check if {ingress 653 nickname, tree, input port} is a valid combination according to the 654 receiving TRILL switch's view of the campus topology. A multi-access 655 link actually has multiple adjacencies overlaid on one physical link 656 and to avoid the problem shown in Section 3.6.1, a stronger check is 657 needed that includes the Layer 2 source address of the TRILL Data 658 packet being received. (TRILL is a Layer 3 protocol and TRILL 659 switches are true routers that logically strip the Layer 2 header 660 from any arriving TRILL Data packets and add the appropriate new 661 Layer 2 header to any outgoing TRILL Data packet to get it to the 662 next TRILL switch, so the Layer 2 source address in a TRILL Data 663 packet identifies the immediately previous TRILL Switch that 664 forwarded the packet.) 666 What is needed, instead of checking the validity of the triplet 667 {ingress nickname, tree, input port} is to check that the quadruplet 668 {ingress nickname, source SNPA, tree, input port} is valid (where 669 "source SNPA" (Sub-Network Point of Access) is the Outer.MacSA for an 670 Ethernet link). Although it is true that [RFC6325] also requires a 671 check that a multi-destination TRILL Data packet is from a TRILL 672 switch that is adjacent in the distribution tree being used, this is 673 a separate check from the RPF Check and these two independent checks 674 are not as powerful as the single unified check for a valid 675 quadruplet. 677 _______ 678 / \ 679 RB1 ------ o ----- RB2 680 \_______/ 682 However, this stronger RPF Check is not without cost. In the simple 683 case of a multi-access link where each TRILL switch has only one port 684 on the link, it merely increases the size of validity entries by 685 adding the source SNPA (Outer.MacSA). However, assume some TRILL 686 Switch RB1 has multiple ports attached to a multi-access link. In the 687 figure above, RB1 is show with three ports on the multi-access link. 688 RB1 is permitted to load split multi-destination traffic it is 689 sending into the multi-access link across those ports (Section 4.4.4 690 [RFC6325]). Assume RB2 is another TRILL Switch on the link and RB2 691 is distribution tree adjacent to RB1. The number of validity 692 quadruplets at RB2 for ingress nicknames whose multi-destination 693 traffic would arrive through RB1 is multiplied by the number of ports 694 RB1 has on the access-link because RB2 has to accept such traffic 695 from any of such ports. Although such instances seem to be very rare 696 in practice, the number of ports an RBridge has on a link could in 697 principle be tens or even a hundred or more ports, vastly increasing 698 the RPF check state at RB2 when this stronger RPF check is used. 700 Another potential cost of the stronger RPF Check is increased 701 transient loss of multi-destination TRILL Data packets during a 702 topology change. For TRILL switch D, the new stronger RPF Check is 703 (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1) while the old 704 one was ( tree->A, Outer.MacSA=C, ingress=A, arrival port=if1). 705 Suppose both A and B have switched to the new tree for multicast 706 forwarding while D has not updated its RPF Check yet, then the 707 multicast packet will be dropped at D's input port since D still 708 expects packet from "Outer.MacSA=C". But we do not have this packet 709 loss issue if the weaker triplet check (tree->A, ingress=A, arrival 710 port=if1) is used. Thus, the stronger check can increase the RPF 711 Check discard of multi-destination packets during topology 712 transients. 714 Because of these potential costs, implementation of this stronger RPF 715 Check is optional. The TRILL base protocol is updated to provide that 716 TRILL Switches MUST, for multi-destination packets, either implement 717 the RPF and other checks in [RFC6325] or implement this stronger RPF 718 Check as a substitute for the [RFC6325] RPF and tree adjacency 719 checks. There is no problem with a campus having a mixture of TRILL 720 switches some of which implement one of these RPF checks and some of 721 which implement the other. 723 4. Nicknames Selection (Unchanged) 725 Nickname selection is covered by Section 3.7.3 of [RFC6325]. 726 However, the following should be noted: 728 1. The second sentence in the second bullet item in Section 3.7.3 of 729 [RFC6325] on page 25 is erroneous [Err3002] and is corrected as 730 follows: 732 o The occurrence of "IS-IS ID (LAN ID)" is replaced with 733 "priority". 735 o The occurrence of "IS-IS System ID" is replaced with "seven- 736 byte IS-IS ID (LAN ID)". 738 The resulting corrected sentence in [RFC6325] reads as follows: 740 "If RB1 chooses nickname x, and RB1 discovers, through receipt 741 of an LSP for RB2 at any later time, that RB2 has also chosen 742 x, then the RBridge or pseudonode with the numerically higher 743 priority keeps the nickname, or if there is a tie in priority, 744 the RBridge with the numerically higher seven-byte IS-IS ID 745 (LAN ID) keeps the nickname, and the other RBridge MUST select 746 a new nickname." 748 2. In examining the link-state database for nickname conflicts, 749 nicknames held by IS-IS unreachable TRILL Switches MUST be 750 ignored, but nicknames held by IS-IS reachable TRILL Switches MUST 751 NOT be ignored even if they are data unreachable. 753 3. An RBridge may need to select a new nickname, either initially 754 because it has none or because of a conflict. When doing so, the 755 RBridge MUST consider as available all nicknames that do not 756 appear in its link-state database or that appear to be held by IS- 757 IS unreachable TRILL Switches; however, it SHOULD give preference 758 to selecting new nicknames that do not appear to be held by any 759 TRILL Switch in the campus, reachable or unreachable, so as to 760 minimize conflicts if IS-IS unreachable TRILL Switches later 761 become reachable. 763 4. An RBridge, even after it has acquired a nickname for which there 764 appears to be no conflicting claimant, MUST continue to monitor 765 for conflicts with the nickname or nicknames it holds. It does so 766 by checking in LSP PDUs it receives that should update its link- 767 state database for the following: any occurrence of any of its 768 nicknames held with higher priority by some other TRILL Switch 769 that is IS-IS reachable from it. If it finds such a conflict, it 770 MUST select a new nickname, even when in overloaded state. (It is 771 possible to receive an LSP that should update the link-state 772 database but does not do so due to overload.) 774 5. In the very unlikely case that an RBridge is unable to obtain a 775 nickname because all valid RBridge nicknames (0x0001 through 776 0xFFBF inclusive) are in use with higher priority by IS-IS 777 reachable TRILL Switches, it will be unable to act as an ingress, 778 egress, or tree root but will still be able to function as a 779 transit TRILL Switch. Although it cannot be a tree root, such an 780 RBridge is included in distribution trees computed for the campus 781 unless all its neighbors are overloaded. It would not be possible 782 to send a unicast RBridge Channel message specifically to such a 783 TRILL Switch [RFC7178]; however, it will receive unicast RBridge 784 Channel messages sent by a neighbor to the Any-RBridge egress 785 nickname and will receive appropriate multi-destination RBridge 786 Channel messages. 788 5. MTU (Maximum Transmission Unit) (Unchanged) 790 MTU values in TRILL key off the originatingL1LSPBufferSize value 791 communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The 792 campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is 793 the minimum value of originatingL1LSPBufferSize for the RBridges in a 794 campus, but not less than 1470. The MTU testing mechanism and 795 limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and 796 thus that IS-IS can operate properly. 798 If an RBridge knows nothing about the MTU of the links or the 799 originatingL1LSPBufferSize of other RBridges in a campus, the 800 originatingL1LSPBufferSize for that RBridge should default to the 801 minimum of the LSP size that its TRILL IS-IS software can handle and 802 the minimum MTU of the ports that it might use to receive or transmit 803 LSPs. If an RBridge does have knowledge of link MTUs or other 804 RBridge originatingL1LSPBufferSize, then, to avoid the necessity to 805 regenerate the local LSPs using a different maximum size, the 806 RBridge's originatingL1LSPBufferSize SHOULD be configured to the 807 minimum of (1) the smallest value that other RBridges are or will be 808 announcing as their originatingL1LSPBufferSize and (2) a value small 809 enough that the campus will not partition due to a significant number 810 of links with limited MTU. However, as provided in [RFC6325], in no 811 case can originatingL1LSPBufferSize be less than 1470. In a well- 812 configured campus, to minimize any LSP regeneration due to re-sizing, 813 all RBridges will be configured with the same 814 originatingL1LSPBufferSize. 816 Section 5.1 below corrects errata in [RFC6325], and Section 5.2 817 clarifies the meaning of various MTU limits for TRILL Ethernet links. 819 5.1 MTU-Related Errata in RFC 6325 821 Three MTU-related errata in [RFC6325] are corrected in the 822 subsections below. 824 5.1.1 MTU PDU Addressing 826 Section 4.3.2 of [RFC6325] incorrectly states that multi-destination 827 MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links 828 with the All-RBridges multicast address as the Outer.MacDA [Err3004]. 829 As TRILL IS-IS PDUs, when multicast on an Ethernet link, these multi- 830 destination MTU-probe and MTU-ack PDUs MUST be sent to the All-IS-IS- 831 RBridges multicast address. 833 5.1.2 MTU PDU Processing 835 As discussed in [RFC6325] and, in more detail, in [RFC7177], MTU- 836 probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of 837 [RFC6325] erroneously does not allow for this possibility [Err3003]. 838 It is corrected by replacing Item numbered "1" in Section 4.6.2 of 839 [RFC6325] with the following quoted text to which TRILL Switches MUST 840 conform: 842 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All- 843 IS-IS-RBridges or the unicast MAC address of the receiving 844 RBridge port, the frame is handled as described in Section 845 4.6.2.1" 847 The reference to "Section 4.6.2.1" in the above quoted text is to 848 that section in [RFC6325]. 850 5.1.3 MTU Testing 852 The last two sentences of Section 4.3.2 of [RFC6325] have errors 853 [Err3053]. They currently read: 855 "If X is not greater than Sz, then RB1 sets the "failed minimum 856 MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X 857 > Sz, then RB1 advertises the largest tested X for each adjacency 858 in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise 859 X as an attribute of the link to RB2 in RB1's LSP." 861 They should read: 863 "If X is not greater than or equal to Sz, then RB1 sets the 864 "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X 865 succeeds, and X >= Sz, then RB1 advertises the largest tested X 866 for each adjacency in the TRILL Hellos RB1 sends on that link, and 867 RB1 MAY advertise X as an attribute of the link to RB2 in RB1's 868 LSP." 870 5.2 Ethernet MTU Values 872 originatingL1LSPBufferSize is the maximum permitted size of LSPs 873 starting with and including the 0x83 Intradomain Routeing Protocol 874 Discriminator byte. In Layer 3 IS-IS, originatingL1LSPBufferSize 875 defaults to 1492 bytes. (This is because, in its previous life as 876 DECnet Phase V, IS-IS was encoded using the SNAP SAP (Sub-Network 877 Access Protocol Service Access Point) [RFC7042] format, which takes 8 878 bytes of overhead and 1492 + 8 = 1500, the classic Ethernet maximum. 880 When standardized by ISO/IEC [IS-IS] to use Logical Link Control 881 (LLC) encoding, this default could have been increased by a few bytes 882 but was not.) 884 In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This 885 allows 27 bytes of headroom or safety margin to accommodate legacy 886 devices with the classic Ethernet maximum MTU despite headers such as 887 an Outer.VLAN. 889 Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet 890 links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of 891 the PDU starting just after the L2-IS-IS Ethertype and ending just 892 before the Ethernet Frame Check Sequence (FCS)) does not to exceed 893 Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 894 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded by an 895 amount that depends on the size being tested (which may exceed Sz). 897 Sz does not limit TRILL Data packets. They are only limited by the 898 MTU of the devices and links that they actually pass through; 899 however, links that can accommodate IS-IS PDUs up to Sz would 900 accommodate, with a generous safety margin, TRILL Data packet 901 payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending 902 just before the FCS. 904 Most modern Ethernet equipment has ample headroom for frames with 905 extensive headers and is sometimes engineered to accommodate 9K byte 906 jumbo frames. 908 6. TRILL Port Modes (Unchanged) 910 Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports 911 but may not be completely clear on the effects of all combinations of 912 bits in terms of allowed frame types. 914 The table below explicitly indicates the effect of all possible 915 combinations of the TRILL port mode bits. "*" in one of the first 916 four columns indicates that the bit can be either zero or one. The 917 following columns indicate allowed frame types. The Disable bit 918 normally disables all frames, but, as an implementation choice, some 919 or all low-level Layer 2 control message can still be sent or 920 received. Examples of Layer 2 control messages are those control 921 frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP 922 link negotiation messages [RFC6361]. 924 +-+-+-+-+--------+-------+-------+-------+-------+ 925 |D| | | | | | | | | 926 |i| |A| | | | TRILL | | | 927 |s| |c|T| |native | Data | | | 928 |a| |c|r| |ingress| | | | 929 |b|P|e|u| | | LSP | | | 930 |l|2|s|n|Layer 2 |native | SNP | TRILL | P2P | 931 |e|P|s|k|Control |egress | MTU | Hello | Hello | 932 +-+-+-+-+--------+-------+-------+-------+-------+ 933 |0|0|0|0| Yes | Yes | Yes | Yes | No | 934 +-+-+-+-+--------+-------+-------+-------+-------+ 935 |0|0|0|1| Yes | No | Yes | Yes | No | 936 +-+-+-+-+--------+-------+-------+-------+-------+ 937 |0|0|1|0| Yes | Yes | No | Yes | No | 938 +-+-+-+-+--------+-------+-------+-------+-------+ 939 |0|0|1|1| Yes | No | No | Yes | No | 940 +-+-+-+-+--------+-------+-------+-------+-------+ 941 |0|1|0|*| Yes | No | Yes | No | Yes | 942 +-+-+-+-+--------+-------+-------+-------+-------+ 943 |0|1|1|*| Yes | No | No | No | Yes | 944 +-+-+-+-+--------+-------+-------+-------+-------+ 945 |1|*|*|*|Optional| No | No | No | No | 946 +-+-+-+-+--------+-------+-------+-------+-------+ 948 The formal name of the "access bit" above is the "TRILL traffic 949 disable bit". The formal name of the "trunk bit" is the "end-station 950 service disable bit" [RFC6325]. 952 7. The CFI/DEI Bit (Unchanged) 954 In May 2011, the IEEE promulgated IEEE Std 802.1Q-2011, which changed 955 the meaning of the bit between the priority and VLAN ID bits in the 956 payload of C-VLAN tags. Previously, this bit was called the CFI 957 (Canonical Format Indicator) bit [802] and had a special meaning in 958 connection with IEEE 802.5 (Token Ring) frames. Now, after 959 802.1Q-2011 and in subsequent versions the current of which is 960 [802.1Q-2014], it is a DEI (Drop Eligibility Indicator) bit, similar 961 to that bit in S-VLAN/B-VLAN tags where this bit has always been a 962 DEI bit. 964 The TRILL base protocol specification [RFC6325] assumed, in effect, 965 that the link by which end stations are connected to TRILL Switches 966 and the restricted virtual link provided by the TRILL Data packet are 967 IEEE 802.3 Ethernet links on which the CFI bit is always zero. 968 Should an end station be attached by some other type of link, such as 969 a Token Ring link, [RFC6325] implicitly assumed that such frames 970 would be canonicalized to 802.3 frames before being ingressed, and 971 similarly, on egress, such frames would be converted from 802.3 to 972 the appropriate frame type for the link. Thus, [RFC6325] required 973 that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in 974 Section 4.1.1 of [RFC6325], always be zero. 976 However, for TRILL Switches with ports conforming to the change 977 incorporated in the IEEE 802.1Q-2011 standard, the bit in the 978 Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by 979 the port interface on ingressing a native frame. Similarly, this bit 980 MUST be provided to the port when transiting or egressing a TRILL 981 Data packet. As with the 3-bit Priority field, the DEI bit to use in 982 forwarding a transit packet MUST be taken from the Inner.VLAN. The 983 exact effect on the Outer.VLAN DEI and priority bits and whether or 984 not an Outer.VLAN appears at all on the wire for output frames may 985 depend on output port configuration. 987 TRILL campuses with a mixture of ports, some compliant with versions 988 of 802.1Q from IEEE Std 802.1Q-2011 onward and some compliant with 989 pre-802.1Q-2011 standards, especially if they have actual Token Ring 990 links, may operate incorrectly and may corrupt data, just as a 991 bridged LAN with such mixed ports and links would. 993 8. Other IS-IS Considerations (Changed) 995 This section covers E-L1FS Support, Control Packet Priorities, 996 Unknown PDUs, the Nickname Flags APPsub-TLV, Graceful Restart, and 997 Purge Originator Identification. 999 8.1 E-L1FS Support (New) 1001 TRILL switches MUST support Extended Level 1 Flooding Scope PDUs (E- 1002 L1FS) [RFC7356] and MUST include a Scoped Flooding Support TLV 1003 [RFC7356] in all TRILL Hellos they send indicating support for this 1004 scope and any other FS-LSP scopes that they support. This support 1005 increases the number of fragments available for link state 1006 information by over two orders of magnitude. (See Section 9 for 1007 further information on support of the Scoped Flooding Support TLV.) 1009 In addition, TRILL switches MUST advertise their support of E-L1FS 1010 flooding in a TRILL Version sub-TLV capability bit (see [RFC7176] and 1011 Section 12.2). This bit is used by a TRILL switch, say RB1, to 1012 determine support for E-L1FS by some remote RBx. The alternative of 1013 simply looking for an E-L1FS FS-LSP originated by RBx fails because 1014 (1) RBx might support E-L1FS flooding but not be originating any E- 1015 L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs there 1016 might, due to legacy TRILL switches in the campus, be no path between 1017 RBx and RB1 through TRILL switches supporting E-L1FS flooding. If 1018 that were the case, no E-L1FS FS-LSP originated by RBx could get to 1019 RB1. 1021 E-L1FS will commonly be used to flood TRILL GENINFO TLVs and enclosed 1022 TRILL APPsub-TLVs [RFC7357]. For robustness, E-L1FS fragment zero 1023 MUST NOT exceed 1470 bytes in length; however, if such a fragment is 1024 received that is larger, it is processed normally. It is anticipated 1025 that in the future, some particularly important TRILL APPsub-TLVs 1026 will be specified as being flooded in E-L1FS fragment zero. TRILL 1027 GENINFO TLVs MUST NOT be sent in LSPs; however, if one is received in 1028 an LSP, it is processed normally. 1030 8.1.1 Backward Compatibility 1032 A TRILL campus might contain TRILL switches supporting E-L1FS 1033 flooding and legacy TRILL switches that do not support E-L1FS or 1034 perhaps do not support any [RFC7356] scopes. 1036 A TRILL switch conformant to this document can always tell which 1037 adjacent TRILL switches support E-L1FS flooding from the adjacency 1038 table entries on its ports (see Section 9). In addition, such a TRILL 1039 switch can tell which remote TRILL switches in a campus support E- 1040 L1FS by the presence of a TRILL Version sub-TLV in that TRILL 1041 switch's LSP with the E-L1FS support bit set in the Capabilities 1042 field; this capability bit is ignored for adjacent TRILL switches for 1043 which only the adjacency table entry is consulted to determine E-L1FS 1044 support. 1046 TRILL specifications making use of E-L1FS MUST specify how situations 1047 involving mixed TRILL campus of TRILL switches will be handled. 1049 8.1.2 E-L1FS Use for Existing (sub)TLVs 1051 In a campus where all TRILL switches support E-L1FS, all TRILL sub- 1052 TLVs listed in Section 2.3 of [RFC7176], except the TRILL Version 1053 sub-TLV, MAY be advertised by inclusion in Router Capability or MT- 1054 Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL Version sub- 1055 TLV still MUST appear in an LSP fragment zero.) 1057 In a mixed campus where some TRILL switches support E-L1FS and some 1058 do not, then only the following four sub-TLVs of those listed in 1059 Section 2.3 of [RFC7176] can appear in E-L1FS and then only under the 1060 conditions discussed below. In the following list, each sub-TLV is 1061 preceded by an abbreviated acronym used only in this Section 8.1.2: 1063 IV: Interested VLANs and Spanning Tree Roots sub-TLV 1064 VG: VLAN Groups sub-TLV 1065 IL: Interested Labels and Spanning Tree Roots sub-TLV 1066 LG: Label Groups sub-TLV 1068 An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an 1069 E-L1FS FS-LSP (instead being advertised in an LSP) unless the 1070 following conditions are met: 1071 - E-L1FS is supported by all of the TRILL switches that are data 1072 reachable from RB1 and are interested in the VLANs mentioned in 1073 the IV or VG sub-TLV, and 1074 - there is E-L1FS connectivity between all such TRILL switches in 1075 the campus interested in the VLANs mentioned in the IV or VG sub- 1076 TLV (connectivity involving only intermediate TRILL switches that 1077 also support E-L1FS). 1079 Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS 1080 LSP by any TRILL switch that has enough room in its LSPs. 1082 The conditions for using E-L1FS for the IL and LG sub-TLVs are the 1083 same as for IV and VG but with Fine Grained Labels [RFC7172] 1084 substituted for VLANs. 1086 Note, for example, that the above would permit a contiguous subset 1087 of the campus that supported Fine Grained Labels and E-L1FS to use 1088 E-L1FS to advertise IL and LG sub-TLVs even if the remainder of 1089 the campus did not support Fine Grained Labels or E-L1FS. 1091 8.2 Control Packet Priorities (New) 1093 When deciding what packet to send out a port, control packets used to 1094 establish and maintain adjacency between TRILL switches SHOULD be 1095 treated as being in the highest priority category. This includes 1096 TRILL IS-IS Hello and MTU PDUs and possibly other adjacency [RFC7177] 1097 or link technology specific packets. Other control and data packets 1098 SHOULD be given lower priority so that a flood of such other packets 1099 cannot lead to loss of or inability to establish adjacency. Loss of 1100 adjacency causes a topology transient that can result in reduced 1101 throughput, re-ordering, increased probability of loss of data, and, 1102 in the worst case, if the adjacency is a cut point, network 1103 partition. 1105 Other important control packets should be given second highest 1106 priority. Lower priorities should be given to data or less important 1107 control packets. 1109 Based on the above, control packets can be ordered into priority 1110 categories as shown below based on the relative criticality of these 1111 types of messages, where the most critical relate to the core routing 1112 between TRILL switches and the less critical are closer to 1113 "application" information. (There may be additional control packets, 1114 not specifically listed in any category below, that SHOULD be handled 1115 as being in the most nearly analogous category.) Although few 1116 implementations will actually treat these four categories with 1117 different priority, an implementation MAY choose to prioritize more 1118 critical messages over less critical. However, an implementation 1119 SHOULD NOT send control packets in a lower priority category with a 1120 priority above those in a higher priority category as, under 1121 sufficiently congested conditions, this could block control packets 1122 in a higher priority category, resulting in network disruption. 1124 Priority 1125 Category Description 1126 -------- -------------- 1128 4. Hello, MTU-probe, MTU-ack, and other packets critical to 1129 establishing and maintaining adjacency. (Normally sent 1130 with highest priority 7.) 1132 3. LSPs, CSNP/PSNPs, and other important control packets, 1134 2. Circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1136 1. Non-circuit scoped FS-LSP, FS-CSNP, and FS-PSNPs. 1138 8.3 Unknown PDUs (New) 1140 TRILL switches MUST silently discard [IS-IS] PDUs they receive with 1141 PDU numbers they do not understand, just as they ignore TLVs and sub- 1142 TLVs they receive that have unknown Types and sub-Types; however, 1143 they SHOULD maintain a counter of how many such PDUs have been 1144 received, on a per PDU number basis. (This is not burdensome as the 1145 PDU number is only a 5-bit field.) 1147 Note: The set of valid [IS-IS] PDUs was stable for so long that 1148 some IS-IS implementations may treat PDUs with unknown PDU 1149 numbers as a serious error and, for example, an indication that 1150 other valid PDUs from the sender are not to be trusted or that 1151 they should drop adjacency to the sender if it was adjacent. 1152 However, the MTU-probe and MTU-ack PDUs were added by [RFC7176] 1153 and now [RFC7356] has added three more new PDUs. While the 1154 authors of this document are not aware of any Internet drafts 1155 calling for further PDUs, the eventual addition of further new 1156 PDUs should not be surprising. 1158 8.4 Nickname Flags APPsub-TLV (New) 1160 An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV 1161 [RFC7357] is specified below. 1163 1 1 1 1 1 1 1164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Type = NickFlags (#tbd2) | (2 bytes) 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Length = 4*K | (2 bytes) 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | NICKFLAG RECORD 1 (4 bytes) | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 ... 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | NICKFLAG RECORD K (4 bytes) | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 Where each NICKFLAG RECORD has the following format: 1179 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1180 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1181 | Nickname | 1182 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1183 |IN| RESV | 1184 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1186 o Type: NickFlags TRILL APPsub-TLV, set to tbd2 (NICKFLAGS) 1188 o Length: 4 times the number of NICKFLAG RECORDS present. 1190 o Nickname: A 16-bit TRILL nickname held by the advertising TRILL 1191 switch ([RFC6325] and Section 4). 1193 o IN: Ingress. If this flag is one, it indicates the advertising 1194 TRILL switch may use the nickname in the NICKFLAG RECORD as the 1195 ingress nickname of TRILL Headers it creates. If the flag is 1196 zero, that nickname will not be used for that purpose. 1198 o RESV: Reserved for additional flags to be specified in the 1199 future. MUST be sent as zero and ignored on receipt. 1201 The entire NickFlags APPsub-TLV is ignored if the Length is not a 1202 multiple of 4. A NICKFLAG RECORD is ignored if the nickname it lists 1203 is not a nickname owned by the TRILL switch advertising the enclosing 1204 NickFlags APPsub-TLV. 1206 If a TRILL switch intends to use a nickname in the ingress nickname 1207 field of TRILL Headers it constructs, it can advertise this through 1208 E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry 1209 with the IN flag set. If it owns only one nickname, there is no 1210 reason to do this because, if a TRILL switch advertises no NickFlags 1211 APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed 1212 that the TRILL switch might use any or all nicknames it owns as the 1213 ingress nickname in TRILL Headers it constructs. If a TRILL switch 1214 advertises any NickFlags APPsub-TLV entries with the IN flag set, 1215 then it MUST NOT use any other nickname(s) it owns as the ingress 1216 nickname in TRILL Headers it constructs. 1218 Every reasonable effort should be made to be sure that Nickname sub- 1219 TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync. If all TRILL 1220 switches in a campus support E-L1FS, so that Nickname sub-TLVs can be 1221 advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any 1222 NickFlags APPsub-TLVs for any particular nickname SHOULD be 1223 advertised in the same fragment. If they are not in the same fragment 1224 then, to the extent practical, all fragments involving those sub-TLVs 1225 for the same nickname should be propagated as an atomic action. If a 1226 TRILL switch sees multiple NickFlags APPsub-TLV entries for the same 1227 nickname, it assumes that nickname might be used as the ingress in a 1228 TRILL Header if any of the NickFlags APPsub-TLV entries have the IN 1229 bit set. 1231 It is possible that a NickFlags APPsub-TLV would not be propagated 1232 throughout the TRILL campus due to legacy TRILL switches not 1233 supporting E-L1FS. In that case, Nickname sub-TLVs MUST be advertised 1234 in LSPs and TRILL switches not receiving NickFlags APPsub-TLVs having 1235 entries with the IN flag set will simply assume that the source TRILL 1236 switch might use any of its nicknames as ingress in constructing 1237 TRILL Headers. Thus the use of this optional APPsub-TLV is backwards 1238 compatible with legacy lack of E-L1FS support. 1240 (Additional flags are assigned from those labeled RESV above and 1241 specified in [irb] and [centralized-replication], works in progress.) 1243 8.5 Graceful Restart (Unchanged) 1245 TRILL Switches SHOULD support the features specified in [RFC5306], 1246 which describes a mechanism for a restarting IS-IS router to signal 1247 to its neighbors that it is restarting, allowing them to reestablish 1248 their adjacencies without cycling through the down state, while still 1249 correctly initiating link-state database synchronization. If this 1250 feature is not supported, it may increase the number of topology 1251 transients cause by a TRILL switch rebooting due to errors or 1252 maintenance. 1254 8.6 Purge Originator Identification (New) 1256 To ease debugging of any purge related problems, TRILL switches 1257 SHOULD include the Purge Originator Identification TLV [RFC6232] in 1258 all purge PDUs in TRILL IS-IS including Flooding Scoped purges 1259 [RFC7356] and in ESADI [RFC7357]. 1261 9. Updates to [RFC7177] (Adjacency) (Changed) 1263 To support the E-L1FS flooding scope [RFC7356] mandated by Section 1264 8.1 and backwards compatibility with legacy RBridges not supporting 1265 E-L1FS flooding, the following changes are made to [RFC7177]: 1267 1. The list in the second paragraph of [RFC7177] Section 3.1 has the 1268 following item added: 1270 - The Scoped Flooding Support TLV. 1272 In addition, the sentence immediately after that list is modified to 1273 read as follows: 1275 Of course, the priority, Desired Designated VLAN, Scoped Flooding 1276 Support TLV, and possibly the inclusion or value of the PORT- 1277 TRILL-VER sub-TLV, and/or BFD-Enabled TLV could change on 1278 occasion, but then the new value(s) must similarly be used in all 1279 TRILL Hellos on the LAN port, regardless of VLAN. 1281 2. An additional bullet item is added to the end of Section 3.2 of 1282 [RFC7177] as follows: 1284 o The value from the Scoped Flooding Support TLV or a null string 1285 if none was included. 1287 3. Near the bottom of Section 3.3 of [RFC7177] a bullet item as 1288 follows is added: 1290 o The variable length value part of the Scoped Flooding Support 1291 TLV in the Hello or a null string if that TLV does not occur in 1292 the Hello. 1294 4. At the beginning of Section 4 of [RFC7177], a bullet item is added 1295 to the list as follows: 1297 o The variable length value part of the Scoped Flooding Support 1298 TLV used in TRILL Hellos sent on the port. 1300 5. Add a line to Table 4: TRILL Hello Contents in Section 9.1 of 1301 [RFC7177] as follows: 1303 LAN P2P Number Content Item 1304 --- --- ------ ----------------------------- 1306 M M 1 Scoped Flooding Support TLV 1308 10. TRILL Header Update (New) 1310 The TRILL header has been updated from its original specification in 1311 [RFC6325] by [RFC7455] and [RFC7179] and is further updated by this 1312 document. The TRILL header is now as shown in the figure below which 1313 is followed by references for all of the fields. Those fields for 1314 which the reference is only to [RFC6325] are unchanged from that RFC. 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | V |A|C|M| RESV |F| Hop Count | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Egress Nickname | Ingress Nickname | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 : Optional Flag Word : 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 In calculating a TRILL Data packet hash as part of equal-cost multi- 1325 path selection, a TRILL switch MUST ignore the value of the "A" and 1326 "C" bits. 1328 In [RFC6325] and [RFC7179] there is an "Ex-Length" or TRILL Header 1329 Extensions Length field which is hereby changed to consist of the 1330 RESV and F fields above. 1332 o V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325]. 1334 o A (Alert): 1 bit. See [RFC7455]. 1336 o C (Color): 1 bit. See Section 10.1. 1338 o M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325]. 1340 o RESV: 4 bits. These bits are reserved and MUST be sent as zero. 1341 Due to the previous use of these bits specified in [RFC6325], most 1342 TRILL fast path hardware implementations trap and do not forward 1343 TRILL Data packets with these bits non-zero. A TRILL switch 1344 receiving a TRILL Data packet with any of these bits non-zero MUST 1345 discard the packet unless the non-zero bit or bits have some 1346 future use specified that the TRILL switch understands. 1348 o F: 1 bit. If this field is non-zero, then the optional Flag Word 1349 described in Section 10.2 is present. If it is zero, the Flag Word 1350 is not present. 1352 o Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 1353 below. 1355 o Egress Nickname. See Section 3.7.1 of [RFC6325]. 1357 o Ingress Nickname. See Section 3.7.2 of [RFC6325]. 1359 o Optional Flag Word: See [RFC7179] and Section 10.2. 1361 10.1 Color Bit 1363 The Color bit provides an optional way ingress TRILL switches MAY 1364 mark TRILL Data packets for implementation specific purposes. 1365 Transit TRILL switches MUST NOT change this bit. Transit and egress 1366 TRILL switches MAY use the Color bit for implementation dependent 1367 traffic labeling or statistical or other traffic study or analysis. 1369 10.2 Flag Word Changes (update to [RFC7179]) 1371 When the F bit in the TRILL Header is non-zero, the first 32 bits 1372 after the Ingress nickname field provides additional flags. These 1373 bits are as specified in [RFC7179] except as changed by the 1374 subsections below that provide extended Hop Count and extended Color 1375 fields. See Section 10.3 for a diagram and summary of these fields. 1377 10.2.1 Extended Hop Count 1379 The TRILL base protocol [RFC6325] specifies the Hop Count field in 1380 the header, to avoid packets persisting in the network due to looping 1381 or the like. However, the Hop Count field size (6 bits) limits the 1382 maximum hops a TRILL Data packet can traverse to 64. Optionally, 1383 TRILL switches can use a field composed of bits 14 through 16 in the 1384 Flag Word, as specified below, to extend this field to 9 bits. This 1385 increases the maximum Hop Count to 512. Except in rare circumstances, 1386 reliable use of Hop Counts in excess of 64 requires support of this 1387 optional capability at all TRILL switches along the path of a TRILL 1388 Data packet. 1390 10.2.1.1 Advertising Support 1392 In case of a TRILL campus such that the unicast calculated path, plus 1393 a reasonable allowance for alternate pathing, or the distribution 1394 tree calculated path, traverse more than 64 hops, it may be that not 1395 all the TRILL switches support the extended Hop Count mechanism. As 1396 such it is required that TRILL switches advertise their support by 1397 setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header 1398 Flags Supported field [RFC7176]; bits 15 and 16 of that field are now 1399 specified as Unassigned (see Section 12.2.5). 1401 10.2.1.2 Ingress Behavior 1403 If an ingress TRILL switch determines it should set the hop count for 1404 a TRILL Data packet to 63 or less, then behavior is as specified in 1405 the TRILL base protocol [RFC6325]. If the optional TRILL Header Flag 1406 Word is present, bits 14, 15, and 16 and the Critical Reserved bit of 1407 the Critical Summary Bits are zero. 1409 If the hop count for a TRILL Data packet should be set to some value 1410 greater than 63 but less than 512 and all TRILL switches that the 1411 packet is reasonably likely to encounter support extended Hop Count, 1412 then the resulting TRILL Header has the Flag Word extension present, 1413 the high order three bits of the desired hop count are stored in the 1414 extended Hop Count field in the Flag Word, the five low order bits 1415 are stored in the Hop Count field in the first word of the TRILL 1416 Header, and bit two (the Critical Reserved bit of the Critical 1417 Summary Bits) in the Flag Word is set to one. 1419 For known unicast traffic (TRILL Header M bit zero), an ingress TRILL 1420 switch discards the frame if it determines that the least cost path 1421 to the egress is (1) more than 64 hops and not all TRILL switches on 1422 that path support the extended Hop Count feature or (2) more than 512 1423 hops. 1425 For multi-destination traffic, when a TRILL switch determines that 1426 one or more tree paths from the ingress are more than 64 hops and not 1427 all TRILL switches in the campus support the extended Hop Count 1428 feature, the encapsulation uses a total Hop Count of 63 to obtain at 1429 least partial distribution of the traffic. 1431 10.2.1.3 Transit Behavior 1433 A transit TRILL switch supporting extended Hop Count behaves like a 1434 base protocol [RFC6325] TRILL switch in decrementing the hop count 1435 except that it considers the hop count to be a 9 bit field where the 1436 extended Hop Count field constitutes the high order three bits. 1438 To be more precise: a TRILL switch supporting extended Hop Count 1439 takes the first of the following actions that is applicable: 1441 1. If both the Hop Count and extended Hop Count fields are zero, the 1442 packet is discarded. 1444 2. If the Hop Count is non-zero, it is decremented. As long as the 1445 extended Hop Count is non-zero, no special action is taken. If the 1446 result of this decrement is zero, the packet is processed 1447 normally. 1449 3. If the Hop Count is zero, it is set to the maximum value of 63 and 1450 the extended Hop Count is decremented. If this results in the 1451 extended Hop Count being zero, the Critical Reserved bit in the 1452 Critical Summary bits is set to zero. 1454 10.2.1.4 Egress Behavior 1456 No special behavior is required when egressing a TRILL Data packet 1457 that uses the extended Hop Count. The Flag Word, if present, is 1458 removed along with the rest of the TRILL Header during decapsulation. 1460 10.2.2 Extended Color Field 1462 Flag Word bits 27 and 28 are specified to be a two-bit Extended Color 1463 field (see Section 10.3). These bits are in the non-critical ingress- 1464 to-egress region of the Flag Word. 1466 The Extended Color field provides an optional way by which ingress 1467 TRILL switches MAY mark TRILL Data packets for implementation 1468 specific purposes. Transit TRILL switches MUST NOT change these bits. 1469 Transit and egress TRILL switches MAY use the Extended Color bits for 1470 implementation dependent traffic labeling or statistical or other 1471 traffic study or analysis. 1473 As provided in Section 2.3.1 of [RFC7176], support for these bits is 1474 indicated by the same bits (27 and 28) in the Capabilities and Header 1475 Flags Supported field of the TRILL Version Sub-TLV. If these bits are 1476 zero in those capabilites, Extended Color is not supported. A TRILL 1477 switch that does not support Extended Color will ignore the 1478 corresponding bits in any TRILL Header Flag Word it receives as part 1479 of a TRILL Data Packet and will set those bits to zero in any TRILL 1480 Header Flag word it creates. A TRILL switch that sets or senses the 1481 Extended Color field on transmitting or receiving TRILL Data packets 1482 MUST set the corresponding 2-bit field in the TRILL Version Sub-TLV 1483 non-zero. Any difference in meaning of the three possible non-zero 1484 values of this 2-bit capability field (0b01, 0b10 or 0b11) is 1485 implementation dependent. 1487 10.3 Updated Flag Word Summary 1489 With the changes above, the 32-bit Flag Word extension to the TRILL 1490 Header [RFC7179], appearing as the "TRILL Extended Header Flags" 1491 registry on the TRILL Parameters IANA web page, is now as follows: 1493 0 1 2 3 1494 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 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 1497 |.....|.........|...........|.....|.......|...........|.........| 1498 |C|C|C| |C|N| | Ext | | |Ext| | 1499 |R|R|R| |R|C| | Hop | | |Clr| | 1500 |H|I|R| |C|C| | Cnt | | | | | 1501 |b|t|s| |A|A| | | | | | | 1502 |H|E|v| |F|F| | | | | | | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 Bit 0 to 2 are the Critical Summary bits as specified in [RFC7179] 1506 consisting of the Critical Hop-by-Hop, Critical Ingres-to-Egress, and 1507 Critical Reserved bits, respectively. The next two fields are 1508 specific Critical and Non-Critical Hop-by-Hop bits, CHbH and NCHbH, 1509 respectively, containing the Critical and Non-Critical Channel Alert 1510 flags as specified in [RFC7179]. The next field is the Critical 1511 Reserved bits (CRSV) that are specified herein to be the Extended Hop 1512 Count. Then the Non-Critical Reserved Bits (NCRSV) and the Critical 1513 Ingress-to-Egress bits (CITE) as specified in [RFC7179]. Finally, 1514 there is the Non-Critical Ingress-to-Egress field including bits 27 1515 and 28 that are specified herein as the Extended Color field. 1517 11. Appointed Forwarder Status Lost Counter (New) 1519 Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on 1520 the value of the Appointed Forwarder Status Lost Counter can result 1521 in splitting of Interested VLANs and Spanning Tree Roots sub-TLVs 1522 [RFC7176] (or the corresponding Interested Labels sub-TLVs where a 1523 VLAN is mapped to an FGL) due to differences in this counter value 1524 for adjacent VLAN IDs (or 24-bit FGLs). This counter is a mechanism 1525 to optimize data plane learning by trimming the expiration timer for 1526 learned addresses on a per VLAN/FGL basis under some circumstances. 1528 The requirement to increment this counter by one whenever a TRILL 1529 switch loses appointed forwarder status on a port is hereby changed 1530 from the mandatory provisions of [RFC6325] to the enumerated 1531 provisions below. To the extent that this might cause the Appointed 1532 Forwarder Status Lost Counter to be increased when [RFC6325] 1533 indicates it should not, this will cause data plane address learning 1534 timeouts at remote TRILL switches to be reduced. To the extent that 1535 this might cause the Appointed Forwarder Status Lost Counter to 1536 remain unchanged when [RFC6325] indicate it should be increased, this 1537 will defeat a reduction in such timeouts that would otherwise occur. 1539 (1) If any of the following apply, either data plane address learning 1540 is not in use or Appointed Forwarder status is irrelevant. In 1541 these cases the Appointed Forwarder Status Lost Counter MAY be 1542 left zero or set to any convenient value such as the value of the 1543 Appointed Forwarder Status Lost Counter for an adjacent VLAN ID 1544 or FGL. 1546 (1a) The TRILL switch port has been configured with the "disable 1547 end station traffic" bit on (also known as the trunk bit). 1549 (1b) The TRILL switch port has been configured in IS-IS as an IS- 1550 IS point-to-point link. 1552 (1C) If the TRILL switch is relying on ESADI [RFC7357] or 1553 Directory Assist [RFC7379] and not using data plane learning. 1555 (2) In cases other than those numerated in point 1 above, the 1556 Appointed Forwarder Status Lost Counter SHOULD be incremented as 1557 described in [RFC6325]. Such incrementing has the advantage of 1558 optimizing data plane learning. Alternatively, the value of the 1559 Appointed Forwarder Status Lost Counters can deviate from that 1560 value, for example to make it match the value for an adjacent 1561 VLAN ID (or FGL), so as to permit greater aggregation of 1562 Interested VLANs and Spanning Tree Roots sub-TLVs. 1564 12. IANA Considerations (Changed) 1566 This section gives IANA actions previously completed and new IANA 1567 actions. 1569 12.1 Previously Completed IANA Actions (Unchanged) 1571 The following IANA actions were completed as part of [RFC7180] and 1572 are included here for completeness, since this document obsoletes 1573 [RFC7180]. 1575 1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated 1576 for use in the TRILL Header Egress Nickname field to indicate an 1577 OOMF (Overload Originated Multi-destination Frame). 1579 2. Bit 1 from the seven previously reserved (RESV) bits in the per- 1580 neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is 1581 allocated to indicate that the RBridge sending the TRILL Hello 1582 volunteers to provide the OOMF forwarding service described in 1583 Section 2.4.2 to such frames originated by the TRILL Switch whose 1584 SNPA (MAC address) appears in that Neighbor RECORD. The 1585 description of this bit is "Offering OOMF service". 1587 3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER 1588 sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub- 1589 TLV [RFC7176] and the VLAN inhibition setting mechanisms specified 1590 in [rfc6439bis]. The description of this bit is "Hello reduction 1591 support". 1593 12.2 New IANA Actions (New) 1595 The following are new IANA actions for this document: 1597 12.2.1 Reference Updated 1599 All references to [RFC7180] in the TRILL Parameters Registry are 1600 replaced with references to this document except that the Reference 1601 for bit 0 in the PORT-TRILL-VER Sub-TLV Capability Flags is changed 1602 to [rfc6439bis]. 1604 12.2.2 The 'E' Capability Bit 1606 There is an existing TRILL Version sub-TLV, sub-TLV #13 under both 1607 TLV #242 and TLV #144 [RFC7176]. This TRILL Version sub-TLV contains 1608 a capability bits field for which assignments are documented in the 1609 "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters 1610 IANA web page. IANA has allocated tbd1 from the previous reserved 1611 bits in this TRILL-VER Sub-TLV Capability Flags registry to indicate 1612 support of the E-L1FS flooding scope as specified in Section 8.1. 1613 This capability bit is referred to as the "E" bit. The following is 1614 the addition to the TRILL-VER Sub-TLV Capability Flags registry: 1616 Bit Description References 1617 ---- --------------------- --------------- 1618 tbd1 E-L1FS FS-LSP support [this document][RFC7356] 1620 12.2.3 NickFlags APPsub-TLV Number and Registry 1622 IANA has assigned tbd2 APPsub-TLV number under the TRILL GENINFO TLV 1623 from the range less than 255. 1625 Type Name References 1626 ---- --------- ----------- 1627 tbd2 NICKFLAGS [this document] 1629 In addition, IANA has created a registry on the TRILL Parameters web 1630 page for NickFlags bit assignments as follows: 1632 Name: NickFlags Bits 1633 Registration Procedure: IETF Review 1634 Reference: [this document] 1636 Bit Mnemonic Description Reference 1637 ----- -------- ----------- --------- 1638 0 IN Used as ingress [this document] 1639 1-15 - Unassigned [this document] 1641 12.2.4 Updated TRILL Extended Header Flags 1643 Update the "TRILL Extended Header Flags" registry as follows: 1645 Bits Purpose References 1646 ----- ------------------------------------------ ------------ 1648 14-16 Extended Hop Count [this document] 1650 27-28 Extended Color [this document] 1652 29-31 Available non-critical ingress-to-egress flags 1653 [RFC7179] [this document] 1655 12.2.5 TRILL-VER Sub-TLV Capability Flags 1657 Update the "TRILL-VER Sub-TLV Capability Flags" registry as follows: 1659 Bit Description Reference 1660 ----- -------------------------- ---------------- 1662 14 Extended Hop Count support [this document] 1664 15-16 Unassigned [this document] 1666 27-28 Extended Color support [this document] 1668 29-31 Extended header flag support [RFC7179] [this document] 1670 12.2.6 Example Nicknames 1672 IANA has assigned a block of four nicknames for use as examples in 1673 documentation such as in Appendix B below. The TRILL Nicknames 1674 registry has been updated by changing the previous "0xFFC2-0xFFFE 1675 Unassigned" line to the following: 1677 Name Description Reference 1678 ------------- -------------- ----------- 1679 0xFFC2-0xFFD7 Unassigned 1680 0xFFD8-0xFFDF For use in documentation examples [this document] 1681 0xFFE0-0xFFFE Unassigned 1683 13. Security Considerations (Changed) 1685 See [RFC6325] for general TRILL security considerations. 1687 This memo improves the documentation of the TRILL protocol, corrects 1688 five errata in [RFC6325], updates [RFC6325], [RFC7177], and [RFC7179] 1689 and obsoletes [RFC7180]. It does not change the security 1690 considerations of those RFCs except as follows: 1692 E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310], 1693 that is, through the inclusion of an IS-IS Authentication TLV in 1694 E-L1FS PDUs. 1696 As discussed in Section 3.6, when using an allowed weaker RPF check 1697 under very rare topolgoies and transient conditions, multi- 1698 destination TRILL Data packets can be duplicated, which could have 1699 secuirty consequences for some protocols. 1701 Normative References 1703 [802.1Q-2014] - IEEE, "IEEE Standard for Local and metropolitan area 1704 networks -- Media Access Control (MAC) Bridges and Virtual 1705 Bridged Local Area Networks", IEEE Std 802.1Q-2014, 19 December 1706 2014. 1708 [IS-IS] - International Organization for Standardization, 1709 "Intermediate System to Intermediate System intra-domain 1710 routeing information exchange protocol for use in conjunction 1711 with the protocol for providing the connectionless-mode network 1712 service (ISO 8473)", Second Edition, November 2002. 1714 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1715 Requirement Levels", BCP 14, RFC 2119, March 1997. 1717 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 1718 Engineering", RFC 5305, October 2008. 1720 [RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 1721 RFC 5306, October 2008. 1723 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1724 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1725 5310, February 2009, . 1727 [RFC6232] - Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 1728 Originator Identification TLV for IS-IS", RFC 6232, May 2011, 1729 . 1731 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1732 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1733 Specification", RFC 6325, July 2011. 1735 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1736 Interconnection of Lots of Links (TRILL) Protocol Control 1737 Protocol", RFC 6361, August 2011. 1739 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1740 and D. Dutt, "Transparent Interconnection of Lots of Links 1741 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1743 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1744 D., and A. Banerjee, "Transparent Interconnection of Lots of 1745 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 1747 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1748 and V. Manral, "Transparent Interconnection of Lots of Links 1749 (TRILL): Adjacency", RFC 7177, May 2014. 1751 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 1752 C. Bestler, "Transparent Interconnection of Lots of Links 1753 (TRILL): Header Extension", RFC 7179, May 2014, 1754 . 1756 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1757 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 1758 . 1760 [RFC7455] - Senevirathne, T., Finn, N., Salam, S., Kumar, D., 1761 Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent 1762 Interconnection of Lots of Links (TRILL): Fault Management", 1763 RFC 7455, March 2015, . 1765 Informative References 1767 [802] - IEEE 802, "IEEE Standard for Local and metropolitan area 1768 networks: Overview and Architecture", IEEE Std 802.1-2014, 12 1769 June 2014. 1771 [centralized-replication] - Weiguo Hao, et al., "Centralized 1772 Replication for BUM traffic in active-active edge connection", 1773 draft-ietf-trill-centralized-replication, Work in Progress. 1775 [irb] - Weiguo Hao, et al., "TRILL Distributed Layer 3 Gateway", 1776 draft-ietf-trill-irb, Work in Progress. 1778 [Err3002] - RFC Errata, Errata ID 3002, RFC 6325, . 1781 [Err3003] - RFC Errata, Errata ID 3003, RFC 6325, . 1784 [Err3004] - RFC Errata, Errata ID 3004, RFC 6325, . 1787 [Err3052] - RFC Errata, Errata ID 3052, RFC 6325, . 1790 [Err3053] - RFC Errata, Errata ID 3053, RFC 6325, . 1793 [Err3508] - RFC Errata, Errata ID 3508, RFC 6325, . 1796 [RFC826] - Plummer, D., "Ethernet Address Resolution Protocol: Or 1797 Converting Network Protocol Addresses to 48.bit Ethernet 1798 Address for Transmission on Ethernet Hardware", STD 37, RFC 1799 826, November 1982, . 1801 [RFC792] - Postel, J., "Internet Control Message Protocol", STD 5, 1802 RFC 792, September 1981, . 1805 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1806 "Randomness Requirements for Security", BCP 106, RFC 4086, June 1807 2005, . 1809 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 1810 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 1811 6327, July 2011, . 1813 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1814 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1815 6439, November 2011, . 1817 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1818 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1819 BCP 141, RFC 7042, October 2013. 1821 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1822 "Transparent Interconnection of Lots of Links (TRILL): 1823 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1824 May 2014. 1826 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1827 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1828 RBridge Channel Support", RFC 7178, May 2014. 1830 [RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., 1831 and A. Banerjee, "Transparent Interconnection of Lots of Links 1832 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1833 May 2014. 1835 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1836 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1837 End Station Address Distribution Information (ESADI) Protocol", 1838 RFC 7357, September 2014, . 1841 [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1842 "Problem Statement and Goals for Active-Active Connection at 1843 the Transparent Interconnection of Lots of Links (TRILL) Edge", 1844 RFC 7379, October 2014, . 1847 [rfc6439bis] - Eastlake, D., et al., "TRILL: Appointed Forwarders", 1848 draft-eastlake-trill-rfc6439bis, work in progress. 1850 Acknowledgements 1852 The contributions of the following individuals to this document are 1853 gratefully acknowledged: 1855 Santosh Rajagopalan, Gayle Noble 1857 The contributions of the following, listed in alphabetic order, to 1858 the preceding version of this document, [RFC7180], are gratefully 1859 acknowledged: 1861 Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia 1862 Perlman, Mike Shand, Meral Shirazipour, and Varun Shah. 1864 The document was prepared in raw nroff. All macros used were defined 1865 within the source file. 1867 Appendix A: Life Cycle of a TRILL Switch Port (New) 1869 The contents of this informational Appendix originated in 1870 http://www.ietf.org/mail-archive/web/trill/current/msg06355.html 1872 Question: Suppose we are developing a TRILL implementation to run on 1873 different machines. Then what happens first? Is LSP flooding or 1874 ESADI started first? -> Link state database creation -> Designated 1875 RBridge election (How to set priority? any fixed process that 1876 depends on user settings? ) -> etc. ? 1878 Answer: 1880 The first thing that happens on a port/link is any link set-up 1881 that is needed. For example, on a PPP link [RFC6361], you need to 1882 negotiate that you will be using TRILL. However, if you have 1883 Ethernet links [RFC6325], which are probably the most common type, 1884 there isn't any link set-up needed. 1886 As soon as the port is set-up, it can ingress or egress native 1887 frames if end-station service is being offered on that port. 1888 Offering end-station service is the default; however, if the port 1889 trunk bit (end-station service disable) is set or the port is 1890 configured as an IS-IS point-to-point link port, then end-station 1891 service is not offered so native frames received are ignored and 1892 native frames are not egressed. 1894 Then TRILL IS-IS Hellos get sent out the port to be exchanged with 1895 any other TRILL switches on the link [RFC7177]. Optionally, you 1896 might also exchange MTU-probe/ack PDUs [RFC7177], BFD PDUs 1897 [RFC7175], or other link test packets. But all these other things 1898 are optional. Only Hellos are required. 1900 TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the 1901 port to the link except Hellos until the link gets to the Two Way 1902 or Report state [RFC7177]. 1904 If a link is configured as a point-to-point link, there is no 1905 Designated RBridge (DRB) election. By default, an Ethernet link is 1906 considered a LAN link and the DRB election occurs when the link is 1907 in any state other than Down. You don't have to configure 1908 priorities for each TRILL switch (RBridge) to be Designated 1909 RBridge (DRB). Things will work fine with all the RBridges on a 1910 link using default priority. But if the network manager wants to 1911 control this, there should be a way for them to configure the 1912 priority to be DRB of the TRILL switch ports on the link. 1914 (To avoid complexity, this appendix generally describes things for 1915 a link that only has two TRILL switches on it. But TRILL works 1916 fine as currently specified on a broadcast link with multiple 1917 TRILL switches on it, actually multiple TRILL switch ports, since 1918 a TRILL switch can have multiple ports connected to the same link. 1919 The most likely way to get such a multi-access link with current 1920 technology and the existing TRILL standards is to have more than 2 1921 TRILL switch Ethernet ports connected to a bridged LAN. Since the 1922 TRILL protocol operates above all bridging, to the first 1923 approximation the bridge LAN looks like a transparent broadcast 1924 link to TRILL.) 1926 When a link gets to the 2-Way or Report state, then LSP, CSNP, and 1927 PSNP PDUs start to flow on the link (as well as FS-LSPs, FS-CSNPs, 1928 and FS-PSNPs for E-L1FS (see Section 8.1)). 1930 When a link gets to the Report state, then there is adjacency. The 1931 existence of that adjacency is flooded (reported) to the campus in 1932 LSPs. TRILL Data packets can then start to flow on the link as 1933 TRILL switches recalculate the least cost paths and distribution 1934 trees to take the new adjacency into account. Until it gets to the 1935 Report state, there is no adjacency and no TRILL Data packets can 1936 flow over that link (with the minor corner case exception that an 1937 RBridge Channel message can, for its first hop only, be sent on a 1938 port where there is no adjacency (Section 2.4 of [RFC7178]). 1939 (Although this paragraph seems to be talking about link state, it 1940 is actually port state. It is possible for different TRILL switch 1941 ports on the same link to temporarily be in different states. The 1942 adjacency state machinery runs independently on each port.) 1944 ESADI [RFC7357] is built on top of the regular TRILL Data routing. 1945 Since ESADI PDUs look, to transit TRILL switches, like regular 1946 TRILL Data packets, no ESADI PDUs can flow until adjacencies are 1947 established and TRILL Data is flowing. Of course, ESADI is 1948 optional and is not used unless configured... 1950 Question: Does it require TRILL Full headers at the time TRILL-LSPs 1951 start being broadcast on a link? Because at that time it's not 1952 defined Egress and Ingress nicknames. 1954 Answer: 1956 TRILL Headers are only for TRILL Data packets. TRILL IS-IS 1957 packets, such as TRILL-LSPs, are sent in a different way that does 1958 not use a TRILL Header and does not depend on nicknames. 1960 Probably, in most implementations, a TRILL switch will start up 1961 using the same nickname it had when it shut down or last got 1962 disconnected from a campus. If you want, you can implement TRILL 1963 to come up initially not reporting any nickname (by not including 1964 an Nickname sub-TLV in its LSPs) until you get the link state 1965 database or most of the link state database, and then choose a 1966 nickname no other TRILL switch in the campus is using. Of course, 1967 if a TRILL switch does not have a nickname, then it cannot ingress 1968 data, cannot egress known unicast data, and cannot be a tree root. 1970 TRILL IS-IS PDUs such as LSPs, and the link state database, all 1971 work based on the 7-byte IS-IS System-ID (sometimes called the LAN 1972 ID [IS-IS]). System-IDs always have to be unique across the campus 1973 so there is no problem determining topology regardless of nickname 1974 state. The Nickname system is built on top of that. 1976 Appendix B: Example TRILL PDUs (New) 1978 This appendix gives example TRILL IS-IS PDUs. The primary purpose of 1979 these examples is to clarify bit ordering issues. 1981 B.1 LAN Hello over Ethernet 1983 A TRILL Hello sent from a TRILL switch (RBridge) with 7-byte System 1984 ID 0x30033003300300 holding nickname 0xFFDE over Ethernet from a port 1985 with MAC address 0x00005E0053DE on VLAN 1 at priority 7. There is one 1986 neighbor that is DRB. The neighbor's port MAC is 0x00005E0053E3 and 1987 the neighbor's System ID is 0x44444444444400. 1989 Ethernet Header 1990 Outer.MacDA, Outer.MacSA 1991 0x0180C2000041 All-IS-IS-RBridges Dest. MAC Addr. 1992 0x00005E0053DE Source MAC Address 1993 Outer VLAN Tag (optional) 1994 0x8100 C-VLAN Ethertype [802.1Q] 1995 0xE001 Priority 7, Outer.VLAN 1996 IS-IS 1997 0x22F4 L2-IS-IS Ethertype 1998 IS-IS Payload 1999 Common Header 2000 0x83 Interdomain Routeing Discriminator 2001 0x08 Header Length 2002 0x01 IS-IS Version Number 2003 0x06 ID Length of 6 Octets 2004 0x0F PDU Type (Level 1 LAN Hello) 2005 0x01 Version 2006 0x00 Reserved 2007 0x01 Maximum Area Addresses 2008 Hello PDU Specific Fields 2009 0x01 Circuit Type (Level 1) 2010 0x30033003300300 Source System ID 2011 0x0009 Holding Time 2012 0xXXXX PDU Length 2013 0x40 Priority to be DRB 2014 0x44444444444400 LAN ID 2015 TLVs (the below order of TLVs or of sub-TLVs in a TLV 2016 is not significant. 2017 Area Addresses TLV 2018 0x01 Area Addresses Type 2019 0x02 Length of Value 2020 0x01 Length of Address 2021 0x00 The fixed TRILL Area Address 2023 MT Port Capabilities TLV 2024 0x8F MT Port Capabilities Type 2025 0x0011 Length of Value 2026 0x0000 Topology 2027 Special VLANs and Flags Sub-TLV 2028 0x01 Sub-TLV Type 2029 0x08 Length 2030 0x0123 Port ID 2031 0xFFDE Sender Nickname 2032 0x0001 Outer.VLAN 2033 0x0001 Designated VLAN 2034 Enabled VLANs sub-TLV (optional) 2035 0x02 Sub-TLV Type 2036 0x03 Length 2037 0x0001 Start VLAN 1 2038 0x80 VLAN 1 2039 TRILL Neighbor TLV 2040 0x91 Neighbor Type 2041 0x0A Length of Value 2042 0xC0 S & L Flags = 1, SIZE field 0 2043 NEIGHBOR RECORD 2044 0x00 Flags 2045 0x2328 MTU = 9K bytes 2046 0x00005E0053E3 Neighbor MAC Address 2047 Scoped Flooding Support TLV 2048 0xF3 Scoped Flooding Support Type 2049 0x01 Length of Value 2050 0x40 E-L1FS Flooding Scope 2051 More TLVs (optional) 2052 ... 2053 Ethernet Trailer 2054 0xXXXXXXXX Ethernet Frame Check Sequence 2056 B.2 LSP Over PPP 2058 Here is an example of a TRILL LSP PDU sent over a PPP link by the 2059 same source TRILL switch as the example in B.1. 2061 PPP Header 2062 0x405D PPP TRILL Link State Protocol 2064 IS-IS Payload 2065 Common Header 2066 0x83 Interdomain Routeing Discriminator 2067 0x08 Header Length 2068 0x01 IS-IS Version Number 2069 0x06 ID Length of 6 Octets 2070 0x12 PDU Type (Level 1 LSP) 2071 0x01 Version 2072 0x00 Reserved 2073 0x01 Maximum Area Addresses 2074 LSP Specific Fields 2075 0xXXXX PDU Length 2076 0x0123 Remaining Lifetime 2077 0x3003300330030009 LSP ID (fragment 9) 2078 0x00001234 Sequence Number 2079 0xXXXX Checksum 2080 0x01 Flags = Level 1 2081 TLVs (the below order of TLVs or of sub-TLVs in a TLV 2082 is not significant. 2083 Router Capability TLV 2084 0xF2 Router Capability Type 2085 0x0F Length of Value 2086 0x00 Flags 2087 Nickname Sub-TLV 2088 0x06 Sub-TLV Type 2089 0x05 Length of Value 2090 NICKNAME RECORD 2091 0x33 Nickname Priority 2092 0x1234 Tree Root Priority 2093 0xFFDE Nickname 2094 TRILL Version Sub-TLV 2095 0x0D Sub-TLV Type 2096 0x05 2097 0x00 Max Version 2098 0x40000000 Flags = FGL Support 2099 More TLVs (optional 2100 ... 2101 PPP Trailer 2102 0xXXXXXX PPP Frame Check Sequence 2104 B.3 TRILL Data Over Ethernet 2106 Below is an IPv4 ICMP Echo [RFC792] sent in a TRILL Data packet from 2107 the TRILL switch that sent the Hello in B.1 to the neighbor TRILL 2108 switch on the link used in B.1. 2110 Ethernet Header 2111 Outer.MacDA, Outer.MacSA 2112 0x00005E0053E3 Destination MAC Address 2113 0x00005E0053DE Source MAC Address 2114 Outer VLAN Tag (optional) 2115 0x8100 C-VLAN Ethertype [802.1Q] 2116 0x0001 Priority 0, Outer.VLAN 1 2117 TRILL 2118 0x22F3 TRILL Ethertype 2119 TRILL Header 2120 0X000E Flags, Hop Count 14 2121 0xFFDF Egress Nickname 2122 0xFFDC Ingress Nickname 2123 Inner Ethernet Header 2124 Inner.MacDA, Inner.MacSA 2125 0x00005E005322 Destination Mac Address 2126 0x00005E005344 Source Mac Address 2127 Inner VLAN Tag 2128 0x8100 C-VLAN Ethertype 2129 0x0022 Priority 0, Inner.VLAN 34 2130 Ethertype 2131 0x0800 IPv4 Ethertype 2132 IP Header 2133 0x4500 Version 4, Header Length 5, ToS 0 2134 0xXXXX Total Length 2135 0x3579 Identification 2136 0x0000 Flags, Fragment Offset 2137 0x1101 TTL 17, ICMP = Protocol 1 2138 0xXXXX Header Checksum 2139 0xC0000207 Source IP 192.0.2.7 2140 0xC000020D Destination IP 192.0.2.13 2141 0x00000000 Options, Padding 2142 ICMP 2143 0x0800 ICMP Echo 2144 0xXXXX Checksum 2145 0x87654321 Identifier, Sequence Number 2146 ... Echo Data 2147 Ethernet Trailer 2148 0xXXXXXXXX Ethernet Frame Check Sequence 2150 B.4 TRILL Data Over PPP 2152 Below is an ARP [RFC826] sent in a TRILL Data packet from the TRILL 2153 switch that sent the Hello in B.1 over a PPP link. 2155 PPP Header 2156 0x005D PPP TRILL Network Protocol 2158 TRILL Header 2159 0X080D Flags (M=1), Hop Count 13 2160 0xFFDD Distribution Tree Root Nickname 2161 0xFFDC Ingress Nickname 2162 Inner Ethernet Header 2163 Inner.MacDA, Inner.MacSA 2164 0xFFFFFFFFFFFF Destination Mac Address 2165 0x00005E005344 Source Mac Address 2166 Inner VLAN Tag 2167 0x8100 C-VLAN Ethertype 2168 0x0022 Priority 0, Inner.VLAN 34 2169 Ethertype 2170 0x0806 ARP Ethertype 2171 ARP 2172 0x0001 Hardware Address Space = Ethernet 2173 0x0001 Protocol Address Space = IPv4 2174 0x06 Size of Hardware Address 2175 0x04 Size of Protocol Address 2176 0x0001 OpCode = Request 2177 0x00005E005344 Sender Hardware Address 2178 0xC0000207 Sender Protocol Address 192.0.2.7 2179 0x000000000000 Target Hardware Address 2180 0xC000020D Target Protocol Address 192.0.2.13 2181 PPP Trailer 2182 0xXXXXXX PPP Frame Check Sequence 2184 Appendix C: Changes to Previous RFCs (New) 2186 C.1 Changes to Obsoleted [RFC7180] 2188 This section summarizes the changes, augmentations, and excisions 2189 this document makes to [RFC7180] which it obsoletes and replaces. 2191 C.1.1 Changes 2193 For each heading in this document ending with "(Changed)", this 2194 section summarizes how it was changed: 2196 Section 1, Introduction: numerous changes to reflect the overall 2197 changes in contents. 2199 Section 1.1, Precedence: changed to add mention of [RFC7179]. 2201 Section 1.3, Terminology and Acronyms: numerous terms added. 2203 Section 3, Distribution Trees and RPF Check: changed by the addition 2204 of the new material in Section 3.6. See C.1.2 item 1. 2206 Section 8, Other IS-IS Considerations: Changed by the addition of 2207 Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.1.2 items 2, 3, 4, 2208 and 5 respectively. 2210 Section 9, Updates to [RFC7177] (Adjacency): Changes and additions to 2211 [RFC7177] to support E-L1FS. See Appendix C.1.2, item 2. 2213 Section 12, IANA Considerations: changed by the addition of material 2214 in Section 12.2. See Appendix C.1.2, item 7. 2216 Section 13, Security Considerations: minor changes in the RFCs 2217 listed. 2219 C.1.2 Additions 2221 The following material was added to [RFC7180] in producing this 2222 document: 2224 1. Addition of support for an alternative Reverse Path Forwarding 2225 Check (RPFC) along with considerations for deciding between the 2226 original [RFC6325] RPFC and this alternative RPFC. This 2227 alternative RPFC was originally discussed on the TRILL WG mailing 2228 list in http://www.ietf.org/mail- 2229 archive/web/trill/current/msg01852.html and subsequent messages. 2230 (Section 3.6) 2232 2. Addition of mandatory E-L1FS [RFC7356] support (Section 8.1, 2233 Section 9). 2235 3. Recommendations concerning control packet priorities. (Section 2236 8.2) 2238 4. Implementation requirements concerning unknown IS-IS PDU types 2239 (Section 8.3). 2241 5. Specification of an optional Nickname Flags APPsub-TLV and an 2242 ingress flag within that APPsub-TLV. (Section 8.4) 2244 6. Update TRILL Header to allocate a Color bit (Section 10.1) and 2245 update the optional TRILL Header Extension Flag Word to allocate 2246 a two-bit Extended Color field (Section 10.2). 2248 7. Some new IANA Considerations in Section 12.2 including 2249 reservation of nicknames for use as examples in documentation. 2251 8. Section 11 on the Appointed Forwarder Status Lost Counter, 2252 loosening mandatory update requirements in [rfc6325]. 2254 9. Informative Appendix A on the Lifecycle of a TRILL Port. 2256 10. Add Appendix B with example TRILL PDUs. 2258 11. Add recommendation to use Purge Originator Identification TLV. 2259 (Section 8.6) 2261 C.1.3 Deletions 2263 The following material was deleted from [RFC7180] in producing this 2264 document: 2266 1. Removal of all updates to [RFC6327] that occurred in [RFC7180]. 2267 These have been rolled into [RFC7177] that obsoletes [RFC6327]. 2268 However, new updates to [RFC7177] are included (see Item 1 in 2269 Section A.1). 2271 2. Removal of all updates to [RFC6439]. These have been rolled into 2273 [rfc6439bis] that obsoletes [RFC6439]. 2275 C.2 Changes to [RFC6325] 2277 This document contains many normative changes to [RFC6325], some of 2278 which were in [RFC7180] that it replaces, including the following: 2280 1. Change nickname allocation to ignore conflicts with data- 2281 unreachable RBridges. 2283 2. Fix errors: [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] 2284 [Err3508]. 2286 3. Change for the requirement to use the RPF check in [RFC6325] for 2287 multi-destination TRILL Data packets by providing an alternative 2288 stronger RPF check. 2290 4. Adoption of the change of the CFI bit, which was required to be 2291 zero in the inner frame, to the DEI bit which is obtained from 2292 inner frame ingress or creation. 2294 5. Require all RBridge to support E-L1FS FS-LSPs flooding. 2296 6. The variable length TRILL Header extensions area is reduced to one 2297 optional flags word and the extensions length field reduced to one 2298 bit indicated that the flag word is present with the rest of the 2299 length field now reserved. 2301 7. Change the mandatory Appointed Forwarder Status Lost Counter 2302 increment provisions as specified in Section 11. 2304 C.3 Changes to [RFC7177] 2306 All of the updates to [RFC7177] herein are in Section 9. Basically, 2307 this document requires a Scoped Flooding Support TLV [RFC7356] to 2308 appear in all Hellos and that TRILL switches retain in their 2309 adjacency state the information received in that TLV. 2311 C.4 Changes to [RFC7179] 2313 The updates to [RFC7179] herein are in Sections 10.2 and 10.3. 2315 Appendix Z: Change History 2317 This appendix lists version changes in this document. 2319 RFC Ediotr: Please delete this Appendix before publicaton. 2321 From -00 to -01: 2323 1. Expand Appendix C to cover changes to RFC 6325, RFC 7177, and RFC 2324 7179 as well as 7180 and add material to the Introduction on 2325 changes or previous RFCs. 2327 2. Add a paragraph just before the Section 8.1.1 header about the 2328 uses of E-L1FS FS-LSPs, the size limit on E-L1FS fragment zero, 2329 and handling of TRILL GENINFO TLVs. 2331 3. At the end of Section 9, add item 5 updating Table 4 in [RFC7177]. 2333 4. In Section 12.2.3, add a Registry for NickFlags bits. 2335 5. Add Section 12.2.6 assigning nicknames for use as examples in 2336 documentation. 2338 6. Small improvements to the Security Considerations section. 2340 7. Augment and update references. 2342 8. Add a bit to Appendix A and add a lot to Appendix B. 2344 9. Minor editorial changes. 2346 From -01 to -02 2348 1. Add Section 8.6 on Purge Originator Identification TLV. 2350 2. Update reference to IEEE Std 802. 2352 3. Move Acknowledgements after References as this is now the RFC 2353 Editor preference. 2355 4. Numerous editorial fixes. 2357 From -02 to -03 2359 Updated for Shepherd comments. No technical change. 2361 From -03 to -04 2363 Update reference to draft-ietf-trill-oam-fm to be to [RFC7455]. 2365 From -04 to -05 2367 Fix typo at the beginning of Section 10 based on RTG Directorate 2368 review. 2370 From -05 to -06 2372 Changes based on AD Review: 2374 1. Move former Appendix C to be the new Section 11, renumbering 2375 following sections and making corresponding updates. 2377 2. Several editorial improvements. 2379 From -06 to -07 2381 Changes based on IESG review (which included GENART and SECDIR 2382 reviews). 2384 Authors' Addresses 2386 Donald Eastlake 3rd 2387 Huawei Technology 2388 155 Beaver Street 2389 Milford, MA 01757 USA 2391 Phone: +1-508-333-2270 2392 EMail: d3e3e3@gmail.com 2394 Mingui Zhang 2395 Huawei Technologies 2396 No. 156 Beiqing Rd. Haidian District, 2397 Beijing 100095 2398 P.R. China 2400 EMail: zhangmingui@huawei.com 2402 Radia Perlman 2403 EMC 2404 2010 256th Avenue NE, #200 2405 Bellevue, WA 98007 USA 2407 EMail: radia@alum.mit.edu 2409 Ayan Banerjee 2410 Cisco 2412 EMail: ayabaner@cisco.com 2414 Anoop Ghanwani 2415 Dell 2416 5450 Great America Parkway 2417 Santa Clara, CA 95054 USA 2419 EMail: anoop@alumni.duke.edu 2421 Sujay Gupta 2422 IP Infusion, 2423 RMZ Centennial 2424 Mahadevapura Post 2425 Bangalore - 560048 India 2427 EMail: sujay.gupta@ipinfusion.com 2429 Copyright and IPR Provisions 2431 Copyright (c) 2015 IETF Trust and the persons identified as the 2432 document authors. All rights reserved. 2434 This document is subject to BCP 78 and the IETF Trust's Legal 2435 Provisions Relating to IETF Documents 2436 (http://trustee.ietf.org/license-info) in effect on the date of 2437 publication of this document. Please review these documents 2438 carefully, as they describe your rights and restrictions with respect 2439 to this document. Code Components extracted from this document must 2440 include Simplified BSD License text as described in Section 4.e of 2441 the Trust Legal Provisions and are provided without warranty as 2442 described in the Simplified BSD License.