idnits 2.17.00 (12 Aug 2021) /tmp/idnits459/draft-ietf-trill-rfc6327bis-04.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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 10, 2014) is 3046 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' == Outdated reference: draft-ietf-trill-rbridge-bfd has been published as RFC 7175 == Outdated reference: draft-ietf-trill-rbridge-channel has been published as RFC 7178 == Outdated reference: draft-ietf-trill-clear-correct has been published as RFC 7180 == Outdated reference: draft-ietf-isis-rfc6326bis has been published as RFC 7176 -- Obsolete informational reference (is this intentional?): RFC 6327 (Obsoleted by RFC 7177) -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) == Outdated reference: draft-ietf-trill-fine-labeling has been published as RFC 7172 == Outdated reference: draft-ietf-trill-esadi has been published as RFC 7357 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Obsoletes: 6327 Radia Perlman 4 Updates: 6325 Intel Labs 5 Intended status: Proposed Standard Anoop Ghanwani 6 Dell 7 Howard Yang 8 Cisco 9 Vishwas Manral 10 HP 11 Expires: July 9, 2014 January 10, 2014 13 TRILL: Adjacency 14 16 Abstract 18 The IETF TRILL (TRansparent Interconnection of Lots of Links) 19 protocol supports arbitrary link technologies between TRILL switches 20 including point-to-point links and multi-access LAN (Local Area 21 Network) links that can have multiple TRILL switches and end stations 22 attached. TRILL uses IS-IS (Intermediate System to Intermediate 23 System) routing. This document specifies the establishment, 24 reporting, and termination of IS-IS adjacencies between TRILL 25 switches, also known as RBridges. It also concerns four other link- 26 local aspects of TRILL: Designated RBridge (DRB) selection, MTU 27 (Maximum Transmission Unit) testing, pseudonode creation, and BFD 28 (Bi-Directional Forwarding Detection) session bootstrapping in 29 connection with adjacency. State diagrams are included where 30 appropriate. This document obsoletes RFC 6327 and updates RFC 6325. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Distribution of this document is unlimited. Comments should be sent 38 to the TRILL working group mailing list. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 51 Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Table of Contents 56 1. Introduction............................................4 57 1.1 Content and Precedence.................................5 58 1.2 Terminology and Acronyms...............................5 60 2. The TRILL Hello Environment and Purposes................6 61 2.1 RBridge Interconnection by Ethernet....................6 62 2.2 Handling Native Frames.................................7 63 2.3 Zero or Minimal Configuration..........................8 64 2.4 MTU Robustness.........................................8 65 2.5 Purposes of the TRILL Hello Protocol...................8 67 3. Adjacency State Machinery..............................10 68 3.1 TRILL Hellos, Ports, and VLANs........................10 69 3.2 Adjacency Table Entries and States....................11 70 3.3 Adjacency and Hello Events............................12 71 3.4 Adjacency State Diagram and Table.....................15 72 3.5 Multiple Parallel Links...............................16 73 3.6 Insufficient Space in Adjacency Table.................17 75 4. LAN Ports and DRB State................................18 76 4.1 Port Table Entries and DRB Election State.............18 77 4.2 DRB Election Events...................................19 78 4.2.1 DRB Election Details................................20 79 4.2.2 Change in DRB.......................................20 80 4.2.3 Change in Designated VLAN...........................21 81 4.3 State Table and Diagram...............................21 83 5. MTU Matching...........................................23 84 6. BFD Enabled and BFD Session Bootstrap..................25 85 7. Pseudonodes............................................27 87 8. More TRILL Hello Details...............................28 88 8.1 Contents of TRILL Hellos..............................28 89 8.2 Transmitting TRILL Hellos.............................29 90 8.2.1 TRILL Neighbor TLVs.................................29 91 8.3 Receiving TRILL Hellos................................30 93 9. Multiple Ports on the Same Broadcast Link..............32 95 10. Security Considerations...............................33 96 11. IANA Considerations...................................33 98 Appendix A: Changes from [RFC6327]........................34 99 Appendix B: Changes to [RFC6325]..........................35 100 Appendix Z: Change History................................36 101 Normative References......................................37 102 Informative References....................................37 103 Acknowledgements..........................................39 104 Authors' Addresses........................................40 106 1. Introduction 108 The IETF TRILL (TRansparent Interconnection of Lots of Links) 109 protocol [RFC6325] provides optimal pair-wise data frame forwarding 110 without configuration, safe forwarding even during transient loops, 111 and support for transmission of both unicast and multicast traffic 112 taking advantage of multiple paths in multi-hop networks with 113 arbitrary topology. End stations are connected to TRILL switches 114 with Ethernet but TRILL switches can be interconnected with arbitrary 115 link technology. TRILL accomplishes this by using [IS-IS] 116 (Intermediate System to Intermediate System) link state routing 117 [RFC1195] [RFC6326bis] and a header in TRILL data packets that 118 includes a hop count. The design supports data labeling by VLANs 119 (Virtual Local Area Networks) and fine grained labels [RFCfgl] as 120 well as optimization of the distribution of multi-destination frames 121 based on data label and multicast groups. Devices that implement 122 TRILL are called TRILL switches or RBridges (Routing Bridges). 124 This document provides detailed specification for five of the link- 125 local aspects of the TRILL protocol used on broadcast links (also 126 called LAN or multi-access links), and for the three of these aspects 127 used on point-to-point links. It includes state diagrams and 128 implementation details where appropriate. Alternative 129 implementations that interoperate on the wire are permitted. 131 The scope of this document is limited to the following aspects of the 132 TRILL protocol with applicability and the most relevant section of 133 this document as shown: 135 LAN P2P Section Link-Local Aspect 136 --- --- ------- ----------------- 138 X X 3 Adjacency formation and dissolution 139 X 4 DRB (Designated RBridge) election 140 X X 5 MTU (Maximum Transmission Unit) matching 141 X X 6 1-hop BFD (Bi-directional Forwarding Detection) 142 for adjacency 143 X 7 Creation and use of pseudonodes [IS-IS] 145 Table 1. LAN/P2P Applicability 147 There is no DRB (also known as DIS (Designated Intermediate System)) 148 election and no pseudonode creation on links configured as point-to- 149 point. 151 For other aspects of the TRILL protocol, see other documents such as 152 [RFC6325], [RFC6439], [RFCclear], and [ESADI]. 154 This document obsoletes [RFC6327]. See Appendix A for a summary of 155 changes from [RFC6327]. This document updates [RFC6325] as described 156 in Appendix B. 158 1.1 Content and Precedence 160 In case of conflict between this document and [RFC6325], this 161 document prevails. 163 Section 2 below explains the rationale for the differences between 164 the TRILL Hello protocol and the Layer 3 IS-IS Hello protocol in 165 light of the environment for which the TRILL protocol is designed. 166 It also describes the purposes of the TRILL Hello protocol. 168 Section 3 describes the adjacency state machine, its states, and its 169 relevant events. 171 Section 4 describes the Designated RBridge (DRB) election state 172 machine for RBridge LAN ports, its states, and its relevant events. 174 Section 5 describes MTU testing and matching on a TRILL link. 176 Section 6 discusses one-hop BFD session bootstrapping in connection 177 with adjacency. 179 Section 7 discusses pseudonode creation and use on LAN links. 181 Section 8 provides more details on the reception and transmission of 182 TRILL Hellos. 184 Section 9 discusses the case of multiple ports from one RBridge on 185 the same link. 187 1.2 Terminology and Acronyms 189 This document uses the acronyms defined in [RFC6325] supplemented by 190 the following additional acronyms: 192 BFD - Bi-directional Forwarding Detection [RFCbfd]. 194 SNPA - Subnetwork Point of Attachment [IS-IS]. 196 TRILL switch - an alternative name for an RBridge. 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 2. The TRILL Hello Environment and Purposes 204 [IS-IS] has subnetwork-independent functions and subnetwork-dependent 205 functions. Currently, Layer 3 use of IS-IS supports two types of 206 subnetworks: (1) point-to-point link subnetworks between routers and 207 (2) general broadcast (LAN) subnetworks. Because of the differences 208 between the environment of Layer 3 routers and the environment of 209 TRILL RBridges, instead of the subnetwork-dependent functions used at 210 Layer 3, which are specified in [IS-IS] Sections 8.2 and 8.4, the 211 TRILL protocol uses modified subnetwork-dependent functions for 212 point-to-point subnetworks and broadcast (LAN) subnetworks. The 213 differences between the TRILL and Layer 3 environments are described 214 in Sections 2.1 through 2.4 followed by a summation, in Section 2.5, 215 of the purposes of the TRILL Hello protocol. 217 2.1 RBridge Interconnection by Ethernet 219 TRILL supports the interconnection of RBridges by multi-access LAN 220 links such as Ethernet. Because this includes general bridged LANs 221 [802.1Q], the links between RBridges may contain devices or services 222 that can restrict VLAN connectivity, such as [802.1Q] bridges or 223 carrier Ethernet services. In addition, RBridge Ethernet ports, like 224 [802.1Q] ports, can be configured to restrict input/output on a VLAN 225 basis. 227 For this reason TRILL Data and TRILL IS-IS packets are sent on 228 Ethernet links in a Designated VLAN that is assumed to provide 229 connectivity between all RBridges on the link. The Designated VLAN 230 is dictated for a LAN link by the elected Designated RBridge on that 231 link (DRB, equivalent to the Designated Intermediate System at Layer 232 3). On an RBridge Ethernet port configured as point-to-point, TRILL 233 Data and IS-IS packets are sent in that port's Desired Designated 234 VLAN regardless of the state of any other ports on the link. 235 Connectivity on an Ethernet link configured as point-to-point 236 generally depends on both ends being configured with the same Desired 237 Designated VLAN. Because TRILL Data packets flow between RBridges on 238 an Ethernet link only in the link's Designated VLAN, adjacency for 239 routing calculations is based only on connectivity characteristics in 240 that VLAN. 242 (Non-Ethernet links, such as PPP [RFC6361] generally do not have any 243 Outer.VLAN labeling so the Designated VLAN for such links has no 244 effect.) 246 2.2 Handling Native Frames 248 This section discusses the handling of "native" frames as defined in 249 Section 1.4 of [RFC6325]. As such, this section is not applicable to 250 point-to-point links between TRILL switches or any link where all the 251 TRILL switch ports on the link have been configured as "trunk ports" 252 by setting the end-station service disable bit for the port (see 253 Section 4.9.1 of [RFC6325]). 255 Layer 3 data packets, such as IP packets, are already "tamed" when 256 they are originated by an end station: they include a hop count and 257 Layer 3 source and destination address fields. Furthermore, for 258 ordinary data packets, there is no requirement to preserve any outer 259 Layer 2 addressing and, if the packets are unicast, they are 260 explicitly addressed to their first hop router. 262 In contrast, TRILL switches must accept, transport, and deliver 263 "untamed" native frames: Native frames that lack a hop count field 264 usable by TRILL and have Layer 2 MAC addresses that indicate their 265 source and destination. These Layer 2 addresses must be preserved 266 for delivery to the native frame's Layer 2 destination. One 267 resulting difference is that RBridge ports providing native frame 268 service must receive in promiscuous MAC (Media Access Control) 269 address mode, while Layer 3 router ports typically receive in a 270 selective MAC address mode. 272 TRILL handles these requirements by having, on the link where an end 273 station originates a native frame, one RBridge "ingress" such a 274 locally originated native frame by adding a TRILL Header that 275 includes a hop count, thus converting it to a TRILL Data packet. 276 This augmented packet is then routed to one RBridge on the link 277 having the destination end station for the frame (or one RBridge on 278 each such link if it is a multi-destination frame). Such final 279 RBridges perform an "egress" function, removing the TRILL Header and 280 delivering the original frame to its destination(s). (For the 281 purposes of TRILL, a Layer 3 router is an end station.) 283 Care must be taken to avoid a loop that would involve egressing a 284 native frame and then re-ingressing it because, while it is in native 285 form, it would not be protected by a hop count and could loop 286 forever. Such a loop could even, for multi-destination frames, 287 involve multiplication of the number of frames each time around and 288 would likely saturate all links involved within milliseconds. For 289 TRILL, safety against such loops for a link is more important than 290 transient loss of data connectivity on that link. 292 The primary TRILL defense mechanism against such loops, which is 293 mandatory, is to assure that, as far as practically possible, there 294 is only a single RBridge that is in charge of ingressing and 295 egressing native frames from and to a link where TRILL is offering 296 end station service. This is the Designated RBridge and appointed 297 forwarder mechanism initially specified in the TRILL base protocol 298 [RFC6325], discussed in Section 2.5 below, and further specified both 299 in Section 4 below and [RFC6439]. 301 2.3 Zero or Minimal Configuration 303 TRILL provides connectivity and least cost paths with zero 304 configuration. For additional services, it strives to require only 305 minimal configuration; however, services that require configuration 306 when offered by [802.1Q] bridges, such as non-default VLAN or 307 priority, will require configuration. This differs from Layer 3 308 routing where routers typically need to be configured as to the 309 subnetworks connected to each port, etc., to provide service. 311 2.4 MTU Robustness 313 TRILL IS-IS needs to be robust against links with reasonably 314 restricted MTUs, including links that accommodate only the classic 315 Ethernet frame size, despite the addition of reasonable headers such 316 as VLAN tags. Such robustness is particularly required for TRILL 317 Hellos to assure correct adjacency and the election of a unique DRB 318 on LAN links. 320 TRILL will also be used inside data centers where it is common for 321 all or most of the links and switches to support frames substantially 322 larger than the classic Ethernet maximum size. For example, they may 323 have an MTU adequate to comfortably handle Fiber Channel over 324 Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE], or 325 even 9K byte jumbo frames. It would be beneficial for a TRILL campus 326 with such a large MTU to be able to safely make use of it. 328 These needs are met by a mandatory maximum on the size of TRILL 329 Hellos and by the optional use of MTU testing as described below. 331 2.5 Purposes of the TRILL Hello Protocol 333 There are three purposes for the TRILL Hello protocol. They are 334 listed below along with a reference to the section of this document 335 in which each is discussed: 337 a) To determine which RBridge neighbors have acceptable connectivity 338 to be reported as part of the topology (Section 3) 340 b) To elect a unique Designated RBridge on broadcast (LAN) links 341 (Section 4) 343 c) To determine the MTU with which it is possible to safely 344 communicate with each RBridge neighbor (Section 5) 346 In Layer 3 IS-IS, all three of these functions are combined. Hellos 347 may be padded to the maximum length (see [RFC3719], Section 6) so 348 that a router neighbor is not even discovered if it is impossible to 349 communicate with it using maximum-sized Layer 3 IS-IS packets. Also, 350 even if Hellos from a neighbor R2 are received by R1, if connectivity 351 to R2 is not 2-way (i.e., R2 does not list R1 in R2's Hello), then R1 352 does not consider R2 as a Designated Intermediate System (Designated 353 Router) candidate. Because of this logic, it is possible at Layer 3 354 for multiple Designated Routers to be elected on a LAN, with each 355 representing the LAN as a pseudonode. It appears to the topology as 356 if the LAN is now two or more separate LANs. Although this is 357 surprising, this does not cause problems for Layer 3. 359 In contrast, this behavior is not acceptable for TRILL, since in 360 TRILL it is important that all RBridges on a link know about each 361 other, and on broadcast (LAN) links that they choose a single RBridge 362 to be the DRB to control the native frame ingress and egress. 363 Otherwise, multiple RBridges might ingress/egress the same native 364 frame, forming loops that are not protected by the hop count in the 365 TRILL header as discussed above. 367 The TRILL Hello protocol is best understood by focusing separately on 368 each of these three functions listed above which we do in Sections 3, 369 4, and 5. 371 One other issue with TRILL LAN Hellos is to ensure that subsets of 372 the information can appear in any single message, and be processable, 373 in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence 374 Number PDUs (CSNPs). LAN TRILL Hello packets, even though they are 375 not padded, can become very large. An example where this might be 376 the case is when some sort of backbone technology interconnects 377 hundreds of TRILL sites over what would appear to TRILL to be a giant 378 Ethernet, where the RBridges connected to that cloud will perceive 379 that backbone to be a single link with hundreds of neighbors. Thus, 380 the TRILL LAN Hello uses a different Neighbor TLV [RFC6326bis] that 381 lists neighbors seen for a range of MAC (SNPA) addresses. 383 3. Adjacency State Machinery 385 Each RBridge port has associated with it a port state, as discussed 386 in Section 4, and a table of zero or more adjacencies (if the port is 387 configured as point-to-point, zero or one) as discussed in this 388 section. The states such adjacencies can have, the events that cause 389 adjacency state changes, the actions associated with those state 390 changes, a state table, and a state diagram are given below. 392 3.1 TRILL Hellos, Ports, and VLANs 394 The determination of adjacencies on links is made using TRILL Hellos 395 (see Section 8), an optional MTU test (see Section 5), and optionally 396 BFD (see Section 6) and/or other connectivity tests. If the MAC 397 (SNPA) address of more than one RBridge port on a broadcast link are 398 the same, all but one of such ports are put in the Suspended state 399 (see Section 4) and do not participate in the link except to monitor 400 whether they should stay suspended. If the two ports on a point-to- 401 point link have MAC (SNPA) addresses it does not affect TRILL 402 operation if they are the same. (PPP ports, for example, do not have 403 MAC addresses [RFC6361].) 405 The following items MUST be the same for all TRILL Hellos issued by 406 an RBridge on a particular Ethernet port regardless of the VLAN in 407 which the Hello is sent: 409 - Source MAC address, 410 - Priority to be DRB, 411 - Desired Designated VLAN, 412 - Port ID, and, 413 - if included, BFD Enabled TLV [RFC6213] and PORT-TRILL-VER sub- 414 TLV [RFC6326bis]. 416 Of course, the priority, Desired Designated VLAN, and possibly the 417 inclusion or value of the PORT-TRILL-VER sub-TLV, and/or BFD Enabled 418 TLV can change on occasion, but then the new value(s) must similarly 419 be used in all TRILL Hellos on the LAN port, regardless of VLAN. 421 On broadcast links: 423 Because bridges acting as glue on an Ethernet broadcast link might 424 be configured in such a way that some VLANs are partitioned, it is 425 necessary for RBridges to transmit Hellos on Ethernet links with 426 multiple VLAN tags. The conceptually simplest solution may have 427 been to have RBridges transmit up to 4,094 times as many Hellos, 428 one with each legal VLAN ID enabled at each port, but this would 429 obviously have deleterious performance implications. So, the 430 TRILL protocol specifies that if RB1 knows it is not the DRB, it 431 transmits its Hellos on only a limited set of VLANs. Only an 432 RBridge that believes itself to be the DRB on a broadcast Ethernet 433 link "sprays" its TRILL Hellos on all of its enabled VLANs at the 434 port. And in both cases, an RBridge can be configured to send 435 Hellos on only a subset of those VLANs. The details are given in 436 [RFC6325], Section 4.4.3. 438 On point-to-point links: 440 If the link technology is VLAN sensitive, such as Ethernet, an 441 RBridge sends TRILL Hellos only in the Desired Designated VLAN for 442 which it is configured. 444 3.2 Adjacency Table Entries and States 446 Each adjacency on broadcast links and the one possible adjacency on 447 each point-to-point link is in one of four states. An RBridge 448 participates in LSP synchronization at a port as long as it has one 449 or more adjacencies out that port that are in the 2-way or Report 450 state. 452 Down: 453 This is a virtual state for convenience in creating state 454 diagrams and tables. It indicates that the adjacency is non- 455 existent, and there is no entry in the adjacency table for it. 457 Detect: 458 A neighbor RBridge has been detected through receipt of a TRILL 459 Hello but either 2-way connectivity has not been confirmed or 460 the detection was on an Ethernet link in a VLAN other than the 461 Designated VLAN. 463 2-Way: 464 2-way connectivity to the neighbor has been found and, if the 465 link is Ethernet, it was found on the Designated VLAN, but some 466 enabled test, such as MTU meeting the minimum campus 467 requirement or BFD confirming connectivity, has not yet 468 succeeded. 470 Report: 471 There is 2-way connectivity to the neighbor (on the Designated 472 VLAN if an Ethernet link) and all enabled tests have succeeded 473 including, if enabled, MTU and/or BFD testing. This state will 474 cause adjacency to be reported in an LSP (with appropriate 475 provision for a pseudonode, if any, as described in Section 7). 477 For an adjacency in any of the three non-Down states (Detect, 2-Way, 478 or Report), there will be an adjacency table entry. That entry will 479 give the state of the adjacency and will also include the information 480 listed below. 482 o The address, if any, of the neighbor, the Port ID, and the 483 System ID in the received Hellos. Together, these three 484 quantities uniquely identify the adjacency on a broadcast link. 486 o For a point-to-point adjacency, there is a single Hello holding 487 timer. For a broadcast LAN adjacency, there are exactly two 488 Hello holding timers: a Designated VLAN holding timer and a 489 non-Designated VLAN holding timer. Each timer consists of a 490 16-bit unsigned integer number of seconds. 492 o If the adjacency is on a broadcast link, the 7-bit unsigned 493 priority of the neighbor to be the DRB. 495 o The 5 bytes of data from the PORT-TRILL-VER received in the 496 most recent TRILL Hello from the neighbor RBridge. 498 o The VLAN that the neighbor RBridge wants to be the Designated 499 VLAN on the link, called the Desired Designated VLAN. 501 o For an adjacency table at an RBridge that supports BFD, a flag 502 indicating whether the last received TRILL Hello from the 503 neighbor RBridge contained a BFD Enabled TLV (see Section 6). 505 3.3 Adjacency and Hello Events 507 The following events can change the state of an adjacency: 509 A0. Receive a TRILL Hello for a broadcast LAN adjacency whose 510 source MAC address (SNPA) is equal to that of the port on 511 which it is received. This is a special event that cannot 512 occur on a port configured as point-to-point and is handled as 513 described immediately after this list of events. It does not 514 appear in the state transition table or diagram. 516 A1. Receive a TRILL Hello (other than an A0 event) such that: 517 - If received on an Ethernet port, it was received in the 518 Designated VLAN. 519 - If received for a broadcast LAN adjacency, it contains a 520 TRILL Neighbor TLV that explicitly lists the receiving 521 port's (SNPA) address. 522 - If received for a point-to-point adjacency, it contains a 523 Three-Way Handshake TLV with the receiver's System ID and 524 Extended Circuit ID. 526 A2. Event A2 is not possible for a port configured as point-to- 527 point. Receive a TRILL Hello (other than an A0 event) such 528 that either 529 - The port is Ethernet and the Hello was not on the 530 Designated VLAN (any TRILL Neighbor TLV in such a Hello is 531 ignored), or 532 - The Hello does not contain a TRILL Neighbor TLV covering an 533 address range that includes the receiver's (SNPA) address. 535 A3. Receive a TRILL Hello (other than an A0 event) such that: 536 - If received on an Ethernet port, it was received in the 537 Designated VLAN. 538 - If received for a broadcast LAN adjacency, it contains one 539 or more TRILL Neighbor TLVs covering an address range that 540 includes the receiver's (SNPA) address and none of which 541 lists the receiver. 542 - If received for a point-to-point adjacency, it contains a 543 Three-Way Handshake TLV with either the System ID or 544 Extended Circuit ID or both not equal to that of the 545 receiver. 547 A4. Either (1) the Hello holding timer expires on a point-to-point 548 adjacency or (2), on a broadcast LAN adjacency, (2a) both 549 Hello timers expire simultaneously or (2b) one Hello timer 550 expires when the other Hello timer is already in the expired 551 state. 553 A5. For a broadcast LAN adjacency, the Designated VLAN Hello 554 holding timer expires, but the non-Designated VLAN Hello 555 holding timer still has time left until it expires. This event 556 cannot occur for a point-to-point adjacency. 558 A6. MTU if enabled, BFD if enabled, and all other enabled 559 connectivity tests successful. 561 A7. MTU if enabled, BFD if enabled, and all other enabled 562 connectivity tests were successful but one or more now fail. 564 A8. The RBridge port goes operationally down. 566 For the special A0 event, the Hello is examined to determine if it 567 has a higher priority than the port on which it is received such that 568 the sending port should be the DRB as described in Section 4.2.1. If 569 the Hello is of lower priority than the receiving port, it is 570 discarded with no further action. If it is of higher priority than 571 the receiving port, then any adjacencies for the receiving port are 572 discarded (transitioned to the Down state), and the port is suspended 573 as described in Section 4.2. 575 The receipt of a TRILL Hello that is not an event A0, causes the 576 following actions (except where the Hello would have created a new 577 adjacency table entry but both the adjacency table is full and the 578 Hello is too low priority to displace an existing entry as described 579 in Section 3.6). The Designated VLAN referred to is the Designated 580 VLAN dictated by the DRB determined without taking the received TRILL 581 LAN Hello into account (see Section 4) for a broadcast LAN and the 582 local Desired Designated VLAN for a port configured as point-to- 583 point. 585 o If the receipt of a Hello creates a new adjacency table entry, 586 the neighbor RBridge MAC (SNPA) address (if any), Port ID, and 587 System ID are set from the Hello. 589 o For a point-to-point adjacency, the Hello holding timer is set 590 from the Holding Time field of the Hello. For a broadcast link 591 adjacency, the appropriate Hello holding timer for that 592 adjacency, depending on whether or not the Hello was received 593 in the Designated VLAN, is set to the Holding Time field of the 594 Hello and if the receipt of the LAN Hello is creating a new 595 adjacency table entry, the other timer is set to expired. 597 o For a broadcast link adjacency, the priority of the neighbor 598 RBridge to be the DRB is set to the priority field of the LAN 599 Hello. 601 o For a broadcast link adjacency, the VLAN that the neighbor 602 RBridge wants to be the Designated VLAN on the link is set from 603 the Hello. 605 o The five bytes of PORT-TRILL-VER data are set from that sub-TLV 606 in the Hello or set to zero if that sub-TLV does not occur in 607 the Hello. 609 o For a broadcast link, if the creation of a new adjacency table 610 entry or the priority update above changes the results of the 611 DRB election on the link, the appropriate RBridge port event 612 (D2 or D3) occurs, after the above actions, as described in 613 Section 4.2. 615 o For a broadcast link adjacency, if there is no change in the 616 DRB, but the neighbor Hello is from the DRB and has a changed 617 Designated VLAN from the previous Hello received from the DRB, 618 the result is a change in Designated VLAN for the link as 619 specified in Section 4.2.3. 621 An event A4 resulting in the adjacency transitioning to the Down 622 state may also result in an event D3 as described in Section 4.2. 624 Concerning events A6 and A7, if none of MTU, BFD, or other testing is 625 enabled, A6 is considered to occur immediately upon the adjacency 626 entering the 2-Way state, and A7 cannot occur. 628 See further TRILL Hello receipt details in Section 7. 630 3.4 Adjacency State Diagram and Table 632 The table below shows the transitions between the states defined 633 above based on the events defined above: 635 | Event | Down | Detect | 2-Way | Report | 636 +-------+--------+--------+--------+--------+ 637 | A1 | 2-Way | 2-Way | 2-Way | Report | 638 | A2 | Detect | Detect | 2-Way | Report | 639 | A3 | Detect | Detect | Detect | Detect | 640 | A4 | N/A | Down | Down | Down | 641 | A5 | N/A | Detect | Detect | Detect | 642 | A6 | N/A | N/A | Report | Report | 643 | A7 | N/A | N/A | 2-Way | 2-Way | 644 | A8 | Down | Down | Down | Down | 646 Table 2. Adjacency State Table 648 N/A indicates that the event to the left is Not Applicable in the 649 state at the top of the column. These events affect only a single 650 adjacency. The special A0 event transitions all adjacencies to Down, 651 as explained immediately after the list of adjacency events above. 653 The diagram below presents the same information as that in the state 654 table: 656 +---------------+ 657 | Down |<--------+ 658 +---------------+ | 659 | | ^ | | 660 A2,A3| |A8| |A1 | 661 | +--+ | | 662 | +-----------|---+ 663 V | | 664 +----------------+ A4,A8 | | 665 +----->| Detect |------->| | 666 | +----------------+ | | 667 | | | ^ | | 668 | A1| |A2,A3,A5 | | | 669 | | +---------+ | | 670 | | | | 671 | | +------------|---+ 672 | | | | 673 | V V | 674 |A3,A5 +----------------+ A4,A8 | 675 |<-----| 2-Way |------->| 676 | +----------------+ | 677 | | ^ | ^ | 678 | A6| | |A1,A2,A7| | 679 | | | +--------+ | 680 | | | | 681 | | |A7 | 682 | V | | 683 |A3,A5 +-------------+ A4,A8 | 684 |<-----| Report |---------->| 685 +-------------+ 686 | ^ 687 |A1,A2,A6 | 688 +---------+ 690 Figure 1. Adjacency State Diagram 692 3.5 Multiple Parallel Links 694 There can be multiple parallel adjacencies between neighbor RBridges 695 that are visible to TRILL. (Multiple low-level links that have been 696 bonded together by technologies such as link aggregation [802.1AX] 697 appear to TRILL as a single link over which only a single TRILL 698 adjacency can be established.) 700 Any such links that have pseudonodes (see Section 7) are 701 distinguished in the topology; such adjacencies, if they are in the 702 Report state, appear in LSPs as per Section 7. However, there can be 703 multiple parallel adjacencies without pseudonodes because they are 704 point-to-point adjacencies or LAN adjacencies for which a pseudonode 705 is not being created. Such parallel, non-pseudonode adjacencies in 706 the Report state appear in LSPs as a single adjacency. The cost of 707 such an adjacency MAY be adjusted downwards to account for the 708 parallel paths. Multipathing across such parallel connections can be 709 freely done for unicast TRILL Data traffic on a per-flow basis but is 710 restricted for multi-destination traffic, as described in Section 711 4.5.2 (point 3) and Appendix C of [RFC6325]. 713 3.6 Insufficient Space in Adjacency Table 715 If the receipt of a TRILL Hello would create a new adjacency table 716 entry (that is, would transition an adjacency out of the Down state), 717 there may be no space for the new entry. It is RECOMMENDED, for 718 ports configured as point-to-point and which can thus only have zero 719 or one adjacency not in the Down state, to reserved space for one 720 adjacency so that this condition cannot occur. 722 When there is adjacency table space exhaustion, the DRB election 723 priority (see Section 4.2.1) of the new entry that would be created 724 is compared with that priority for the existing entries. If the new 725 entry is higher priority than the lowest priority existing entry, it 726 replaces the lowest priority existing entry, which is transitioned to 727 the Down state. 729 4. LAN Ports and DRB State 731 This section specifies the DRB election process in TRILL at a 732 broadcast (LAN) link port. Since there is no such election when a 733 port is configured as point-to-point, this section does not apply in 734 that case. 736 The information at an RBridge associated with each of its broadcast 737 LAN ports includes the following: 739 o Enablement bit, which defaults to enabled. 741 o The five bytes of PORT-TRILL-VER sub-TLV data used in TRILL 742 Hellos sent on the port. 744 o SNPA address (commonly a 48-bit MAC address) of the port. 746 o Port ID, used in TRILL Hellos sent on the port. 748 o The Holding Time, used in TRILL Hellos sent on the port. 750 o The Priority to be the DRB, used in TRILL LAN Hellos sent on 751 the port. 753 o If the port supports BFD, a BFD enabled flag that controls 754 whether or not a BFD Enabled TLV is included in TRILL Hellos 755 sent on the port. 757 o The DRB state of the port, determined as specified below. 759 o A 16-bit unsigned Suspension timer, measured in seconds. 761 o The desired Designated VLAN. The VLAN this RBridge wants to be 762 the Designated VLAN for the link out this port, used in TRILL 763 Hellos sent on the port if the link is Ethernet. 765 o A table of zero or more adjacencies (see Section 3). 767 4.1 Port Table Entries and DRB Election State 769 The TRILL equivalent of the DIS (Designated Intermediate System) on a 770 broadcast link is the DRB or Designated RBridge. The DRB election 771 state machinery is described below. 773 Each RBridge port that is not configured as point-to-point is in one 774 of the following four DRB states: 776 Down: 777 The port is operationally down. It might be administratively 778 disabled or down at the link layer. In this state, there will 779 be no adjacencies for the port, and no TRILL Hellos or other 780 TRILL IS-IS PDUs or TRILL Data packets are accepted or 781 transmitted. 783 Suspended: 784 Operation of the port is suspended because there is a higher 785 priority port on the link with the same MAC (SNPA) address. 786 This is the same as the down state with the exception that 787 TRILL Hellos are accepted for the sole purpose of determining 788 whether to change the value of the Suspension timer for the 789 port as described below. 791 DRB: 792 The port is the DRB and can receive and transmit TRILL Data 793 packets. 795 Not DRB: 796 The port is deferring to another port on the link, which it 797 believes is the DRB, but can still receive and transmit TRILL 798 Data packets. 800 4.2 DRB Election Events 802 The following events can change the DRB state of a port. Note that 803 this is only applicable to broadcast links. There is no DRB state or 804 election at a port configured to be point-to-point. 806 D1. Expiration of the suspension timer while the port is in the 807 Suspended state or the enablement of the port. 809 D2. The adjacency table for the port changes and there are now 810 entries for one or more other RBridge ports on the link that 811 appear to be higher priority to be the DRB than the local 812 port. 814 D3. The port is not Down or Suspended, and the adjacency table for 815 the port changes, so there are now no entries for other 816 RBridge ports on the link that appear to be higher priority to 817 be the DRB than the local port. 819 D4. Receipt of a TRILL LAN Hello with the same MAC address (SNPA) 820 as the receiving port and higher priority to be the DRB as 821 described for event A0. 823 D5. The port becomes operationally down. 825 Event D1 is considered to occur on RBridge boot if the port is 826 administratively and link-layer enabled. 828 Event D4 causes the port to enter the Suspended state and all 829 adjacencies for the port to be discarded (transitioned to the Down 830 state). If the port was in some state other than Suspended, the 831 suspension timer is set to the Holding Time in the Hello that causes 832 event D4. If it was in the Suspended state, the suspension timer is 833 set to the maximum of its current value and the Holding Time in the 834 Hello that causes event D4. 836 4.2.1 DRB Election Details 838 Events D2 and D3 constitute losing and winning the DRB election at 839 the port, respectively. 841 The candidates for election are the local RBridge and all RBridges 842 with which there is an adjacency on the port in an adjacency state 843 other than Down state. The winner is the RBridge with highest 844 priority to be the DRB, as determined from the 7-bit priority field 845 in that RBridge's Hellos received and the local port's priority to be 846 the DRB field, with MAC (SNPA) address as a tiebreaker, Port ID as a 847 secondary tiebreaker, and System ID as a tertiary tiebreaker. These 848 fields are compared as unsigned integers with the larger magnitude 849 being considered higher priority. 851 Resort to the secondary and tertiary tiebreakers should only be 852 necessary in rare circumstances when multiple ports have the same 853 priority and MAC (SNPA) address and some of them are not yet 854 suspended. For example, RB1, that has low priority to be the DRB on 855 the link, could receive Hellos from two other ports on the link that 856 have the same MAC address as each other and are higher priority to be 857 the DRB. One of these two ports with the same MAC address will be 858 suspended, cease sending Hellos, and the Hello from it received by 859 RB1 will eventually time out. But, in the meantime, RB1 can use the 860 tiebreakers to determine which port is the DRB and thus which port's 861 Hello to believe for such purposes as setting the Designated VLAN on 862 the link. 864 4.2.2 Change in DRB 866 Events D2 and D3 result from a change in the apparent DRB on the 867 link. Unnecessary DRB changes should be avoided, especially on links 868 offering native frame service, as a DRB change will generally cause a 869 transient interruption to native frame service. 871 If a change in the DRB on the link changes the Designated VLAN on an 872 Ethernet link, the actions specified in Section 4.2.3 are taken. 874 If an RBridge changes in either direction between being the DRB and 875 not being the DRB at a port, this will generally change the VLANs on 876 which that RBridge sends Hellos through that port, as specified in 877 Section 4.4.3 of [RFC6325]. 879 4.2.3 Change in Designated VLAN 881 Unnecessary changes in the Designated VLAN on an Ethernet link should 882 be avoided because a change in the Designated VLAN can cause a 883 transient interruption to adjacency and thus to TRILL Data forwarding 884 on the link. When practical, all RBridge ports on a link should be 885 configured with the same Desired Designated VLAN so that, in case the 886 winner of the DRB election changes, for any reason, the Designated 887 VLAN will remain the same. 889 If an RBridge detects a change in Designated VLAN on an Ethernet 890 link, then, for all adjacency table entries for a port to that link, 891 the RBridge takes the following steps in the order given. 893 o The non-Designated VLAN Hello Holding timer is set to the 894 maximum of its time to expiration and the current time to 895 expiration of the Designated VLAN Hello Holding timer. 897 o The Designated VLAN Hello Holding timer is then set to expired 898 (if necessary), and an event A5 occurs for the adjacency (see 899 Section 3.3). 901 If the Designated VLAN for a link changes, this will generally change 902 the VLANs on which Hellos are sent by an RBridge port on that link as 903 specified in Section 4.4.3 of [RFC6325]. 905 4.3 State Table and Diagram 907 The table below shows the transitions between the DRB states defined 908 above based on the events defined above: 910 | Event | Down | Suspend | DRB | Not DRB | 911 +-------+--------+---------+---------+---------+ 912 | D1 | DRB | DRB | N/A | N/A | 913 | D2 | N/A | N/A | Not DRB | Not DRB | 914 | D3 | N/A | N/A | DRB | DRB | 915 | D4 | N/A | Suspend | Suspend | Suspend | 916 | D5 | Down | Down | Down | Down | 918 Table 3. Port State Table 920 N/A indicates that the event to the left is Not Applicable in the 921 state at the top of the column. 923 The diagram below presents the same information as in the state 924 table: 926 +-------------+ 927 | Down |<--------------+ 928 +-+---+-------+ ^ | 929 | | ^ | | 930 D1| |D5 | | | 931 | +---+ |D5 | 932 | | | 933 | +--------+----+ | 934 | | Suspended |<---|---+ 935 | +-+-----+-----+ | | 936 | D1| ^ | ^ | | 937 | | | |D4 | | | 938 | | | +---+ | | 939 | | | | | 940 | | |D4 | | 941 V V | | | 942 +---------------+-+ D5 | | 943 | DRB |---------->| | 944 +--------+--+-----+ | | 945 ^ | | ^ | | 946 | D2| |D3| | | 947 | | +--+ | | 948 | | D4 | | 949 |D3 | +-----------------|---+ 950 | V | | 951 +----+-------+-+ D5 | 952 | Not DRB |-------------->| 953 +----+---------+ 954 | ^ 955 |D2 | 956 +----+ 958 Figure 2. Port State Diagram 960 5. MTU Matching 962 The purpose of MTU testing is to ensure that the links used in the 963 campus topology can pass TRILL IS-IS packets, particularly LSP PDUs, 964 at the TRILL campus MTU. The LSP PDUs generated at a TRILL switch 965 could, as part of the flooding process, be sent over any adjacency in 966 the campus. To assure correct operation of IS-IS, an LSP PDU must be 967 able to reach every RBridge in the IS-IS reachable campus, which 968 might be impossible if the PDU exceeded the MTU of an adjacency that 969 was part of the campus topology. 971 An RBridge, RB1, determines the desired campus link MTU by 972 calculating the minimum of its originatingL1LSPBufferSize and the 973 originatingL1LSPBufferSize of other RBridges in the campus, as 974 advertised in the link state database, but not less than 1,470 bytes. 975 Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to 976 the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the 977 range 1,470 to 65,535 bytes inclusive. (See Section 5 of [RFCclear].) 979 Although MTU testing is optional, it is mandatory for an RBridge to 980 respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] 981 [RFC6326bis]. Use of multicast or unicast for MTU-probe and MTU-ack 982 is an implementation choice. However, the burden on the link is 983 generally minimized by the following: (1) multicasting MTU-probes 984 when a response from all other RBridges on the link is desired, such 985 as when initializing or re-confirming MTU, (2) unicasting MTU-probes 986 when a response from a single RBridge is desired, such as one that 987 has just been detected on the link, and (3) unicasting all MTU-ack 988 packets. 990 RB1 can test the MTU size to RB2 as described in Section 4.3.2 of 991 [RFC6325]. For this purpose, MTU testing is only done in the 992 Designated VLAN. An adjacency that fails the MTU test at the campus 993 MTU will not enter the Report state or, if the adjacency is in that 994 state, it leaves that state. Thus, an adjacency failing the MTU test 995 at the campus minimum MTU will not be reported by the RBridge 996 performing the test. Since inclusion in least-cost route computation 997 requires the adjacency to be reported by both ends, as long as the 998 RBridge at either end of the adjacency notices the MTU failure, it 999 will not be so used. 1001 If it tests MTU size, RB1 reports the largest size for which the MTU 1002 test succeeds or a flag indicating that it fails at the campus MTU. 1003 This report always appears with the neighbor in RB1's TRILL Neighbor 1004 TLV. RB1 MAY also report this with the adjacency in an Extended 1005 Reachability TLV in RB1's LSP. RB1 MAY choose to test MTU sizes 1006 greater than the desired campus MTU as well as the desired campus 1007 MTU. 1009 Most types of TRILL IS-IS packets, such as LSPs, can make use of the 1010 campus MTU. The exceptions are TRILL Hellos, which must be kept 1011 small for loop safety, and the MTU PDUs, whose size must be adjusted 1012 appropriately for the tests being performed. 1014 6. BFD Enabled and BFD Session Bootstrap 1016 When the adjacency between RBridges reaches the 2-Way state, TRILL 1017 Hellos will already have been exchanged. If an RBridge supports BFD 1018 [RFCbfd] it will have learned whether the other RBridge has BFD 1019 enabled by whether or not a BFD Enabled TLV [RFC6213] was included in 1020 its Hellos. In addition, TRILL Hellos include a nickname of the 1021 sending RBridge [RFC6326bis] so that information will be available to 1022 the receiving RBridge. 1024 The BFD Enabled TLVs in TRILL Hellos will look like the following: 1026 +-+-+-+-+-+-+-+-+ 1027 | Type=148 | (1 bytes) 1028 +-+-+-+-+-+-+-+-+ 1029 | Length=3*n | (1 bytes) 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | RESV | MTID=0 | (2 bytes) 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | NLPID=0xC0 | (1 bytes) 1034 +-+-+-+-+-+-+-+-+-+-+-... 1035 | possible additional (3*(n-1) bytes) 1036 | topology/NLPID pairs 1037 +-+-+-+-+-+-+-... 1039 Figure 3. BFD Enabled TLV Example/Format 1041 Type = 148 for BFD Enabled [RFC6213]. 1043 Length will be 3 times the number of topology and protocol 1044 pairs in the TLV. 1046 MTID is a topology ID [RFC5120] that will be zero unless multi- 1047 topology is being supported [MT]. 1049 NLPID is a Network Layer Protocol ID [RFC6328] and will be 0xC0 1050 for TRILL. but additional topology and protocol pairs could 1051 conceivably be listed. 1053 An RBridge port initiates a one-hop BFD session with another RBridge 1054 if the following conditions are met: (1) it has BFD enabled, (2) it 1055 has an adjacency to another RBridge in the 2-way or Report state, and 1056 (3) the Hellos it receives indicate that the other RBridge also has 1057 BFD enabled. Either (a) BFD was enabled on both RBridge ports when 1058 the adjacency changed to the 2-way or Report state or (b) the 1059 adjacency was already in 2-way or Report state and BFD was enabled on 1060 one RBridge port when BFD had been enabled on the other or (c) BFD 1061 was simultaneously enabled on both RBridge ports. 1063 In such a BFD session, BFD is encapsulated as specified in [RFCbfd]. 1065 The egress nickname to be used will have been learned from received 1066 Hellos. On a point-to-point link, the Any-RBridge nickname [RFCclear] 1067 can also be used as egress since support of that nickname is required 1068 by support of RBridge Channel [RFCchannel] and support of RBridge 1069 Channel is required for support of BFD over TRILL. 1071 The rare case of transient nickname conflict (due to the network 1072 operator configuring a conflict, connectivity appearing to a 1073 previously isolated RBridge, or the like) can cause transient failure 1074 of an ongoing BFD session. This can be avoided in the one-hop point- 1075 to-point case by using the Any-RBridge egress nickname. In cases 1076 where Any-RBridge cannot be used as the egress nickname and a 1077 transient nickname conflict is detected for the intended destination 1078 of a BFD session, initiation of the session SHOULD be delayed until 1079 the conflict is resolved. 1081 If a one-hop BFD session is initiated when the adjacency is in the 1082 2-way state, the adjacency MUST NOT advance to the Report state until 1083 BFD and any other enabled connectivity test (including MTU if 1084 enabled) have succeeded, as specified in Section 3. 1086 If a one-hop BFD session is established when the adjacency is in the 1087 Report state, due to enablement at the RBridges, then, to minimize 1088 unnecessary topology changes, the adjacency MUST remain in the Report 1089 state unless and until the BFD session (or some other enabled 1090 connectivity test) fails. 1092 7. Pseudonodes 1094 This section only applies to broadcast links as there is no DRB and 1095 there cannot be a pseudonode [IS-IS] for a link configured as point- 1096 to-point. The Designated RBridge (DRB), determined as described 1097 above, controls whether a pseudonode will be used on a link. 1099 If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos, 1100 the RBridges on the link (including the DRB) just directly report all 1101 their adjacencies on the LAN that are in the Report state. If the 1102 DRB does not set the bypass pseudonode bit in its TRILL Hellos, then 1103 (1) the DRB reports in its LSP its adjacency to the pseudonode, (2) 1104 the DRB sends LSPs on behalf of the pseudonode in which it reports 1105 adjacency to all other RBridges on the link where it sees that 1106 adjacency in the Report state, and (3) all other RBridges on the link 1107 report their adjacency to the pseudonode if they see their adjacency 1108 to the DRB as being in the Report state and do not report any other 1109 adjacencies on the link. Setting the bypass pseudonode bit has no 1110 effect on how LSPs are flooded on a link. It only affects what LSPs 1111 are generated. 1113 It is anticipated that many links between RBridges will actually be 1114 point-to-point even in cases where the link technology supports 1115 operation as a multi-access broadcast link, in which case using a 1116 pseudonode merely adds to the complexity. For example, if RB1 and 1117 RB2 are the only RBridges on the link, and RB1 is DRB, then if RB1 1118 creates a pseudonode that is used, there are 3 LSPs: for, say, RB1.25 1119 (the pseudonode), RB1, and RB2, where RB1.25 reports connectivity to 1120 RB1 and RB2, and RB1 and RB2 each just say they are connected to 1121 RB1.25. Whereas if DRB RB1 sets the bypass pseudonode bit in its 1122 Hellos, then there will be only 2 LSPs: RB1 and RB2 each reporting 1123 connectivity to each other. 1125 A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has 1126 not seen at least two simultaneous adjacencies in the Report state 1127 since it last rebooted or was reset by network management. 1129 8. More TRILL Hello Details 1131 This section provides further details on the receipt, transmission, 1132 and content of TRILL Hellos. Unless otherwise stated, it applies to 1133 both LAN and point-to-point Hellos. 1135 TRILL Hellos, like all TRILL IS-IS packets, are primarily 1136 distinguished from Layer 3 IS-IS packets on Ethernet by being sent to 1137 the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41). TRILL 1138 IS-IS packets on Ethernet also have the L2-IS-IS Ethertype (0x22F4) 1139 and are Ethertype encoded. 1141 Although future extensions to TRILL may include use of Level 2 IS-IS, 1142 [RFC6325] specifies TRILL using a single Level 1 Area using the fixed 1143 Area Address zero (see Section 4.2 of [RFC6326bis]). 1145 IS-IS Layer 3 routers are frequently connected to other Layer 3 1146 routers that are part of a different routing domain. In that case, 1147 the externalDomain flag (see [IS-IS]) is normally set for the port 1148 through which such a connection is made. The setting of this flag to 1149 "true" causes no IS-IS PDUs to be sent out the port and any IS-IS 1150 PDUs received to be discarded, including Hellos. RBridges operate in 1151 a different environment where all neighbor RBridges merge into a 1152 single campus. For loop safety, RBridges do not implement the 1153 externalDomain flag or implement it with the fixed value "false". 1154 They send and can receive TRILL Hellos on every port that is not 1155 disabled. 1157 8.1 Contents of TRILL Hellos 1159 The table below lists mandatory (M) and optional (O) content TLVs for 1160 TRILL Hellos that are particularly relevant to this document, 1161 distinguishing between TRILL LAN Hellos and TRILL P2P Hellos. A "-" 1162 indicates that an occurrence would be ignored. There are additional 1163 TLVs and sub-TLVs that can occur in TRILL Hellos [RFC6326bis]. 1165 LAN P2P Numb Content Item 1166 --- --- ---- ------------ 1168 M M 1 Area Addresses TLV with area zero only 1169 M M 1 MT Port Capabilities TLV containing a VLAN-FLAGs 1170 sub-TLV 1171 O O 0-n Other MT Port Capability TLVs 1172 M - 0-n TRILL Neighbor TLV (see Section 8.2.1) 1173 - M 1 Three-Way Handshake TLV 1174 O O 0-n Protocols Supported TLV that MUST list the TRILL 1175 NLPID (0xC0) [RFC6328] 1176 O O 0-1 BFD Enabled TLV 1177 O O 0-1 Authentication TLV 1178 - - 0-n Padding TLV, SHOULD NOT be included 1180 Table 4. TRILL Hello Contents 1182 A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS 1183 Hello. As with all IS-IS PDUs, TLVs that are unsupported/unknown in 1184 TRILL Hellos are ignored. 1186 8.2 Transmitting TRILL Hellos 1188 TRILL Hellos are sent with the same timing as Layer 3 IS-IS Hellos 1189 [IS-IS]; however, no Hellos are sent if a port is in the Suspended or 1190 Down states or if the port is disabled. 1192 TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent exceeding 1193 1,470 bytes; however, a received TRILL Hello longer than 1,470 bytes 1194 is processed normally. 1196 TRILL Hello PDU headers MUST conform to the following: 1198 o Maximum Area Addresses equal to 1. 1200 o Circuit Type equal to 1. 1202 See Section 8.1 for mandatory and some optional Hello TLV contents. 1204 8.2.1 TRILL Neighbor TLVs 1206 A TRILL Neighbor TLV SHOULD NOT be included in TRILL point-to-point 1207 Hellos as it MUST be ignored in that context and wastes space. 1209 TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show 1210 the neighbor information, as sensed by the transmitting RBridge, for 1211 the VLAN on which the Hello is sent. Since implementations 1212 conformant to this document maintain such information on a per-VLAN 1213 basis only for the Designated VLAN, such implementations only send 1214 the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated VLAN. 1216 It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor 1217 TLV or TLVs, as described in Section 4.4.2.1 of [RFC6325], covering 1218 the entire range of MAC addresses and listing all adjacencies with a 1219 non-zero Designated VLAN Hello Holding time, or an empty list of 1220 neighbors if there are no such adjacencies, be in TRILL Hellos sent 1221 on the Designated VLAN. If this is not possible, then TRILL Neighbor 1222 TLV's covering sub-ranges of MAC addresses should be sent so that the 1223 entire range is covered reasonably promptly. Delays in sending TRILL 1224 Neighbor TLVs will delay the advancement of adjacencies to the Report 1225 state and the discovery of some link failures. Rapid (for example, 1226 sub-second) detection of link or node failures is best addressed with 1227 a protocol designed for that purpose, such as BFD (see Section 6). 1229 To ensure that any RBridge RB2 can definitively determine whether RB1 1230 can hear RB2, RB1's neighbor list MUST eventually cover every 1231 possible range of IDs, that is, within a period that depends on RB1's 1232 policy and not necessarily within any specific period such as its 1233 Holding Time. In other words, if X1 is the smallest ID reported in 1234 one of RB1's neighbor lists, and the "smallest" flag is not set, then 1235 X1 MUST appear in a different neighbor list as well, as the largest 1236 ID reported in that fragment. Or lists may overlap, as long as there 1237 is no gap, such that some range, say between Xi and Xj, would never 1238 appear in any list. 1240 8.3 Receiving TRILL Hellos 1242 Assuming a packet has the L2-IS-IS Ethertype and, if received on 1243 Ethernet, the All-IS-IS-RBridges multicast address, it will be 1244 examined to see if it appears to be an IS-IS PDU. If so, and it 1245 appears to be a TRILL Hello PDU, the following tests are performed. 1247 o The type of Hello PDU (LAN or P2P) is compared with the port 1248 configuration. If a LAN Hello is received on a port configured 1249 to be point-to-point or a P2P Hello is received on a port not 1250 configured to be point-to-point, it is discarded. 1252 o If the Circuit Type field is not 1, the PDU is discarded. 1254 o If the PDU does not contain an Area Address TLV or it contains 1255 an Area Address TLV that is not the single Area Address zero, 1256 it is discarded. 1258 o If the Hello includes a Protocols Supported TLV that does not 1259 list the TRILL NLPID (0xC0), it is discarded. It is acceptable 1260 if there is no Protocols Supported TLV present. 1262 o If the Hello does not contain an MT Port Capabilities TLV 1263 containing a VLAN-FLAGS sub-TLV [RFC6326bis], it is discarded. 1265 o If the maximumAreaAddresses field of the PDU is not 1, it is 1266 discarded. 1268 o If IS-IS authentication is in use on the link and the PDU 1269 either has no Authentication TLV or validation of that 1270 Authentication TLV fails, it is discarded. 1272 If none of the rules in the list above causes the packet to be 1273 discarded and it is parseable, it is assumed to be a well-formed 1274 TRILL Hello received on the link. It is treated as an event A0, A1, 1275 A2, or A3 based on the criteria listed in Section 3.3. 1277 9. Multiple Ports on the Same Broadcast Link 1279 It is possible for an RBridge RB1 to have multiple ports on the same 1280 broadcast (LAN) link that are not in the Suspended state. It is 1281 important for RB1 to recognize which of its ports are on the same 1282 link. RB1 can detect this condition based on receiving TRILL Hello 1283 messages with the same LAN ID on multiple ports. 1285 The DRB election is port-based (see Section 4) and only the Hellos 1286 from the elected port can perform certain functions such as dictating 1287 the Designated VLAN or whether a pseudonode will be used; however, 1288 the election also designates the RBridge with that port as DRB for 1289 the link. An RBridge may choose to load split some tasks among its 1290 ports on the link if it has more than one. Section 4.4.4 of [RFC6325] 1291 describes when it is safe to do so. 1293 10. Security Considerations 1295 This memo provides improved documentation of some aspects of the 1296 TRILL base protocol standard, particularly five aspects of the TRILL 1297 adjacency establishment and Hello protocol as listed in Section 1. 1298 It does not change the security considerations of the TRILL base 1299 protocol that are in Section 6 of [RFC6325]. 1301 See [RFCbfd] for security considerations for BFD whose use in 1302 connection with TRILL adjacency is discussed in this document, 1303 particularly Section 6. 1305 11. IANA Considerations 1307 This document requires no IANA Actions. RFC Editor: Please remove 1308 this section before publication. 1310 Appendix A: Changes from [RFC6327] 1312 This document has the following changes from [RFC6327]. It obsoletes 1313 [RFC6327]. 1315 1. Extends the TRILL Hello size limit, MTU testing, and state machine 1316 to point-to-point links. 1318 2. Incorporates the updates to [RFC6327] from [RFCclear]. 1320 3. The bulk of [RFC6327] was written from the point of view that 1321 links between TRILL switches would only be Ethernet. In fact, they 1322 could be any technology, such as PPP [RFC6361] or IP [TrillIP]. 1323 This replacement document generalizes [RFC6327] to cover such link 1324 types. 1326 4. Includes a specification of one-hop BFD session establishment in 1327 connection with adjacency. 1329 5. Numerous editorial changes. 1331 Appendix B: Changes to [RFC6325] 1333 Section 2 of this document replaces Section 4.4.1 of [RFC6325] and 1334 Section 8 of this document replaces Section 4.4.2 of [RFC6325] except 1335 for Section 4.4.2.1. The changes in [RFC6325] made by this document 1336 include 1338 - Prohibiting the sending of TRILL Hellos out a port while it is 1339 in the Suspended state and the specification of the Suspended 1340 state. ([RFC6325] specifies Hellos to be sent with the same 1341 timing as [IS-IS].) 1343 - Permitting the inclusion of the Three-Way-Handshake TLV, BFD 1344 Enabled TLV, and other TLVs in TRILL Hellos when these were 1345 omitted in TRILL Hello contents lists in Section 4.4.2 of 1346 [RFC6325]. 1348 - Extending the TRILL Hello protocol to support point-to-point 1349 and non-Ethernet links. 1351 Appendix Z: Change History 1353 RFC Editor Note: Please delete this section before publication. 1355 From -00 to -01 1357 Improvements to Section 6 related to the rare case of transient 1358 nickname conflict. 1360 Numerous editorial improvements and typos fixes. 1362 Changes to Acknowledgements and author list. 1364 From -01 to -02 1366 Editorial improvements. 1368 One editorial correction: deleting "or received in TRILL Hellos" from 1369 Section 6. (If a new RBridge joins a campus on a link with an MTU 1370 lower than the campus MTU (Sz), there might be a problem where LSPs 1371 wouldn't get through the link and, since LSPs carry the 1372 originatingLSPBufferSize, this might never get fixed. However, this 1373 has been fixed in draft-ietf-isis-rfc6326bis by requiring 1374 originatingLSPBufferSize be in LSP fragment zero and restricting the 1375 size of LSP fragment zero to 1470 bytes so it will get through. This 1376 snippet of text is left over from when it was thought to fix this in 1377 a different way by including originatingLSPBufferSize in Hellos.) 1379 Add one Acknowledgement. 1381 From -02 to -03 1383 Editorial improvements resulting from GENART review. Add GENART 1384 reviewer to acknowledgements. 1386 From -03 to -04 1388 Clarify what this document changes in RFC 6325 and add Appendix B. 1390 Minor editorial fixes. 1392 Normative References 1394 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 1395 Intermediate System Intra-Domain Routing Exchange Protocol for 1396 use in Conjunction with the Protocol for Providing the 1397 Connectionless-mode Network Service (ISO 8473)", 2002. 1399 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1400 dual environments", RFC 1195, December 1990. 1402 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, March 1997. 1405 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1406 Topology (MT) Routing in Intermediate System to Intermediate 1407 Systems (IS-ISs)", RFC 5120, February 2008. 1409 [RFC6213] - Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 1410 6213, April 2011. 1412 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 1413 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 1414 July 2011. 1416 [RFC6328] - Eastlake 3rd, D., "IANA Considerations for Network Layer 1417 Protocol Identifiers", BCP 164, RFC 6328, July 2011. 1419 [RFCbfd] - Manral, V., D. Eastlake, D. Ward, A. Banerjee, "TRILL 1420 (Transparent Interconnetion of Lots of Links): Bidirectional 1421 Forwarding Detection (BFD) Support", draft-ietf-trill-rbridge- 1422 bfd, in RFC Editor's queue. 1424 [RFCchannel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, 1425 "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge- 1426 channel-08.txt, in RFC Editor's queue. 1428 [RFCclear] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A. 1429 Banerjee, "TRILL: Clarifications, Corrections, and Updates " 1430 draft-ietf-trill-clear-correct, in RFC Editor's queue. 1432 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 1433 A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-rfc6326bis, 1434 work in progress. 1436 Informative References 1438 [802.1AX] - "IEEE Standard for Local and metropolitan area networks / 1439 Link Aggregation", 802.1AX-2008, 1 January 2008. 1441 [802.1Q] - "IEEE Standard for Local and metropolitan area networks / 1442 Media Access Control (MAC) Bridges and Virtual Bridge Local 1443 Area Networks", 802.1Q-2011, 31 August 2011. 1445 [FCoE] - From www.t11.org discussion of "FCoE Max Size" generated 1446 from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU". 1448 [MT] - D. Eastlake, M. Zhang, A. Banerjee, V. Manral, "TRILL: Multi- 1449 Topology", draft-eastlake-trill-multi-topology, work in 1450 progress. 1452 [RFC3719] - Parker, J., Ed., "Recommendations for Interoperable 1453 Networks using Intermediate System to Intermediate System (IS- 1454 IS)", February 2004. 1456 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 1457 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 1458 6327, July 2011. 1460 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1461 Interconnection of Lots of Links (TRILL) Protocol Control 1462 Protocol", RFC 6361, August 2011. 1464 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1465 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1466 6439, November 2011. 1468 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 1469 "TRILL (Transparent Interconnection of Lots of Links): Fine- 1470 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 1471 Editor's queue. 1473 [ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, " 1474 TRILL (Transparent Interconnection of Lots of Links): ESADI 1475 (End Station Address Distribution Information) Protocol", 1476 draft-ietf-trill-esadi, work in progress. 1478 [TrillIP] - M. Wasserman, D. Eastlake, D. Zhang, "Transparent 1479 Interconnection of Lots of Links (TRILL) over IP", draft-mrw- 1480 trill-over-ip, work in progress. 1482 Acknowledgements 1484 The suggestions and comments of the following are gratefully 1485 acknowledged: 1487 Stewart Bryant, Elwyn Davies, Adrian Farrel, Brian Haberman, Jon 1488 Hudson, Arnel Lim, and Gayle Noble 1490 The authors of [RFC6327] included Dinesh Dutt and the 1491 acknowledgements section of [RFC6327] includes the following listed 1492 in alphabetic order: Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay 1493 Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand. 1495 The document was prepared in raw nroff. All macros used were defined 1496 within the source file. 1498 Authors' Addresses 1500 Donald E. Eastlake, 3rd 1501 Huawei Technologies 1502 155 Beaver Street 1503 Milford, MA 01757 USA 1505 Phone: +1-508-333-2270 1506 EMail: d3e3e3@gmail.com 1508 Radia Perlman 1509 Intel Labs 1510 2200 Mission College Blvd. 1511 Santa Clara, CA 95054-1549 USA 1513 Phone: +1-408-765-8080 1514 EMail: Radia@alum.mit.edu 1516 Anoop Ghanwani 1517 Dell 1518 350 Holger Way 1519 San Jose, CA 95134 USA 1521 Phone: +1-408-571-3500 1522 EMail: anoop@alumni.duke.edu 1524 Howard Yang 1525 Cisco Systems 1526 170 West Tasman Drive 1527 San Jose, CA 95134 USA 1529 Email: howardy@cisco.com 1531 Vishwas Manral 1532 Hewlett Packard Co. 1533 19111 Pruneridge Ave, 1534 Cupertino, CA 95014 USA 1536 Phone: +1-408-447-1497 1537 EMail: vishwas.manral@hp.com 1539 Copyright, Disclaimer, and Additional IPR Provisions 1541 Copyright (c) 2014 IETF Trust and the persons identified as the 1542 document authors. All rights reserved. 1544 This document is subject to BCP 78 and the IETF Trust's Legal 1545 Provisions Relating to IETF Documents 1546 (http://trustee.ietf.org/license-info) in effect on the date of 1547 publication of this document. Please review these documents 1548 carefully, as they describe your rights and restrictions with respect 1549 to this document. Code Components extracted from this document must 1550 include Simplified BSD License text as described in Section 4.e of 1551 the Trust Legal Provisions and are provided without warranty as 1552 described in the Simplified BSD License. The definitive version of 1553 an IETF Document is that published by, or under the auspices of, the 1554 IETF. Versions of IETF Documents that are published by third parties, 1555 including those that are translated into other languages, should not 1556 be considered to be definitive versions of IETF Documents. The 1557 definitive version of these Legal Provisions is that published by, or 1558 under the auspices of, the IETF. Versions of these Legal Provisions 1559 that are published by third parties, including those that are 1560 translated into other languages, should not be considered to be 1561 definitive versions of these Legal Provisions. For the avoidance of 1562 doubt, each Contributor to the IETF Standards Process licenses each 1563 Contribution that he or she makes as part of the IETF Standards 1564 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1565 language to the contrary, or terms, conditions or rights that differ 1566 from or are inconsistent with the rights and licenses granted under 1567 RFC 5378, shall have any effect and shall be null and void, whether 1568 published or posted by such Contributor, or included with or in such 1569 Contribution.