idnits 2.17.1 draft-ietf-trill-adj-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2011) is 4739 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' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Radia Perlman 4 Updates: RFCtrill Intel Labs 5 Anoop Ghanwani 6 Brocade 7 Dinesh G. Dutt 8 Cisco Systems 9 Vishwas Manral 10 IP Infusion 11 Expires: October 28, 2011 April 29, 2011 13 RBridges: Adjacency 14 16 Abstract 18 The IETF TRILL (TRansparent Interconnection of Lots of Links) 19 protocol provides optimal pair-wise data forwarding without 20 configuration, safe forwarding even during periods of temporary 21 loops, and support for multipathing of both unicast and multicast 22 traffic. TRILL accomplishes this by using IS-IS (Intermediate System 23 to Intermediate System) link state routing and by encapsulating 24 traffic using a header that includes a hop count. Devices that 25 implement TRILL are called RBridges. 27 TRILL supports multi-access LAN (Local Area Network) links that can 28 have multiple end stations and RBridges attached. This document 29 describes four aspects of the TRILL LAN Hello protocol used on such 30 links, particularly adjacency, designated RBridge selection, and MTU 31 (Maximum Transmission Unit) and pseudonode procedures, with state 32 machines. There is no change for IS-IS point-to-point Hellos used on 33 links configured as point-to-point in TRILL. 35 Status of This Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. Distribution of this document is 39 unlimited. Comments should be sent to the TRILL working group 40 mailing list . 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 Acknowledgements 59 The authors of [RFCtrill], those listed in the Acknowledgements 60 section of [RFCtrill] and the contributions of Jari Arkko, Ayan 61 Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Erik Nordmark, 62 Pete McCann, and Mike Shand, to this document, are hereby 63 acknowledged. 65 Table of Contents 67 1. Introduction............................................4 68 1.1 Content and Precedence.................................4 69 1.2 Terminology and Acronyms...............................5 71 2. The TRILL Hello Environment and Purposes................6 72 2.1 Incrementally Replacing 802.1Q-2005 Bridges............6 73 2.2 Handling Native Frames.................................7 74 2.3 Zero or Minimal Configuration..........................8 75 2.4 MTU Robustness.........................................8 76 2.5 Purposes of the TRILL Hello Protocol...................8 78 3. Adjacency State Machinery..............................10 79 3.1 TRILL LAN Hellos, MTU Test, and VLANs.................10 80 3.2 Adjacency Table Entries and States....................10 81 3.3 Adjacency and Hello Events............................11 82 3.4 Adjacency State Diagram and Table.....................13 83 3.5 Multiple Parallel Links...............................15 84 3.6 Insufficient Space in Adjacency Table.................16 86 4. RBridge LAN Ports and DRB State........................17 87 4.1 Port Table Entries and DRB Election State.............17 88 4.2 DRB Election Events...................................18 89 4.2.1 DRB Election Details................................18 90 4.2.2 Change in DRB.......................................19 91 4.2.3 Change in Designated VLAN...........................19 92 4.3 State Table and Diagram...............................20 94 5. MTU Matching...........................................22 95 6. Pseudonodes............................................23 97 7. TRILL Hello Reception and Transmission.................24 98 7.1 Transmitting TRILL Hellos.............................24 99 7.1 Receiving TRILL Hellos................................25 101 8. Multiple Ports on the Same Link........................27 102 9. Security Considerations................................27 103 10. IANA Considerations...................................27 105 11. References............................................28 106 11.1 Normative References.................................28 107 11.2 Informative References...............................28 109 Appendix: Change Record...................................30 111 1. Introduction 113 The IETF TRILL (TRansparent Interconnection of Lots of Links) 114 protocol [RFCtrill] provides optimal pair-wise data frame forwarding 115 without configuration, safe forwarding even during periods of 116 temporary loops, and support for multipathing of both unicast and 117 multicast traffic. TRILL accomplishes this by using [IS-IS] 118 (Intermediate System to Intermediate System) link state routing and 119 encapsulating traffic using a header that includes a hop count. The 120 design supports VLANs (Virtual Local Area Networks) and optimization 121 of the distribution of multi-destination frames based on VLANs and IP 122 derived multicast groups. Devices that implement TRILL are called 123 RBridges. 125 The purpose of this document is to improve the quality of the 126 description of four aspects of the TRILL LAN (Local Area Network) 127 Hello protocol that RBridges use on broadcast (LAN) links. It 128 includes reference implementation details. Alternative 129 implementations that interoperate on the wire are permitted. There is 130 no change for IS-IS point-to-point Hellos used on links configured as 131 point-to-point in TRILL. 133 The scope of this document is limited to the following aspects of the 134 TRILL LAN Hello protocol: 136 - Adjacency formation 138 - DRB (Designated RBridge aka DIS (Designated Intermediate 139 System)) election 141 - Rules for two-way and MTU (Maximum Transmission Unit) matching 142 for advertisements 144 - Creation and use of pseudo-nodes 146 For other aspects of the TRILL base protocol see [RFCtrill]. 148 1.1 Content and Precedence 150 Section 2 below explains the rationale for the differences between 151 the TRILL LAN Hello protocol and the Layer 3 IS-IS LAN Hello protocol 152 [IS-IS] [RFC1195] in light of the environment for which the TRILL 153 protocol is designed. It also describes the purposes of the TRILL LAN 154 Hello protocol. 156 Section 3 describes the adjacency state machine and its states and 157 relevant events. 159 Section 4 describes the Designated RBridge (DRB) election state 160 machine for RBridge ports and its states and relevant events. 162 Section 5 describes MTU testing and matching on a TRILL link. 164 Section 6 discusses pseudonode creation and use. 166 Section 7 provides more details on the reception and transmission of 167 TRILL LAN Hellos. 169 Section 8 discusses multiple ports from one RBridge on the same link. 171 In case of conflict between this document and [RFCtrill], this 172 document prevails. 174 1.2 Terminology and Acronyms 176 This document uses the acronyms defined in [RFCtrill] supplemented by 177 the following additional acronym: 179 SNPA - Sub-Network Point of Attachment 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 2. The TRILL Hello Environment and Purposes 187 [IS-IS] has subnetwork independent functions and subnetwork dependent 188 functions. Currently Layer 3 use of IS-IS supports two types of 189 subnetworks: (1) point-to-point link subnetworks between routers and 190 (2) general broadcast (LAN) subnetworks. Because of the differences 191 between the environment of Layer 3 routers and the environment of 192 TRILL RBridges, instead of the broadcast (LAN) subnetwork dependent 193 functions encountered at Layer 3, which are specified in [IS-IS] 194 Section 8.4, the TRILL protocol uses modified subnetwork dependent 195 functions for a LAN subnetwork. The environmental differences are 196 described in Sections 2.1 through 2.4 below followed by a summation, 197 in Section 2.5, of the purposes of the TRILL LAN Hello protocol. 199 2.1 Incrementally Replacing 802.1Q-2005 Bridges 201 RBridges can incrementally replace IEEE [802.1Q-2005] bridges. Thus 202 RBridges need to provide similar services, including delivery of 203 frames only to links in the frame's VLAN and priority queuing of 204 frames, to the extent that multiple queues are implemented at any 205 particular RBridge port. 207 RBridge ports are IEEE [802.1Q-2005] ports in terms of their frame 208 VLAN and priority configuration and processing as described in 209 Section 2.6 of [RFCtrill]. When a frame is received through an 210 RBridge port, like a frame received through any [802.1Q-2005] port, 211 it has an associated VLAN ID and frame priority. When a frame is 212 presented to an [802.1Q-2005] port for queuing and transmission, it 213 must be accompanied by a VLAN ID and frame priority, although whether 214 the frame, if actually transmitted, will be VLAN tagged is determined 215 by whether the port is configured to "strip VLAN tags" or not. 216 Furthermore, in the general case, a broadcast (LAN) link between 217 RBridges can be a VLAN-capable bridged LAN that may be configured to 218 partition VLANs. 220 Because devices that restrict VLAN connectivity, such as bridged LANs 221 or provider bridging equipment, can be part of the link between 222 RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the 223 link's Designated VLAN. The Designated VLAN is dictated for a link by 224 the elected Designated RBridge (equivalent to the Designated 225 Intermediate System at Layer 3). Because TRILL Data frames flow 226 between RBridges on a link only in the link's Designated VLAN, 227 adjacency for routing calculations is based only on connectivity 228 characteristics in that VLAN. 230 2.2 Handling Native Frames 232 Ordinary layer 3 data packets are already "tamed" when they are 233 originated by an end station: they include a hop count and layer 3 234 source and destination address fields. Furthermore, for ordinary data 235 packets, there is no requirement to preserve their outer layer 2 236 addressing and, at least if unicast, they are addressed to their 237 first hop router. In contrast, RBridges running TRILL must accept, 238 transport, and deliver untamed "native" frames (as defined in Section 239 1.4 of [RFCtrill]). Native frames lack a TRILL hop count field. 240 Native frames also have layer 2 addresses that indicate their source 241 and are used as the basis for their forwarding. These layer 2 address 242 must be preserved for delivery to the native frame's layer 2 243 destination. One resulting difference is that RBridge ports providing 244 native frame service must receive in promiscuous MAC address mode 245 while Layer 3 router ports typically receive in a regularly selective 246 MAC address mode. 248 TRILL handles this by having, on the link where an end station 249 originated a native frame, one RBridge "ingress" that native frame by 250 adding a TRILL Header that includes a hop count, thus converting it 251 to a TRILL Data frame. This augmented frame is then routed to one 252 RBridge on the link having the destination end-station for the frame 253 (or one RBridge on each such link if it is a multi-destination 254 frame). Such final RBridges perform an "egress" function, removing 255 the TRILL Header and delivering the original frame to its 256 destination(s). (For the purposes of TRILL, a Layer 3 router is an 257 end station.) 259 Care must be taken to avoid a loop that would involve egressing a 260 native frame and then re-ingressing it because, while it is in native 261 form, it would not be protected by a hop count. Such a loop could 262 involve multiplication of the number of frames each time around and 263 would likely saturate all links involved within milliseconds. For 264 TRILL, safety against such loops for a link is more important than 265 data connectivity on that link. 267 The primary TRILL defense mechanism against such loops, which is 268 mandatory, is to assure that, as far as practically possible, there 269 is only a single RBridge on each link that is in charge of ingressing 270 and egressing native frames from and to that link. This is the 271 Designated RBridge which is elected using TRILL LAN Hellos as further 272 described in Sections 2.5 and 4 below. 274 Because bridged LANs between RBridges can be configured in complex 275 ways, including so as to pass frames in some VLANs in one direction 276 only, and loop safety is so important, there are additional TRILL 277 defenses against loops, where the looping traffic is in native format 278 for part of the loop, that are beyond the scope of this document. 279 These additional defenses have no effect on adjacency states or the 280 receipt or forwarding of TRILL Data frames, they only affect native 281 frame ingress and egress. 283 2.3 Zero or Minimal Configuration 285 RBridges are expected to provide service with zero configuration, 286 except for services such as non-default VLAN or priority that require 287 configuration when offered by [802.1Q-2005] bridges. This differs 288 from Layer 3 routing where routers typically need to be configured as 289 to the subnetworks connected to each port, etc., to provide service. 291 2.4 MTU Robustness 293 TRILL IS-IS needs to be robust against links with reasonably 294 restricted MTUs, including links that accommodate only classic 295 Ethernet frames, despite the addition of reasonable headers such as 296 VLAN tags. This is particularly true for TRILL LAN Hellos so as to 297 assure that a unique DRB is elected. 299 TRILL will also be used inside data centers where it is not uncommon 300 for all or most of the links and switches to support frames 301 substantially larger than the classic Ethernet maximum. For example 302 they may have an MTU adequate to comfortably handle Fiber Channel 303 over Ethernet frames, for which T11 recommends a 2,500 byte MTU 304 [FCoE]. It would be beneficial for an RBridge campus with such a 305 larger MTU to be able to safely make use of it. 307 These needs are met by limiting the size of TRILL LAN Hellos and by 308 the use of MTU testing as described below. 310 2.5 Purposes of the TRILL Hello Protocol 312 There are three purposes for the TRILL Hello protocol as listed below 313 along with a reference to the Section of this document in which each 314 is discussed: 316 a) To determine which RBridge neighbors have acceptable connectivity 317 to be reported as part of the topology (Section 3) 319 b) To elect a unique Designated RBridge on the link (Section 4) 321 c) To determine the MTU with which it is possible to communicate with 322 each RBridge neighbor (Section 5) 323 In Layer 3 IS-IS all three of these functions are combined. Hellos 324 may be padded to the maximum length (see [RFC3719], Section 6) so 325 that a router neighbor is not even discovered if it is impossible to 326 communicate with it using maximum sized packets. Also, even if Hellos 327 from a neighbor R2 are received by R1, if connectivity to R2 is not 328 2-way (i.e., R2 does not list R1 in R2's Hello), then R1 does not 329 consider R2 as a Designated Router candidate. Because of this logic, 330 it is possible at Layer 3 for multiple Designated Routers to be 331 elected on a LAN, with each representing the LAN as a pseudonode. It 332 appears to the topology as if the LAN is now two or more separate 333 LANs. Although this is surprising, it does not disrupt Layer 3 IS-IS. 335 In contrast, this behavior is not acceptable for TRILL, since in 336 TRILL it is important that all RBridges on the link know about each 337 other, and choose a single RBridge to be the DRB and to control the 338 native frame ingress and egress on that link. Otherwise, multiple 339 RBridges might encapsulate/decapsulate the same native frame, forming 340 loops that are not protected by the hop count in the TRILL header as 341 discussed above. 343 So, the TRILL Hello protocol is best understood by focusing on each 344 of these functions separately. 346 One other issue with TRILL LAN Hellos is to ensure that subsets of 347 the information can appear in any single message, and be processable, 348 in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even 349 though they are not padded, can become very large. An example where 350 this might be the case is when some sort of backbone technology 351 interconnects hundreds of TRILL sites over what would appear to TRILL 352 to be a giant Ethernet, where the RBridges connected to that cloud 353 will perceive that backbone to be a single link with hundreds of 354 neighbors. Thus the TRILL Hellos uses a different Neighbor TLV 355 [RFCtisis] that lists neighbors seen for a range of MAC (SNPA) 356 addresses. 358 3. Adjacency State Machinery 360 Each RBridge port has associated with it a port state, as discussed 361 in Section 4, and a table of zero or more adjacencies as discussed in 362 this Section 3. The states such adjacencies can have, the events that 363 cause state changes, the actions associated with those state changes, 364 and a state table and diagram are given below. 366 3.1 TRILL LAN Hellos, MTU Test, and VLANs 368 The determination of LSP reported adjacencies on links that are not 369 configured as point-to-point is made using TRILL LAN Hellos (see also 370 Section 7) and an optional MTU test. Appropriate TRILL LAN Hello 371 exchange and the satisfaction of the MTU test, if the MTU test is 372 enabled (see Section 5), is required for there to be an adjacency 373 that will be reported in an LSP of the RBridge in question. 375 Because bridges acting as glue on the LAN might be configured in such 376 a way that some VLANs are partitioned, it is necessary for RBridges 377 to transmit Hellos with multiple VLAN tags. The conceptually simplest 378 solution may have been to have all RBridges transmit up to 4,094 379 times as many Hellos, one with each legal VLAN ID enabled at each 380 port, but this would obviously have deleterious performance 381 implications. So, the TRILL protocol specifies that if RB1 knows it 382 is not DRB, it transmits its Hellos on only a limited set of VLANs, 383 and only an RBridge that believes itself to be DRB on a port "sprays" 384 its TRILL Hellos on all of its enabled VLANs at a port (with the 385 ability to configure to send on only a subset of those). The details 386 are given in [RFCtrill] Section 4.4.3. 388 If the MAC (SNPA) address of more than one RBridge port on a link are 389 the same, all but one of such ports are put in the Suspended state 390 (see Section 4) and do not participate in the link except to monitor 391 whether they should stay suspended. 393 All TRILL LAN Hellos issued by an RBridge on a particular port MUST 394 have the same source MAC address, priority, desired Designated VLAN, 395 and Port ID regardless of the VLAN in which the Hello is sent. Of 396 course, the priority and desired Designated VLAN can change on 397 occasion, but then the new value must similarly be used in all TRILL 398 Hellos on the port, regardless of VLAN. 400 3.2 Adjacency Table Entries and States 402 Each adjacency is in one of the following four states: 404 Down: 405 This is a virtual state for convenience in creating state 406 diagrams and tables. It indicates that the adjacency is non- 407 existent and there is no entry in the adjacency table for it. 409 Detect: 410 An adjacent neighbor has been detected either (1) not on the 411 Designated VLAN or (2) on the Designated VLAN but neither 2-way 412 connectivity nor the MTU of such connectivity has been 413 confirmed. 415 2-Way: 416 2-way connectivity to the neighbor has been found on the 417 Designated VLAN but MTU testing is enabled and has not yet 418 confirmed that the connectivity meets the campus minimum MTU 419 requirement. 421 Report: 422 There is 2-way connectivity to the neighbor on the Designated 423 VLAN and either MTU testing has confirmed that the connectivity 424 meets the campus minimum MTU requirement or MTU testing is not 425 enabled. This connectivity will be reported in an LSP (with 426 appropriate provision for the link pseudonode, if any, as 427 described in Section 6). 429 For an adjacency in any of the three non-down states (Detect, 2-Way, 430 and Report), there will be an adjacency table entry. That entry will 431 give the state of the adjacency and will also include the information 432 listed below. 434 o The address of the neighbor (that is, its SNPA address, usually 435 a 48-bit MAC address), the Port ID and the System ID in the 436 received Hellos. Together, these three quantities uniquely 437 identify the adjacency. 439 o Exactly two Hello holding timers, each consisting of a 16-bit 440 unsigned integer number of seconds: a Designated VLAN holding 441 timer and a non-Designated VLAN holding timer. 443 o The 7-bit unsigned priority of the neighbor to be DRB. 445 o The VLAN that the neighbor RBridge wants to be the Designated 446 VLAN on the link, called the desired Designated VLAN. 448 3.3 Adjacency and Hello Events 450 The following events can change the state of an adjacency: 452 A0. Receive a TRILL Hello whose source MAC address (SNPA) is equal 453 to that of the port on which it is received. This is a special 454 event that is handled as described immediately after this list 455 of events. It does not appear in the state transition table or 456 diagram. 458 A1. Receive a TRILL Hello (other than an A0 event) on the 459 Designated VLAN with a TRILL Neighbor TLV that explicitly 460 lists the receiver's (SNPA) address 462 A2. Receive a TRILL Hello (other than an A0 event) that either (1) 463 is not on the Designated VLAN (any TRILL Neighbor TLV in such 464 a Hello is ignored) or (2) is on the Designated VLAN but does 465 not contain a TRILL Neighbor TLV covering an address range 466 including the receiver's (SNPA) address 468 A3. Receive a TRILL Hello (other than an A0 event) on the 469 Designated VLAN with one or more TRILL Neighbor TLVs covering 470 an address range including the receiver's (SNPA) address none 471 of which lists the receiver 473 A4. The expiration of one or both Hello holding timers results in 474 them both being expired 476 A5. The Designated VLAN Hello holding timer expires but the non- 477 Designated VLAN Hello holding timer still has time left until 478 it expires 480 A6. MTU test successful 482 A7. MTU test was successful but now fails 484 A8. The RBridge port goes operationally down 486 For the special A0 event, the Hello is examined to determine if it is 487 higher priority to be DRB than the port on which is received as 488 described in Section 4.2.1. If the Hello is of lower priority than 489 the receiving port, it is discarded with no further action. If it is 490 higher priority than the receiving port, then any adjacencies for 491 that port are discarded (transitioned to the Down state) and the port 492 is suspended as described in Section 4.2. 494 The receipt of a TRILL LAN Hello with a source MAC (SNPA) address 495 different from that of the receiving port, that is, the occurrence of 496 events A1, A2, or A3, causes the following actions (except where the 497 Hello would create a new adjacency table entry, the table is full, 498 and the Hello is too low a priority to displace an existing entry as 499 described in Section 3.6). The Designated VLAN used in these actions 500 is the Designated VLAN dictated by the DRB determined without taking 501 the received TRILL LAN Hello into account (see Section 4). 503 o If the receipt of the Hellos creates a new adjacency table 504 entry, the neighbor RBridge MAC (SNPA) address, Port ID, and 505 System ID are set from the Hello. 507 o The appropriate Hello holding timer for the adjacency, 508 depending on whether the Hello was received on the Designated 509 VLAN or not, is set to the Holding Time field of the Hello. If 510 the receipt of the Hello is creating a new adjacency table 511 entry, the other timer is set to expired. 513 o The priority of the neighbor RBridge to be DRB is set to the 514 priority field of the Hello. 516 o The VLAN that the neighbor RBridge wants to be the Designated 517 VLAN on the link is set from the Hello. 519 o If the creation of a new adjacency table entry or the priority 520 update above changes the results of the DRB election on the 521 link, the appropriate RBridge port event (D2 or D3) occurs, 522 after the above actions, as described in Section 4.2. 524 o If there is no change in DRB but the neighbor Hello is from the 525 DRB and has a changed Designated VLAN from the previous Hello 526 received from the DRB, the result is a change in Designated 527 VLAN for the link as specified in Section 4.2.3. 529 An event A4 resulting in both Hello Holding timers for an adjacency 530 being expired and the adjacency going Down may also result in an 531 event D3 as described in Section 4.2. 533 Concerning events A6 and A7, if MTU testing is not enabled, A6 is 534 considered to occur immediately upon the adjacency entering the 2-Way 535 state and A7 cannot occur. 537 See further TRILL LAN Hello receipt details in Section 7. 539 3.4 Adjacency State Diagram and Table 541 The table below shows the transitions between the states defined 542 above based on the events defined above: 544 | Event | Down | Detect | 2-Way | Report | 545 +-------+--------+--------+--------+--------+ 546 | A1 | 2-Way | 2-Way | 2-Way | Report | 547 | A2 | Detect | Detect | 2-Way | Report | 548 | A3 | Detect | Detect | Detect | Detect | 549 | A4 | N/A | Down | Down | Down | 550 | A5 | N/A | Detect | Detect | Detect | 551 | A6 | N/A | N/A | Report | Report | 552 | A7 | N/A | N/A | 2-Way | 2-Way | 553 | A8 | Down | Down | Down | Down | 555 N/A indicates that the event to the left is Not Applicable in the 556 state at the top of the column. These events affect only a single 557 adjacency. The special A0 event transitions all adjacencies to Down, 558 as explained immediately after the list of adjacency events above. 560 Below is the same information as that in the state table presented as 561 a diagram: 563 +---------------+ 564 | Down |<--------+ 565 +---------------+ | 566 | | ^ | | 567 A2,A3| |A8| |A1 | 568 | +--+ | | 569 | +-----------|---+ 570 V | | 571 +----------------+ A4,A8 | | 572 +----->| Detect |------->| | 573 | +----------------+ | | 574 | | | ^ | | 575 | A1| |A2,A3,A5 | | | 576 | | +---------+ | | 577 | | | | 578 | | +------------|---+ 579 | | | | 580 | V V | 581 |A3,A5 +----------------+ A4,A8 | 582 |<-----| 2-Way |------->| 583 | +----------------+ | 584 | | ^ | ^ | 585 | A6| | |A1,A2,A7| | 586 | | | +--------+ | 587 | | | | 588 | | |A7 | 589 | V | | 590 |A3,A5 +-------------+ A4,A8 | 591 |<-----| Report |---------->| 592 +-------------+ 593 | ^ 594 |A1,A2,A6 | 595 +---------+ 597 3.5 Multiple Parallel Links 599 There can be multiple parallel adjacencies between neighbor RBridges 600 that are visible to TRILL. (Multiple low level links that have been 601 bonded together by technologies such as link aggregation [802.1AX] 602 appear to TRILL as a single link over which only a single TRILL 603 adjacency could be established.) 605 Any such links that have pseudonodes (see Section 6) are 606 distinguished in the topology and such adjacencies, if they are in 607 the Report state, appear in LSPs as per Section 6. However, there can 608 be multiple parallel adjacencies without pseudonodes because they are 609 point-to-point adjacencies or LAN adjacencies for which a pseudonode 610 is not being created. Such parallel, non-pseudonode adjacencies in 611 the Report state appear in LSPs as a single adjacency. The cost of 612 such an adjacency MAY be adjusted downwards to account for the 613 parallel paths. Multipathing across such parallel connections can be 614 freely done for unicast TRILL Data traffic on a per flow basis but is 615 restricted for multi-destination traffic, as described in [RFCtrill] 616 Section 4.5.2, point 3, and Appendix C. 618 3.6 Insufficient Space in Adjacency Table 620 If the receipt of a TRILL LAN Hello would create a new adjacency 621 table entry, that is, would transition an adjacency out of the Down 622 state, there may be no space for the new entry. In that case, the DRB 623 election priority (see Section 4.2.1) of the new entry that would be 624 created is compared with that priority for the existing entries. If 625 the new entry is higher priority than the lowest priority existing 626 entry, it replaces the lowest priority existing entry, which is 627 transitioned to the Down state. 629 4. RBridge LAN Ports and DRB State 631 The information at an RBridge associated with each of its LAN ports 632 includes the following: 634 o Enablement bit, which defaults to enabled. 636 o SNPA address (usually a 48-bit MAC address) of the port. 638 o Port ID, used in TRILL Hellos sent on the port. 640 o The Holding Time, used in TRILL Hellos sent on the port. 642 o The Priority to be DRB, used in TRILL Hellos sent on the port. 644 o The DRB status of the port, determined as specified below. 646 o A 16-bit unsigned Suspension timer denominated in seconds 648 o The desired Designated VLAN. The VLAN this RBridge wants to be 649 the Designated VLAN for the link out this port, used in TRILL 650 Hellos sent on the port. 652 o A table of zero or more adjacencies (see Section 3). 654 4.1 Port Table Entries and DRB Election State 656 The TRILL equivalent of the DIS (Designated Intermediate System) on a 657 link is the DRB or Designated RBridge. The DRB election state 658 machinery is described below. 660 Each RBridge port is in one of the following four DRB states: 662 Down: 663 The port is operationally down. It might be administratively 664 disabled or down at the link layer. In this state there will be 665 no adjacency table entries for the port, and no TRILL Hellos or 666 other IS-IS PDUs or TRILL Data frames are accepted or 667 transmitted. 669 Suspended: 670 Operation of the port is suspended because there is a higher 671 priority port on the link with the same MAC (SNPA) address. 672 This is the same as the down state with the exception that 673 TRILL Hellos are accepted for the sole purpose of determining 674 whether to change the value of the Suspension timer for the 675 port as described below. 677 DRB: 678 The port is DRB and can receive and transmit TRILL Data frames. 680 Not DRB: 681 The port is deferring to another port on the link, which it 682 believes is DRB, but can still receive and transmit TRILL Data 683 frames. 685 4.2 DRB Election Events 687 The following events can change the DRB state of a port: 689 D1. Expiration of the suspension timer while the port is in the 690 Suspended state or the enablement of the port. 692 D2. Adjacency table for the port changes and there are now entries 693 for one or more other RBridge ports on the link that appear to 694 be higher priority to be DRB than the local port. 696 D3. The port is not Down or Suspended and the adjacency table for 697 the port changes so there are now no entries for other RBridge 698 ports on the link that appear to be higher priority to be DRB 699 than the local port. 701 D4. Receipt of a TRILL Hello with the same MAC address (SNPA) as 702 the receiving port and higher priority to be DRB as described 703 for event A0. 705 D5. The port becomes operationally down. 707 Event D1 is considered to occur on RBridge boot if the port is 708 administratively and link layer enabled. 710 Event D4 causes the port to enter the Suspended state and all 711 adjacencies for the port to be discarded (transitioned to the Down 712 state). If it was in some state other than Suspended, the suspension 713 timer is set to the Holding Time in the Hello causing event D4. If it 714 was in the Suspended state, the suspension timer is set to the 715 maximum of its current value and the Holding Time in the Hello 716 causing event D4. 718 4.2.1 DRB Election Details 720 Events D2 and D3 constitute losing and winning the DRB election at 721 the port, respectively. 723 The candidates for election are the local RBridge and all RBridges 724 with which there is an adjacency on the port in an adjacency state 725 other than Down state. The winner is the RBridge with highest 726 priority to be DRB, as determined from the 7-bit priority field in 727 that RBridge's Hellos received and the local port's priority to be 728 DRB field, with MAC (SNPA) address as a tie breaker, Port ID as a 729 secondary tie breaker, and System ID as a tertiary tie breaker. These 730 fields are compared as unsigned integers with the larger magnitude 731 being considered higher priority. 733 Resort to the secondary and tertiary tie breakers should only be 734 necessary in rare circumstances when multiple ports have the same 735 priority and MAC (SNPA) address and some of them are not yet 736 suspended. For example, RB1, that has low priority to be DRB on the 737 link, could receive Hellos from two other ports on the link that have 738 the same MAC address as each other and are higher priority to be DRB. 739 One of these two same-MAC ports will be suspended, cease sending 740 Hellos, and the Hello from it received by RB1 will eventually time 741 out. But in the meantime RB1 can use the tie breakers to determine 742 which port is DRB and thus which port's Hello to believe for such 743 purposes as setting the Designated VLAN on the link. 745 4.2.2 Change in DRB 747 Events D2 and D3 result from a change in the apparent DRB on the 748 link. Unnecessary DRB changes should be avoided, especially on links 749 offering native frame service, as a DRB change will generally cause a 750 transient interruption to native frame service. 752 If a change in the DRB on the link changes the Designated VLAN on the 753 link, the actions specified in Section 4.2.3 are taken. 755 If an RBridge changes in either direction between being the 756 Designated RBridge and not being the Designated RBridge at a port, 757 this will generally change the VLANs on which Hellos are sent by that 758 RBridge on that port as specified in Section 4.4.3 of [RFCtrill]. 760 4.2.3 Change in Designated VLAN 762 Unnecessary changes in the Designated VLAN on a link should be 763 avoided because a change in the Designated VLAN can cause a transient 764 interruption to TRILL Data forwarding on the link. When practical, 765 all RBridge ports on a link should be configured with the same 766 desired Designated VLAN so that, in case the winner of the DRB 767 election changes, for any reason, the Designated VLAN will remain the 768 same. 770 If an RBridge detects a change in Designated VLAN on a link, then, 771 for all adjacency table entries for a port to that link, the RBridge 772 takes the following steps in the order given: 774 o The non-Designated VLAN Hello Holding timer is set to the 775 maximum of its time to expiration and the current time to 776 expiration of the Designated VLAN Hello Holding timer. 778 o The Designated VLAN Hello Holding timer is then set to expired 779 (if necessary) and an event A5 occurs for the adjacency (see 780 Section 3.3). 782 If the Designated VLAN for a link changes, this will generally change 783 the VLANs on which Hellos are sent by an RBridge port on that link as 784 specified in Section 4.4.3 of [RFCtrill]. 786 4.3 State Table and Diagram 788 The table below shows the transitions between the DRB states defined 789 above based on the events defined above: 791 | Event | Down | Suspend | DRB | Not DRB | 792 +-------+--------+---------+---------+---------+ 793 | D1 | DRB | DRB | N/A | N/A | 794 | D2 | N/A | N/A | Not DRB | Not DRB | 795 | D3 | N/A | N/A | DRB | DRB | 796 | D4 | N/A | Suspend | Suspend | Suspend | 797 | D5 | Down | Down | Down | Down | 799 N/A indicates that the event to the left is Not Applicable in the 800 state at the top of the column. 802 Below is the same information as in the state table presented as a 803 diagram: 805 +-------------+ 806 | Down |<--------------+ 807 +-+---+-------+ ^ | 808 | | ^ | | 809 D1| |D5 | | | 810 | +---+ |D5 | 811 | | | 812 | +--------+----+ | 813 | | Suspended |<---|---+ 814 | +-+-----+-----+ | | 815 | D1| ^ | ^ | | 816 | | | |D4 | | | 817 | | | +---+ | | 818 | | | | | 819 | | |D4 | | 820 V V | | | 821 +---------------+-+ D5 | | 822 | DRB |---------->| | 823 +--------+--+-----+ | | 824 ^ | | ^ | | 825 | D2| |D3| | | 826 | | +--+ | | 827 | | D4 | | 828 |D3 | +-----------------|---+ 829 | V | | 830 +----+-------+-+ D5 | 831 | Not DRB |-------------->| 832 +----+---------+ 833 | ^ 834 |D2 | 835 +----+ 837 5. MTU Matching 839 The purpose of MTU testing is to ensure that the links used in the 840 campus topology can pass TRILL IS-IS and Data frames at the RBridge 841 campus MTU. 843 An RBridge, RB1, determines the desired campus link MTU by 844 calculating the minimum of its originatingL1LSPBufferSize and the 845 originatingL1LSPBufferSize of other RBridges in the campus, as 846 advertised in the link state database, but not less than 1,470 bytes. 847 Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to 848 the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the 849 range 1,470 to 65,535 bytes inclusive. 851 Although MTU testing is optional, it is mandatory for an RBridge to 852 respond to an MTU-probe PDU with an MTU-ack PDU [RFCtrill] 853 [RFCtisis]. Use of multicast or unicast for MTU-probe and MTU-ack is 854 an implementation choice. However, the burden on the link is 855 generally minimized by multicasting MTU-probes when a response from 856 all other RBridges on the link is desired, such as when initializing 857 or re-confirming MTU, unicasting MTU-probes when a response from a 858 single RBridge is desired, such as one that has just been detected on 859 the link, and unicasting all MTU-ack frames. 861 RB1 can test the MTU size to RB2 as described in Section 4.3.2 of 862 [RFCtrill]. For this purpose, MTU testing is only done in the 863 Designated VLAN. An adjacency that fails the MTU test at the campus 864 MTU will not enter the "Report" state or, if the adjacency is in that 865 state, it leaves that state. Thus an adjacency failing the MTU test 866 will not be reported by the RBridge performing the test. Since 867 inclusion in least cost route computation requires the adjacency to 868 be reported by both ends, as long as the MTU failure is noticed by 869 the RBridge at either end of the adjacency, it will not be so used. 871 If it tests MTU, RB1 lists the largest size for which the MTU test 872 succeeds or a flag indicating that it fails at the campus MTU, with 873 the neighbor in RB1's TRILL Neighbor TLV and MAY report this with the 874 adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY 875 choose to test MTU sizes greater than the desired campus MTU as well 876 as the desired campus MTU. 878 Most types of TRILL IS-IS frames, such as LSPs, can make use of the 879 campus MTU. The exceptions are TRILL Hellos, which must be kept small 880 for loop safety, and the MTU PDUs, whose size must be adjusted 881 appropriately for the tests being performed. 883 6. Pseudonodes 885 The Designated RBridge (DRB), determined as described above, controls 886 whether a pseudonode will be used on a link. 888 If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos, 889 the RBridges on the link (including the DRB) just directly report all 890 their adjacencies on the LAN that are in the Report state. If the 891 DRB does not set the bypass pseudonode bit in its TRILL Hellos, then 892 (1) the DRB reports in its LSP its adjacency to the pseudonode, (2) 893 the DRB sends LSPs on behalf of the pseudonode in which it reports 894 adjacency to all other RBridges on the link where it sees that 895 adjacency in the Report state, and (3) all other RBridges on the link 896 report their adjacency to the pseudonode if they see their adjacency 897 to the DRB as being in the Report state and do not report any other 898 adjacencies on the link. Setting the bypass pseudonode bit has no 899 effect on how LSPs are flooded on a link. It only affects what LSPs 900 are generated. 902 It is anticipated that many links between RBridges will actually be 903 point-to-point, in which case using a pseudonode merely adds to the 904 complexity. For example, if RB1 and RB2 are the only RBridges on the 905 link and RB1 is DRB, then if RB1 creates a pseudonode that is used, 906 there are 3 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, 907 where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 908 each just say they are connected to RB1.25. Whereas if DRB RB1 sets 909 the bypass pseudonode bit in its Hellos, then there will be only 2 910 LSPs: RB1 and RB2 each reporting connectivity to each other. 912 A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has 913 not seen at least two simultaneous adjacencies in the Report state 914 since it last re-booted or was reset by network management. 916 7. TRILL Hello Reception and Transmission 918 This section provides further details on the receipt and transmission 919 of TRILL LAN Hellos. 921 TRILL LAN Hellos, like all TRILL IS-IS frames, are primarily 922 distinguished from Layer 3 IS-IS frames by being sent to the All-IS- 923 IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS frames 924 also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded. 926 Although future extensions to TRILL may include use of Level 2 IS-IS, 927 [RFCtrill] specifies TRILL using a single Level 1 Area with Area 928 Address zero (see Section 4.2 of [RFCtisis]). 930 IS-IS Layer 3 routers are frequently connected to other Layer 3 931 routers that are part of a different routing domain. In that case, 932 the externalDomain flag (see [IS-IS]) is normally set for the port 933 through which such a connection is made. The setting of this flag to 934 "true" causes no IS-IS PDUs to be sent out the port and any IS-IS 935 PDUs received to be discarded, including Hellos. RBridges operate in 936 a different environment where all neighbor RBridges merge into a 937 single campus. For loop safety, RBridges do not implement the 938 externalDomain flag or implement it with the fixed value "false". 939 They send and receive TRILL LAN Hellos on every port that is not 940 disabled or configured as point-to-point. 942 7.1 Transmitting TRILL Hellos 944 TRILL LAN Hellos are sent with the same timing as Layer 3 IS-IS LAN 945 Hellos [IS-IS]; however, no Hellos are sent if a port is in the 946 Suspended or Down states. 948 TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent exceeding 949 1,470 octets; however, a received TRILL Hello longer than 1,470 950 octets is processed normally. 952 TRILL Hello PDU headers MUST conform to the following: 954 o Maximum Area Addresses equal to 1. 956 o Circuit Type equal to 1. 958 Each TRILL Hello MUST contain an Area Addresses TLV listing only the 959 single Area zero, and an MT Port Capabilities TLV containing a VLAN- 960 FLAGS sub-TLV [RFCtisis]. If a Protocols Supported TLV is present, it 961 MUST list the TRILL NLPID (0xC0). 963 The TRILL Neighbor TLV sent in a Hello MUST show the neighbor 964 information, as sensed by the transmitting RBridge, for the VLAN on 965 which the Hello is sent. Since implementations conformant to this 966 document maintain such information on a per VLAN basis only for the 967 Designated VLAN, such implementations only send the TRILL Neighbor 968 TLV in TRILL Hellos on the Designated VLAN. 970 It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor 971 TLV or TLVs, as described in Section 4.4.2.1 of [RFCtrill], covering 972 the entire range of MAC addresses and listing all adjacencies with a 973 non-zero Designated VLAN Hello Holding time, or an empty list of 974 neighbors if there are no such adjacencies, be in TRILL Hellos sent 975 on the Designated VLAN. If this is not possible, then TRILL Neighbor 976 TLV's covering sub-ranges of MAC addresses should be sent so that the 977 entire range is covered reasonably promptly. Delays in sending TRILL 978 Neighbor TLVs will delay the advancement of adjacencies to the Report 979 state and the discovery of some link failures. Rapid, for example 980 sub-second, detection of link or node failures is best addressed with 981 a protocol designed for that purpose, such as BFD [RFC5880], use of 982 which with TRILL will be specified in a separate document. 984 To ensure that any RBridge RB2 can definitively determine whether RB1 985 can hear RB2, RB1's neighbor list MUST eventually cover every 986 possible range of IDs, that is, within a period that depends on RB1's 987 policy and not necessarily within any specific period such as its 988 Holding Time. In other words, if X1 is the smallest reported in one 989 of RB1's neighbor lists, and the "smallest" flag is not set, then X1 990 MUST appear in a different neighbor list as well, as the largest ID 991 reported in that fragment. Or lists may overlap, as long as there is 992 no gap, such that some range, say between Xi and Xj, never appears in 993 any list. 995 A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS 996 Hello. TLVs that are unsupported/unknown are ignored. 998 7.1 Receiving TRILL Hellos 1000 Assuming a frame has the All-IS-IS-RBridges multicast address and 1001 L2-IS-IS Ethertype, it will be examined to see if it appears to be an 1002 IS-IS PDU. If so, and it appears to be a LAN Hello PDU, the following 1003 tests are performed. 1005 o If the Circuit Type field is other than 1, the PDU is 1006 discarded. 1008 o If the PDU does not contain an Area Address TLV or it contains 1009 an Area Address TLV that is other than the single Area Address 1010 zero, it is discarded. 1012 o If the Hello includes a Protocols Supported TLV that does not 1013 list the TRILL NLPID (0xC0), it is discarded. It is acceptable 1014 if there is no Protocols Supported TLV present. 1016 o If the Hello does not contain an MT Port Capabilities TLV 1017 containing a VLAN-FLAGS sub-TLV [RFCtisis], it is discarded. 1019 o If the maximumAreaAddresses field of the PDU is not 1, it is 1020 discarded. 1022 o If IS-IS authentication is in use on the link and the PDU 1023 either has no Authentication TLV or validation of that 1024 Authentication TLV fails, it is discarded. 1026 If none of the rules in the list above has been satisfied, and the 1027 frame is parseable, it is assumed to be a well-formed TRILL Hello 1028 received on the link. It is treated as an event A0, A1, A2, or A3 1029 based on the criteria listed in Section 3.3. 1031 8. Multiple Ports on the Same Link 1033 It is possible for an RBridge RB1 to have multiple ports on the same 1034 link that are not in the Suspended state. It is important for RB1 to 1035 recognize which of its ports are on the same link. RB1 can detect 1036 this condition based on receiving TRILL LAN Hello messages with the 1037 same LAN ID on multiple ports. 1039 The DRB election is port-based (see Section 4) and only the Hellos 1040 from the elected port can perform certain functions such as dictating 1041 the Designated VLAN or whether a pseudonode will be used; however, 1042 the election also designates the RBridge with that port as DRB for 1043 the link. An RBridge may choose to load split some tasks among its 1044 ports on the link if it has more than one and it is safe to do so as 1045 described in Section 4.4.4 of [RFCtrill]. 1047 9. Security Considerations 1049 This memo provides improved documentation of some aspects of the 1050 TRILL base protocol standard, particularly four aspects of the TRILL 1051 LAN Hello protocol. It does not change the security considerations of 1052 the TRILL base protocol. See Section 6 of [RFCtrill]. 1054 10. IANA Considerations 1056 This document requires no IANA actions. RFC Editor: Please delete 1057 this section before publication. 1059 11. References 1061 Normative and Informational references for this document are listed 1062 below. 1064 11.1 Normative References 1066 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 1067 Intermediate System Intra-Domain Routing Exchange Protocol for 1068 use in Conjunction with the Protocol for Providing the 1069 Connectionless-mode Network Service (ISO 8473)", 2002. 1071 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1072 dual environments", RFC 1195, December 1990. 1074 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, March 1997. 1077 [RFCtisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A. 1078 Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill, work in 1079 progress. 1081 [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 1082 Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- 1083 trill-rbridge-protocol-16.txt, in RFC Editor's queue. 1085 11.2 Informative References 1087 [802.1AX] - "IEEE Standard for Local and metropolitan area networks / 1088 Link Aggregation", 802.1AX-2008, 1 January 2008. 1090 [FCoE] - From www.t11.org discussion of "FCoE Max Size" generated 1091 from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU". 1093 [RFC3719] - Parker, J., Ed., "Recommendations for Interoperable 1094 Networks using Intermediate System to Intermediate System (IS- 1095 IS)", February 2004. 1097 [RFC5880] - Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1098 (BFD)", RFC 5880, June 2010. 1100 Authors' Addresses 1102 Donald E. Eastlake, 3rd 1103 Huawei Technologies 1104 155 Beaver Street 1105 Milford, MA 01757 USA 1107 Phone: +1-508-333-2270 1108 Email: d3e3e3@gmail.com 1110 Radia Perlman 1111 Intel Labs 1112 2200 Mission College Blvd. 1113 Santa Clara, CA 95054-1549 USA 1115 Phone: +1-408-765-8080 1116 Email: Radia@alum.mit.edu 1118 Anoop Ghanwani 1119 Brocade Communications Systems 1120 130 Holger Way 1121 San Jose, CA 95134 USA 1123 Phone: +1-408-333-7149 1124 Email: anoop@brocade.com 1126 Dinesh G. Dutt 1127 Cisco Systems 1128 170 Tasman Drive 1129 San Jose, CA 95134-1706 USA 1131 Phone: +1-408-527-0955 1132 Email: ddutt@cisco.com 1134 Vishwas Manral 1135 IP Infusion Inc. 1136 1188 E. Arques Ave. 1137 Sunnyvale, CA 94089 USA 1139 Tel: +1-408-400-1900 1140 email: vishwas@ipinfusion.com 1142 Appendix: Change Record 1144 This appendix summarizes changes between versions of this draft. 1146 RFC Editor: Please delete this Appendix before publication. 1148 From -01 to -02 1150 1. Add a prefix letter "A" or "D" to the adjacency and DRB selection 1151 event numbers. 1153 2. Some re-wording for clarification in Section 6 concerning 1154 reporting pseudonode adjacencies. 1156 3. Minor editorial changes. 1158 From -02 to -03 1160 1. Add coverage of the case where the DRB on a link stays the same 1161 but the Designated VLAN changes. 1163 2. Clarify that, in all of the non-Down states, an RBridge port can 1164 receive and transmit TRILL Data frames. 1166 3. Split out separate sub-sections on the details of the DRB 1167 election, on changes in the DRB, and on changes in the Designated 1168 VLAN. 1170 4. Minor editorial changes. 1172 From -03 to -04 1174 1. Clarify exactly what adjacencies are reported in LSPs when bypass 1175 pseudonode is or is not set by the DRB. 1177 2. Clarify that TRILL Hellos received in excess of 1470 bytes in 1178 length are still processed normally. 1180 3. Items related to duplicate MAC addresses: Add the Suspended port 1181 state and the A0 event. Add a tertiary tie breaker for the DRB 1182 election to handle perverse cases of multiple ports with the same 1183 priority and MAC address on the same or different RBridges. Use 1184 the MAC address, Port ID, System ID triplet to identify 1185 adjacencies. 1187 4. Add text recommending transmission of a TRILL Neighbor TLV 1188 covering the full range of MAC addresses (will a null neighbor 1189 list if there are none) in every TRILL Hello if there is room and 1190 prompt transmission of TRILL Neighbor TLV fragments covering that 1191 whole range, if the full TLV will not fit. 1193 5. Add recommendation concerning use of unicast and multicast for MTU 1194 PDUs. 1196 6. Minor editorial changes. 1198 From -04 to -05 1200 1. Eliminate the "Pre-DRB" port state. That state relates to one 1201 reason for the inhibition of Appointed Forwarders, is out of scope 1202 for this document, and this capability will be provided by other 1203 means in a separate document. 1205 2. Clarify that a TRILL Hello need not contain a Protocols Supported 1206 TLV. But if one if present it must contain the TRILL NLPID. 1208 3. Minor Editorial changes. 1210 From -05 to -06 1212 1. Swap Sections 7.1 and 7.2 so tranmission appears before reception. 1214 2. Minor changes so as to refer to "SNPA address" rather than just 1215 "SNPA". 1217 3. Minor editorial changes and typo fixes. 1219 From -06 to -07 1221 Editorial changes resulting from IESG DISCUSSes and COMMENTs. 1223 Copyright and IPR Provisions 1225 Copyright (c) 2011 IETF Trust and the persons identified as the 1226 document authors. All rights reserved. 1228 This document is subject to BCP 78 and the IETF Trust's Legal 1229 Provisions Relating to IETF Documents 1230 (http://trustee.ietf.org/license-info) in effect on the date of 1231 publication of this document. Please review these documents 1232 carefully, as they describe your rights and restrictions with respect 1233 to this document. Code Components extracted from this document must 1234 include Simplified BSD License text as described in Section 4.e of 1235 the Trust Legal Provisions and are provided without warranty as 1236 described in the Simplified BSD License. The definitive version of 1237 an IETF Document is that published by, or under the auspices of, the 1238 IETF. Versions of IETF Documents that are published by third parties, 1239 including those that are translated into other languages, should not 1240 be considered to be definitive versions of IETF Documents. The 1241 definitive version of these Legal Provisions is that published by, or 1242 under the auspices of, the IETF. Versions of these Legal Provisions 1243 that are published by third parties, including those that are 1244 translated into other languages, should not be considered to be 1245 definitive versions of these Legal Provisions. For the avoidance of 1246 doubt, each Contributor to the IETF Standards Process licenses each 1247 Contribution that he or she makes as part of the IETF Standards 1248 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1249 language to the contrary, or terms, conditions or rights that differ 1250 from or are inconsistent with the rights and licenses granted under 1251 RFC 5378, shall have any effect and shall be null and void, whether 1252 published or posted by such Contributor, or included with or in such 1253 Contribution.