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