idnits 2.17.1 draft-eastlake-trill-rbridge-notes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. 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 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 (9 December 2008) is 5616 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-10 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Stellar Switches 3 Intended status: Informational 4 Expires: 8 June 2009 9 December 2008 6 Rbridge Notes 8 10 Status of This Document 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this document is unlimited. Comments should be sent 18 to the TRILL working group mailing list . 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides additional informational material related to 39 RBridges, which are devices that implement the TRILL protocol. It is 40 a supplement to the RBridges base protocol specification and includes 41 discussion of tradeoffs in some features and configurations of 42 RBridges. In addition, it provides a sketch of a proof that, with 43 reasonable assumptions, persistent loops do not occur in a TRILL 44 campus. 46 Table of Contents 48 Status of This Document....................................1 49 Abstract...................................................1 51 Table of Contents..........................................2 53 1. Introduction............................................3 55 2. Zero Configuration Comparison...........................4 56 2.1 IEEE 802.1D Bridges....................................4 57 2.2 IEEE 802.1Q Bridges....................................4 58 2.3 RBridges...............................................6 60 3. Pluses and Minuses......................................8 61 3.1 Trees and the Forest...................................8 62 3.2 Loop Safety............................................9 63 3.2.1 Loop Safety Mechanisms...............................9 64 3.2.2 Loop Safety Tradeoffs...............................10 66 4. No Persistent Loops....................................11 67 4.1 Categories of Loops...................................11 68 4.2 Analysis for a Single Pair of RBridges................12 69 4.3 Analysis for on Arbitrary Bridged LAN.................14 71 5. Security Considerations................................18 72 6. Normative References...................................18 73 7. Informative References.................................18 74 8. IANA Considerations....................................18 76 Disclaimer................................................19 77 Additional IPR Provisions.................................19 79 Author's Address..........................................20 80 Expiration and File Name..................................20 82 1. Introduction 84 This document provides informational material related to RBridges, 85 which are devices that implement the TRILL protocol. 87 Section 2 briefly compares some aspects of zero configuration IEEE 88 802.1D and 802.1Q bridges and RBridges. Section 3 discusses some 89 tradeoffs in features and configurations of RBridges. While Section 4 90 presents a sketch of a proof that, with reasonable assumptions, 91 persistent loops do not occur in a TRILL campus. 93 The terms and acronyms defined in Sections 1.3 and 1.4 of 94 [RFCprotocol] are used with the same definitions herein. 96 2. Zero Configuration Comparison 98 This section provides an informational comparison of the behavior of 99 a zero configuration IEEE 802.1D bridge, a zero configuration IEEE 100 802.1Q bridge, or a zero configuration RBridge, in a network of 101 possibly configured devices. The goal is to clarify the behavioral 102 differences, particularly in regard to VLANs and priority. All three 103 devices can learn end station addresses in essentially the same way, 104 through the observation of traffic (although RBridges provide an 105 additional facility, which can be configured to learn such 106 information via ESADI messages). 108 2.1 IEEE 802.1D Bridges 110 802.1D bridges [802.1D] are ignorant of VLANs. They are unaware 111 whether frames received have a C-tag (formerly called Q-tag), the tag 112 which provides VLAN ID and priority. As a result, 802.1D bridges 113 learn end station address locations based on simple 48-bit MAC 114 addresses unqualified by VLAN. (Actually 47 significant bits as 115 addresses with the group bit on are not learned.) 117 In a bridged LAN with 802.1D bridges, a single spanning tree is 118 determined and frames must flow along this tree. As a result, only 119 links that are part of the spanning tree can be used for through 120 traffic. 122 Since 802.1D bridges are ignorant of priority, frames do not get re- 123 ordered based on priority, low priority frames do not get 124 preferentially discarded due to he favoring of high priority frames, 125 and there are no facilities for mapping priority levels. 127 2.2 IEEE 802.1Q Bridges 129 802.1Q bridges [802.1Q] are aware of VLANs. Every frame internal to 130 such a bridge has a VLAN ID and priority associated with it. If the 131 frame arrived without a VLAN tag, the bridge port logic either drops 132 the frame or associates a VLAN and priority with it (see 133 [RFCprotocol] Appendix D). When a frame is transmitted by an 802.1Q 134 bridge, it can be sent with a VLAN tag indicating its VLAN and 135 priority or without such a tag, depending on port configuration. 136 Frames are only transmitted through a port if the VLAN of the frame 137 is in the set of VLANs enabled on that port. For a zero configuration 138 port, that set consists of only VLAN 1. 140 The learning of end station addresses in such a bridge is based on a 141 combined 12-bit VLAN ID and 48-bit (actually 47-bit as above) MAC 142 address. (However, 802.1Q bridges may support mapping VLAN IDs into a 143 smaller number of learning table IDs so that learning between those 144 VLANs is shared (see Section 4.6.3 of [RFCprotocol].) 146 A zero configuration 802.1Q bridge accepts frames that arrive tagged 147 with any valid VLAN. (They drop frames tagged with the illegal VLAN 148 0xFFF.) Frames without a VLAN tag are associated with VLAN 1. 149 However, because the ports of a zero configuration bridge have only 150 VLAN 1 enabled for output, accepted frames for any VLANs other than 151 1, unless they are addressed to the bridge itself, have no place they 152 can go. As a result, in an 802.1Q bridge network where there is 153 bridged traffic in any VLAN other than the default VLAN 1, it is 154 essential to configure ports to permit output for these other VLANs. 155 This can be done through management at each bridge or with VLAN 156 Registration Protocol messages (GVRP [802.1Q] or MVRP [802.1ak]) or a 157 combination of these techniques (see Section 4.7.2 of [RFCprotocol]). 159 By default, 802.1Q bridges form a single spanning tree and frames 160 flow along that tree. The bridge ports on spanning tree inter-bridge 161 links must be configured to enable all the VLANs which require the 162 link for connectivity. 802.1Q bridged LANs can be configured to have 163 up to an additional 64 spanning trees with traffic segregated between 164 the trees based on VLAN; however, the above considerations would 165 apply within each of such multiple spanning trees. 167 The recommended default for 802.1Q bridge ports is that VLANs be 168 disabled by default but dynamically registerable, except for VLAN 1, 169 which is fixed registered. As a result, VLAN Registration Protocol 170 frames can generally flow along the spanning tree adding the needed 171 VLANs to the ports where they are received so as to provide 172 connectivity between all end stations in each VLAN. 174 Since they recognize priority, 802.1Q bridges can re-order frames to 175 expedite those of higher priority and discard lower priority frames 176 in preference to discarding higher priority frames. 802.1Q bridge 177 ports not only associate a priority code point (0 through 7, default 178 1) with any frame received without a C-tag, they also map the 179 priority of a frame received with a C-tag. By default, this mapping 180 (which in IEEE 802.1 is called "regeneration") is the identity 181 mapping but can map each received priority code point to an arbitrary 182 other frame priority code point. 184 This priority mapping would make it possible, for example, to 185 configure a bridged LAN so that it had regions in which priority code 186 points had different external semantics such that the priority 187 associated with a frame was mapped at the regions boundaries. This 188 would require careful configuration of the appropriate ports of all 189 bridges at inter-regional boundaries. 191 2.3 RBridges 193 RBridges are VLAN tag aware and, in terms of VLANs and priority, the 194 port behavior and configurability of an RBridge port is identical 195 that of an 802.1Q customer bridge except for the handling of VLAN 196 registration protocols (GVRP and MVRP). RBridges also learn end 197 station addresses based on a combined 12-bit VLAN ID and 48-bit MAC 198 address (actually 47-bit as above). 200 Zero configuration RBridges accept TRILL frames for any valid VLAN 201 but accept native frames only on a port where they are appointed 202 forwarder for the frame's VLAN. Native frames are not forwarded in 203 native form out of any local port unless the RBridge is the appointed 204 forwarder for the port and VLAN. In the zero configuration case, it 205 could only be appointed forwarder for VLAN 1. However, once a native 206 frame is encapsulated into a TRILL data frame, it is not restricted 207 to ports where output to its Inner.VLAN is enabled. 209 A zero configuration RBridge could forward TRILL data frames and 210 encapsulate and forward native frames to another RBridge or RBridges. 211 For example, a known unicast TRILL data frame would be forwarded 212 toward the correct egress RBridge even if it is in a VLAN other than 213 1. An RBridge would distribute a multidestination frame on its 214 distribution tree, possibly pruned for efficiency, to a subset of 215 RBridges. This is because an RBridge to RBridge link does not need 216 its end ports to have the relevant end-to-end VLANs added to them; 217 the encapsulation can tag the frame with the Designated VLAN as the 218 outer VLAN ID. 220 As a result of this, there is normally no need for VLAN Registration 221 Protocol frames to affect the receiving ports of transit or egress 222 RBridges. It can, however, still be useful for such frames to add 223 VLANs to the set for the ports of ingress RBridges where they are 224 received. Also, it can be useful for RBridges to send such VLAN 225 Registration Protocol frames to bridges (or possibly even end 226 stations) that may be included in the campus. (See Section 4.7.2 of 227 [RFCprotocol] for more details on RBridge handling of dynamic VLAN 228 registration.) 230 In terms of frame priority, RBridges associate a priority code point 231 with every native frame they receive in the same way that an IEEE 232 802.1Q bridge does. They assign a priority if the frame is untagged. 233 If the frame is tagged and thus has a priority code point, they map 234 it to a potentially different priority code point, although the 235 default mapping is the identity mapping. While this determines the 236 priority of a native frame, if the frame received is a TRILL data or 237 ESADI frame, it contains an Inner.VLAN tag with the priority of the 238 frame at the time it was TRILL encapsulated. This inner priority code 239 point is used in the case of TRILL data and ESADI frames. (Priority 240 is not relevant for a core TRILL IS-IS frame received by an RBridge.) 241 This use of the Inner.VLAN priority code point for forwarded TRILL 242 frames means that, in some sense, the interpretation of priority code 243 points should be uniform throughout a campus. 245 3. Pluses and Minuses 247 The subsections below examine the tradeoffs in various RBridge 248 features and configuration options. 250 3.1 Trees and the Forest 252 Although one distribution tree is logically sufficient to distribute 253 multi-destination frames in a campus, TRILL supports multiple 254 distribution trees for the following reasons: 256 1. It is desirable to allow choosing a different distribution tree 257 than the one rooted at the ingress RBridge for some frames in 258 order to allow multipathing of multi-destination traffic 259 encapsulated by a particular RBridge. (See [RFCprotocol] Appendix 260 C.) 262 2. Using a tree rooted at the ingress RBridge optimizes the 263 distribution path and (almost always) the cost of delivery when 264 the number of destination links is a subset of the total number of 265 links, as is the case with VLANs and IP multicasts. 267 3. For unknown unicast destinations, using a tree rooted at the 268 ingress RBridge minimizes out-of-order delivery because, in the 269 case where a flow starts before the location of the destination is 270 known by the RBridges, the path to the destination is the same as 271 the shortest path to the destination (unless equal cost multipath 272 is being used). 274 A distribution tree rooted in the ingress RBridge is not always the 275 best choice. To assure availability of such a tree, it would be 276 necessary to compute a tree rooted at every RBridges. But a different 277 tradeoff might be wanted in terms of the expense of computing many 278 trees versus optimality of traffic distribution, so fewer trees would 279 be desired. 281 As described in [RFCprotocol] Section 4.3, each RBridge includes in 282 its LSP a priority for itself to be chosen as a distribution tree 283 root and a number of distribution trees. Ties in priority are broken 284 by System ID. The number of trees specified by the RBridge that is 285 highest priority (lowest numeric priority / system ID) to be a 286 distribution tree root governs the campus. RBridge computes the 287 specified number, say n, trees rooted at the n RBridges that are 288 highest priority to be a tree root. In a zero configuration RBridge 289 campus, each RBridge calculates two trees, one rooted at each of the 290 two RBridges with lowest System IDs, and each RBridges distributes 291 multi-destination frames which it ingresses over the tree whose root 292 is least cost from the ingress RBridge. 294 3.2 Loop Safety 296 Avoidance of loops at Layer 2 is critical as they lead to rapid 297 network saturation, denial of service, and even exponential growth in 298 the number of frames looping. 300 The asynchronous and distributed nature of the processes in RBridges 301 and bridges and the imperfections of these devices and communications 302 paths between them make absolute guarantees of delivery, frame 303 ordering, or transient loop avoidance impossible. However, the 304 default loop safety provisions of TRILL, under the assumptions TRILL 305 makes, are intended to provide the same order of reliability in loop 306 avoidance as modern bridged LANs. 308 3.2.1 Loop Safety Mechanisms 310 There are two primary safety mechanisms used by RBridges to protect 311 against persistent loops. (There are also additional mechanisms to 312 greatly reduce the occurrence and severity of transient loops.) The 313 primary persistent loop safety mechanisms are as follows: 315 o The use of TRILL IS-IS Hellos, and 316 o The decapsulation check. 318 The adequacy of the default set of TRILL Hellos to protect against 319 persistent loops is discussed in Section 4 below. 321 The second mechanism is the optional "decapsulation check" (sometimes 322 called the "root bridge collision" check). Every RBridge is required 323 to report in its link state for each VLAN for which it is appointed 324 forwarder on at least one of its ports, the complete list of root 325 bridges it sees on those ports. (This list may be null if none of 326 those ports leads to a bridged LAN.) 328 When an egress RBridge is about to decapsulate a TRILL data frame and 329 send a VLAN-x native frame out a port and it sees a root bridge R out 330 that port, it may optionally check to see if that R is on the list of 331 root bridges seen for VLAN-x by the frame's ingress RBridge. If this 332 check finds R, then the checking RBridge knows that it was about to 333 decapsulate onto either (1) the same bridged LAN from which the 334 native frame originated, possibly forming a loop, or (2) onto a 335 bridged LAN that was also directly connected to the ingress RBridge 336 on a port where the ingress RBridge was appointed forwarder for the 337 frame's VLAN. In this second case, the ingress RBridge should have 338 already forwarded the frame locally and so it should not have arrived 339 at the egress RBridge in encapsulated form. In any case, if this 340 optional check is performed and the locally observed root bridge is 341 found in the ingress RBridge's list for the frame's VLAN, the egress 342 Rbridge does not send the decapsulated native frame out the port but 343 discards it. 345 3.2.2 Loop Safety Tradeoffs 347 The transmission and reception of many TRILL IS-IS Hellos can impact 348 available communications bandwidth and processing power. In other 349 words, they can stress the control plane. On the other hand, use of 350 the decapsulation (root bridge collision) check requires an 351 additional check in the data plane before any TRILL data is 352 decapsulated onto a link, making the data plane more complex. 354 If the computational and bandwidth load are acceptable, a campus will 355 be safer to the extent the RBridges are configured to perform the 356 decapsulation check and also send Hellos on at least the default set 357 of VLANs as specified in [RFCprotocol] Section 4.2.3.1. 359 Under normal circumstances, if any of the RBridges connected to a 360 link are configured to send Hellos into the link on fewer than the 361 default set of VLANs, it is recommended that those RBridges implement 362 and use the decapsulation check on their ports connected to that 363 link. 365 Under special circumstances, where it is known to be safe with a high 366 degree of reliability, RBridges may be configured to send Hellos on 367 fewer VLANs than the default without using the decapsulation check. 369 4. No Persistent Loops 371 This section demonstrates that, with reasonable assumptions, the 372 default set of Hellos that RBridges send do not permit the occurrence 373 of persistent loops in an RBridge campus. 375 Section 4.1 below divides cases where a frame persistently loops into 376 three categories and show that only one of these can be problematic. 377 Section 4.2 discusses the possibly problematic case from the point of 378 view of a single pair of connected RBridges and provides a sketch of 379 a proof that, for any pair of connected RBridges and under reasonable 380 assumptions, the problematic case cannot persist. Finally Section 4.3 381 expands this sketch of a proof to an arbitrary bridged LAN connected 382 to an arbitrary number of RBridges. 384 4.1 Categories of Loops 386 An RBridge campus can consist of a large number of RBridges (in 387 principle somewhat less than 2**16 or more if some do not require 388 nicknames) interconnected by LANs that may be bridged. The RBridge 389 ports and any bridges involved could be arbitrarily configured 390 concerning what VLANs they pass, how they treat untagged frames on 391 frame receipt and for what VLANs they strip VLAN tags on 392 transmission. 394 A persistent loop would be a frame that cycled indefinitely, although 395 it might, at various parts of that cycle, be tagged with different 396 VLANs and might be in TRILL encapsulated form or native form. 397 Persistent loops can be divided into three categories as follows: 399 1. The first category of persistent loop would be one within a 400 bridged or unbridged LAN between RBridges or end stations. The 401 looping frame could be any type of frame, native, TRILL, or 402 control. This category is the concern of IEEE 802.1 bridging 403 standards. They solve this potential problem by forwarding frames, 404 when they are forwarded, in accordance with one of several 405 variations of the spanning tree protocol. While transient loops 406 can occur due to loss of spanning tree BPDUs or topology changes 407 that are not immediately detected, spanning tree prevents 408 persistent loops unless unsafe bridge options, such an inhibiting 409 the transmission of BPDUs, are used. 411 2. The second category of persistent loop would be one of TRILL 412 frames persistently transiting the same set of at least two 413 RBridges. The frames cannot loop in the network between RBridges 414 as that would be a category one loop discussed above. Also, there 415 is no way for core TRILL IS-IS frames to loop as they only go one 416 RBridge hop and are never forwarded by an RBridge. So such a loop 417 would have to be of a TRILL data or TRILL ESADI frame among 418 RBridges. Such persistent loops cannot occur because TRILL uses 419 IS-IS, which does not produce persistent loops in the forwarding 420 of unicast frames or in the trees constructed for the distribution 421 of multi-destination frames. 423 In addition, all TRILL data and ESADI frames have a TTL that must 424 be decremented by at least one each RBridge hop and the frame 425 discarded, rather than forwarded, if the TTL is reduced to zero. 426 Therefore no individual frame can persistently loop. 428 Although not necessary to avoid persistent loops as herein 429 defined, RBridges further inhibit possible temporary looping of 430 multi-destination TRILL frames through the adjacency checks, 431 including the reverse path forwarding check, made on arriving 432 TRILL data or ESADI frames. 434 3. There remains only one further category for persistent loops. In 435 category 1 above, we discuss why there cannot be persistent loops 436 within the possibly bridged LANs which connect RBridges. Therefore 437 the loop must involve frames sent between RBridges. In category 2 438 above, we discuss why there cannot be persistent loops of TRILL 439 frames being transmitted between RBridges. Therefore, any 440 persistent loop must involve, at least in part, non-TRILL frames 441 transmitted between RBridges. 443 There are only two non-TRILL types of frames, control frames and 444 native frames. Control frames are transmitted only one RBridge or 445 bridge hop and are not forwarded so they cannot loop. Therefore, 446 any persistent loop must involve a native frame sent from one 447 RBridge to another RBridge. Note that native frames do not have 448 TTL protection. 450 Section 4.2 below gives a sketch of a proof that native frame type 3 451 persistent loops cannot occur by considering a single pair of 452 RBridges on a link. Section 4.3 goes into excruciating detail 453 extending this to an arbitrary set RBridges connected to an arbitrary 454 bridged LAN. 456 4.2 Analysis for a Single Pair of RBridges 458 It is shown above that any persistent loop in an RBridge campus must 459 involve a native frame sent from one RBridge to another. These must 460 be different RBridges as it is a fundamental assumption of the 461 Ethernet service model that a frame transmitted on an Ethernet link 462 will not be received by the transmitter. 464 For there to be a loop, the receiving RBridge must actually accept 465 the frame and forward it in some form. An RBridge only accepts a 466 native frame if it is appointed forwarder on the port for the frame's 467 VLAN. If it is not the appointed VLAN-x forwarder for the native 468 frame, the native frame is simply discarded. 470 An RBridge never transmits a native frame unless it is appointed 471 forwarder for the frame's VLAN on the port where the frame is 472 transmitted. 474 Thus, for their to be a loop involving native frame transmission 475 between RBridges, both must be appointed forwarder on the link. 476 However, they would not necessarily have to be appointed for the same 477 VLAN. For example, the transmitting RBridge or some bridge along the 478 way could be stripping VLAN tags and some later bridge or the 479 receiving RBridge could insert a different VLAN tag or associate the 480 frame with a different VLAN. 482 Can this situation occur? 484 The primary defenses against such dual appointed forwarder situations 485 are, as described in [RFCprotocol] Section 4.2.3.1, the DRB and its 486 appointer forwarder determinations, which are mediated by TRILL IS-IS 487 Hellos. By default, the ports on which Hellos are transmitted include 488 any port where an RBridge is an appointed forwarder. Hellos are sent 489 out such a port for each VLAN for which the RBridge is appointed 490 forwarder. 492 Assume the RBridge sending the native frame is RB-s and the RBridge 493 receiving it is RB-r. Since a native frame is getting from RB-s to 494 RB-r, we assume that a Hello sent in the same VLAN will also get from 495 RB-s to RB-r and arrive with the same VLAN as the native frame. (This 496 might not be true if successive bridge/RBridge ports were configured 497 so that the Outer.VLAN was stripped and then frames were assigned a 498 VLAN based on frame protocol with different VLANs for TRILL IS-IS 499 frames (VLAN-T) and for a possibly looping native frame (VLAN-n). 500 Such a situation would not necessarily cause a loop but could if 501 other conditions were met including that no VLAN-n Hellos were being 502 sent from RBridges and received by RB-r. In any case, we assume that 503 this is not the situation.) 505 It will be clear to RB-r from the Hello it receives from RB-s that 506 RB-s considers itself to be the appointed forwarder as there is a 507 flag in the Hello for this purpose. If the Hello is received with a 508 different Outer.VLAN ID from its Inner.VLAN ID, then VLAN mapping is 509 occurring and, as stated in [RFCprotocol], native frames received by 510 RB-r in VLAN-n will be discarded. Thus there can be no loop with VLAN 511 mapping. 513 Without VLAN mapping, VLAN-T equals VLAN-n and RB-r will receive 514 Hellos from RB-s indicating that RB-s believes itself to be appointed 515 forwarder for the VLAN. This will cause RB-s to inhibit its appointed 516 forwarder activity and discard the native frame, so no loop is 517 formed. 519 4.3 Analysis for on Arbitrary Bridged LAN 521 When a link provides full bi-directional connectivity between the 522 RBridges connected to it, each such RBridge can see the Hellos sent 523 by the others on that link. In that case, the selection of the one 524 DRB on the link and the decisions by that DRB as to appointed 525 forwarders are straightforward. However, the exact situation on an 526 arbitrary bridged LAN connecting multiple RBridges can, in the worst 527 case, be much more complex than this. 529 Of course, with N RBridges attached to a bridged LAN, the analysis in 530 Section 4.2 applies to each N*(N-1)/2 unordered pairs. Thus, it is 531 clear from the outset that there cannot be any loops. Nevertheless, 532 it is interesting to analyze the different populations of RBridges 533 there can be attached to the bridged LAN link. 535 We will model the transmission of Hellos between the N RBridges 536 connected by an arbitrary bridged LAN as the existence of a pipe 537 between each pair of RBridges. Thus there are N*(N-1)/2 such pipes. 538 When an RBridge sends a Hello, it is pushed into all the pipes 539 terminating at that RBridge. Each pipe passes frames tagged with an 540 arbitrary subset of legal VLAN IDs. In general, the set of VLANs 541 passed can be asymmetric, that is, it is different in each direction 542 through the pipe. 544 TRILL IS-IS Hellos have the ID of the VLAN on which they are sent 545 embedded in the body of the Hello. In this section, we will initially 546 assume that no VLAN mapping is occurring. With this assumption, we 547 need not worry about Outer.VLAN tags getting stripped or added by 548 ports. By the time a TRILL IS-IS Hello arrives at RBridge specific 549 code as shown in [RFCprotocol] Figure 4.3, it will have had a VLAN ID 550 associated with it. The no-VLAN-mapping assumption implies that this 551 will necessarily be the VLAN ID with which it was transmitted. 553 Consider the set of N RBridges connected to a bridged LAN: RB1, RB2, 554 disabled or have no VLANs enabled do not count as a connection to the 555 link to which they are physically attached.) These RBridges can be 556 strictly ordered by their priority to become DRB. This priority is an 557 unsigned 55-bit integer consisting of the RBridge's 7-bit priority to 558 become DRB (the IS-IS Hello header DIS priority) concatenated with 559 its 48-bit port MAC address. (There actually should be only 54 560 significant bits as the group bit in the MAC address should always be 561 zero.) Assume, without loss of generality, that the RBridges are 562 numbered in priority order so that RB1 is the highest priority to 563 become DRB. 565 RB1 will specify a Designated VLAN in its Hellos and will specify the 566 adjacencies that it sees on its Designated VLAN in the Hellos that it 567 sends on that VLAN. The set of RBridges receiving Hellos from RB1 on 568 any VLAN will be denoted {H+RB1}. The RBridges in {H+RB1} will see 569 that RB1 is DRB and will defer to RB1 since, by construction, they 570 are of lower priority. If they have the Designated VLAN enabled on 571 the port on which they receive a Hello from RB1, they will send such 572 a Hello on the Designated VLAN on that port. If that Hellos makes it 573 through to RB1, the normal IS-IS mechanisms will establish IS-IS 574 adjacencies between them and RB1 and transitively among this subset 575 of the RBridges with connectivity to RB1 over its Designated VLAN. 576 Thus they will be able to exchange TRILL data, LSPs, etc. In the 577 normal case, where the bridged LAN conforms to the assumptions in 578 [RFCprotocol] Section 2.3, this will be all of the RBridges connected 579 by this bridged LAN. It is only in the case of badly configured 580 bridges, that is, configurations which violate the the assumptions in 581 Section 2.3, that the discussion below in this section is relevant. 583 There may be other RBridges in {H+RB1} that can see Hellos from RB1 584 on one or more VLANs but cannot establish an IS-IS adjacency with it 585 on the Designated VLAN as above and are orphaned from the link on 586 that port. This can occur for two reasons: (1) because the Designated 587 VLAN is not enabled on their RBridge port connected to the link, or 588 (2) because, although the Designated VLAN is enabled, there is only 589 connectivity for the VLAN through the bridged LAN from RB1 to the 590 RBridge in question but no connectivity in the other direction. 592 There may be RBridges connected to the bridged LAN which cannot see 593 Hellos from RB1. That is, in {RB*} but not in {H+RB1}. Such RBridges 594 have no knowledge of RB1 and thus could not defer to it as DRB. 595 However, they may receive a Hello from a member of {H+RB1} other than 596 RB1; that is, in effect, they may be two "Hello ops" from RB1. If 597 they receive such Hello from an RBridge that is higher priority than 598 they are, they will defer and know that they are not DRB. They do not 599 have connectivity from RB1 over the Designated VLAN because, if they 600 did, they would have received Hellos from RB1 and be in {H+RB1}. Thus 601 they are orphaned from the link. Denoting such RBridges as {H++RB1}, 602 there may be yet further RBridges in {RB*} that are no in {H+RB1} or 603 {H++RB1} but which can receive Hellos from a higher priority RBridge 604 in {H++RB1} and which they will defer too. Such RBridges are three 605 Hellos hops from RB1, are similarly orphaned, are denoted as 606 {H+++RB1}. This process may continue if there are further RBridges 607 even more Hello hops from RB1 such that there is a chain of RBridges 608 from them to RB1 with incraesing priority as RB1 is approached. We 609 will denote the union of RB1, {H+RB1}, {H++RB1}, etc., will be 610 denoted as {H*RB1}, i.e. the set of all RBridges on the link which 611 either are RB1 or which defer to RB1 as DRB or are at the end of a 612 chain of RBridges each of which defers to the next ending in RB1. 614 In the worst case, there could be configuration such that RB1 is DRB 615 but cannot form an adjacency with any other RBridge, RB2 will defer 616 to RB1 because it sees Hellos from RB1, RB3 defers to RB2 because it 617 sees Hellos from RB2 but not RB1, RB4 defers to RB3 because it sees 618 Hellos from RB3 but not RB1 or RB2, etc., through RBN which defers to 619 RB(N-1) because it sees Hellos from RB(N-1) but not from any lower 620 numbered RBridge. 622 Consider the RBridges in {RB*} but not in {H*RB1}. If this set is not 623 empty, there will be one RBridge in this set that is highest priority 624 to be DRB, say RBi. Since, by construction, RBi is not in {H*RB1}, it 625 is not receiving Hellos from any higher priority RBridge and thinks 626 itself to be DRV. We can now perform the same analysis above leading 627 to the conclusion that there will be a set (possibly consisting of 628 just RBi) of RBridges {H*RBi} which (1) receive Hellos from RBi or a 629 deferral chain ending in RBi via one or more Hello hops, (2) do not 630 receive Hellos from RB1 or from any RBridge with a higher priority in 631 {H*RB1}. Thus the members of {H*RBi} directly or indirectly defer to 632 RBi as DRB. 634 There are several possibilities for connectivity between the {H*RB1} 635 and {H*RBi} sets: 637 1. It may be that there is no connectivity at all between RBridges in 638 {H*RB1} and {H*RBi} in which case each of these sets is connected 639 to what is, for all practical purposes, a separate link. In this 640 case it is loop safe that there is a separate DRB for each (RB1 641 and RBi) and there may be a different appointed forwarders in each 642 set for the same VLAN. In this case a native frame sent by an 643 RBridge in either set cannot get to an RBridge in the other set 644 since, in this case, there is no connectivity. 646 2. Alternatively, there may be some unidirectional or bi-directional 647 connectivity between one or more RBridges in {H*RB1} and {H*RBi}. 648 However, in no case could there be connectivity from a higher 649 priority RBridge in {H*RB1} to a lower priority RBridge in {H*RBi} 650 as that would cause the lower priority RBridge to leave {H*RBi} 651 and join {H*RB1}, deferring directly or indirectly to RB1. 652 However, other possible connectivity is still potentially 653 dangerous. In particular, connectivity over VLAN-x between two 654 RBridges that are both VLAN-x appointed forwarders for that VLAN 655 causes a loop unless one of the appointed forwarders is inhibited. 656 There are three possibilities: 657 2a. Unidirectional connectivity from a lower priority RBridge in 658 the set with the lower priority DRB ( {H*RBi} ) to a higher 659 priority RBridge in the set with a higher priority DRB ( 660 {H*RB1} ). 661 2b. Unidirectional connectivity from a lower priority RBridge in 662 the set with the higher priority DRB to a higher priority 663 RBridge in the set with a lower priority DRB. 665 2c. Bidirectional connectivity as in 2b. 667 The danger possible in 2a through 2c is solved by providing that 668 while a higher priority RBridge is receiving Hellos on VLAN-x from a 669 lower priority RBridge where the lower priority RBridge is an 670 appointed forwarder for VLAN-x, the higher priority RBridge does not 671 encapsulate native frames off the link or decapsulate native frames 672 onto the link for VLAN-x. This is one reason why all RBridges, by 673 default, send Hellos on all VLANs for which they are appointed 674 forwarder. 676 Even outside of the union of {H*RB1} and {H*RBi}, there may be 677 additional RBridges connected to the bridged LAN. If so there would 678 be one of them with highest priority, say RBj. We can then repeat the 679 above analysis and see that there is a set {H*RBj} of RBridges 680 deferring directly or indirectly to RBj. As above, if there is no 681 connectivity between any RBridge in {H*RBj} and any RBridge in either 682 {H*RB1} or {H*RBi}, then these populations of RBridges can act 683 independently without risk of a loop. However, if there is 684 connectivity on VLAN-x from a VLAN-x appointed forwarder in {H*RBj} 685 to one in {H*RB1} or {H*RBi} then the higher priority of the 686 conflicting appointed forwarders inhibit any encapsulation or 687 decapsulation of any VLAN-x native frames off of or onto the link. 689 This process can be continued as long as their remain RBridges 690 connected to the bridged LAN in question which are not yet found to 691 be part of a set of RBridges deferring directly or indirectly to a 692 DRB. The method of construction for these sets outlined above means 693 that the sets will be produced in order of declining priority of the 694 set's DRB. By construction, they can be no persistent connectivity, 695 unidirectional or otherwise, from a higher priority RBridge in a set 696 with a higher priority DRB to a lower priority RBridge in a set with 697 a lower priority DRB as it would cause the lower priority RBridge to 698 switch sets. Any of these sets of RBridges can safely act 699 independently if they have no connectivity over the bridged LAN to 700 any RBridges in any other set. Whenever there is connectivity over 701 VLAN-x between two RBridges that are appointed VLAN-x forwarder, the 702 higher priority RBridge of the two does not encapsulate or 703 decapsulating VLAN-x native frames off of or onto the link. 705 The addition of VLAN mapping, ignored in the analysis above, makes 706 more complex loop possible. For example, if mappings form a cycle, 707 there could be loops in the campus where a frame is decapsulated from 708 VLAN-x, encapsulated as VLAN-y, then decapsulated from VLAN-y and 709 encapsulated as VLAN-x (x->y->x) or longer loops going through more 710 VLANs. However, as specified in [RFCprotocol] Section 4.2.3.1.3, when 711 VLAN mapping is detected, the "to" VLAN ID is disabled at the 712 detecting RBridge. Thus, a loop cannot be formed via a VLAN mapping 713 path through a bridged LAN between RBridges because the mapping would 714 inhibit processing of frames in the receiving RBridge. 716 5. Security Considerations 718 This document provides additional informational notes related to 719 RBridges and the TRILL protocol but not directly related to security. 720 For RBridge base protocol security considerations, see [RFCprotocol]. 722 6. Normative References 724 [RFCprotocol] - "Rbridges: Base Protocol Specification", R. Perlman 725 et al, draft-ietf-trill-rbridge-protocol-10.txt, November 2, 2008, 726 work in progress. 728 7. Informative References 730 [802.1ak] "IEEE Standard for Local and metropolitan area networks / 731 Virtual Bridged Local Area Networks / Multiple Registration 732 Protocol", IEEE Standard 802.1ak-2007, 22 June 2007. 734 [802.1D] "IEEE Standard for Local and metropolitan area networks / 735 Media Access Control (MAC) Bridges", IEEE Standard 802.1D-2004, 9 736 June 2004. 738 [802.1Q] "IEEE Standard for Local and metropolitan area networks / 739 Virtual Bridged Local Area Networks", IEEE Standard 802.1Q-2005, 740 19 May 2006. 742 8. IANA Considerations 744 This document requires no IANA actions. 746 RFC Editor: This section should be deleted before publication. 748 Disclaimer 750 This document and the information contained herein are provided on an 751 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 752 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 753 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 754 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 755 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 756 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 758 Additional IPR Provisions 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed to 762 pertain to the implementation or use of the technology described in 763 this document or the extent to which any license under such rights 764 might or might not be available; nor does it represent that it has 765 made any independent effort to identify any such rights. Information 766 on the procedures with respect to rights in RFC documents can be 767 found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use of 772 such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository at 774 http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention any 777 copyrights, patents or patent applications, or other proprietary 778 rights that may cover technology that may be required to implement 779 this standard. Please address the information to the IETF at ietf- 780 ipr@ietf.org. 782 Copyright (C) The IETF Trust 2008 This document is subject to the 783 rights, licenses and restrictions contained in BCP 78, and except as 784 set forth therein, the authors retain all their rights. 786 Author's Address 788 Donald E. Eastlake 3rd 789 Stellar Switches 790 155 Beaver Street 791 Milford, MA 01757 USA 793 email: d3e3e3@gmail.com 795 Expiration and File Name 797 This draft expires in 8 June 2009. 799 Its file name is draft-eastlake-trill-notes-01.txt.