idnits 2.17.1 draft-ietf-trill-clear-correct-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC6439, but the abstract doesn't seem to directly say this. It does mention RFC6439 though, so this could be OK. -- The draft header indicates that this document updates RFC6325, but the abstract doesn't seem to directly say this. It does mention RFC6325 though, so this could be OK. -- The draft header indicates that this document updates RFC6327, but the abstract doesn't seem to directly say this. It does mention RFC6327 though, so this could be OK. 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 (July 30, 2012) is 4259 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) -- Duplicate reference: RFC6325, mentioned in 'Err3003', was also mentioned in 'Err3002'. -- Duplicate reference: RFC6325, mentioned in 'Err3004', was also mentioned in 'Err3003'. -- Duplicate reference: RFC6325, mentioned in 'Err3052', was also mentioned in 'Err3004'. -- Duplicate reference: RFC6325, mentioned in 'Err3053', was also mentioned in 'Err3052'. -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) -- Duplicate reference: RFC6325, mentioned in 'RFC6325', was also mentioned in 'Err3053'. ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Mingui Zhang 3 Intended status: Proposed Standard Huawei 4 Updates: 6325, 6327, 6439 Anoop Ghanwani 5 Dell 6 Vishwas Manral 7 Hewlett-Packard 8 Ayan Banerjee 9 Cumulus Networks 10 Expires: January 29, 2013 July 30, 2012 12 TRILL: Clarifications, Corrections, and Updates 13 15 Abstract 17 The IETF TRILL (TRansparent Interconnection of Lots of Links) 18 protocol provides least cost pair-wise data forwarding without 19 configuration in multi-hop networks with arbitrary topology and link 20 technology, safe forwarding even during periods of temporary loops, 21 and support for multipathing of both unicast and multicast traffic. 22 TRILL accomplishes this by using IS-IS (Intermediate System to 23 Intermediate System) link state routing and by encapsulating traffic 24 using a header that includes a hop count. Since the TRILL base 25 protocol was approved in March 2010, active development of TRILL has 26 revealed errata in the original RFC 6325 and some cases that could 27 use clarifications or updates. 29 RFC 6327 and RFC 6439 provide clarifications and updates with respect 30 to Adjacency and Appointed Forwarders. This document provides other 31 known clarifications, corrections, and updates to RFC 6325, RFC 6327, 32 and RFC 6439. 34 Status of This Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. Distribution of this document is 38 unlimited. Comments should be sent to the TRILL working group 39 mailing list . 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 52 Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Table of Contents 57 1. Introduction............................................4 58 1.1 Precedence.............................................4 59 1.2 Changes That Are Not Backwards Compatible..............4 60 1.3 Terminology and Acronyms...............................5 62 2. Overloaded and/or Unreachable RBridges..................6 63 2.1 Reachability...........................................6 64 2.2 Distribution Trees.....................................7 65 2.3 Overloaded Receipt of TRILL Data Frames................7 66 2.3.1 Known Unicast Receipt................................7 67 2.3.2 Multi-Destination Receipt............................8 68 2.4 Overloaded Origination of TRILL Data Frames............8 69 2.4.1 Known Unicast Origination............................8 70 2.4.2 Multi-Destination Origination........................8 71 2.4.2.1 An Example Network.................................8 72 2.4.2.2 Indicating OOMF Support............................9 73 2.4.2.3 Using OOMF Service................................10 75 3. Distribution Trees.....................................11 76 3.1 Number of Distribution Trees..........................11 77 3.2 Clarification of Distribution Tree Updates............11 78 3.3 IP Address Based Multicast Pruning....................11 79 3.4 Numbering of Distribution Trees.......................12 81 4. Nickname Selection.....................................13 83 5. MTU (Maximum Transmission Unit)........................15 84 5.1 MTU Related Errata in RFC 6325........................15 85 5.1.1 MTU PDU Addressing..................................15 86 5.1.2 MTU PDU Processing..................................16 87 5.1.3 MTU Testing.........................................16 88 5.2 Ethernet MTU Values...................................16 90 6. Port Modes.............................................18 91 7. The CFI / DEI Bit......................................19 92 8. Graceful Restart.......................................20 93 9. Updates to RFC 6327....................................21 95 10. Updates on Appointed Forwarders and Inhibition........22 96 10.1 Optional TRILL Hello Reduction.......................22 97 10.2 Overload and Appointed Forwarders....................24 99 11. IANA Considerations...................................25 100 12. Security Considerations...............................26 101 Acknowledgements..........................................26 102 Change History............................................26 103 Normative References......................................28 104 Informative References....................................29 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 in multi-hop networks with arbitrary topology 111 and link technology, safe forwarding even during periods of temporary 112 loops, and support for multipathing of both unicast and multicast 113 traffic. TRILL accomplishes this by using IS-IS (Intermediate System 114 to Intermediate System) [IS-IS] [RFC1195] [RFC6326bis] link state 115 routing and encapsulating traffic using a header that includes a hop 116 count. The design supports VLANs (Virtual Local Area Networks) and 117 optimization of the distribution of multi-destination frames based on 118 VLANs and IP derived multicast groups. 120 In the more than two years since the TRILL base protocol [RFC6325] 121 was approved, the active development of TRILL has revealed five 122 errors in the original specification document [RFC6325] and cases 123 that could use clarifications or updates. 125 [RFC6327] and [RFC6439] provide clarifications with respect to 126 Adjacency and Appointed Forwarders. This document provides other 127 known clarifications, corrections, and updates to [RFC6325], 128 [RFC6327], and [RFC6439]. 130 1.1 Precedence 132 In case of conflict between this document and any of [RFC6325], 133 [RFC6327], or [RFC6439], this document takes precedence. In addition, 134 Section 1.2 (Normative Content and Precedence) of [RFC6325] is 135 updated to provide a more complete precedence ordering of the 136 sections of [RFC6325] as following, where sections to the left take 137 precedence over sections to their right: 139 4 > 3 > 7 > 5 > 2 > 6 > 1 141 1.2 Changes That Are Not Backwards Compatible 143 The change made by Section 3.4 below is not backward compatible with 144 [RFC6325] but has nevertheless been adopted to reduce distribution 145 tree changes resulting from topology changes. 147 The several other changes herein that are fixes to previously posted 148 [RFC6325] Errata [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] 149 may not be backward compatible with previous implementations that 150 conformed to errors in the specification. 152 1.3 Terminology and Acronyms 154 This document uses the acronyms defined in [RFC6325] and the 155 following additional acronyms: 157 CFI - Canonical Format Indicator [802] 159 DEI - Drop Eligibility Indicator [802.1Q-2011] 161 EISS - Enhanced Internal Sublayer Service 163 OOMF - Overload Originated Multi-destination Frame 165 TRILL Switch - An alternative name for an RBridge 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in 170 [RFC2119]. 172 2. Overloaded and/or Unreachable RBridges 174 RBridges may be in overload as indicated by the [IS-IS] overload flag 175 in their LSPs (Link State PDUs (Protocol Data Units)). This means 176 that either (1) they are incapable of holding the entire link state 177 database and thus do not have a view of the entire topology or (2) 178 they have been configured to have the overload bit set. Although 179 networks should be engineered to avoid actual link state overload, it 180 might occur under various circumstances. For example, if a large 181 campus included one or more low-end TRILL Switches. 183 It is a common operational practice to set the overload bit in an 184 [IS-IS] router (such as an RBridge) when performing maintenance on 185 that router that might affect its ability to correctly forward 186 frames; this will usually leave the router reachable for maintenance 187 traffic but transit traffic will not be routed through it. (Also, in 188 some cases, TRILL provides for setting the overload bit in the 189 pseudonode of a link to stop TRILL Data traffic on an access link 190 (see Section 4.9.1 of [RFC6325]).) 192 [IS-IS] and TRILL make a reasonable effort to do what they can even 193 if some RBridges/routers are in overload. They can do reasonably well 194 if a few scattered nodes are in overload. However, actual least cost 195 paths are no longer assured if any RBridges are in overload. 197 For the effect of overload on the appointment of forwarders, see 198 Section 10.2. 200 In this Section 2, the term "neighbor" refers only to actual RBridges 201 and ignores pseudonodes. 203 2.1 Reachability 205 Frames are not least cost routed through an overloaded TRILL Switch, 206 although they may originate or terminate at an overloaded TRILL 207 Switch. In addition, frames will not be least cost routed over links 208 with cost 2**24 - 1 [RFC5305]; such links are reserved for traffic 209 engineered frames, the handling of which is beyond the scope of this 210 document. 212 As a result, a portion of the campus may be unreachable for least 213 cost routed TRILL Data because all paths to it would be through a 214 link with cost 2**24 - 1 or through an overloaded RBridge. For 215 example, an RBridge RB1 is not reachable by TRILL Data if all of its 216 neighbors are connected to RB1 by links with cost 2**24 - 1. Such 217 RBridges are called "data unreachable". 219 The link state database at an RBridge RB1 can also contain 220 information on TRILL Switches that are unreachable by IS-IS link 221 state flooding due to link or RBridge failures. When such failures 222 partition the campus, the TRILL Switches adjacent to the failure and 223 on the same side of the failure as RB1 will update their LSPs to show 224 the lack of connectivity and RB1 will receive those updates. As a 225 result, RB1 will be aware of the partition. Nodes on the far side of 226 the partition are both "IS-IS unreachable" and data unreachable. 227 However, LSPs held by RB1 for TRILL Switches on the far side of the 228 failure will not be updated and may stay around until they time out, 229 which could be tens of minutes or longer. (The default in [IS-IS] is 230 twenty minutes.) 232 2.2 Distribution Trees 234 An RBridge in overload cannot be trusted to correctly calculate 235 distribution trees or correctly perform the RPFC (Reverse Path 236 Forwarding Check). Therefore, it cannot be trusted to forward multi- 237 destination TRILL Data frames. It can only appear as a leaf node in a 238 TRILL multi-destination distribution tree. Furthermore, if all the 239 immediate neighbors of an RBridge are overloaded, then it is omitted 240 from all trees in the campus and is unreachable by multi-destination 241 frames. 243 When an RBridge determines what nicknames to use as the roots of the 244 distribution trees it calculates, it MUST ignore all nicknames held 245 by TRILL Switches that are in overload or are data unreachable. When 246 calculating RPFCs for multi-destination frames, an RBridge RB1 MAY, 247 to avoid calculating unnecessary RPF check state, ignore any trees 248 that cannot reach to RB1 even if other RBridges list those trees as 249 trees those other TRILL Switches might use. (But see Section 3.) 251 2.3 Overloaded Receipt of TRILL Data Frames 253 The receipt of TRILL Data frames by overloaded RBridge RB2 is 254 discussed in the subsections below. In all cases, the normal Hop 255 Count decrement is performed and the TRILL Data frame is discarded if 256 the result is less than one or if the egress nickname is illegal. 258 2.3.1 Known Unicast Receipt 260 RB2 will not usually receive unicast TRILL Data frames unless it is 261 the egress, in which case it decapsulates and delivers the frames 262 normally. If RB2 receives a unicast TRILL Data frame for which it is 263 not the egress, perhaps because a neighbor does not yet know it is in 264 overload, RB2 MUST NOT discard the frame because the egress is an 265 unknown nickname as it might not know about all nicknames due to its 266 overloaded condition. If any neighbor, other than the neighbor from 267 which it received the frame, is not overloaded it MUST attempt to 268 forward the frame to one of those neighbors. If there is no such 269 neighbor, the frame is discarded. 271 2.3.2 Multi-Destination Receipt 273 If RB2 in overload receives a multi-destination TRILL Data frame, RB2 274 MUST NOT apply an RPFC since, due to overload, it might not do so 275 correctly. RB2 decapsulates and delivers the frame locally where it 276 is Appointed Forwarder for the frame's VLAN, subject to any multicast 277 pruning. But since, as stated above, RB2 can only be the leaf of a 278 distribution tree, it MUST NOT forward a multi-destination TRILL Data 279 frame (except as an egressed native frame where RB2 is Appointed 280 Forwarder). 282 2.4 Overloaded Origination of TRILL Data Frames 284 Overloaded origination of unicast frames with known egress and of 285 multi-destination frames are discussed in the subsections below. 287 2.4.1 Known Unicast Origination 289 When an overloaded RBridge RB2 ingresses or creates a known 290 destination unicast TRILL Data frame, it delivers it locally if the 291 destination MAC is local. Otherwise RB2 unicasts it to any neighbor 292 TRILL Switch that is not overloaded. It MAY use what routing 293 information it has to help select the neighbor. 295 2.4.2 Multi-Destination Origination 297 Overloaded RBridge RB2 ingressing or creating a multi-destination 298 TRILL Data frame is more complex than for a known unicast frame. 300 2.4.2.1 An Example Network 302 For example, consider the network below in which, for simplicity, end 303 stations and any bridges are not shown. There is one distribution 304 tree of which RB4 is the root and which is represented by double 305 lines. Only RBridge RB2 is overloaded. 307 +-----+ +-----+ +-----+ +-----+ 308 | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 | 309 +-----+ +--+--+ +-++--+ +--+--| 310 | || | 311 +---+---+ || | 312 +------+RB2(ov)|======++ | 313 | +-------+ || | 314 | || | 315 +--+--+ +-----+ ++==++=++ +--+--+ 316 | RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 | 317 +-----+ +-----+ ++=====++ +-----+ 319 Since RB2 is overloaded it does not know what the distribution tree 320 or trees are for the network. Thus there is no way it can provide 321 normal TRILL Data encapsulation for multi-destination native frames. 322 So RB2 tunnels the frame to a neighbor that is not overloaded if it 323 has such a neighbor that has signaled it is willing to offer this 324 service. RBridges indicate this in their Hellos as described below. 325 This service is called OOMF (Overloaded Origination of Multi- 326 destination Frame) service. 328 - The multi-destination frame MUST NOT be locally distributed in 329 native form at RB2 before tunneling to a neighbor because this 330 would cause the frame to be delivered twice. For example, if RB2 331 locally distributed a multicast native frame and then tunneled it 332 to RB5, RB2 would get a copy of the frame when RB3 transmitted it 333 as a TRILL Data frame on the multi-access RB2-RB3-RB4 link. Since 334 RB2 would, in general, not be able to tell that this was a frame 335 it had tunneled for distribution, RB2 would decapsulate it and 336 locally distribute it a second time. 338 - On the other hand, if there is no neighbor of RB2 offering RB2 the 339 OOMF service, RB2 cannot tunnel the frame to a neighbor. In this 340 case RB2 MUST locally distribute the frame where it is Appointed 341 Forwarder for the frame's VLAN and optionally subject to multicast 342 pruning. 344 2.4.2.2 Indicating OOMF Support 346 A RBridge RB3 indicates its willingness to offer the OOMF service to 347 RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit 348 associated with the SNPA (SubNetwork Point of Attachment, also known 349 as MAC address) of RB2 on the link. (See Section 11.) Overloaded 350 RBridge RB2 can only distribute multi-destination TRILL Data frames 351 to the campus if a neighbor of RB2 not in overload offers RB2 the 352 OOMF service. If RB2 does not have OOMF service available to it, RB2 353 can still receive multi-destination frames from non-overloaded 354 neighbors and, if RB2 should originate or ingress such a frame, it 355 distributes it locally in native form. 357 2.4.2.3 Using OOMF Service 359 If RB2 sees this OOMF (Overloaded Origination of Multi-destination 360 Frame) service advertised for it by any of its neighbors on any link 361 to which RB2 connects, it selects one such neighbor by a means beyond 362 the scope of this document. Assuming RB2 selects RB3 to handle multi- 363 destination frames it originates. RB2 MUST advertise in its LSP that 364 it might use any of the distribution trees that RB3 advertises so 365 that the RPFC will work in the rest of the campus. Thus, 366 notwithstanding its overloaded state, RB2 MUST retain this 367 information from RB3 LSPs, which it will receive as it is directly 368 connected to RB3. 370 RB2 then encapsulates such frames as TRILL Data frames to RB3 as 371 follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held 372 by RB2, and, since RB2 cannot tell what distribution tree RB3 will 373 use, egress nickname = a special nickname indicating an OOMF frame 374 (see Section 11). RB2 then unicasts this TRILL Data frame to RB3. 375 (Implementation of Item 4 in Section 4 below provides reasonable 376 assurance that, notwithstanding its overloaded state, the ingress 377 nickname used by RB2 will be unique within at least the portion of 378 the campus that is IS-IS reachable from RB2.) 380 On receipt of such a frame, RB3 does the following: 382 - change the egress nickname field to designate a distribution tree 383 that RB3 normally uses, 384 - set the M bit to one, 385 - change the Hop Count to the value it would normally use if it were 386 the ingress, and 387 - forward the frame on that tree. 389 RB3 MAY rate limit the number of frames for which it is providing 390 this service by discarding some such frames from RB2. The provision 391 of even limited bandwidth for OOMFs by RB3, perhaps via the slow 392 path, may be important to the bootstrapping of services at RB2 or at 393 end stations connected to RB2, such as supporting DHCP and ARP/ND. 394 (Everyone sometimes needs a little OOMF (pronounced oomph) to get off 395 the ground.) 397 3. Distribution Trees 399 A correction, a clarification, and two updates related to 400 distribution trees appear in the subsections below. See also Section 401 2.2. 403 3.1 Number of Distribution Trees 405 In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the 406 parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. 407 It should read "(up to k if j is zero or the minimum of (j, k) if j 408 is non-zero)". 410 3.2 Clarification of Distribution Tree Updates 412 When a link state database change causes a change in the distribution 413 tree(s), there are several possibilities. If a tree root remains a 414 tree root but the tree changes, then local forwarding and RPFC 415 entries for that tree should be updated as soon as practical. 416 Similarly, if a new nickname becomes a tree root, forwarding and RPFC 417 entries for the new tree should be installed as soon as practical. 418 However, if a nickname ceases to be a tree root and there is 419 sufficient room in local tables, the forwarding and RPFC entries for 420 the former tree MAY be retained so that any multi-destination TRILL 421 Data frames already in flight on that tree have a higher probability 422 of being delivered. 424 3.3 IP Address Based Multicast Pruning 426 The TRILL base protocol specification [RFC6325] provides for and 427 recommends the pruning of multi-destination frame distribution trees 428 based on the location of IP multicast routers and listeners; however, 429 multicast listening is identified by derived MAC addresses as 430 communicated in the Group MAC Address sub-TLV [RFC6326bis]. 432 TRILL Switches MAY communicate multicast listeners and prune 433 distribution trees based on the actual IPv4 or IPv6 multicast 434 addresses involved. Additional Group Address sub-TLVs are provided in 435 [RFC6326bis] to carry this information. A TRILL Switch that is only 436 capable of pruning based on derived MAC address SHOULD calculate and 437 use such derived MAC addresses from multicast listener IPv4/IPv6 438 address information it receives. 440 3.4 Numbering of Distribution Trees 442 Section 4.5.1 of [RFC6325] specifies that, when building distribution 443 tree number j, node (RBridge) N that has multiple possible parents in 444 the tree is attached to possible parent number j mod p. Trees are 445 numbered starting with 1 but possible parents are numbered starting 446 with 0. As a result, if there are two trees and two possible parents, 447 in tree 1 parent 1 will be selected and in tree 2 parent 0 will be 448 selected. 450 This is changed so that the selected parent MUST be (j-1) mod p. As a 451 result, in the case above, tree 1 will select parent 0 and tree 2 452 will select parent 1. This change is not backwards compatible with 453 [RFC6325]. If all RBridges in a campus do not determine distribution 454 trees in the same way then, for most topologies, the reverse path 455 forwarding checking will drop many multi-destination frames before 456 they have been properly delivered. 458 4. Nickname Selection 460 Nickname selection is covered by Section 3.7.3 of [RFC6325]. However, 461 the following should be noted: 463 1. The second sentence in the second bullet item in Section 3.7.3 of 464 [RFC6325] on page 25 is erroneous [Err3002] and is corrected as 465 follows: 467 1.a The occurrence of "IS-IS ID (LAN ID)" is replaced with 468 "priority". 470 1.b The occurrence of "IS-IS System ID" is replaced with "seven 471 byte IS-IS ID (LAN ID)". 473 The resulting corrected [RFC6325] sentence reads as follows: "If 474 RB1 chooses nickname x, and RB1 discovers, through receipt of an 475 LSP for RB2 at any later time, that RB2 has also chosen x, then 476 the RBridge or pseudonode with the numerically higher priority 477 keeps the nickname, or if there is a tie in priority, the RBridge 478 with the numerically higher seven byte IS-IS ID (LAN ID) keeps the 479 nickname, and the other RBridge MUST select a new nickname." 481 2. In examining the link state database for nickname conflicts, 482 nicknames held by IS-IS unreachable TRILL Switches MUST be ignored 483 but nicknames held by IS-IS reachable TRILL Switches MUST NOT be 484 ignored even if they are data unreachable. 486 3. An RBridge may need to select a new nickname, either initially 487 because it has none or because of a conflict. When doing so, the 488 RBridge MUST consider as available all nicknames that do not 489 appear in its link state database or that appear to be held by IS- 490 IS unreachable TRILL Switches; however, it SHOULD give preference 491 to selecting new nicknames that do not appear to be held by any 492 TRILL Switch in the campus, reachable or unreachable, so as to 493 minimize conflicts if IS-IS unreachable TRILL Switches later 494 become reachable. 496 4. An RBridge, even after it has acquired a nickname for which there 497 appears to be no conflicting claimant, MUST continue to monitor 498 for conflicts with the nickname or nicknames it holds. It does so 499 by checking in LSPs it receives that should update its link state 500 database for any of its nicknames held with higher priority by 501 another TRILL Switch that is IS-IS reachable. If it finds such a 502 conflict, it MUST select a new nickname, even when in overloaded 503 state. (It is possible to receive an LSP that should update the 504 link state database but does not due to overload.) 506 5. In the very unlikely case that an RBridge is unable to obtain a 507 nickname because all valid RBridge nicknames (0x0001 through 508 0xFFBF inclusive) are in use with higher priority by IS-IS 509 reachable TRILL Switches, it will be unable to act as an ingress, 510 egress, or tree root but will still be able to function as a 511 transit TRILL Switch. Although it cannot be a tree root, such an 512 RBridge is included in distribution trees computed for the campus 513 unless all its neighbors are overloaded. It would not be possible 514 to send a unicast RBridge Channel message specifically to such a 515 TRILL Switch [Channel]; however, it will receive unicast Channel 516 messages sent by a neighbor to the Any-RBridge egress nickname and 517 will receive appropriate multi-destination Channel messages. 519 5. MTU (Maximum Transmission Unit) 521 MTU values in TRILL key off the originatingL1LSPBufferSize value 522 communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The 523 campus-wide value Sz, as described in [RFC6325] Section 4.3.1, is the 524 minimum value of originatingL1LSPBufferSize for the RBridges in a 525 campus, but not less than 1470. The MTU testing mechanism and 526 limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and 527 thus that IS-IS can operate properly. 529 If nothing is known about the MTU of the links or the 530 originatingL1LSPBufferSize of other RBridges in a campus, the 531 originatingL1LSPBufferSize for an RBridge should default to the 532 minimum of the LSP size that its TRILL IS-IS software can handle and 533 the minimum MTU of the ports that it might use to receive or transmit 534 LSPs. If an RBridge does have knowledge of link MTUs or other RBridge 535 originatingL1LSPBufferSize then, to avoid the necessity to regenerate 536 the local LSPs using a different maximum size, the RBridge's 537 originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) 538 the smallest value that other RBridges are or will be announcing as 539 their originatingL1LSPBufferSize and (2) a value small enough that 540 the campus will not partition due to a significant number of links 541 with limited MTU. However, as provided in [RFC6325], in no case can 542 originatingL1LSPBufferSize be less than 1470. In a well configured 543 campus, to minimize any LSP regeneration due to re-sizing, it is 544 desirable for all RBridges to be configured with the same 545 originatingL1LSPBufferSize. 547 Section 5.1 below corrects errata in [RFC6325] and Section 5.2 548 clarifies the meaning of various MTU (Maximum Transmission Unit) 549 limits for TRILL Ethernet links. 551 5.1 MTU Related Errata in RFC 6325 553 Three MTU related errata in [RFC6325] are corrected in the 554 subsections below. 556 5.1.1 MTU PDU Addressing 558 Section 4.3.2 of [RFC6325] incorrectly states that multi-destination 559 MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links 560 with the All-RBridges multicast address as the Outer.MacDA [Err3004]. 561 As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be 562 sent to the All-IS-IS-RBridges multicast address. 564 5.1.2 MTU PDU Processing 566 As discussed in [RFC6325] and, in more detail, in [RFC6327], MTU- 567 probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of 568 [RFC6325] erroneously does not allow for this possibility [Err3003]. 569 It is corrected by replacing Item numbered "1" in Section 4.6.2 of 570 [RFC6325] with the following quoted text to which TRILL Switches MUST 571 conform: 573 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All- 574 IS-IS-RBridges or the unicast MAC address of the receiving 575 RBridge port, the frame is handled as described in Section 576 4.6.2.1" 578 The reference to "Section 4.6.2.1" in the above quoted text is to 579 that Section in [RFC6325]. 581 5.1.3 MTU Testing 583 The last two sentences of Section 4.3.2 of [RFC6325] have errors 584 [Err3053]. They currently read: 586 If X is not greater than Sz, then RB1 sets the "failed minimum MTU 587 test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, 588 then RB1 advertises the largest tested X for each adjacency in the 589 TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an 590 attribute of the link to RB2 in RB1's LSP. 592 They should read: 594 If X is not greater than or equal to Sz, then RB1 sets the "failed 595 minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, 596 and X >= Sz, then RB1 advertises the largest tested X for each 597 adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY 598 advertise X as an attribute of the link to RB2 in RB1's LSP. 600 5.2 Ethernet MTU Values 602 originatingL1LSPBufferSize is the maximum permitted size of LSPs 603 starting with the 0x83 Intradomain Routeing Protocol Discriminator 604 byte. In layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 605 bytes. (This is because, in its previous life as DECnet Phase V, IS- 606 IS was encoded using the SNAP SAP [RFC5342] format which takes 8 607 bytes of overhead and 1492 + 8 = 1500, the classic Ethernet maximum. 608 When standardized by ISO/IEC [IS-IS] to use LLC encoding, this 609 default could have been increased by a few bytes but was not.) 610 In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This 611 allows 27 bytes of headroom or safety margin to accommodate legacy 612 devices with the classic Ethernet maximum MTU despite headers such as 613 an Outer.VLAN. This safety margin is called "Margin" below. 615 Assuming the campus wide minimum link MTU is Sz, RBridges on Ethernet 616 links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of 617 the PDU starting just after the L2-IS-IS Ethertype and ending just 618 before the Ethernet frame FCS) does not to exceed Sz. The PDU 619 exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, 620 and MTU-probe and MTU-ack PDUs that are padded, depending on the size 621 being tested (which may exceed Sz). 623 Sz does not limit TRILL Data frames. They are only limited by the MTU 624 of the devices and links that they actually pass through; however, 625 links that can accommodate IS-IS PDUs up to Sz would accommodate, 626 with a generous safety margin, TRILL Data frame payloads, starting 627 after the Inner.VLAN and ending just before the FCS, of Sz - 24 628 bytes. Most modern Ethernet equipment has ample headroom for frames 629 with extensive headers and is sometimes engineered to accommodate 9K 630 byte jumbo frames. 632 6. Port Modes 634 Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports 635 but may not be completely clear on the effects of various 636 combinations of bits. 638 The table below explicitly indicates the effect of all possible 639 combinations of the TRILL port mode bits. "*" in one of the first 640 four columns indicates that the bit can be either zero or one. The 641 following columns indicate allowed frame types. The Disable bit 642 normally disables all frames but, as an implementation choice, some 643 or all low level Layer 2 control frames (as specified in [RFC6325] 644 Section 1.4) can still be sent or received. 646 +-+-+-+-+--------+-------+-----+-----+-----+ 647 |D| | | | | | | | | 648 |i| |A| | | |TRILL| | | 649 |s| |c|T| | |Data | | | 650 |a| |c|r| | | | | | 651 |b|P|e|u| |native | LSP | | | 652 |l|2|s|n|Layer 2 |ingress| SNP |TRILL| P2P | 653 |e|P|s|k|Control |egress | MTU |Hello|Hello| 654 +-+-+-+-+--------+-------+-----+-----+-----+ 655 |0|0|0|0| Yes | Yes | Yes | Yes | No | 656 +-+-+-+-+--------+-------+-----+-----+-----+ 657 |0|0|0|1| Yes | No | Yes | Yes | No | 658 +-+-+-+-+--------+-------+-----+-----+-----+ 659 |0|0|1|0| Yes | Yes | No | Yes | No | 660 +-+-+-+-+--------+-------+-----+-----+-----+ 661 |0|0|1|1| Yes | No | No | Yes | No | 662 +-+-+-+-+--------+-------+-----+-----+-----+ 663 |0|1|0|*| Yes | No | Yes | No | Yes | 664 +-+-+-+-+--------+-------+-----+-----+-----+ 665 |0|1|1|*| Yes | No | No | No | Yes | 666 +-+-+-+-+--------+-------+-----+-----+-----+ 667 |1|*|*|*|Optional| No | No | No | No | 668 +-+-+-+-+--------+-------+-----+-----+-----+ 670 (The formal name of the "access bit" is the "TRILL traffic disable 671 bit" and the formal name of the "trunk bit" is the "end-station 672 service disable bit" [RFC6325].) 674 7. The CFI / DEI Bit 676 In May 2011, the IEEE promulgated [802.1Q-2011] which changes the 677 meaning of the bit between the priority and VLAN ID bits in the 678 payload of C-VLAN tags. Previously this bit was called the CFI 679 (Canonical Format Indicator) bit [802] and had a special meaning in 680 connection with IEEE 802.5 (Token Ring) frames. Now, under 681 [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar 682 to that bit in S-VLAN / B-VLAN tags where this bit has always been a 683 DEI bit. 685 The TRILL base protocol specification [RFC6325] assumed, in effect, 686 that the link by which end stations are connected to TRILL Switches 687 and the restricted virtual link provided by the TRILL Data frame are 688 IEEE 802.3 Ethernet links on which the CFI bit is always zero. Should 689 an end station be attached by some other type of link, such as a 690 Token Ring link, [RFC6325] implicitly assumed that such frames would 691 be canonicalized to 802.3 frames before being ingressed and 692 similarly, on egress, such frames would be converted from 802.3 to 693 the appropriate frame type for the link. Thus, [RFC6325] required 694 that the CFI bit in the Inner.VLAN always be zero. 696 However, for TRILL Switches with ports conforming to the change 697 incorporated in the IEEE 802.1Q-2011 standard, the bit in the 698 Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by 699 the EISS (Enhanced Internal Sublayer Service) interface on ingressing 700 a native frame. Similarly, this bit MUST be provided to the EISS 701 when transiting or egressing a TRILL Data frame. As with the 3-bit 702 priority field, the DEI bit to use in forwarding a transit frame MUST 703 be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI 704 and priority bits and whether or not an Outer.VLAN appears at all on 705 the wire for output frames may depend on output port configuration. 707 TRILL campuses with a mixture of ports, some compliant with 708 [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards, 709 especially if they have actual Token Ring links, may operate 710 incorrectly and may corrupt data, just as a bridged LAN with such 711 mixed ports and links would. 713 8. Graceful Restart 715 TRILL Switches SHOULD support the features specified in [RFC5306] 716 which describes a mechanism for a restarting IS-IS router to signal 717 to its neighbors that it is restarting, allowing them to reestablish 718 their adjacencies without cycling through the down state, while still 719 correctly initiating link state database synchronization. 721 9. Updates to RFC 6327 723 [RFC6327] provides for multiple states of the potential adjacency 724 between two TRILL Switches. It makes clear that only an adjacency in 725 the "Report" state is reported in LSPs. LSP synchronization (LSP and 726 SNP transmission and receipt), however, is performed if and only if 727 there is at least one adjacency on the link in either the "Two-Way" 728 or "Report" state. 730 To support the PORT-TRILL-VER sub-TLV specified in [RFC6326bis], the 731 following updates are made to [RFC6327]: 733 1. The first sentence of the last paragraph in [RFC6327] Section 734 3.1 is modified from 735 "All TRILL LAN Hellos issued by an RBridge on a particular 736 port MUST have the same source MAC address, priority, 737 desired Designated VLAN, and Port ID, regardless of the VLAN 738 in which the Hello is sent." 739 to 740 "All TRILL LAN Hellos issued by an RBridge on a particular 741 port MUST have the same source MAC address, priority, 742 desired Designated VLAN, Port ID, and PORT-TRILL-VER sub-TLV 743 [RFC6326bis] if included, regardless of the VLAN in which 744 the Hello is sent." 746 2. An additional bullet item is added to the end of [RFC6327] 747 Section 3.2 as follows: 749 o The 5 bytes of data from the PORT-TRILL-VER received in 750 the most recent TRILL Hello from the neighbor RBridge. 752 3. In [RFC6327] Section 3.3, near the bottom of page 12, a bullet 753 item as follows is added: 755 o The five bytes of PORT-TRILL-VER data are set from that 756 sub-TLV in the Hello or set to zero if that sub-TLV does 757 not occur in the Hello. 759 4. At the beginning of [RFC6327] Section 4, a bullet item is added 760 to the list as follows: 762 o The five bytes of PORT-TRILL-VER sub-TLV data used in 763 TRILL Hellos sent on the port. 765 10. Updates on Appointed Forwarders and Inhibition 767 An optional method of Hello reduction is specified in Section 10.1 768 below and a recommendation on forwarder appointments in the face of 769 overload is given in Section 10.2. 771 10.1 Optional TRILL Hello Reduction 773 If a network manager has sufficient confidence that they know the 774 configuration of bridges, ports, and the like, within a link, they 775 may be able to reduce the number of TRILL Hellos sent on that link; 776 for example, if all RBridges on the link will see all Hellos 777 regardless of VLAN constraints, Hellos could be sent on fewer VLANs. 778 However, because adjacencies are established in the Designated VLAN, 779 an RBridge MUST always attempt to send Hellos in the Designated VLAN. 780 Hello reduction makes TRILL less robust in the face of decreased VLAN 781 connectivity in a link such as partitioned VLANs, many VLANs disabled 782 on ports, or disagreement over the Designated VLAN; however, as long 783 as all RBridge ports on the link are configured for the same desired 784 Designated VLAN, can see each other's frames in that VLAN, and 785 utilize the mechanisms specified below to update VLAN inhibition 786 timers, operations will be safe. (These considerations do not arise 787 on links between RBridges that are configured as point-to-point 788 since, in that case, each RBridge sends point-to-point Hellos, other 789 TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to 790 be the Designated VLAN of the link and no native frame end-station 791 service is provided.) 793 The provision for a configurable set of "Announcing VLANs", as 794 described in Section 4.4.3 of [RFC6325] provides a mechanism in the 795 TRILL base protocol for a reduction in TRILL Hellos. 797 To maintain loop safety in the face of occasional lost frames, 798 RBridge failures, link failures, new RBridges coming up on a link, 799 and the like, the inhibition mechanism specified in [RFC6439] is 800 still required. Under Section 3 of [RFC6439], a VLAN inhibition timer 801 can only be set by the receipt of a Hello sent or received in that 802 VLAN. Thus, to safely send a reduced number of TRILL Hellos on a 803 reduced number of VLANs requires additional mechanisms to set the 804 VLAN inhibition timers at an RBridge, thus extending Section 3, Item 805 4, of [RFC6439]. Two such mechanisms are specified below. Support for 806 both of these mechanisms is indicated by a capability bit in the 807 PORT-TRILL-VER sub-TLV (see Section 9 above and [RFC6326bis]). It may 808 be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the 809 set of VLANs recommended in [RFC6325] on a link unless all its 810 adjacencies on that link (excluding those in the Down state 811 [RFC6327]) indicate support of these mechanisms and these mechanisms 812 are in use. 814 1. An RBridge RB2 MAY include in any TRILL Hello an Appointed 815 Forwarders sub-TLV [RFC6326bis] appointing itself for one or more 816 ranges of VLANs. The Appointee Nickname field(s) in the Appointed 817 Forwarder sub-TLV MUST be the same as the Sender Nickname in the 818 Special VLANs and Flags sub-TLV in the TRILL Hello. This indicates 819 the sending RBridge believes it is Appointed Forwarder for those 820 VLANs. An RBridge receiving such a sub-TLV sets each of its VLAN 821 inhibition timers for every VLAN in the block or blocks listed in 822 the Appointed Forwarders sub-TLV to the maximum of its current 823 value and the Holding Time of the Hello containing the sub-TLV. 824 This is backwards compatible because such sub-TLVs will have no 825 effect on any receiving RBridge not implementing this mechanism 826 unless RB2 is the DRB (Designated RBridge) sending Hello on the 827 Designated VLAN in which case, as specified in [RFC6439], RB2 MUST 828 include in the Hello all forwarder appointments, if any, for 829 RBridges other than itself on the link. 831 2. An RBridge MAY use the new VLANs Appointed sub-TLV [RFC6326bis]. 832 When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from 833 RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all 834 the VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is 835 Appointed Forwarder. Each such timer is updated to the maximum of 836 its current value and the Holding Time of the TRILL Hello 837 containing the VLANs Appointed sub-TLV. This sub-TLV will be an 838 unknown sub-TLV to RBridge not implementing it and such RBridges 839 will ignore it. Even if a TRILL Hello send by the DRB on the 840 Designated VLAN includes one or more VLANs Appointed sub-TLVs, as 841 long as no Appointed Forwarders sub-TLVs appear, the Hello is not 842 required to indicate all forwarder appointments. 844 Two different encodings are providing above to optimize the listing 845 of VLANs. Large blocks of contiguous VLANs are more efficiently 846 encoded with the Appointed Forwarders sub-TLV and scattered VLANs are 847 more efficiently encoded with the VLANs Appointed sub-TLV. These 848 encodings may be mixed in the same Hello. The use of these sub-TLVs 849 does not affect the requirement that the "AF" bit in the Special 850 VLANs and Flags sub-TLV MUST be set if the originating RBridge 851 believes it is Appointed Forwarder for the VLAN in which the Hello is 852 sent. If the above mechanisms are used on a link, then each RBridge 853 on the link MUST send Hellos in one or more VLANs with such VLANs 854 Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders 855 sub-TLV(s) and the "AF" bit appropriately set such that no VLAN 856 inhibition timer will improperly expire unless three or more Hellos 857 are lost. For example, an RBridge could announce all VLANs for which 858 it believes it is Appointed Forwarder in a Hello sent on the 859 Designated VLAN three times per Holding Time. 861 10.2 Overload and Appointed Forwarders 863 An RBridge in overload (see Section 2) will, in general, do a poorer 864 job of ingressing and forwarding frames than an RBridge not in 865 overload that has full knowledge of the campus topology. For example, 866 an overloaded RBridge may not be able to distribute multi-destination 867 TRILL Data frames at all. 869 Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an 870 Appointed Forwarder unless there is no alternative. Furthermore, if 871 an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign 872 VLANs from the overloaded RBridge to another RBridge on the link that 873 is not overloaded, if one is available. DRB election is not affected 874 by overload. 876 A counter-example would be if all campus end stations in VLAN-x were 877 on links attached to RB1 via ports where VLAN-x was enabled. In such 878 a case, RB1 SHOULD be made the VLAN-x Appointed Forwarder on all such 879 links even if RB1 is overloaded. 881 11. IANA Considerations 883 The following IANA actions are required: 885 1. The nickname 0xTBD [0xFFC1 suggested], which was reserved by 886 [RFC6325], is allocated for use in the TRILL Header egress 887 nickname field to indicate an OOMF (Overload Originated Multi- 888 destination Frame). 890 2. Bit 1 from the seven previously reserved (RESV) bits in the per 891 neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC6326bis] 892 is allocated to indicate that the RBridge sending the TRILL Hello 893 volunteers to provide the OOMF forwarding service described in 894 Section 2.4.2 to such frames originated by the TRILL Switch whose 895 SNPA (MAC address) appears in that Neighbor RECORD. 897 3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER 898 sub-TLV [RFC6326bis] to indicate support of the VLANs Appointed 899 sub-TLV [RFC6326bis] and the VLAN inhibition setting mechanisms 900 specified in Section 10.1. 902 12. Security Considerations 904 This memo improves the documentation of the TRILL protocol, corrects 905 five errata in [RFC6325], and updates [RFC6325], [RFC6327], and 906 [RFC6439]. It does not change the security considerations of these 907 RFCs. 909 Acknowledgements 911 The contributions of the following persons are gratefully 912 acknowledged: 914 Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia 915 Perlman, Mike Shand, Meral Shirazipour, and Varun Varshah. 917 This document was produced with raw nroff. All macros used were 918 defined in the source file. 920 Change History 922 RFC Editor Note: Please delete this Change History section before 923 publication. 925 Changes from -01 to -02: 926 Add Section 3.4. Minor editorial changes and update of the version 927 and dates. 929 Changes from -02 to -03: 930 Emphasize in Section 3.4 that the change is not backwards 931 compatible and that all the RBridges in a campus must calculate 932 the distribution trees the same way or RPFC will discard too much. 933 Provide additional detail at the end of Item 5, Section 4, as to 934 what Channel messages can be received by an RBridge without a 935 nickname. Add Section 1.2 on incompatible changes, renumbering the 936 former Section 1.2 as 1.3. 938 Changes from -03 to -04: 939 Update author information. Numerous typos fixes and editorial 940 changes based on the GENART review and various Area Director 941 reviews. The update from -03 to -04 is not intended to make any 942 technical change. 944 Changes from -04 to -05: 945 Change text to make it clear that frames are not least cost routed 946 through overloaded RBridges. Minor editorial changes, some to 947 resolve second-pass GENART comments. 949 Changes from -05 to -06: 950 Improve wording of Section 4, bullet 4, and Section 5, paragraph 951 2, as per suggestions by Mike Shand. Fix typos in Change History. 953 Normative References 955 [802.1Q-2011] - IEEE 802.1, "IEEE Standard for Local and metropolitan 956 area networks - Virtual Bridged Local Area Networks", IEEE Std 957 802.1Q-2011, May 2011. 959 [Err3002] - RFC Errata, Errata ID 3002, RFC 6325, http://www.rfc- 960 editor.org. 962 [Err3003] - RFC Errata, Errata ID 3003, RFC 6325, http://www.rfc- 963 editor.org. 965 [Err3004] - RFC Errata, Errata ID 3004, RFC 6325, http://www.rfc- 966 editor.org. 968 [Err3052] - RFC Errata, Errata ID 3052, RFC 6325, http://www.rfc- 969 editor.org. 971 [Err3053] - RFC Errata, Errata ID 3053, RFC 6325, http://www.rfc- 972 editor.org. 974 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 975 Intermediate System Intra-Domain Routeing Exchange Protocol for 976 use in Conjunction with the Protocol for Providing the 977 Connectionless-mode Network Service (ISO 8473)", 2002. 979 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 980 dual environments", RFC 1195, December 1990. 982 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 986 Engineering", RFC 5305, October 2008. 988 [RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 989 RFC 5306, October 2008. 991 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 992 Ghanwani, "Routing Bridges (RBridges): Base Protocol 993 Specification", RFC 6325, July 2011. 995 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 996 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 997 6327, July 2011. 999 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1000 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1001 6439, November 2011. 1003 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 1004 A. Ghanwani, draft-eastlake-isis-rfc6326bis, work in progress. 1006 Informative References 1008 [802] - IEEE 802, "IEEE Standard for Local and metropolitan area 1009 networks: Overview and Architecture", IEEE Std 802.1-2001, 8 1010 March 2002. 1012 [Channel] - Eastlake, E., Manral, V., Li, Y., Ward, D., draft-ietf- 1013 trill-rbridge-channel, work in progress. 1015 [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol 1016 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 1017 2008. 1019 Authors' Addresses 1021 Donald Eastlake 1022 Huawei R&D USA 1023 155 Beaver Street 1024 Milford, MA 01757 USA 1026 Phone: +1-508-333-2270 1027 Email: d3e3e3@gmail.com 1029 Mingui Zhang 1030 Huawei Technologies Co., Ltd 1031 Huawei Building, No.156 Beiqing Rd. 1032 Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, 1033 Beijing 100095 P.R. China 1035 Email: zhangmingui@huawei.com 1037 Anoop Ghanwani 1038 Dell 1039 350 Holger Way 1040 San Jose, CA 95134 USA 1042 Phone: +1-408-571-3500 1043 Email: anoop@alumni.duke.edu 1045 Vishwas Manral 1046 HP Networking 1047 19111 Pruneridge Avenue 1048 Cupertino, CA 95014 USA 1050 Tel: +1-408-477-0000 1051 Email: vishwas.manral@hp.com 1053 Ayan Banerjee 1054 Cumulus Networks 1055 1089 West Evelyn Avenue 1056 Sunnyvale, CA 94086 USA 1058 Email: ayabaner@gmail.com 1060 Copyright and IPR Provisions 1062 Copyright (c) 2012 IETF Trust and the persons identified as the 1063 document authors. All rights reserved. 1065 This document is subject to BCP 78 and the IETF Trust's Legal 1066 Provisions Relating to IETF Documents 1067 (http://trustee.ietf.org/license-info) in effect on the date of 1068 publication of this document. Please review these documents 1069 carefully, as they describe your rights and restrictions with respect 1070 to this document. Code Components extracted from this document must 1071 include Simplified BSD License text as described in Section 4.e of 1072 the Trust Legal Provisions and are provided without warranty as 1073 described in the Simplified BSD License. The definitive version of 1074 an IETF Document is that published by, or under the auspices of, the 1075 IETF. Versions of IETF Documents that are published by third parties, 1076 including those that are translated into other languages, should not 1077 be considered to be definitive versions of IETF Documents. The 1078 definitive version of these Legal Provisions is that published by, or 1079 under the auspices of, the IETF. Versions of these Legal Provisions 1080 that are published by third parties, including those that are 1081 translated into other languages, should not be considered to be 1082 definitive versions of these Legal Provisions. For the avoidance of 1083 doubt, each Contributor to the IETF Standards Process licenses each 1084 Contribution that he or she makes as part of the IETF Standards 1085 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1086 language to the contrary, or terms, conditions or rights that differ 1087 from or are inconsistent with the rights and licenses granted under 1088 RFC 5378, shall have any effect and shall be null and void, whether 1089 published or posted by such Contributor, or included with or in such 1090 Contribution.