idnits 2.17.1 draft-ietf-trill-rbridge-af-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 (September 26, 2011) is 4586 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Intel Labs 3 Intended status: Proposed Standard Donald Eastlake 4 Updates: 6325 Yizhou Li 5 Huawei 6 Ayan Banerjee 7 Cisco 8 Hu Fangwei 9 ZTE 10 Expires: March 25, 2012 September 26, 2011 12 RBridges: Appointed Forwarders 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, safe 20 forwarding even during periods of temporary loops, and support for 21 multipathing of both unicast and multicast traffic. TRILL 22 accomplishes this by using IS-IS (Intermediate System to Intermediate 23 System) link state routing and by encapsulating traffic using a 24 header that includes a hop count. Devices that implement TRILL are 25 called RBridges. 27 TRILL supports multi-access LAN (Local Area Network) links that can 28 have multiple end stations and RBridges attached. Where multiple 29 RBridges are attached to a link, native traffic to and from end 30 stations on that link is handled by a subset of those RBridges called 31 Appointed Forwarders, with the intent that native traffic in each 32 VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of 33 this document is to improve the documentation of the Appointed 34 Forwarder mechanism and thus it updates RFC 6325. 36 Status of This Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. Distribution of this document is 40 unlimited. Comments should be sent to the TRILL working group mailing 41 list . 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 Acknowledgements 61 The authors of [RFC6325] and [RFC6327], those listed in the 62 Acknowledgements section of [RFC6325] and [RFC6327], and Ron Bonica, 63 Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan 64 Romascanu, and Mike Shand are hereby thanked for their contributions. 66 Table of Contents 68 1. Introduction............................................4 69 1.1 Terminology and Acronyms...............................5 71 2. Appointed Forwarders and Their Appointment..............6 72 2.1 Appointment Effects of DRB Elections...................6 73 2.2 Appointment and Removal by the DRB.....................7 74 2.2.1 Processing Forwarder Appointments....................7 75 2.2.2 Frequency of Appointments............................9 76 2.2.3 Appointed Forwarders Limit...........................9 77 2.3 Local Configuration Action Appointment Effects........10 78 2.4 VLAN Mapping Within a Link............................10 80 3. The Inhibition Mechanism...............................12 81 4. Inhibited Appointed Forwarder Behavior.................15 82 5. Multiple Ports on the Same Link........................16 84 6. Security Considerations................................17 85 7. IANA Considerations....................................17 87 8. References.............................................18 88 8.1 Normative References..................................18 89 8.2 Informative References................................18 91 Authors' Addresses........................................19 93 Appendix: VLAN Inhibition Example.........................20 95 Appendix Z: Change Record.................................21 97 1. Introduction 99 The IETF TRILL (Transparent Interconnection of Lots of Links) 100 protocol [RFC6325] provides optimal pair-wise data frame forwarding 101 without configuration in multi-hop networks with arbitrary topology, 102 safe forwarding even during periods of temporary loops, and support 103 for multipathing of both unicast and multicast traffic. TRILL 104 accomplishes this by using IS-IS (Intermediate System to Intermediate 105 System) [IS-IS] [RFC1195] link state routing and encapsulating 106 traffic using a header that includes a hop count. The design supports 107 VLANs (Virtual Local Area Networks) and optimization of the 108 distribution of multi-destination frames based on VLANs and IP 109 derived multicast groups. Devices that implement TRILL are called 110 RBridges. 112 Section 2 of [RFC6327] explains the environment for which the TRILL 113 protocol is designed and the differences between that environment and 114 the typical Layer 3 routing environment. 116 TRILL supports multi-access LAN (Local Area Network) links that can 117 have multiple end stations and RBridges attached. Where multiple 118 RBridges are attached to a link, native traffic to and from end 119 stations on that link is handled by a subset of those RBridges called 120 Appointed Forwarders, with the intent that native traffic in each 121 VLAN be handled by at most one RBridge. An RBridge can be Appointed 122 Forwarder for many VLANs. 124 The purpose of this document is to improve the documentation of the 125 Appointed Forwarder mechanism and thus it updates RFC 6325. It 126 includes reference implementation details. Alternative 127 implementations that interoperate on the wire are permitted. 129 The Appointed Forwarder mechanism is irrelevant to any link on which 130 end station service is not offered. This includes links configured as 131 point-to-point IS-IS links and any link with all RBridge ports on 132 that link configured as trunk ports. (In TRILL, configuration of a 133 port as a "trunk port" just means that no end station service will be 134 provided. It does not imply that all VLANs are enabled on that port.) 136 The Appointed Forwarder mechanism has no affect on the formation of 137 adjacencies, the election of the DRB for a link, MTU matching, or 138 pseudonode formation. Those topics are covered in [RFC6327]. 139 Furthermore, Appointed Forwarder status has no effect on the 140 forwarding of TRILL Data frames. It only affects the handling of 141 native frames. 143 For other aspects of the TRILL base protocol see [RFC6325] and 144 [RFC6327]. Familiarity with [RFC6325] and [RFC6327] is assumed in 145 this document. In case of conflict between this document and 146 [RFC6325], this document prevails. 148 1.1 Terminology and Acronyms 150 This document uses the acronyms defined in [RFC6325]. 152 A "trunk port" is a port configured with the "end station service 153 disable" bit on, as described in Section 4.9.1 of [RFC6325]. 155 In this document, the term "link" means "bridged LAN", that is to say 156 some combination of physical links with zero or more bridges, hubs, 157 repeaters, or the like. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 [RFC2119]. 164 2. Appointed Forwarders and Their Appointment 166 The Appointed Forwarder on a link for VLAN-x is the RBridge that 167 ingresses native frames from the link and egresses native frames to 168 the link in VLAN-x. By default, the DRB (Designated RBridge) on a 169 link is in charge of native traffic for all VLANs on the link. The 170 DRB may, if it wishes, act as Appointed Forwarder for any VLAN and it 171 may appoint other RBridges that have ports on the link as Appointed 172 Forwarder for one or more VLANs. 174 It is important that there not be two Appointed Forwarders on a link 175 that are ingressing and egressing native frames for the same VLAN at 176 the same time. Should this occur, it could form a loop where frames 177 are not protected by a TRILL Hop Count for part of the loop. (Such a 178 condition can even occur through two Appointed Forwarders for two 179 different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the 180 link are configured to map frames between VLAN-x and VLAN-y as 181 discussed in Section 2.4.) While TRILL tries to avoid such 182 situations, for loop safety there is also an "inhibition" mechanism 183 (see Section 3) that can cause an RBridge that is an Appointed 184 Forwarder to not ingress or egress native frames. 186 As discussed in Section 5, an RBridge may have multiple ports on a 187 link. As discussed in [RFC6327], if there are multiple ports with the 188 same MAC address on a link, all but one will be suspended. The case 189 of multiple ports on a link for one RBridge and the case of multiple 190 ports with the same MAC address on a link and combinations of these 191 cases are fully accommodated; however, multiple ports on a link for 192 one RBridge is expected to be a rare condition and duplicate MAC 193 addresses are not recommended by either TRILL or IEEE 802.1 194 standards. 196 Appointed Forwarder status has no affect on the forwarding of TRILL 197 Data frames. It only affects the handling of native frames. 199 There are three mechanisms by which an RBridge can be appointed or 200 un-appointed as Appointed Forwarder: as a result of DRB elections 201 [RFC6327] as discussed in Section 2.1, as a result of action by the 202 DRB as discussed in Section 2.2, as a result of a local configuration 203 action as discussed in Section 2.3. 205 2.1 Appointment Effects of DRB Elections 207 When an RBridge believes that it has become the DRB on a link, by 208 default it can act as Appointed Forwarder for any VLANs on that link 209 that it chooses as long as its port is not configured as a trunk port 210 and has that VLAN enabled (or at least one of its ports meets these 211 criteria if it has more than one port on the link). 213 An RBridge loses all Appointed Forwarder status when 214 1. it decides that it has lost the status of being DRB for a link 215 or 216 2. it observes a change in the RBridge that is DRB for the link 217 without itself becoming DRB. 219 In the rare corner case where an RBridge has more than one port on a 220 link, one of which was previously the DRB election winner but that 221 port has just lost the DRB election to a different port of the same 222 RBridge (possibly due to management configuration of port 223 priorities), there is no change in which RBridge is DRB. Therefore 224 neither of the above points applies and there is no change in 225 Appointed Forwarder status. 227 2.2 Appointment and Removal by the DRB 229 The DRB may appoint other RBridges on the link through inclusion of 230 one or more Appointed Forwarders sub-TLVs [RFC6326] in a TRILL Hello 231 it sends on the Designated VLAN out the port that won the DRB 232 election. When the DRB sends any appointments in a TRILL Hello, it 233 must send all appointments for that link in that Hello. Any previous 234 appointment not included is implicitly revoked. 236 Although the DRB does not need to announce the VLANs for which it has 237 chosen to act as Appointed Forwarder by sending appoints for itself, 238 if the DRB wishes to revoke all appointments for RBridges other than 239 itself on the link, it is recommended that it send a TRILL Hello with 240 an appointment for itself for some VLAN. 242 The DRB MUST NOT send any appointments on a link unless its DRB 243 inhibition timer (see Section 3) for that link is expired. 245 How the DRB decides what other RBridges on the link, if any, to 246 appoint forwarder for which VLANs is beyond the scope of this 247 document. 249 2.2.1 Processing Forwarder Appointments 251 When a non-DRB RBridge that can offer end station service on a link 252 receives a TRILL Hello that is not discarded for one of the reasons 253 given in [RFC6327], it checks the source MAC address and the Port ID 254 and System ID in the Hello to determine if it is from the winning DRB 255 port. If it is not from that port, any Appointed Forwarder sub-TLVs 256 in the Hello are ignored and there is no change in the receiving 257 RBridge's Appointed Forwarder status. Also, if no Appointed Forwarder 258 sub-TLVs are present in the TRILL Hello, there is no change in the 259 receiver's Appointed Forwarder status. 261 However, if the TRILL Hello is from the winning DRB port and the 262 Hello includes one or more Appointed Forwarder sub-TLVs, then the 263 receiving RBridge becomes appointed for the VLANs that are both 264 listed for it in the Hello and are enabled on the receiving port. (If 265 the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored 266 but any other VLAN IDs are still effective.) If the receiver was 267 Appointed Forwarder for any other VLANs, its Appointed Forwarder 268 status for such other VLANs is revoked. For example, if none of these 269 sub-TLVs in a Hello appoints the receiving RBridge, then it loses all 270 Appointed Forwarder status and is no longer Appointed Forwarder for 271 any VLAN. 273 The handling of one or more Appointed Forwarder sub-TLVs in a Hello 274 from the winning port that appoint the receiving RBridge is as 275 follows: An appointment in an Appointed Forwarder sub-TLV is for a 276 specific RBridge and a contiguous interval of VLAN IDs; however, as 277 stated above, it actually appoints that RBridge forwarder only for 278 the VLAN(s) in that range that are enabled on one or more ports that 279 RBridge has on the link (ignoring any ports configured as trunk ports 280 or as IS-IS point-to-point ports). If the RBridge was Appointed 281 Forwarder for any additional VLANs beyond the VLANs for which it was 282 being appointed, it loses Appointed Forwarder status for such 283 additional VLANs. 285 There is no reason for an RBridge to remember that it received a 286 valid appointment message for a VLAN that was ineffective because the 287 VLAN was not enabled on the port where the message was received or 288 because the port was a trunk or point-to-point port. It does not 289 become appointed forwarder for such a VLAN just because that VLAN is 290 later enabled or the port later re-configured. 292 It should be straightforward for the DRB to send, within one Hello, 293 the appointments for several dozen VLAN IDs or several dozen blocks 294 of contiguous VLAN IDs. Should the VLANs the DRB wishes to appoint be 295 inconveniently distributed, for example the proverbial case where DRB 296 RB1 wishes to appoint RB2 forwarder for all even numbered VLANs and 297 appoint RB3 forwarder for all odd numbered VLANs, the following 298 method may be used: The network manager normally controls what VLANs 299 are enabled on RBridge port. Thus the network manager can appoint an 300 RBridge forwarder for an arbitrary set of scattered VLANs by enabling 301 only those VLANs on the relevant port (or ports) and then having the 302 DRB send an appointment that appears to appoint the target RBridge 303 forwarder for all VLANs. However, for proper operation and inter- 304 RBridge communication, the Designated VLAN for a link SHOULD be 305 enabled on all RBridge ports on that link and it may not be desired 306 to appoint the RBridge forwarder for the Designated VLAN. Thus, in 307 the general case, it would require two appointments, although it 308 would still only require one appointment if the Designated VLAN were 309 an extreme low or high value such as VLAN 0xFFE or the default VLAN 310 1. 312 For example, assume the DRB wants RB2 to be Appointed Forwarder for 313 all even numbered VLANs and the Designated VLAN for the link is VLAN 314 101. The network manager could cause all even numbered VLANs plus 315 VLAN 101 to be enabled on the relevant port of RB2 and then, with the 316 desired effect, cause the DRB to send appointments to RB2 appointing 317 it forwarder for all VLANs from 1 through 100 and from 102 through 318 4,094. 320 Should the network manager have misconfigured the enabled VLANs and 321 appointed forwarders, resulting in two RBridges believing they are 322 appointed forwarders for the same VLAN, then item 4 in section 3 will 323 cause one or more of the RBridges to be inhibited for that VLAN. 325 2.2.2 Frequency of Appointments 327 It is not necessary for the DRB to include the forwarder appointments 328 in every TRILL Hello that it sends on the Designated VLAN for a link. 329 For loop safety, every RBridge is required to indicate, in every 330 TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed 331 Forwarder for VLAN-x for that link (see item 4 in Section 3). And it 332 is RECOMMENDED that the DRB have all VLANs for which end station 333 service will be offered on the link, as well as the Designated VLAN, 334 enabled. Thus the DRB will generally be informed by other RBridges on 335 the link of the VLANs for which they believe they are Appointed 336 Forwarder. If this matches the appointments the DRB wishes to make, 337 it is not required to re-send its forwarder appointments; however, 338 for robustness, especially in cases such as VLAN misconfigurations in 339 a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder 340 appointments on the designated VLAN at least once per its Holding 341 Time on the port that won the DRB election. 343 2.2.3 Appointed Forwarders Limit 345 The mechanism of DRB forwarder appointment and the limited length of 346 TRILL Hellos imposes a limit on the number of RBridges on a link that 347 can be Appointed Forwarders. To obtain a conservative estimate, 348 assume that no more than 1000 bytes are available in a TRILL Hello 349 for such appointments. Assume it is desired to appoint various 350 RBridges on a link forwarders for arbitrary non-intersecting sets of 351 VLANs. Using the technique discussed above would generally require 352 two appointments, or 12 bytes, per RBridge. With allowance for sub- 353 TLV and TLV overhead, appointments for 83 RBridges would fit in under 354 1000 bytes. Including the DRB, this implies a link with 84 or more 355 RBridges attached. Links with more than a handful of RBridges 356 attached are expected to be rare. 358 (If the Designated VLAN were an extreme low or high value, such as 359 VLAN 1, which is the default and may be a common value in practice, 360 only 6 bytes per RBridge would be required. This would permit twice 361 as many different Appointed Forwarder RBridges than indicated by the 362 general analysis above or, alternatively, would take only half as 363 much space to appoint the same number of Appointed Forwarders.) 365 Unnecessary changes in Appointed Forwarders SHOULD NOT be made as 366 they may result in transient lack of end station service. Large 367 numbers of Appointed Forwarders on a link (in excess of 65) are NOT 368 RECOMMENDED due to the complexity of their establishment and 369 maintenance. 371 2.3 Local Configuration Action Appointment Effects 373 Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder 374 status that RBridge has for VLAN-x unless VLAN-x is enabled on some 375 other port that the RBridge has connected to the same link. 376 Configuring a port as a trunk port or point-to-point port revokes any 377 Appointed Forwarder status that depends on enabled VLANs at that 378 port. 380 Causing a port to no longer be configured as a trunk or point-to- 381 point port or enabling VLAN-x on a port does not, in itself, cause 382 the RBridge to become an Appointed Forwarder for the link that port 383 is on. However, such actions can allow the port's RBridge to become 384 Appointed Forwarder by choice if it is DRB or by appointment if it is 385 not DRB on the link. 387 2.4 VLAN Mapping Within a Link 389 TRILL Hellos include a field that is set to the VLAN in which they 390 are sent. If they arrive on a different VLAN, then VLAN mapping is 391 occurring within the link. (Such VLAN mapping within a link between 392 RBridges should not be confused with VLAN mapping inside an RBridge. 393 [VLANmap]) VLAN mapping between VLAN-x and VLAN-y can lead to a loop 394 if the Appointed Forwarders for the VLANs are different. If such 395 mapping within a link was allowed and occurred on two or more links 396 so that there was a cycle of VLAN mappings, a broadcast frame, for 397 example, would loop forever. 399 To prevent this potential problem, if the DRB on a link detects VLAN 400 mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it 401 MUST make or revoke appointments so as to assure that the same 402 RBridge (possibly the DRB) is Appointed Forwarder on the link for 403 both VLAN-x and VLAN-y. 405 3. The Inhibition Mechanism 407 An RBridge has, for every link on which it can offer end station 408 service (that is every link for which it can act as an Appointed 409 Forwarder), the following timers denominated in seconds: 411 a DRB inhibition timer, 413 a root change inhibition timer, and 415 up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. 417 The DRB and root change inhibition timers MUST be implemented. 419 The loss of native traffic due to inhibition will be minimized by 420 logically implementing a VLAN inhibition timer per each VLAN for 421 which end station service will ever be offered by the RBridge on the 422 link and this SHOULD be done. (See Appendix for an example motivating 423 VLAN inhibition timers.) However, if implementation limitations make 424 a full set of such timers impractical, the VLAN inhibition timers for 425 more than one VLAN can, with care, be merged into one timer. In 426 particular, an RBridge MUST NOT merge the VLAN inhibition timers 427 together for two VLANs if it is Appointer Forwarder for one and not 428 for the other as this can lead to unnecessary indefinitely prolonged 429 inhibition. In the limit, there will be safe operations, albeit with 430 more native frame loss than would otherwise be required, even if only 431 two VLAN inhibition timers are provided, one for VLANs for which the 432 RBridge is Appointed Forwarder and one for all other VLANs. At least 433 two VLAN inhibition timers MUST be implemented. Where a VLAN 434 inhibition timer represents more than one VLAN, an update or test 435 that would have be done to the timer for any of the VLANs is 436 performed on the merged timer. 438 These timers are set as follows: 440 1. On booting or management reset, each port will have its own set 441 of timers, as even if two or more are on the same link as the 442 RBridge will not have had a chance to learn that yet. All 443 inhibition timers are set to expired except the DRB inhibition 444 timer that is set in accordance with item 2 below. The DRB 445 inhibition timer is handled differently because each port will 446 initially believe it is DRB. 448 2. When an RBridge decides that it has become DRB on a link, 449 including when it is first booted or reset by management, it 450 sets the DRB inhibition timer to the Holding Time of its port 451 on that link that won the DRB election. 453 3. When an RBridge decides that it has lost DRB status on a link, 454 it sets the DRB inhibition timer to expired. 456 Note: In the rare corner case where one port of an RBridge was 457 the DRB election winner but later loses the DRB election to a 458 different port of the same RBridge on that link (perhaps due 459 to management configuration of port priority), neither 2 nor 460 3 above applies and the DRB timer is not changed. 462 4. When an RBridge RB1 receives a TRILL Hello asserting that the 463 sender is Appointed Forwarder that either (1) arrives on VLAN-x 464 or (2) was sent on VLAN-x as indicated inside the Hello, then 465 RB1 sets its VLAN-x inhibition timer for the link to the 466 maximum of that timer's existing value and the Holding Time in 467 the received Hello. An RBridge MUST maintain VLAN inhibition 468 timers for a link to which it connects if it can offer end 469 station service on that link even if it is not currently 470 Appointed Forwarder for any VLAN on that link. 472 5. When an RBridge RB1 enables VLAN-x on a port connecting to a 473 link and VLAN-x was previously not enabled on any of RB1's 474 ports on that link, it sets its VLAN inhibition timer for VLAN- 475 x for that link to its Holding Time for that port. This is done 476 even if the port is configured as a trunk or point-to-point 477 port as long as there is some chance it might be later 478 configured to not be a trunk or point-to-point port. 480 6. When an RBridge detects a change in the common spanning tree 481 root bridge on a port, it sets its root change inhibition timer 482 for the link to an amount of time that defaults to 30 seconds 483 and is configurable to any value from 30 down to zero seconds. 484 This condition will not occur unless the RBridge is receiving 485 BPDUs on the port from an attached bridged LAN. It is safe to 486 configure this inhibition time to the settling time of an 487 attached bridged LAN. For example, if it is known that Rapid 488 Spanning Tree Protocol (RSTP [802.1Q]) is running throughout 489 the attached bridged LAN, it should be safe to configure this 490 inhibition time to 7 seconds or, if the attached bridges have 491 been configured to have a minimum Bridge Hello Timer, safe to 492 configure it to 4 seconds. Note that, while an RBridge could 493 determine what version of spanning tree is running on the 494 physical link between it and any directly connected bridge by 495 examination of the BPDUs it receives, it could not tell if 496 inter-bridge links beyond those directly connected bridges were 497 running classic Spanning Tree Protocol (STP), which might 498 require the root change inhibition timer to be set to 30 499 seconds for safety. 501 7. When an RBridge decides that one of its ports (or a set of its 502 ports) P1 is on the same link as another of its ports (or set 503 of its ports) P2, then the inhibition timers are merged to a 504 single set of inhibition timers by using the maximum value of 505 the corresponding timers. 507 8. When an RBridge decides that a set of its ports that it had 508 been treating as being on the same link are no longer on the 509 same link, those ports will necessarily be on two or more links 510 (one link per port in the limit). This is handled by cloning a 511 copy of the timers for each of the two or more links the 512 RBridge has decided these ports connect to. 514 4. Inhibited Appointed Forwarder Behavior 516 An Appointed Forwarder for a link is inhibited for VLAN-x if 517 1. its DRB inhibition timer for that link is not expired, or 518 2. its root change inhibition timer for that link is not expired, 519 or 520 3. its VLAN inhibition timer for that link for VLAN-x is not 521 expired. 523 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 524 a TRILL Data frame whose encapsulated frame is in VLAN-x and would 525 normally be egressed to that link, it decapsulates the native frame 526 as usual. But it does not output it to or queue it for that link 527 although, if appropriate (for example the frame is multi- 528 destination), it may output it to or queue it for other links. 530 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 531 a native frame in VLAN-x that would normally be ingressed from that 532 link, the native frame is ignored except for address learning. 534 An RBridge with one or more un-expired inhibition timers, possibly 535 including an unexpired inhibition timer for VLAN-x, is still required 536 to indicate in TRILL Hellos it sends on VLAN-x whether or not it is 537 Appointed Forwarder for VLAN-x for the port on which it sends the 538 Hello. 540 Inhibition has no effect on the receipt or forwarding of TRILL Data 541 frames. 543 5. Multiple Ports on the Same Link 545 An RBridge may have multiple ports on the same link. Some of these 546 ports may be suspended due to MAC address duplication as described in 547 [RFC6327]. Suspended ports never ingress or egress native frames. 549 If an RBridge has one or more non-suspended ports on a link and those 550 ports offer end station service, that is, those ports are not 551 configured as point-to-point or trunk ports, then that RBridge is 552 eligible to be an Appointed Forwarder for that link. It can become 553 Appointed Forwarder either by its choice because it is DRB, or by 554 appointment by the DRB as described in Sections 2.1 and 2.2. 556 If an RBridge which is Appointed Forwarder for VLAN-x on a link has 557 multiple non-suspended ports on that link, it may load share the task 558 of ingressing and egressing VLAN-x native frames across those ports 559 however it chooses, as long as there is no case in which a frame it 560 egresses onto the link from one port can be ingressed on another of 561 its ports, creating a loop. If the RBridge is Appointed Forwarder for 562 multiple VLANs, a straightforward thing to do would be to partition 563 those VLANs among the ports it has on the link. 565 6. Security Considerations 567 This memo provides improved documentation of the TRILL Appointed 568 Forwarder mechanism. It does not change the security considerations 569 of the TRILL base protocol. See Section 6 of [RFC6325]. 571 7. IANA Considerations 573 This document requires no IANA actions. RFC Editor: Please delete 574 this section before publication. 576 8. References 578 Normative and Informational references for this document are listed 579 below. 581 8.1 Normative References 583 [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 584 networks - Virtual Bridged Local Area Networks", IEEE Std 585 802.1Q-2011, May 2011. 587 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 588 Intermediate System Intra-Domain Routeing Exchange Protocol for 589 use in Conjunction with the Protocol for Providing the 590 Connectionless-mode Network Service (ISO 8473)", 2002. 592 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 593 dual environments", RFC 1195, December 1990. 595 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 599 Ghanwani, "Routing Bridges (RBridges): Base Protocol 600 Specification", RFC 6325, July 2011. 602 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 603 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 604 Use of IS-IS", RFC 6326, July 2011. 606 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 607 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 608 6327, July 2011. 610 8.2 Informative References 612 [VLANmap] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, D. 613 Eastlake, "RBridges: Campus VLAN and Priority Regions", draft- 614 ietf-trill-rbridge-vlan-mapping, work in progress. 616 Authors' Addresses 618 Radia Perlman 619 Intel Labs 620 2200 Mission College Blvd. 621 Santa Clara, CA 95054 USA 623 Phone: +1-408-765-8080 624 Email: Radia@alum.mit.edu 626 Donald Eastlake 627 Huawei Technologies 628 155 Beaver Street 629 Milford, MA 01757 USA 631 Phone: +1-508-333-2270 632 Email: d3e3e3@gmail.com 634 Yizhou Li 635 Huawei Technologies 636 101 Software Avenue, 637 Nanjing 210012, China 639 Phone: +86-25-56622310 640 Email: liyizhou@huawei.com 642 Ayan Banerjee 643 Cisco Systems 644 170 West Tasman Drive 645 San Jose, CA 95134 USA 647 Phone: +1-408-333-7149 648 Email: ayabaner@cisco.com 650 Fangwei Hu 651 ZTE Corporation 652 889 Bibo Road 653 Shanghai 201203 654 China 656 Phone: +86-21-68896273 657 Email: hu.fangwei@zte.com.cn 659 Appendix: VLAN Inhibition Example 661 The per VLAN Inhibition timers (or the equivalent) are needed to be 662 loop safe in the case of misconfigured bridges on a link. 664 For a simple example, assume that RB1 and RB2 are the only RBridges 665 on the link, that RB1 is higher priority to be DRB, and that they 666 both want VLAN 1 (the default) to be the designated VLAN. But there 667 is a bridge between them configured so that RB1 can see all the 668 frames sent by RB2 but none of the frames from RB1 can get through to 669 RB2. 671 Both will think they are DRB. RB1 because it is higher priority even 672 though it sees the Hellos from RB2. And RB2 because it doesn't see 673 the Hellos from RB1 and so thinks it is highest priority. 675 Say RB1 chooses to act as appointed forwarder for VLANs 2 and 3 while 676 RB2 chooses to act as appointed forwarder for VLANs 3 and 4. There is 677 no problem with VLANs 2 and 4 but if you do not do something about 678 it, you could have a loop involving VLAN 3. RB1 will see the Hellos 679 RB2 issues on VLAN 3 declaring itself Appointed Forwarder and so RB1 680 will be inhibited on VLAN 3. RB2 does not see the Hellos issued by 681 RB1 on VLAN 3 and so RB2 will become uninhibited and will handle VLAN 682 3 native traffic. 684 But this situation may change. RB2 might crash or the bridge might 685 crash or RB2 might be re-configured so it no longer tried to act as 686 appointed forwarder for VLAN 3 or ... So RB1 has to maintain a VLAN 3 687 inhibition timer and if it sees no Hellos from any other RBridge on 688 the link claiming to be Appointed Forwarder for VLAN 3 in a long 689 enough time, then RB1 becomes uninhibited for that VLAN on the port 690 in question and can handle end station traffic in VLAN 3. 692 Appendix Z: Change Record 694 This appendix summarizes changes between versions of this draft. 696 RFC Editor: Please delete this Appendix before publication. 698 From -00 to -01 700 1. Clarify that an RBridge needs to check the source MAC, Port ID, 701 and System Id in received TRILL Hellos to determine whether 702 forwarder appointment sub-TLVs are ignored or take effect. 704 2. Note that RB1's Appointed Forwarder status for VLAN-x is cancelled 705 if VLAN-x is disabled on all ports RB1 has on a link. 707 3. Minor editorial changes. 709 From -01 to -02 711 1. Include additional appropriate references to configuring ports as 712 trunk ports or to no longer be trunk ports. 714 2. Minor editorial changes. 716 From -02 to -03 718 1. Add note on "trunk port" to Section 1.1. 720 2. Clarify that RBridges do not maintain state for AF appointments 721 that were ineffective due to being for a disabled VLAN, trunk 722 port, or point-to-point port. 724 3. Add material in Section 2.2.1 pointing to Item 4 in Section 3 as 725 the safety measure when you do have two AFs on a link for the same 726 VLAN. 728 4. Add VLAN inhibition timer example Appendix. 730 5. Provide that an inhibited AF can still learn end station addresses 731 from native frames it receives. 733 6. Minor editorial changes. 735 From -03 to -04 737 1. Add a definition of "link". 739 2. Specify that VLAN IDs 0x000 and 0xFFF are ignored in appointments. 741 3. Add Section 2.4 on VLAN Mapping Within a Link. 743 4. Note that a VLAN inhibition timer is set for the VLAN identified 744 inside an appropriate Hello as well as for the VLAN in which that 745 Hello is delivered. 747 5. Add to Section 2.2 a recommendation that, if the DRB wants to 748 clear all appointments, it just send a appointment for itself. 750 6. Minor editorial changes. 752 From -04 to -05 754 1. In Section 3, Item 6, correct the default safe RSTP root bridge 755 change inhibition timer value to 7 seconds and note that it 756 requires minimum Bridge Hello Timer configuration of attached 757 bridges to be able to safely reduce this to 4 seconds. 759 2. Update references for RFCs that have been published. 761 3. Add a few acknowledgements. 763 4. Note in the Abstract and Introduction that this document updates 764 RFC 6325. 766 5. Minor editorial changes. 768 Copyright and IPR Provisions 770 Copyright (c) 2011 IETF Trust and the persons identified as the 771 document authors. All rights reserved. 773 This document is subject to BCP 78 and the IETF Trust's Legal 774 Provisions Relating to IETF Documents 775 (http://trustee.ietf.org/license-info) in effect on the date of 776 publication of this document. Please review these documents 777 carefully, as they describe your rights and restrictions with respect 778 to this document. Code Components extracted from this document must 779 include Simplified BSD License text as described in Section 4.e of 780 the Trust Legal Provisions and are provided without warranty as 781 described in the Simplified BSD License. The definitive version of 782 an IETF Document is that published by, or under the auspices of, the 783 IETF. Versions of IETF Documents that are published by third parties, 784 including those that are translated into other languages, should not 785 be considered to be definitive versions of IETF Documents. The 786 definitive version of these Legal Provisions is that published by, or 787 under the auspices of, the IETF. Versions of these Legal Provisions 788 that are published by third parties, including those that are 789 translated into other languages, should not be considered to be 790 definitive versions of these Legal Provisions. For the avoidance of 791 doubt, each Contributor to the IETF Standards Process licenses each 792 Contribution that he or she makes as part of the IETF Standards 793 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 794 language to the contrary, or terms, conditions or rights that differ 795 from or are inconsistent with the rights and licenses granted under 796 RFC 5378, shall have any effect and shall be null and void, whether 797 published or posted by such Contributor, or included with or in such 798 Contribution.