idnits 2.17.00 (12 Aug 2021) /tmp/idnits61791/draft-ietf-trill-rfc6439bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2017) is 1908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 6439 (Obsoleted by RFC 8139) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Yizhou Li 3 Intended status: Proposed Standard Huawei 4 Obsoletes: 6439 Mohammed Umair 5 Updates: 6325, 7177 IPinfusion 6 Ayan Banerjee 7 Cisco 8 Fangwei Hu 9 ZTE 10 Expires: August 20, 2017 February 21, 2017 12 TRILL: Appointed Forwarders 13 15 Abstract 17 TRILL (Transparent Interconnection of Lots of Links) supports multi- 18 access LAN (Local Area Network) links where a single link can have 19 multiple end stations and TRILL switches attached. Where multiple 20 TRILL switches are attached to a link, native traffic to and from end 21 stations on that link is handled by a subset of those TRILL switches 22 called "Appointed Forwarders" as originally specified in RFC 6325, 23 with the intent that native traffic in each VLAN be handled by at 24 most one TRILL switch. This document clarifies and updates the 25 Appointed Forwarder mechanism. It updates RFC 6325, updates RFC 7177, 26 and obsoletes RFC 6439. 28 Status of This Document 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. Distribution of this document is 32 unlimited. Comments should be sent to the TRILL working group mailing 33 list . 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction...........................................4 53 1.1 Appointed Forwarders and Active-Active.................5 54 1.2 Terminology and Acronyms...............................5 56 2. Appointed Forwarders and Their Appointment..............7 57 2.1 The Appointment Databases and DRB Actions..............8 58 2.2 Appointment Effects of DRB Elections...................9 59 2.2.1 Processing Forwarder Appointments in Hellos.........10 60 2.2.2 Frequency of Hello Appointments.....................12 61 2.2.3 Appointed Forwarders Hello Limit....................12 62 2.3 Local Configuration Actions Appointment Effects.......13 63 2.4 Overload and Appointed Forwarders.....................13 64 2.5 VLAN Mapping within a Link............................14 66 3. The Inhibition Mechanism...............................15 67 3.1 Inhibited Appointed Forwarder Behavior................17 68 3.2 Root Change Inhibition Optimizations..................17 69 3.2.1 Optimization for Change to Lower Priority...........18 70 3.2.2 Optimization for Change to Priority Only............18 71 3.2.3 Settling Detection Optimization.....................18 73 4. Optional TRILL Hello Reduction.........................20 74 5. Multiple Ports on the Same Link........................22 76 6. Port-Shutdown Messages.................................23 77 6.1 Planned Shutdown and Hellos...........................23 78 6.2 Port-Shutdown Message Structure.......................23 79 6.3 Port-Shutdown Message Transmission....................24 80 6.4 Port-Shutdown Message Reception.......................25 81 6.5 Port-Shutdown Message Security........................25 82 6.6 Port-Shutdown Configuration...........................25 84 7. FGL-VLAN Mapping Consistency Checking..................27 86 8. Support of E-L1CS......................................28 87 8.1 Backwards Compatibility...............................28 89 9. Security Considerations................................29 91 10. Code Points and Data Structures.......................30 92 10.1 IANA Considerations..................................30 93 10.2 Appointment Bitmap APPsub-TLV........................30 94 10.3 Appointment List APPsub-TLV..........................31 95 10.4 FGL-VLAN Mapping Bitmap APPsub-TLV...................32 96 10.5 FGL-VLAN Mapping Pairs APPsub-TLV....................34 98 11. Management Considerations.............................35 100 Table of Contents (continued) 102 Normative References......................................36 103 Informative References....................................37 105 Acknowledgements..........................................38 106 Authors' Addresses........................................39 108 Appendix A: VLAN Inhibition Example.......................40 109 Appendix B: Changes to RFCs 6325, 6439, 7177..............41 110 Appendix C: Multi-Link VLAN Mapping Loop Example..........42 111 Appendix Z: Change Record.................................44 113 Copyright and IPR Provisions..............................45 115 1. Introduction 117 The IETF TRILL (Transparent Interconnection of Lots of Links) 118 protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame 119 forwarding without configuration in multi-hop networks with arbitrary 120 topology and link technology, safe forwarding even during periods of 121 temporary loops, and support for multipathing of both unicast and 122 multicast traffic. TRILL accomplishes this by using IS-IS 123 (Intermediate System to Intermediate System) [IS-IS] [RFC7176] link 124 state routing and encapsulating traffic using a header that includes 125 a hop count. The design supports VLANs, FGLs (Fine Grained Labels 126 [RFC7172]), and optimization of the distribution of multi-destination 127 frames based on VLANs and multicast groups. Devices that implement 128 TRILL are called TRILL switches or "RBridges" (Routing Bridges). 130 Section 2 of [RFC7177] discusses the environment for which the TRILL 131 protocol is designed and the differences between that environment and 132 the typical Layer 3 routing environment. 134 TRILL supports multi-access LAN (Local Area Network) links that can 135 have multiple end stations and TRILL switches attached. Where 136 multiple TRILL switches are attached to a link, native traffic to and 137 from end stations on that link is handled by a subset of those 138 switches called "Appointed Forwarders" as originally specified in 139 [RFC6325], with the intent that native traffic in each VLAN be 140 handled by at most one switch. A TRILL switch can be Appointed 141 Forwarder for many VLANs. 143 The purpose of this document is to update and improve the Appointed 144 Forwarder mechanism and free it from the limitations imposed by the 145 requirement in its initial design that all appointments fit within a 146 TRILL Hello PDU. This is accomplished by requiring support of link 147 scoped FS-LSPs (Flooding Scoped - Link State PDUs, Section 7) and 148 proving for appointment information to optionally be sent in those 149 LSPs. In addition this document provides a number of other optional 150 features to (1) detect inconsistent VLAN to FGL [RFC7172] mappings 151 among the TRILL switch ports on a link as discussed in Section 7, (2) 152 expedite notification of ports going down so that Appointed 153 Forwarders can be adjusted as discussed in Section 6, and (3) reduce 154 or eliminate the need for "inhibition" of ports for loop safety as 155 discussed in Section 3.2. This document replaces and obsoletes 156 [RFC6439], incorporating the former material in [RFC6439] with these 157 additions. The various optimizations are orthogonal and optional. 158 Implementers can choose to provide all, some, or none of them and 159 TRILL switches will still be interoperable. In accordance with the 160 TRILL design philosophy, these optimizations require zero or minimal 161 configuration but there are a couple of configurable parameters as 162 summarized in Section 11. 164 This document, as described in Appendix B, updates [RFC6325] by 165 mandating support of E-L1CS FS-LSPs and provides backwards 166 compatibility in the presence of legacy TRILL switches that do not 167 provide this support. It also updates [RFC7177] by providing, as an 168 optional optimization, that receipt of the port shutdown message 169 specified herein be treated as an event in the state machine 170 specified in [RFC7177]. 172 This document includes reference implementation details. Alternative 173 implementations that interoperate on the wire are permitted. 175 The Appointed Forwarder mechanism is irrelevant to any link on which 176 end station service is not offered. This includes links configured 177 as point-to-point IS-IS links and any link with all TRILL switch 178 ports on that link configured as trunk ports. (In TRILL, 179 configuration of a port as a "trunk port" just means that no end 180 station service will be provided. It does not imply that all VLANs 181 are enabled on that port.) 183 The Appointed Forwarder mechanism has no effect on the formation of 184 adjacencies, the election of the Designated RBridge (DRB, [RFC7177]) 185 for a link, MTU matching, or pseudonode formation. Those topics are 186 covered in [RFC7177]. Furthermore, Appointed Forwarder status has no 187 effect on the forwarding of TRILL Data frames; it only affects the 188 handling of native frames to and from end stations. 190 For other aspects of the TRILL base protocol, see [RFC6325], 191 [RFC7177], and [RFC7780]. In case of conflict between this document 192 and [RFC6325] or [RFC7177], this document prevails. 194 1.1 Appointed Forwarders and Active-Active 196 As discussed in [RFC7379], TRILL active-active provides support for 197 end stations connected to multiple edge TRILL switches where these 198 connections are separate links. Since TRILL Hellos are not forwarded 199 between these links, the Appointed Forwarder mechanism as described 200 herein operates separately on each such link. 202 1.2 Terminology and Acronyms 204 This document uses the acronyms and terms defined in [RFC6325], some 205 of which are repeated below for convenience, and additional acronyms 206 and terms listed below. 208 DRB: Designated RBridge. The RBridge on a link elected as specified 209 in [RFC7177] to handle certain decisions and tasks for that 210 link including forwarder appointment as specified herein. 212 E-L1CS: Extended Level 1 Circuit Scoped (Section 8). 214 FGL: Fine Grained Label [RFC7172]. 216 FS-LSP: Flooding Scoped - Link State PDU (Section 8). 218 Link: The means by which adjacent TRILL switches are connected. A 219 TRILL link may be various technologies and, in the common case 220 of Ethernet, can be a "bridged LAN", that is to say, some 221 combination of Ethernet links with zero or more bridges, hubs, 222 repeaters, or the like. 224 LSDB: Link State Data Base. 226 RBridge: An alternative name for a TRILL switch. 228 TRILL: Transparent Interconnection of Lots of Links or Tunneled 229 Routing in the Link Layer. 231 TRILL switch: A device implementing the TRILL protocol. An 232 alternative name for an RBridge. 234 Trunk port: A TRILL switch port configured with the "end station 235 service disable" bit on, as described in Section 4.9.1 of 236 [RFC6325]. 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 240 document are to be interpreted as described in [RFC2119]. 242 2. Appointed Forwarders and Their Appointment 244 The Appointed Forwarder on a link for VLAN-x is the TRILL switch 245 (RBridge) that ingresses native frames from the link and egresses 246 native frames to the link in VLAN-x. By default, the DRB (Designated 247 RBridge) on a link is in charge of native traffic for all VLANs on 248 the link. The DRB may, if it wishes, act as Appointed Forwarder for 249 any VLAN and it may appoint other TRILL switches that have ports on 250 the link as Appointed Forwarder for one or more VLANs. 252 By definition, the DRB considers the other ports on the link to be 253 the ports with which a DRB port has adjacency on that link [RFC7177]. 254 If the DRB loses adjacency to a TRILL switch that it has appointed a 255 forwarder and the native traffic that was being handled by that 256 Appointed Forwarder is still to be ingressed and egressed, it SHOULD 257 immediately appoint another forwarder or itself become forwarder for 258 that traffic. 260 It is important that there not be two Appointed Forwarders on a link 261 that are ingressing and egressing native frames for the same VLAN at 262 the same time. Should this occur, it could form a loop where frames 263 are not protected by a TRILL Hop Count for part of the loop. (Such a 264 condition can even occur through two Appointed Forwarders for two 265 different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the 266 link are configured to map frames between VLAN-x and VLAN-y as 267 discussed in Section 2.5.) While TRILL tries to avoid such 268 situations, for loop safety there is also an "inhibition" mechanism 269 (see Section 3) that can cause a TRILL switch that is an Appointed 270 Forwarder to not ingress or egress native frames. Appointed 271 Forwarder status and port "inhibition" have no effect on the 272 reception, transmission, or forwarding of TRILL Data or TRILL IS-IS 273 frames. Appointed Forwarder status and inhibition only affect the 274 handling of native frames. 276 As discussed in Section 5, an RBridge may have multiple ports on a 277 link. As discussed in [RFC7177], if there are multiple ports with 278 the same Media Access Control (MAC) address on the same link, all but 279 one will be suspended. The case of multiple ports on a link for the 280 same TRILL switch and the case of multiple ports with the same MAC 281 address on a link and combinations of these cases are fully 282 accommodated; however, multiple ports on a link for the same TRILL 283 switch is expected to be a rare condition and duplicate MAC addresses 284 is not recommended by either TRILL or IEEE 802.1 standards. 286 There are six mechanisms by which an RBridge can be appointed or un- 287 appointed as Appointed Forwarder: (1) assumption of appointment, when 288 the DRB decides to act as Appointed Forwarder for a VLAN, (2) Hello 289 appointment, as a result of appointments sent by the DRB in TRILL 290 Hellos, (3) E-L1CS appointment, as a result of appointments sent by 291 the DRB in E-L1CS FS-LSPs, (4) as a result of the DRB elections 293 [RFC7177] as discussed in Section 2.2, (5) as a result of a Port- 294 Shutdown message as discussed in Section 6, and (6) as a result of a 295 local configuration action as discussed in Section 2.3. Mechanisms 2 296 and 3 are covered in Section 2.1. 298 2.1 The Appointment Databases and DRB Actions 300 The DRB MAY appoint other RBridges on the link as Appointed 301 Forwarders through the mechanisms A and B described below. 303 Each RBridge maintains two databases of appointment information: (1) 304 its E-L1CS LSDB that shows appointments each RBridge on the link 305 would make using mechanism A if it were the DRB, and (2) its Hello 306 appointment database that shows the appointments most recently sent 307 by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is 308 only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment 309 database is more transient and is completely reset by each Hello 310 received from the DRB that contains any appointments and is also 311 cleared under other circumstances as described below. An RBridge 312 considers itself to be the Appointed Forwarder for VLAN-x if this is 313 indicated by either its Hello appointment database or its E-L1CS LSDB 314 entries from the DRB. 316 The two mechanisms by which the DRB can appoint other RBridges on a 317 link Appointed Forwarders are as follows: 319 (A) The inclusion of one or more Appointed Forwarders sub-TLVs 320 [RFC7176], Appointment Bitmap APPsub-TLVs (Section 10.2), or 321 Appointment List APPsub-TLVs (Section 10.3) in E-L1CS LSPs it 322 sends on a link. Appointments sent with this method will not be 323 seen by legacy RBridges that do not support E-L1CS (Section 8). 325 (B) The inclusion of one or more Appointed Forwarders sub-TLVs 326 [RFC7176] in a TRILL Hello it sends on the Designated VLAN out 327 the port that won the DRB election. When the DRB sends any 328 appointments in a TRILL Hello, it must send all appointments it 329 is sending in Hellos for that link in that Hello. Any previous 330 appointment it has sent in a Hello that is not included is 331 implicitly revoked. 333 To avoid the size limitations of the Hello PDU, it is RECOMMENDED 334 that the E-L1CS FS-LSP method be used to distribute forwarder 335 appointments and that all RBridges on a link advertise by this method 336 the appointments they would make if they were DRB. However, if some 337 RBridges on a link do not support E-L1CS FS-LSPs, then Hello 338 appointments must be used for the DRB to appoint such legacy RBridges 339 an Appointed Forwarder. 341 Although the DRB does not need to announce the VLANs for which it has 342 chosen to act as Appointed Forwarder by sending appoints for itself, 343 if the DRB wishes to revoke all appointments made in Hellos for 344 RBridges other than itself on the link, it can do so by sending a 345 TRILL Hello with just an appointment for itself for some VLAN. 347 How the DRB decides what other RBridges on the link, if any, to 348 appoint forwarder for which VLANs is beyond the scope of this 349 document. 351 Unnecessary changes in Appointed Forwarders SHOULD NOT be made as 352 they may result in transient lack of end station service. 354 Should the network manager have misconfigured the enabled VLANs and 355 Appointed Forwarders, resulting in two RBridges believing they are 356 Appointed Forwarders for the same VLAN, then item 4 in Section 3 will 357 cause one or more of the RBridges to be inhibited for that VLAN thus 358 avoiding persistent loops. 360 When forwarder appointments are being encoded for transmission, 361 different patterns of VLANs are most efficiently encoded in different 362 ways. The following table gives advice for the most efficient 363 encoding: 365 sub-TLV and Reference 366 Pattern of VLAN IDs |enclosing TLV(s) and Reference 367 ----------------- ------------------------------------ 369 Blocks of consecutive VLANs 370 Appointed Forwarders sub-TLV [RFC7176] 371 |Router Capabilities TLV [RFC7981] 372 |or MT Capabilities TLV [RFC6329] 374 Scattered VLANs within a small range 375 Appointment Bitmap APPsub-TLV (Section 10.2) 376 |TRILL GENINFO TLV [RFC7357] 378 Scattered VLANs over a large range 379 Appointment List APPsub-TLV (Section 10.3) 380 |TRILL GENINFO TLV [RFC7357] 382 2.2 Appointment Effects of DRB Elections 384 When a TRILL switch port on a link wins the DRB election, there are 385 four possible cases: 387 1. A TRILL switch believes it was the DRB and remains the DRB: There 388 is no change in Appointed Forwarder status. This also applies in 389 the corner case where a TRILL switch has more than one port on a 390 link, one of which was previously the DRB election winner but has 391 just lost the DRB election to a different port of the same TRILL 392 switch on the same link (possibly due to management configuration 393 of port priorities). In this case there also is no change in which 394 TRILL switch is the DRB. 396 2. A TRILL switch believes that it was not the DRB but has now won 397 the DRB election and become the DRB on a link: by default, it can 398 act as Appointed Forwarder for any VLANs on that link that it 399 chooses as long as its port is not configured as a trunk port and 400 has that VLAN enabled (or at least one of its ports meets these 401 criteria, if it has more than one port on the link). It ignores 402 any previous forwarder appointment information it received from 403 other TRILL switches on the link. 405 3. A TRILL switch was not DRB and does not become DRB but it observes 406 that the port winning the DRB election has changed: The TRILL 407 switch loses all Hello appointments. In addition, there are two 408 subcases: 409 3.a The new winning port and the old winner are ports of different 410 TRILL switches on the link. In this case, it switches to using 411 the E-L1CS FS-LSP appointments for the winning TRILL switch. 412 3.b The new winning port and the old winner are ports of the same 413 TRILL switch, which has two (or more) ports on the link: 414 Although the Hello appointments are still discarded, since the 415 same TRILL switch is DRB, the E-L1CS FS-LSP appointments are 416 unchanged. 418 4. The winning port is unchanged: As in case 1, there is no change in 419 Appointed Forwarder status. 421 2.2.1 Processing Forwarder Appointments in Hellos 423 When a non-DRB RBridge that can offer end station service on a link 424 receives a TRILL Hello that is not discarded for one of the reasons 425 given in [RFC7177], it checks the source MAC address and the Port ID 426 and System ID in the Hello to determine if it is from the winning DRB 427 port. If it is not from that port, any forwarder appointment sub- 428 TLVs in the Hello are ignored, and there is no change in the 429 receiving RBridge's Appointed Forwarder status due to that Hello. 430 Also, if no forwarder appointment sub-TLVs are present in the TRILL 431 Hello, there is no change in the receiver's Appointed Forwarder 432 status due to that Hello. 434 However, if the TRILL Hello is from the winning DRB port and the 435 Hello includes one or more forwarder appointment sub-TLVs, then the 436 receiving RBridge sets its Hello appointment database to be the VLANs 437 that are both listed for it in the Hello and are enabled on the 438 receiving port. (If the appointment includes VLAN IDs 0x000 or 439 0xFFF, they are ignored, but any other VLAN IDs are still effective.) 440 It then becomes Appointed Forwarder for all the VLANs for which it is 441 appointed in either its Hello appointment database or its E-L1CS 442 appointment database from the DRB if the VLAN is enabled and if the 443 port is not configured as a trunk or IS-IS point-to-point port. If 444 the receiver was Appointed Forwarder for any VLANs because they were 445 in the Hello appointment database and they are no longer in the Hello 446 appointment database, its Appointed Forwarder status for such VLANs 447 is revoked. For example, if none of these sub-TLVs in a Hello 448 appoints the receiving RBridge, then it loses all Appointed Forwarder 449 status on the port where the Hello was received due to Hello 450 appointment database entries but it retains Appointed Forwarder 451 status due to E-L1CS FS-LSP appointments. 453 The handling of one or more forwarder appointment sub-TLVs in a Hello 454 from the winning port that appoints the receiving RBridge is as 455 follows: An appointment in an Appointed Forwarder sub-TLV is for a 456 specific RBridge and a contiguous interval of VLAN IDs; however, as 457 stated above, it actually appoints that RBridge forwarder only for 458 the VLAN(s) in that range that are enabled on one or more ports that 459 RBridge has on the link (ignoring any ports configured as trunk ports 460 or as IS-IS point-to-point ports). 462 There is no reason for an RBridge to remember that it received a 463 valid appointment Hello message for a VLAN that was ineffective 464 because the VLAN was not enabled on the port where the Hello was 465 received or because the port was a trunk or point-to-point port. It 466 does not become Appointed Forwarder for such a VLAN just because that 467 VLAN is later enabled or the port later reconfigured. 469 The limitations due to the size of the Hello PDU make it desirable to 470 use E-L1CS FS-LSPs for appointment. But if Hellos need to be used, 471 due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the 472 remainder of this section gives a method to maximize the use of the 473 limited space in Hellos for forwarder appointment. 475 It should be straightforward for the DRB to send, within one Hello, 476 the appointments for several dozen VLAN IDs or several dozen blocks 477 of contiguous VLAN IDs. Should the VLANs that the DRB wishes to 478 appoint be inconveniently distributed (for example the proverbial 479 case where the DRB RB1 wishes to appoint RB2 forwarder for all even- 480 numbered VLANs and appoint RB3 forwarder for all odd-numbered VLANs) 481 the following method may be used: 482 The network manager normally controls what VLANs are enabled on an 483 RBridge port. Thus, the network manager can appoint an RBridge 484 forwarder for an arbitrary set of scattered VLANs by enabling only 485 those VLANs on the relevant port (or ports) and then having the 486 DRB send an appointment that appears to appoint the target RBridge 487 forwarder for all VLANs. However, for proper operation and inter- 488 RBridge communication, the Designated VLAN for a link SHOULD be 489 enabled on all RBridge ports on that link, and it may not be 490 desired to appoint the RBridge forwarder for the Designated VLAN. 491 Thus, in the general case, it would require two appointments, 492 although it would still only require one appointment if the 493 Designated VLAN were an extreme low or high value such as VLAN 494 0xFFE or the default VLAN 1. 496 For example, assume the DRB wants RB2 to be Appointed Forwarder for 497 all even-numbered VLANs and the Designated VLAN for the link is VLAN 498 101. The network manager could cause all even-numbered VLANs plus 499 VLAN 101 to be enabled on the relevant port of RB2 and then, with the 500 desired effect, cause the DRB to send appointments to RB2 appointing 501 it forwarder for all VLANs from 1 through 100 and from 102 through 502 4,094. 504 2.2.2 Frequency of Hello Appointments 506 Appointments made though E-L1CS FS-LSPs use the same IS-IS timing 507 constants as for LSP flooding. The general IS-IS link state flooding 508 mechanism is robust and includes acknowledgements so that it 509 automatically recovers from lost PDUs, re-booted TRILL switches, and 510 the like. 512 For Hello appointments, it is not necessary for the DRB to include 513 the Hello forwarder appointments in every TRILL Hello that it sends 514 on the Designated VLAN for a link. For loop safety, every RBridge is 515 required to indicate, in every TRILL Hello it sends in VLAN-x on a 516 link, whether it is an Appointed Forwarder for VLAN-x for that link 517 (see item 4 in Section 3 but see also Section 4). It is also 518 RECOMMENDED that the DRB have enabled all VLANs for which end station 519 service will be offered on the link as well as the Designated VLAN. 520 Thus, the DRB will generally be informed by other RBridges on the 521 link of the VLANs for which they believe they are Appointed 522 Forwarder. If this matches the appointments the DRB wishes to make, 523 it is not required to re-send its forwarder appointments; however, 524 for robustness, especially in cases such as VLAN misconfigurations in 525 a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder 526 appointments on the Designated VLAN at least once per its Holding 527 Time on the port that won the DRB election. 529 2.2.3 Appointed Forwarders Hello Limit 531 The Hello mechanism of DRB forwarder appointment and the limited 532 length of TRILL Hellos impose a limit on the number of RBridges on a 533 link that can be Appointed Forwarders when E-L1CS FS-LSP appointments 534 cannot be used due to the presence of legacy RBridges. To obtain a 535 conservative estimate of this limit, assume that no more than 1000 536 bytes are available in a TRILL Hello for such appointments. Assume 537 it is desired to appoint various RBridges on a link forwarder for 538 arbitrary non-intersecting sets of VLANs. Using the technique 539 discussed at the end of Section 2.2.1 would generally require two 540 appointments, or 12 bytes, per RBridge. With allowance for sub-TLV 541 and TLV overhead, appointments for 83 RBridges would fit in under 542 1000 bytes. Including the DRB, this implies a link with 84 or more 543 RBridges attached. Links with more than a handful of RBridges 544 attached are expected to be rare. And in any case such limitations 545 are easily avoided by using E-L1CS FS-LSP appointment. 547 2.3 Local Configuration Actions Appointment Effects 549 Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder 550 status that RBridge has for VLAN-x unless VLAN-x is enabled on some 551 other port that the RBridge has connected to the same link. 552 Configuring a port as a trunk port or point-to-point port revokes any 553 Appointed Forwarder status that depends on enabled VLANs at that 554 port. 556 Causing a port to no longer be configured as a trunk or point-to- 557 point port or enabling VLAN-x on a port does not necessarily cause 558 the RBridge to become an Appointed Forwarder for the link that port 559 is on. However, such actions allow the port's RBridge to become 560 Appointed Forwarder by choice if it is the DRB or, if it is not the 561 DRB on the link, by appointment as indicated by the Hello or E-L1CS 562 FS-LSP appointment databases. 564 2.4 Overload and Appointed Forwarders 566 A TRILL switch in link state overload [RFC7780] will, in general, do 567 a poorer job of forwarding frames than a TRILL switch not in overload 568 because the TRILL switch not in overload has full knowledge of the 569 campus topology. For example, as explained in [RFC7780], an 570 overloaded TRILL switch may not be able to distribute multi- 571 destination TRILL Data packets at all. 573 Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an 574 Appointed Forwarder and, if an Appointed Forwarder becomes 575 overloaded, the DRB SHOULD re-assign VLANs from the overloaded 576 RBridge to another RBridge on the link that is not overloaded, if one 577 is available. 579 This does not violate the IS-IS standards prohibition on routing 580 through an overloaded node. Designation as an appointed forwarder has 581 to do with the ingress and egress of native frames and has nothing to 582 do with the IS-IS routing of TRILL Data packets through a TRILL 583 switch. 585 A counter-example where it would be best to appoint an RBridge in 586 overload as appointed forwarder would be if RB1 was in overload but 587 all end stations in the campus in VLAN-x were on links attached to 588 RB1. In such a case, RB1 would never have to route VLAN-x end 589 station traffic as a TRILL Data packet but would always be forwarding 590 it locally as a native frame. In this case, RB1 SHOULD NOT be 591 disadvantaged for selection as the VLAN-x Appointed Forwarder on any 592 such links even if EB1 is in overload. 594 There is also the case where it is unavoidable to appoint an RBridge 595 in overload as appointed forwarder because all RBridges on the link 596 are in overload. 598 Overload does not affect DRB election but a TRILL switch in overload 599 MAY reduce its own priority to be DRB. 601 2.5 VLAN Mapping within a Link 603 TRILL Hellos include a field that is set to the VLAN in which they 604 are sent when they are sent on a link technology such as Ethernet 605 that has outer VLAN labeling. (For link technologies such as PPP 606 that do not have outer VLAN labeling, this Hello field is ignored.) 607 If a TRILL Hello arrives on a different VLAN than it was sent on, 608 then VLAN mapping is occurring within the link. VLAN mapping between 609 VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for 610 the VLANs are different. If such mapping within a link was allowed 611 and occurred on two or more links so that there was a cycle of VLAN 612 mappings, a multi-destination frame would loop forever. Such a frame 613 would be immortal. For a specific example, see Appendix C. 615 To prevent this potential problem, if the DRB on a link detects VLAN 616 mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it 617 MUST make or revoke appointments so as to assure that the same TRILL 618 switch (possibly the DRB) is the Appointed Forwarder on the link for 619 both VLAN-x and VLAN-y. 621 3. The Inhibition Mechanism 623 A TRILL switch has, for every link on which it can offer end station 624 service (that is every link for which it can act as an Appointed 625 Forwarder), the following timers denominated in seconds: 627 - a DRB inhibition timer, 629 - a root change inhibition timer, and 631 - up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. 633 The DRB and root change inhibition timers MUST be implemented. 635 The loss of native traffic due to inhibition will be minimized by 636 logically implementing a VLAN inhibition timer per each VLAN for 637 which end station service will ever be offered by the RBridge on the 638 link; this SHOULD be done. (See Appendix A for an example motivating 639 VLAN inhibition timers.) However, if implementation limitations make 640 a full set of such timers impractical, the VLAN inhibition timers for 641 more than one VLAN can, with care, be merged into one timer. In 642 particular, an RBridge MUST NOT merge the VLAN inhibition timers 643 together for two VLANs if it is the Appointer Forwarder for one and 644 not for the other, as this can lead to unnecessary indefinitely 645 prolonged inhibition. In the limit, there will be safe operations, 646 albeit with more native frame loss than would otherwise be required, 647 even if only two VLAN inhibition timers are provided: one for the 648 VLANs for which the RBridge is the Appointed Forwarder and one for 649 all other VLANs. Thus, at least two VLAN inhibition timers MUST be 650 implemented. Where a VLAN inhibition timer represents more than one 651 VLAN, an update or test that would have been done to the timer for 652 any of the VLANs is performed on the merged timer. 654 These timers are set as follows: 656 1. On booting or management reset, each port will have its own set of 657 timers, even if two or more such ports are on the same link, 658 because the TRILL switch will not have had a chance yet to learn 659 they are on the same link. All inhibition timers are set to 660 expired except the DRB inhibition timer that is set in accordance 661 with item 2 below. The DRB inhibition timer is handled 662 differently because each port will initially believe it is the 663 DRB. 665 2. When a TRILL switch decides that it has become the DRB on a link, 666 including when it is first booted or reset by management, it sets 667 the DRB inhibition timer to the Holding Time of its port on that 668 link that won the DRB election. 670 3. When a TRILL switch decides that it has lost DRB status on a link, 671 it sets the DRB inhibition timer to expired. 673 Note: In the corner case where one port of a TRILL switch was the DRB 674 election winner, but later lost the DRB election to a different 675 port of the same TRILL switch on that link (perhaps due to 676 management configuration of port priorities), neither 2 nor 3 677 above applies, and the DRB timer is not changed. 679 4. When a TRILL switch RB1 receives a TRILL Hello asserting that the 680 sender is the Appointed Forwarder and that Hello either (1) 681 arrives on VLAN-x or (2) was sent on VLAN-x as indicated inside 682 the Hello, then RB1 sets its VLAN-x inhibition timer for the link 683 to the maximum of that timer's existing value and the Holding Time 684 in the received Hello. A TRILL switch MUST maintain VLAN 685 inhibition timers covering a link to which it connects if it can 686 offer end station service on that link even if it is not currently 687 Appointed Forwarder for any VLAN on that link. 689 5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a 690 link and VLAN-x was previously not enabled on any of RB1's ports 691 on that link, it sets its VLAN inhibition timer for VLAN-x for 692 that link to its Holding Time for that port. This is done even if 693 the port is configured as a trunk or point-to-point port as long 694 as there is some chance it might later be configured not to be a 695 trunk or point-to-point port. Remember, inhibition has no effect 696 on TRILL Data or IS-IS packets, inhibition only affects native 697 frames. 699 6. When a TRILL switch detects a change in the common spanning tree 700 root bridge on a port, it sets its root change inhibition timer 701 for the link to an amount of time that defaults to 30 seconds and 702 is configurable to any value from 30 down to zero seconds. This 703 condition will not occur unless the TRILL switch is receiving 704 Bridge PDU (BPDUs) on the port from an attached bridged LAN; if no 705 BPDUs are being received, the root change inhibition timer will 706 never be set. It is safe to configure this inhibition time to the 707 settling time of an attached bridged LAN. For example, if it is 708 known that Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running 709 throughout the attached bridged LAN, it is safe to configure this 710 inhibition time to 7 seconds or, if the attached bridges have been 711 configured to have a minimum Bridge Hello Timer, safe to configure 712 it to 4 seconds. Further optimizations are specified in Section 713 3.2. 715 7. When a TRILL switch decides that one of its ports (or a set of its 716 ports) P1 is on the same link as another of its ports (or set of 717 its ports) P2, then the inhibition timers are merged to a single 718 set of inhibition timers by using the maximum value of the 719 corresponding timers as the initial value of the merged timers. 721 8. When an RBridge decides that a set of its ports that it had been 722 treating as being on the same link are no longer on the same link, 723 those ports will necessarily be on two or more links (one link per 724 port in the limit). This is handled by cloning a copy of the 725 timers for each of the two or more links to which the TRILL switch 726 has decided these ports connect. 728 3.1 Inhibited Appointed Forwarder Behavior 730 Inhibition has no effect on the receipt or forwarding of TRILL Data 731 packets or TRILL IS-IS packets. It only affects ingressing and 732 egressing native frames. 734 An Appointed Forwarder for a link is inhibited for VLAN-x if: 736 1. its DRB inhibition timer for that link is not expired, or 738 2. its root change inhibition timer for that link is not expired, or 740 3. its VLAN inhibition timer for that link covering VLAN-x is not 741 expired. 743 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 744 a TRILL Data packet whose encapsulated frame would normally be 745 egressed to that link in VLAN-x, it decapsulates the native frame as 746 usual. However, it does not output it to, or queue it for, that 747 link, although, if appropriate (for example, the frame is multi- 748 destination), it may output it to, or queue it for, other links. 750 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 751 a native frame in VLAN-x that would normally be ingressed from that 752 link, the native frame is ignored except for address learning. 754 An TRILL switch with one or more unexpired inhibition timers, 755 possibly including an unexpired inhibition timer covering VLAN-x, is 756 still required to indicate in TRILL Hellos it sends on VLAN-x whether 757 or not it is Appointed Forwarder for VLAN-x for the port on which it 758 sends the Hello. 760 3.2 Root Change Inhibition Optimizations 762 The subsections below specify three optimizations that can reduce 763 inhibition time of an RBridge port under certain circumstances for 764 changes in the root Bridge ID being received by that port and thus 765 decrease any transient interruption in end station service due to 766 inhibition. TRILL switches MAY implement these optimizations. In the 767 first two optimizations, inhibition can be eliminated entirely under 768 some circumstances. These optimizations are a bit heuristic in that 769 with some unlikely multiple changes in a bridged LAN that occur 770 simultaneously or nearly so the optimizations make transient looping 771 more likely. 773 3.2.1 Optimization for Change to Lower Priority 775 Assume the root Bridge ID being received on an RBridge port changes 776 to a new root Bridge ID with lower priority and a different root 777 Bridge MAC address due to a single change in the bridged LAN. There 778 are two possible reasons for this: (1) the bridged LAN to which the 779 port is connected has partitioned due to link failure or otherwise, 780 and the port is connected to a part that does not contain the 781 original root bridge; (2) the original root bridge has been 782 reconfigured to have a lower priority and a new root has taken over. 783 Both of these are safe conditions that do not require inhibition. 785 3.2.2 Optimization for Change to Priority Only 787 Assume the root Bridge ID changes due to a single change in the 788 bridged LAN but only the explicit priority portion of it changes. 789 This means that the 48-bit MAC address portion is unchanged so the 790 root bridge has been reconfigured to have a different priority but 791 the same bridge is root and there has been no topology change. Thus, 792 it is safe to ignore this sort of root Bridge ID change and not 793 invoke the inhibition mechanism. 795 3.2.3 Settling Detection Optimization 797 The dangerous case is the merger of bridged LANs that had been 798 separate TRILL links in the same campus. In general, these links may 799 have had different Appointed Forwarders on them for the same VLAN. 800 Without inhibition, after the merger, you could have loops involving 801 those VLANs. 803 (Only native frames egressed and ingressed by RBridges are a 804 potential problem. TRILL data packets are either individually 805 addressed (TRILL Header M bit = 0) and will be ignored if delivered 806 to any incorrect TRILL switch ports, or multicast (TRILL Header M bit 807 = 1), in which case the Reverse Path Forwarding Check discards any 808 copies delivered to incorrect TRILL switch ports. Thus there is no 809 need for inhibition to affect sending or receiving TRILL data packets 810 and inhibition does not do so.) 811 However, root change inhibition is only needed until TRILL Hellos 812 have been exchanged on the merged bridged LAN. Hellos indicate 813 Appointed Forwarder status and, in general, after an exchange of 814 Hellos the new merged bridged LAN link will, if necessary, be 815 rendered TRILL loop safe by VLAN inhibition so that root change 816 inhibition is not longer needed. 818 TRILL switches are required to advertise in their link state the IDs 819 of the root Bridge IDs they can see. If an RBridge port sees a change 820 in root Bridge ID from Root1 to Root2, it is safe to terminate root 821 bridge inhibition on that port as soon as Hellos have been received 822 on the port from all RBridges that can see Root1 or Root2 except any 823 such RBridge that is no longer reachable. 825 In further detail, when a change from Root1 to Root2 is noticed at a 826 port of RB1, RB1 associates with that port a list of all of the 827 reachable RBridges, other than itself, that had reported in their LSP 828 that they could see either Root1 or Root2. It then removes from this 829 list any RBridge that becomes unreachable from RB1 or from which it 830 has received a Hello on that port. If there is a subsequent change in 831 root Bridge ID being received before this list is empty, say to 832 Root7, then those RBridges reporting in their LSP that they can see 833 Root7 are added to the list. Root bridge change inhibition can be 834 terminated for the port as soon as either the timeout is reach or 835 this list of RBridges is empty. 837 If the optimizations in Sections 3.2.1 and/or 3.2.2 are in effect at 838 an RBridge port and indicate that no inhibition is needed, then the 839 mechanism in this section is not needed either. 841 4. Optional TRILL Hello Reduction 843 If a network manager has sufficient confidence that they know the 844 configuration of bridges, ports, and the like, within an Ethernet 845 link, they may be able to reduce the number of TRILL Hellos sent on 846 that link by sending Hellos in fewer VLANs; for example, if all TRILL 847 switches on the link will see all Hellos without VLAN constraints. 848 However, because adjacencies are established in the Designated VLAN, 849 an RBridge MUST always attempt to send Hellos in the Designated VLAN. 851 Hello reduction makes TRILL less robust in the face of decreased VLAN 852 connectivity within a link, such as partitioned VLANs, VLANs disabled 853 on ports, or disagreement over the Designated VLAN; however, as long 854 as all RBridge ports on the link are configured for the same Desired 855 Designated VLAN, can see each other's frames in that VLAN, and 856 utilize the mechanisms specified below to update VLAN inhibition 857 timers, operations will be safe. (These considerations do not arise 858 on links between RBridges that are configured as point-to-point 859 since, in that case, each RBridge sends point-to-point Hellos, other 860 TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to 861 be the Designated VLAN of the link (although it may send them un- 862 tagged) and no native frame end-station service is provided. Thus, 863 for such links, there is no reason to send Hellos in any other VLAN 864 than the Designated VLAN.) 866 The provision for a configurable set of "Announcing VLANs", as 867 described in Section 4.4.3 of [RFC6325], provides a mechanism in the 868 TRILL base protocol for a reduction in TRILL Hellos. 870 To maintain loop safety in the face of occasional lost frames, 871 RBridge failures, link failures, new RBridges coming up on a link, 872 and the like, the inhibition mechanism specified in Section 3 is 873 still required. Strictly following Section 3, a VLAN inhibition timer 874 can only be set by the receipt of a Hello sent or received in that 875 VLAN. Thus, to safely send a reduced number of TRILL Hellos on a 876 reduced number of VLANs requires additional mechanisms to set the 877 VLAN inhibition timers at an RBridge, thus extending Section 3. Two 878 such mechanisms are specified below. Support for both of these 879 mechanisms is indicated by a capability bit in the PORT-TRILL-VER 880 sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge 881 to send TRILL Hellos on fewer VLANs than the set of VLANs recommended 882 in [RFC6325] on a link unless all its adjacencies on that link 883 (excluding those in the Down state [RFC7177]) indicate support of 884 these mechanisms and these mechanisms are in use. 886 1. An RBridge RB2 MAY include in any TRILL Hello an Appointed 887 Forwarders sub-TLV [RFC7176] appointing itself for one or more 888 ranges of VLANs. The Appointee Nickname field(s) in the self- 889 appointment Appointed Forwarder sub-TLV MUST be the same as the 890 Sender Nickname in the Special VLANs and Flags sub-TLV in the 891 TRILL Hellos sent by RB2. This indicates the sending RBridge 892 believes it is Appointed Forwarder for those VLANs. An RBridge 893 receiving such a sub-TLV sets each of its VLAN inhibition timers 894 for every VLAN in the block or blocks listed in the Appointed 895 Forwarders sub-TLV to the maximum of its current value and the 896 Holding Time of the Hello containing the sub-TLV. This is 897 backward compatible. That is, such sub-TLVs will have no effect on 898 any legacy receiving RBridge not implementing this mechanism 899 unless RB2, the sending RBridge, is the DRB (Designated RBridge) 900 sending Hellos on the Designated VLAN. If RB2 is DRB, it MUST 901 include in the Hello all forwarder appointments, if any, for 902 RBridges other than itself on the link. 904 2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When 905 RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 906 on any VLAN, RB1 updates the VLAN inhibition timers for all the 907 VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is 908 Appointed Forwarder. Each such timer is updated to the maximum of 909 its current value and the Holding Time of the TRILL Hello 910 containing the VLANs Appointed sub-TLV. This sub-TLV will be an 911 unknown sub-TLV to RBridges not implementing it, and such RBridges 912 will ignore it. Even if a TRILL Hello sent by the DRB on the 913 Designated VLAN includes one or more VLANs Appointed sub- TLVs, as 914 long as no Appointed Forwarders sub-TLVs appear, the Hello is not 915 required to indicate all forwarder appointments. 917 Two different encodings are provided above to optimize the listing of 918 VLANs. Large blocks of contiguous VLANs are more efficiently encoded 919 with the Appointed Forwarders sub-TLV, and scattered VLANs are more 920 efficiently encoded with the VLANs Appointed sub-TLV. These 921 encodings may be mixed in the same Hello. The use of these sub-TLVs 922 does not affect the requirement that the "AF" bit in the Special 923 VLANs and Flags sub-TLV MUST be set if the originating RBridge 924 believes it is Appointed Forwarder for the VLAN in which the Hello is 925 sent. 927 If the above mechanisms are used on a link, then each RBridge on the 928 link MUST send Hellos in one or more VLANs with such VLANs Appointed 929 sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), 930 and the "AF" bit is appropriately set such that no VLAN inhibition 931 timer will improperly expire unless three or more Hellos are lost. 932 For example, an RBridge could announce all VLANs for which it 933 believes it is Appointed Forwarder in a Hello sent on the Designated 934 VLAN three times per Holding Time. 936 5. Multiple Ports on the Same Link 938 A TRILL switch may have multiple ports on the same link. Some of 939 these ports may be suspended due to MAC address duplication as 940 described in [RFC7177]. Suspended ports never ingress or egress 941 native frames. 943 If a TRILL switch has one or more non-suspended ports on a link and 944 those ports offer end station service, that is, those ports are not 945 configured as point-to-point or trunk ports, then that TRILL switch 946 is eligible to be an Appointed Forwarder for that link. It can 947 become Appointed Forwarder in the ways discussed in Section 2. 949 If a TRILL switch that is the Appointed Forwarder for VLAN-x on a 950 link has multiple non-suspended ports on that link, it may load share 951 the task of ingressing and egressing VLAN-x native frames across 952 those ports however it chooses, as long as there is no case in which 953 a frame it egresses onto the link from one port can be ingressed on 954 another of its ports, creating a loop. If the TRILL switch is the 955 Appointed Forwarder for multiple VLANs, a straightforward thing to do 956 would be to partition those VLANs among the ports it has on the link. 958 6. Port-Shutdown Messages 960 A TRILL switch may note that one of its ports has failed or it may be 961 about to shut down that port. If the port is on a link along with 962 ports of other TRILL switches, those TRILL switches will not notice 963 the port shutdown or failure using TRILL base protocol mechanisms 964 until there is a failure to receive a number of Hellos from that 965 port. This can take many seconds. Network topology (adjacencies) and 966 forwarder appointments can react more rapidly to port shutdown or 967 failure through explicit notification. As discussed below, this 968 notification SHOULD be provided through the Port-Shutdown message. 970 6.1 Planned Shutdown and Hellos 972 A TRILL switch that is shutting down one of its ports P1 soon SHOULD 973 reduce its Holding Time on that port, so that the shutdown will be 974 more rapidly noticed by adjacent RBridges that might not support the 975 Port Shutdown message. 977 6.2 Port-Shutdown Message Structure 979 The Port-Shutdown Message is an RBridge Channel Message [RFC7178] 980 using RBridge Channel protocol number tbd5. The Channel Protocol 981 specific payload consists of a list of Port IDs (see Section 4.4.2 of 982 [RFC6325]) for the port or ports that have failed or are being 983 shutdown as shown below. Support for the Port Shutdown message is 984 advertised by simply advertising support for its RBridge Channel 985 protocol in the RBridge Channel Protocols Sub-TLV [RFC7176]. 987 0 1 2 3 988 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 989 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | V |A|C|M| RESV |F| Hop Count | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Egress Nickname | Ingress Nickname | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Special Inner.MacDA = All-Egress-RBridges | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Special Inner.MacDA cont. | Inner.MacSA | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Inner.MacSA cont. | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 RBridge Channel Header: 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=tbd5 | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Flags | ERR=0 | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 Information specific to the Port-Shutdown Channel Protocol: 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Port ID 1 | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Port ID 2 | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | ... 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Port ID K | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 6.3 Port-Shutdown Message Transmission 1021 For robustness, a TRILL switch sends a configurable number of copies 1022 of Port-Shutdown messages separated by a configurable time interval. 1023 The default number of copies is two, although this can be configured 1024 as one copy or as three copies, and the default interval is 20 1025 milliseconds (see Section 6.6). As with any adjacency critical 1026 message, the Port-Shutdown Message SHOULD be sent with highest 1027 priority 7 and SHOULD NOT be marked as drop eligible. 1029 If a failure of port P1 on RBridge RB2 is detected by RB2, then the 1030 Port-Shutdown message announcing this is sequentially unicast through 1031 the rest of the TRILL campus to all RBridges with which P1 had an 1032 adjacency and which are advertising support for the Port-Shutdown 1033 RBridge Channel protocol. 1035 If a port shutdown is planned within one second, then the TRILL 1036 switch ceases to send Hellos out the port being shut down and either 1037 (1) sends the Port-Shutdown message to RBridge ports on the link 1038 advertising support of the Port-Shutdown RBridge Channel protocol, or 1039 (2) broadcasts the Port-Shutdown message announcing this through the 1040 port as follows: 1041 - The Outer.MacDA is the All-RBridges multicast address. 1042 - If an outer VLAN tag is present, it specifies the designated 1043 VLAN for the link, SHOULD specify priority 7, and SHOULD NOT 1044 specify drop eligible. 1045 - In the TRILL Header, the egress nickname is All-RBridges and the 1046 M bit in the TRILL Header set to 0. 1047 - In the RBridge Channel Header, the MH and NA bits are zero. 1049 There is no need for a special message to indicate that a port P1 has 1050 come back up or that a shutdown has been "cancelled". This is 1051 indicated by simply sending Hellos out port P1. 1053 6.4 Port-Shutdown Message Reception 1055 When a TRILL switch RB1 receives a Port-Shutdown message RB1 checks 1056 that the ingress nickname specifies some TRILL switch RB2 with which 1057 RB1 has one or more adjacencies. If so, it drops those adjacencies 1058 that are to RB2 ports whose Port IDs are listed in the Port-Shutdown 1059 message. There could be more than one if RB2 had multiple ports on 1060 the link that are going down. 1062 If RB1 is DRB and this eliminates all adjacencies on a link between 1063 the DRB and RB2, then, for all VLANs whose ingress/egress was being 1064 handled by RB2, the DRB either starts acting an Appointed Forwarder 1065 or appoints some new TRILL switch with which it has adjacency as 1066 Appointed Forwarder. 1068 6.5 Port-Shutdown Message Security 1070 Port-Shutdown messages can be secured through use of the Channel 1071 Tunnel security features [RFC7978]. 1073 6.6 Port-Shutdown Configuration 1075 There are two Port-Shutdown configuration parameters (see Section 1076 6.3): 1078 Parameter Default Range 1079 --------- --------- ------- 1080 PShutdownRepeat 2 1-3 1081 PShutdownDelay 20ms 0-1000 milliseconds 1083 7. FGL-VLAN Mapping Consistency Checking 1085 TRILL switches support 24-bit Fine Grained Labels as specified in 1086 [RFC7172]. Basically a VLAN ID in native traffic between an edge 1087 TRILL switch and an end station is mapped from/to an FGL as an 1088 Inner.Label in TRILL Data packets. Since the Appointed Forwarder for 1089 a VLAN will be ingressing and egressing such native traffic, the 1090 mapping configured at the Appointed Forwarder is the mapping 1091 performed. 1093 However, the Appointed Forwarder for VLAN-x on a link can change for 1094 reasons discussed elsewhere in this document. Thus all TRILL switches 1095 on a link that are configured with a FGL-VLAN mapping SHOULD be 1096 configured with the same mapping. Otherwise traffic might 1097 unpredictably jump from one FGL to another when the Appointed 1098 Forwarder changes. TRILL switches SHOULD advertise their mapping on 1099 the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs 1100 (Sections 10.4 and 10.5) so that consistency checking can be 1101 automated. 1103 A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees 1104 advertised by other TRILL switches on a link with its own and alert 1105 the network operator if they are inconsistent. Inconsistent means 1106 that (1) one TRILL switch maps FGL-z to VLAN-x while another maps 1107 FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while 1108 another maps VLAN-x to FGL-z, all on the same link. 1110 Depending on how the network is being managed, a transient 1111 inconsistency may not be a problem. Thus the network operator SHOULD 1112 NOT be alerted unless the inconsistency persists for a period of time 1113 which defaults to the TRILL switch's Holding Time and is configurable 1114 to between zero and 2**16 - 1 seconds where 2**16 - 1 is a special 1115 value and indicates that such alerts are disabled. 1117 8. Support of E-L1CS 1119 All TRILL switches MUST support the E-L1CS flooding scope [RFC7356], 1120 E-L1FS flooding scope [RFC7780], and base LSPs [IS-IS]. It will be 1121 apparent to any TRILL switch on a link if any other TRILL switch on 1122 the link is a legacy implementation not supporting E-L1CS because, as 1123 stated in [RFC7780], all TRILL switches MUST include a Scoped 1124 Flooding Support TLV [RFC7356] in all TRILL Hellos they send. This 1125 support of E-L1CS increases the amount of information from each TRILL 1126 switch that can be synchronized on the link, compared with the 1127 information capacity of Hellos, by several orders of magnitude. 1129 For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs, and 1130 E-L1CS FS-PSNPs) MUST NOT exceed 1470 bytes in length; however, any 1131 such E-L1CS PDU that is received that is longer than 1470 bytes is 1132 processed normally. 1134 As with any type of IS-IS LSP, FS-LSPs are identified by the System 1135 ID of the originating router (TRILL switch) and the fragment number. 1136 In particular, there is no port identifier in the header of a E-L1CS 1137 PDU. Thus a TRILL switch RB1 with more than one non-suspended port on 1138 a link (Section 5) transmitting such a PDU MAY transmit it out any 1139 one or more of such ports. RB1 will generally receive such a PDU that 1140 other TRILL switches send on all of RB1's ports on the link. In 1141 addition, with multiple ports on the link, it will receive any such 1142 PDU that it sends on the ports it has on the link other than the 1143 transmitting port. 1145 8.1 Backwards Compatibility 1147 Future TRILL specifications making use of E-L1CS MUST specify how 1148 situations involving a TRILL link will be handled when one or more 1149 TRILL switches attached to that link support E-L1CS and one or more 1150 do not. 1152 9. Security Considerations 1154 This document provides improved documentation of the TRILL Appointed 1155 Forwarder mechanism. It does not change the security considerations 1156 of the TRILL base protocol as described in Section 6 of [RFC6325]. 1158 The Port-Shutdown messages specified in Section 6 are sent using the 1159 RBridge Channel facility [RFC7178]. Such messages SHOULD be secured 1160 through use of the RBridge Channel Header Extension [RFC7978]. If 1161 they are not adequately secured, they are a potential denial of 1162 service vector. 1164 The E-L1CS FS-LSPs added by Section 6 are a type of IS-IS PDU 1165 [RFC7356]. As such, they are securable through the addition of 1166 Authentication TLVs [RFC5310] in the same way as Hellos or other IS- 1167 IS PDUs. 1169 10. Code Points and Data Structures 1171 This section provides IANA Considerations for this document and 1172 specifies the structure of the Appointment Bitmap, Appointment List, 1173 VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs. 1174 These APPsub-TLVs appears within a TRILL GENINFO TLV [RFC7357] in E- 1175 L1CS FS-LSPs [RFC7356]. 1177 10.1 IANA Considerations 1179 IANA is requested to assign four new APPsub-TLV type codes from the 1180 range below 255 and enter them in the "TRILL APPsub-TLV Types under 1181 IS-IS TLV 251 Application Identifier 1" Registry as follows: 1183 Type Name Reference 1184 ---- ----------------- --------------- 1185 tbd1 AppointmentBitmap [this document] 1186 tbd2 AppointmentList [this document] 1187 tbd3 FGL-VLAN-Bitmap [this document] 1188 tbd4 FGL-VLAN-Pairs [this document] 1190 IANA is requested to assign a new RBridge Channel protocol number in 1191 the range assigned by Standards Action and update the "RBridge 1192 Channel Protocols" registry as follows: 1194 Protocol Description Reference 1195 -------- -------------- --------- 1196 tbd5 Port Shut-Down [this document] 1198 IANA is requested to update the reference for the "Hello reduction 1199 support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags" 1200 registry on the TRILL Parameters IANA web page to refer to this 1201 document. 1203 10.2 Appointment Bitmap APPsub-TLV 1205 The Appointment Bitmap APPsub-TLV provides an efficient method for a 1206 TRILL switch to indicate which TRILL switches it appoints as 1207 forwarders for which VLAN IDs when those VLAN IDs are relatively 1208 compact, that is, they do not span a large numeric range. Such 1209 appointment is only effective when the appointing TRILL switch is 1210 DRB. 1212 1 1 1 1 1 1 1213 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Type | (2 bytes) 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Length | (2 bytes) 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Appointee Nickname | (2 bytes) 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | RESV | Starting VLAN ID | (2 bytes) 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Bit Map ... (variable) 1224 +-+-+-+-+-+-+-+-... 1226 o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV tbd1. 1228 o Length: 4 + size of bit map in bytes. If Length is less than 4, 1229 the APPsub-TLV is corrupt and MUST be ignored. 1231 o Appointee Nickname: The nickname of the TRILL switch being 1232 appointed a forwarder. 1234 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 1236 o Starting VLAN ID: The smallest VLAN ID to which the bits in the 1237 Bit Map correspond. 1239 o Bit Map: A bit map of the VLANs for which the TRILL switch with 1240 appointee nickname is appointed the forwarder. The size of the bit 1241 map is length minus 4. If the size of the bit map is zero, no 1242 appointments are made. 1244 Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the 1245 VLAN whose ID appears in the Starting VLAN field. Bit 1 is for that 1246 VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and so on 1247 with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and 1248 VLAN 0xFFF or any larger ID are invalid and are ignored. 1250 If the Appointment Bitmap APPsub-TLV is originated by the DRB on a 1251 link, it appoints the TRILL switch whose nickname appears in the 1252 Appointee Nickname field for the VLAN IDs corresponding to 1 bits in 1253 the Bit Map and revokes any Hello appointment of that TRILL switch 1254 for VLANs corresponding to 0 bits in the Bit Map. 1256 10.3 Appointment List APPsub-TLV 1258 The Appointment List APPsub-TLV provides a convenient method for a 1259 TRILL switch to indicate which TRILL switches it appoints as 1260 forwarders for which VLAN IDs. Such appointment is only effective 1261 when the appointing TRILL switch is DRB. 1263 1 1 1 1 1 1 1264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Type | (2 bytes) 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Length | (2 bytes) 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Appointee Nickname | (2 bytes) 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | RESV | VLAN ID 1 | (2 bytes) 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | RESV | VLAN ID 2 | (2 bytes) 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | ... 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | RESV | VLAN ID k | (2 bytes) 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 o Type: APPsub-TLV type, set to AppointmentList sub-TLV tbd2. 1283 o Length: 2+2*k. If Length is not an even number, the APPsub-TLV 1284 is corrupt and MUST be ignored. 1286 o Appointee Nickname: The nickname of the TRILL switch being 1287 appointed a forwarder. 1289 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 1291 o VLAN ID: A 12-bit VLAN ID for which appointee is being 1292 appointed the forwarder. 1294 Type and Length are 2 bytes because these are extended FS-LSPs. 1296 This APPsub-TLV, when originated by the DRB, appoints the TRILL 1297 switch with Appointee Nickname to be the Appointed Forwarder for the 1298 VLAN IDs listed. 1300 10.4 FGL-VLAN Mapping Bitmap APPsub-TLV 1302 The FGL-VLAN Mapping Bitmap APPsub-TLV provides a method for a TRILL 1303 switch to indicate the FGL to VLAN ID mappings it is configured to 1304 perform when egressing and ingressing native frames. The coding is 1305 efficient when the VLAN IDs are compact, that is, they do not span a 1306 large numeric range, and the FGLs and VLANs are paired in a 1307 monotonically increasing fashion. 1309 1 1 1 1 1 1 1310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Type | (2 bytes) 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Length | (2 bytes) 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | RESV | Starting VLAN ID | (2 bytes) 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Starting FGL | (3 bytes) 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Bit Map ... (variable) 1321 +-+-+-+-+-+-+-+-... 1323 o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV tbd3. 1325 o Length: 5 + size of bit map in bytes. If Length is less than 5, 1326 the APPsub-TLV is corrupt and MUST be ignored. 1328 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 1330 o Starting VLAN ID: Initial VLAN ID for the mapping information 1331 as discussed below. 1333 o Starting FGL: Fine Grained Label [RFC7172] 1335 o Bit Map: Map of bits for VLANs to FGL mappings. The size of the 1336 bit map is Length minus 5. If the size of the bit map is zero, no 1337 mappings are indicated. 1339 Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. Bit 0 1340 is for the VLAN whose ID appears in the Starting VLAN field and the 1341 Fine Grained Label that appears in the FGL field. Bit 1 is for that 1342 VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as 1343 unsigned integers) and so on with Bit N generally being Starting VLAN 1344 ID plus N and FGL plus N. 1346 If a Bit Map bit is a 1, it indicates that the advertising TRILL 1347 switch will map between the corresponding VLAN ID and FGL on 1348 ingressing native frames and egressing TRILL Data packets if it is 1349 Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does 1350 not indicate any configured VLAN ID to FGL mapping. However, VLAN ID 1351 0x000 and VLAN ID 0xFFF or any larger ID are invalid and FGLs larger 1352 than 0xFFFFFF are invalid; any Bit Map bits that corresponds to an 1353 illegal VLAN ID or illegal FGL is ignored. 1355 10.5 FGL-VLAN Mapping Pairs APPsub-TLV 1357 The FGL-VLAN Mapping Pairs APPsub-TLV provides a method for a TRILL 1358 switch to indicate a list of FGL to VLAN ID mappings it is configured 1359 to perform when egressing and ingressing native frames. 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Type | (2 bytes) 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Length | (2 bytes) 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 1366 | Mapping RECORD 1 | (5 bytes) 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 1368 | Mapping RECORD 2 | (5 bytes) 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 1370 | ... 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 1372 | Mapping RECORD k | (5 bytes) 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 1375 Where a Mapping RECORD has the following structure: 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | RESV | VLAN ID | (2 bytes) 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | FGL | (3 bytes) 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV tbd4. 1385 o Length: 5*k. If Length is not a multiple of 5, the APPsub-TLV 1386 is corrupt and MUST be ignored. 1388 o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 1390 o VLAN ID: 12-bit VLAN label. 1392 o FGL: Fine Grained Label [RFC7172] 1394 Each Mapping RECORD indicates that the originating TRILL switch is 1395 configured to map between the FGL and VLAN given on egressing and 1396 ingressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF 1397 are invalid; any Mapping RECORD that corresponds to an illegal VLAN 1398 ID is ignored. 1400 11. Management Considerations 1402 This document primarily adds optional enhancements or optimizations 1403 The only configuration parameters specified in this document are the 1404 number and frequency of copies sent of the Port Shutdown message as 1405 specified in Section 6.6. 1407 TRILL switch support of SNMPv3 is provided in the TRILL base protocol 1408 document [RFC6325] and MIBs have been specified in [RFC6850] and 1409 [RFC7784] but do not include the configurable parameters specified 1410 herein. It is anticipated that YANG modules will be specified for 1411 TRILL. 1413 Normative References 1415 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 1416 networks - Virtual Bridged Local Area Networks", IEEE Std 1417 802.1Q-2014, 19 December 2014. 1419 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 1420 Intermediate System Intra-Domain Routeing Exchange Protocol for 1421 use in Conjunction with the Protocol for Providing the 1422 Connectionless-mode Network Service (ISO 8473)", 2002. 1424 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1425 Requirement Levels", BCP 14, RFC 2119, March 1997, 1426 . 1428 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1429 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1430 Specification", RFC 6325, July 2011, . 1433 [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, 1434 A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 1435 Shortest Path Bridging", RFC 6329, April 2012, . 1438 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1439 and D. Dutt, "Transparent Interconnection of Lots of Links 1440 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 1441 . 1443 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1444 D., and A. Banerjee, "Transparent Interconnection of Lots of 1445 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 1446 . 1448 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1449 and V. Manral, "Transparent Interconnection of Lots of Links 1450 (TRILL): Adjacency", RFC 7177, May 2014, . 1453 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1454 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1455 RBridge Channel Support", RFC 7178, May 2014, . 1458 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1459 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 1460 . 1462 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1463 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1464 End Station Address Distribution Information (ESADI) Protocol", 1465 RFC 7357, September 2014, . 1468 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1469 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 1470 Lots of Links (TRILL): Clarifications, Corrections, and 1471 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 1472 . 1474 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 1475 Interconnection of Lots of Links (TRILL): RBridge Channel 1476 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 1477 2016, . 1479 [RFC7981] - Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1480 for Advertising Router Information", RFC 7981, DOI 1481 10.17487/RFC7981, October 2016, . 1484 Informative References 1486 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1487 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1488 5310, February 2009, . 1490 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1491 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 1492 6439, November 2011, . 1494 [RFC6850] - Rijhsinghani, A. and K. Zebrose, "Definitions of 1495 Managed Objects for Routing Bridges (RBridges)", RFC 6850, DOI 1496 10.17487/RFC6850, January 2013, . 1499 [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1500 "Problem Statement and Goals for Active-Active Connection at 1501 the Transparent Interconnection of Lots of Links (TRILL) Edge", 1502 RFC 7379, October 2014, 1505 [RFC7784] - Kumar, D., Salam, S., and T. Senevirathne, "Transparent 1506 Interconnection of Lots of Links (TRILL) Operations, 1507 Administration, and Maintenance (OAM) MIB", RFC 7784, DOI 1508 10.17487/RFC7784, February 2016, . 1511 Acknowledgements 1513 The following are hereby thanked for their contributions to this 1514 document: 1516 Spencer Dawkins, Shawn M Emery, Stephen Farrell, Joel Halpern, Sue 1517 Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan 1518 Romascanu, Mingui Zhang 1520 The following were acknowledged and thanked by in [RFC6439] or were 1521 an author of [RFC6439], the predecessor to this document: 1523 Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik 1524 Nordmark, Radia Perlman, Dan Romascanu, and Mike Shand. 1526 Authors' Addresses 1528 Donald Eastlake 3rd 1529 Huawei Technologies 1530 155 Beaver Street 1531 Milford, MA 01757 USA 1533 Phone: +1-508-333-2270 1534 EMail: d3e3e3@gmail.com 1536 Yizhou Li 1537 Huawei Technologies 1538 101 Software Avenue, 1539 Nanjing 210012, China 1541 Phone: +86-25-56622310 1542 EMail: liyizhou@huawei.com 1544 Mohammed Umair 1545 IPinfusion 1547 EMail: mohammed.umair2@ipinfusion.com 1549 Ayan Banerjee 1550 Cisco Systems 1551 170 West Tasman Drive 1552 San Jose, CA 95134 USA 1554 Phone: +1-408-333-7149 1555 EMail: ayabaner@cisco.com 1557 Fangwei Hu 1558 ZTE Corporation 1559 889 Bibo Road 1560 Shanghai 201203 1561 China 1563 Phone: +86-21-68896273 1564 EMail: hu.fangwei@zte.com.cn 1566 Appendix A: VLAN Inhibition Example 1568 The per-VLAN inhibition timers (or the equivalent) are needed to be 1569 loop safe in the case of misconfigured bridges on a link. 1571 For a simple example, assume that RB1 and RB2 are the only RBridges 1572 on the link, that RB1 is higher priority to be the DRB, and that they 1573 both want VLAN 1 (the default) to be the Designated VLAN. However, 1574 there is a bridge between them configured so that RB1 can see all the 1575 frames sent by RB2 but none of the frames from RB1 can get through to 1576 RB2. 1578 Both will think they are the DRB. RB1 because it is higher priority 1579 even though it sees the Hellos from RB2, and RB2 because it doesn't 1580 see the Hellos from RB1 and therefore thinks it is highest priority. 1582 Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while 1583 RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There 1584 is no problem with VLANs 2 and 4 but if you do not do something about 1585 it, you could have a loop involving VLAN 3. RB1 will see the Hellos 1586 RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 1587 will be inhibited on VLAN 3. RB2 does not see the Hellos issued by 1588 RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3 1589 native traffic. 1591 However, this situation may change. RB2 might crash, the bridge 1592 might crash, or RB2 might be reconfigured so it no longer tried to 1593 act as Appointed Forwarder for VLAN 3, or other issues may occur. 1594 So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no 1595 Hellos from any other RBridge on the link claiming to be Appointed 1596 Forwarder for VLAN 3 for a long enough time, then RB1 becomes 1597 uninhibited for that VLAN on the port in question and can handle end 1598 station traffic in VLAN 3. 1600 Appendix B: Changes to RFCs 6325, 6439, 7177 1602 This document updates [RFC6325], obsoletes [RFC6439], and updates 1603 [RFC7177]. 1605 Change to [RFC6325], the TRILL base protocol, is as follows: 1607 Addition of mandatory support for E-L1CS FS-LSPs. 1609 Changes from [RFC6439], which this document obsoletes, are as 1610 follows: 1612 1. Specify APPsub-TLVs and procedures to be used in E-L1CS FS-LSP 1613 forwarder appointments. 1615 2. Incorporate updates to [RFC6439] that appeared in Section 10 of 1616 RFC 7180, which has been obsoleted by [RFC7780]. They appear 1617 primarily in Section 4 of this document. 1619 3. Add optional FGL-VLAN consistency check feature including 1620 specification of APPsub-TLVs. 1622 4. Delete references to the draft-ietf-trill-rbridge-vlan-mapping 1623 draft, which has been dropped by the TRILL WG. 1625 5. Addition of the Port Shutdown message. 1627 6. Eliminate requirement that the DRB not send appointments in 1628 Hellos until its DRB inhibition timer has expired. This was an 1629 unnecessary safety precaution that is pointless given that 1630 appointments in E-L1CS FS-LSPs are immediately visible. 1632 7. Addition of three optional methods to optimize (reduce) 1633 inhibition time under various circumstances. 1635 8. Editorial changes. 1637 Changes to [RFC7177] are as follows: 1639 As provided in Section 6, TRILL switches SHOULD treat the 1640 reception of a Port-Shutdown RBridge Channel message from RB1 1641 listing port P1 as if it were an event A3 as specified in 1642 [RFC7177] resulting in transition of any adjacency to P1 to the 1643 Detect state. 1645 Appendix C: Multi-Link VLAN Mapping Loop Example 1647 Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively, 1648 that are both on link L1 and that RBridges RB3 and RB4 have ports P3 1649 and P4, respectively, that are both on Link L2. Assume further that 1650 P1 and P3 are Appointed Forwarder for VLAN-x and P2 and P4 are 1651 Appointed Forwarder for VLAN-y. This situation is shown in the figure 1652 below. 1654 + - - - - - - - - - - - - - - - - - - - - - + 1655 | | 1656 | TRILL network | 1657 | | 1658 | +---+ +---+ +---+ +---+ | 1659 + -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- + 1660 +---+ +---+ +---+ +---+ 1661 P1| P2| P3| P4| 1662 | | | | 1663 |x |y |x |y 1664 | +-+ | | +-+ | 1665 L1 ---+---|M|---+--+--- L2 ---+---|M|---+--- 1666 +-+ | +-+ 1667 +---+ 1668 |ES1| 1669 +---+ 1671 Further assume L1 and L2 are each bridged LANs that include a device 1672 M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into 1673 VLAN-x. 1675 If end station ES1 originated a broadcast or other multi-destination 1676 frame in VLAN-y, it would be ingressed by RB2. (The frame would also 1677 be mapped to VLAN-x and ingressed by RB1 but we initially ignore 1678 that.) RB2 will flood the resulting TRILL Data packet through the 1679 campus and, at least in the broadcast and unknown unicast cases, it 1680 will get to RB4 where it will be egressed to L2. Inside L2, this 1681 broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 1682 then floods the resulting TRILL Data packet through the campus, this 1683 time with an Inner.VLAN of VLAN-x, as a result of which it will be 1684 egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y 1685 and then ingressed by RB2 completing the loop. The packet will loop 1686 indefinitely, because in native form on L1 and L2 it has no TRILL hop 1687 count, and an indefinitely large number of copies will be delivered 1688 to ES1 and any other end station so situated. The same problem would 1689 occur even if P1 and P2 were on the same RBridge and/or P3 and P4 1690 were on the same RBridge. Actually, because the original frame was 1691 also mapped to VLAN-x inside L1 and ingressed by RB1, there are two 1692 copies looping around in opposite directions. 1694 The use of Fine Grained Labels [RFC7172] complicates but does not 1695 essentially change the potential problem. 1697 This example shows why VLAN mapping between Appointed Forwarder ports 1698 on a TRILL link is loop unsafe. When such a situation is detected, 1699 the DRB on the link changes Appointed Forwarders as necessary to 1700 assure that a single RBridge port is Appointed Forwarder for all 1701 VLANs involved in mapping. This change makes the situation loop safe. 1703 Appendix Z: Change Record 1705 This appendix summarizes changes between versions of this draft. 1707 RFC Editor: Please delete this Appendix before publication. 1709 Initial WG version -00 1711 From -00 to -01 1713 Primarily editorial changes based on review by Gayle Noble. 1715 From -01 to -02 1717 Primarily editorial changes based on RTGDIR QA review by Joel 1718 Halpern. 1720 From -03 to -04 1722 Update references and incorporate changes from SECDIR review. 1724 From -04 to -05 1726 Changes to resolve GENART, RTG DIR, OPS DIR, and IESG comments. 1728 Copyright and IPR Provisions 1730 Copyright (c) 2017 IETF Trust and the persons identified as the 1731 document authors. All rights reserved. 1733 This document is subject to BCP 78 and the IETF Trust's Legal 1734 Provisions Relating to IETF Documents 1735 (http://trustee.ietf.org/license-info) in effect on the date of 1736 publication of this document. Please review these documents 1737 carefully, as they describe your rights and restrictions with respect 1738 to this document. Code Components extracted from this document must 1739 include Simplified BSD License text as described in Section 4.e of 1740 the Trust Legal Provisions and are provided without warranty as 1741 described in the Simplified BSD License. The definitive version of 1742 an IETF Document is that published by, or under the auspices of, the 1743 IETF. Versions of IETF Documents that are published by third parties, 1744 including those that are translated into other languages, should not 1745 be considered to be definitive versions of IETF Documents. The 1746 definitive version of these Legal Provisions is that published by, or 1747 under the auspices of, the IETF. Versions of these Legal Provisions 1748 that are published by third parties, including those that are 1749 translated into other languages, should not be considered to be 1750 definitive versions of these Legal Provisions. For the avoidance of 1751 doubt, each Contributor to the IETF Standards Process licenses each 1752 Contribution that he or she makes as part of the IETF Standards 1753 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1754 language to the contrary, or terms, conditions or rights that differ 1755 from or are inconsistent with the rights and licenses granted under 1756 RFC 5378, shall have any effect and shall be null and void, whether 1757 published or posted by such Contributor, or included with or in such 1758 Contribution.