Network Working Group Donald Eastlake 3rd INTERNET-DRAFT Eastlake Enterprises Intended status: Informational Expires: February 19, 2009 August 20, 2008 Rbridge Notes Status of This Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides additional informational material related to RBridges, which are devices that implement the TRILL protocol. It is a supplement to the RBridges base protocol specification and includes discussion of tradeoffs in some features and configurations of RBridges. In addition, it provides a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. D. Eastlake [Page 1] INTERNET-DRAFT TRILL Header Options Table of Contents Status of This Document....................................1 Abstract...................................................1 Table of Contents..........................................2 1. Introduction............................................3 2. Zero Configuration Comparison...........................4 2.1 IEEE 802.1D Bridges....................................4 2.2 IEEE 802.1Q Bridges....................................4 2.3 RBridges...............................................6 3. Pluses and Minuses......................................8 3.1 Trees and the Forest...................................8 3.2 Loop Safety............................................9 3.2.1 Loop Safety Mechanisms...............................9 3.2.2 Loop Safety Tradeoffs...............................10 4. No Persistent Loops....................................11 4.1 Categories of Loops...................................11 4.2 Analysis for a Single Pair of RBridges................12 4.3 Analysis for on Arbitrary Bridged LAN.................14 5. Security Considerations................................18 6. Normative References...................................18 7. Informative References.................................18 8. IANA Considerations....................................18 Disclaimer................................................19 Additional IPR Provisions.................................19 Author's Address..........................................19 Expiration and File Name..................................20 D. Eastlake [Page 2] INTERNET-DRAFT TRILL Header Options 1. Introduction This document provides informational material related to RBridges, which are devices that implement the TRILL protocol. Section 2 briefly compares some aspects of zero configuration IEEE 802.1D and 802.1Q bridges and RBridges. Section 3 discusses some tradeoffs in features and configurations of RBridges. While Section 4 presents a sketch of a proof that, with reasonable assumptions, persistent loops do not occur in a TRILL campus. The terms and acronyms defined in Sections 1.3 and 1.4 of [RFCprotocol] are used with the same definitions herein. D. Eastlake [Page 3] INTERNET-DRAFT TRILL Header Options 2. Zero Configuration Comparison This section provides an informational comparison of the behavior of a zero configuration IEEE 802.1D bridge, a zero configuration IEEE 802.1Q bridge, or a zero configuration RBridge in a network of possibly configured devices. The goal is to clarify the behavioral differences, particularly in regard to VLANs and priority. All three devices can learn end station addresses in essentially the same way, through the observation of traffic (although RBridges provide an additional facility, which can be configured to learn such information via TRILL IS-IS messages). 2.1 IEEE 802.1D Bridges 802.1D bridges [802.1D] are ignorant of VLANs. They are unaware whether frames received have a C-tag (formerly called Q-tag), the tag which provides VLAN ID and priority. As a result, 802.1D bridges learn end station address locations based on simple 48-bit MAC addresses unqualified by VLAN. (Actually 47 significant bits as addresses with the group bit on are not learned.) In a bridged LAN of 802.1D bridges, a single spanning tree is determined and frames must flow along this tree. As a result, only links that are part of the spanning tree can be used for through traffic. Since 802.1D bridges are ignorant of priority, frames do not get re- ordered based on priority, low priority frames do not get preferentially discarded due to he favoring of high priority frames, and there are no facilities for mapping priority levels. 2.2 IEEE 802.1Q Bridges 802.1Q bridges [802.1Q] are aware of VLANs. Every frame internal to such a bridge has a VLAN ID and priority associated with it. If the frame arrived without a VLAN tag, the bridge port logic either drops the frame or associates a VLAN and priority with it (see [RFCprotocol] Appendix D). When a frame is transmitted by an 802.1Q bridge, it can be sent with a VLAN tag indicating its VLAN and priority or without such a tag, depending on port configuration. Frames are only transmitted through a port if the VLAN of the frame is in the set of VLANs enabled on that port. For a zero configuration port, that set consists of only VLAN 1. The learning of end station addresses in such a bridge is based on a combined 12-bit VLAN ID and 48-bit (actually 47-bit as above) MAC D. Eastlake [Page 4] INTERNET-DRAFT TRILL Header Options address. (However, 802.1Q bridges may support mapping VLAN IDs into a smaller number of learning table IDs so that learning between those VLANs is shared (see Section 4.6.3 of [RFCprotocol].) A zero configuration 802.1Q bridge accepts frames that arrive tagged with any valid VLAN. (They drop frames tagged with the illegal VLAN 0xFFF.) Frames without a VLAN tag are associated with VLAN 1. However, because the ports of a zero configuration bridge have only VLAN 1 enabled for output, accepted frames for any VLANs other than 1, unless they are addressed to the bridge itself, have no place they can go. As a result, in an 802.1Q bridge network where there is bridged traffic in any VLAN other than the default VLAN 1, it is essential to configure ports to permit output for these other VLANs. This can be done through management at each bridge or with VLAN Registration Protocol messages (GVRP [802.1Q] or MVRP [802.1ak]) or a combination of these techniques (see Section 4.7.2 of [RFCprotocol]). By default, 802.1Q bridges form a single spanning tree and frames flow along that tree. The bridge ports on spanning tree inter-bridge links must be configured to enable all the VLANs which require the link for connectivity. 802.1Q bridged LANs can be configured to have up to an additional 64 spanning trees with traffic segregated between the trees based on VLAN; however, the above considerations would apply within each of such multiple spanning trees. The recommended default for 802.1Q bridge ports is that VLANs be disabled by default but dynamically registerable, except for VLAN 1, which is fixed registered. As a result, VLAN Registration Protocol frames can generally flow along the spanning tree adding the needed VLANs to the ports where they are received so as to provide connectivity between all end stations in each VLAN. Since they recognize priority, 802.1Q bridges can re-order frames to expedite those of higher priority and discard lower priority frames in preference to discarding higher priority frames. 802.1Q bridge ports not only associate a priority code point (0 through 7, default 1) with any frame received without a C-tag, they also map the priority of a frame received with a C-tag. By default, this mapping (which in IEEE 802.1 is called "regeneration") is the identity mapping but can map each received priority code point to an arbitrary other frame priority code point. This priority mapping would make it possible, for example, to configure a bridged LAN so that it had regions in which priority code points had different external semantics such that the priority associated with a frame was mapped and the regions boundaries. But this would require careful configuration of the appropriate ports of all bridges at inter-regional boundaries. D. Eastlake [Page 5] INTERNET-DRAFT TRILL Header Options 2.3 RBridges RBridges are VLAN tag aware and, in terms of VLANs and priority, the port behavior and configurability of an RBridge is almost identical to that of an 802.1Q customer bridge. RBridges also learn end station addresses based on a combined 12-bit VLAN ID and 48-bit MAC address (actually 47-bit as above). Zero configuration RBridges accept TRILL frames for any valid VLAN but accept native frames only on a port where they are appointed forwarder for the frame's VLAN. Native frames are not forwarded in native form out of any local port unless the RBridge is the appointed forwarder for the port and VLAN. In the zero configuration case, it could only be appointed forwarder for VLAN 1. However, once a native frame is encapsulated into a TRILL data frame, it is not restricted to ports where output to its Inner.VLAN is enabled. A zero configuration RBridge could forward TRILL data frames and encapsulate and forward native frames to another RBridge or RBridges. For example, a known unicast TRILL data frame would be forwarded toward the correct egress RBridge even if it is in a VLAN other than 1. An RBridge would distribute a multidestination frame on its distribution tree, possibly pruned for efficiency, to a subset of RBridges. This is because an RBridge to RBridge link does not need its end ports to have the relevant end-to-end VLANs added to them; the encapsulation can tag the frame with the Designated VLAN as the outer VLAN ID. As a result of this, there is normally no need for VLAN Registration Protocol frames to affect the receiving ports of transit or egress RBridges. It can, however, still be useful for such frames to add VLANs to the set for the ports of ingress RBridges where they are received. Also, it can be useful for RBridges to send such VLAN Registration Protocol frames to bridges (or possibly even end stations) that may be included in the campus. (See Section 4.7.2 of [RFCprotocol] for more details on RBridge handling of dynamic VLAN registration.) In terms of frame priority, RBridges associate a priority code point with every native frame they receive in the same way that an IEEE 802.1Q bridge does. They assign a priority if the frame is untagged. If the frame is tagged and thus has a priority code point, they map it to a potentially different priority code point although the default mapping is the identity mapping. While this determines the priority of a native frame, if the frame received is a TRILL data or ESADI frame, it contains an Inner.VLAN tag with the priority of the frame at the time it was TRILL encapsulated. This inner priority code point is used the case of TRILL data and ESADI frames. (Priority is not relevant for a core TRILL IS-IS frame received by an RBridge.) D. Eastlake [Page 6] INTERNET-DRAFT TRILL Header Options This use of the Inner.VLAN priority code point for forwarded TRILL frames means that, in some sense, the interpretation of priority code points should be uniform throughout a campus. D. Eastlake [Page 7] INTERNET-DRAFT TRILL Header Options 3. Pluses and Minuses The subsections below examine the tradeoffs in various RBridge features and configuration options. 3.1 Trees and the Forest Although one distribution tree is logically sufficient to distribute multi-destination frames in a campus, TRILL supports multiple distribution trees for the following reasons: 1. It is desirable to allow choosing a different distribution tree than the one rooted at the ingress RBridge for some frames in order to allow multipathing of multi-destination traffic encapsulated by a particular RBridge. (See [RFCprotocol] Appendix C.) 2. Using a tree rooted at the ingress RBridge optimizes the distribution path and (almost always) the cost of delivery when the number of destination links is a subset of the total number of links, as is the case with VLANs and IP multicasts. 3. For unknown unicast destinations, using a tree rooted at the ingress RBridge minimizes out-of-order delivery because, in the case where a flow starts before the location of the destination is known by the RBridges, the path to the destination is the same as the shortest path to the destination (unless equal cost multipath is being used). A distribution tree rooted in the ingress RBridge is not always the best choice. To assure availability of such a tree, it would be necessary to compute a tree rooted at every RBridges. 0 tradeoff might be wanted in terms of the expense of computing many trees versus optimality of traffic distribution, so fewer trees would be desired. As described in [RFCprotocol] Section 4.3, each RBridge includes in its LSP a priority for itself to be chosen as a distribution tree root and a number of distribution trees. Ties in priority are broken by System ID. The number of trees specified by the RBridge that is highest priority (lowest numeric priority / system ID) to be a distribution tree root governs the campus. RBridge computes the specified number, say n, trees rooted at the n RBridges that are highest priority to be a tree root. In a zero configuration RBridge campus, each RBridge calculates two trees, one rooted at each of the two RBridges with lowest System IDs, and each RBridges distributes multi-destination frames which it ingresses over the tree whose root is least cost from the ingress RBridge. D. Eastlake [Page 8] INTERNET-DRAFT TRILL Header Options 3.2 Loop Safety Avoidance of loops at Layer 2 is critical as they lead to rapid network saturation, denial of service, and even exponential growth in the number of frames looping. The asynchronous and distributed nature of the processes in RBridges and bridges and the imperfections of these devices and communications paths between them make absolute guarantees of delivery, frame ordering, or transient loop avoidance impossible. However, the default loop safety provisions of TRILL, under the assumptions TRILL makes, are intended to provide the same order of reliability in loop avoidance as modern bridged LANs. 3.2.1 Loop Safety Mechanisms There are two primary safety mechanisms used by RBridges to protect against persistent loops. (There are also additional mechanisms to greatly reduce the occueance and severity of transient loops.) The primary persistent loop safety mechanisms are as follows: The use of TRILL IS-IS Hellos, and The decapsulation check. The adequacy of the default set of TRILL Hellos to protect against persistent loops is discussed in Section 4 below. The second mechanism is the optional "decapsulation check" (sometimes called the "root bridge collision" check). Every RBridge is required to report in its link state for each VLAN for which it is appointed forwarder on at least one of its ports, the complete list of root bridges it sees on those ports. (This list may be null if none of those ports leads to a bridged LAN.) When an egress RBridge is about to decapsulate a TRILL data frame and send a VLAN-x native frame out a port and it sees a root bridge R out that port, it may optionally check to see if that R is on the list of root bridges seen for VLAN-x by the frame's ingress RBridge. If this check finds R, then the checking RBridge knows that it was about to decapsulate onto either (1) the same bridged LAN from which the native frame originated, possibly forming a loop, or (2) onto a bridged LAN that was also directly connected to the ingress RBridge on a port where the ingress RBridge was appointed forwarder for the frame's VLAN. In this second case, the ingress RBridge should have already forwarded the frame in native form and so it should not have arrived at the egress RBridge in encapsulated form. In any case, if this optional check is performed and the locally observed root bridge is found in the ingress RBridge's list for the frame's VLAN, the D. Eastlake [Page 9] INTERNET-DRAFT TRILL Header Options egress Rbridge does not send the decapsulated native frame out the port but discards it. 3.2.2 Loop Safety Tradeoffs The transmission and reception of many TRILL IS-IS Hellos can impact available communications bandwidth and processing power. In other words, they can stress the control plane. On the other hand, use of the decapsulation (root bridge collision) check requires an additional check in the data plane before any TRILL data is decapsulated onto a link, making the data plane more complex. If the computational and bandwidth load are acceptable, a campus will be safer to the extent the RBridges are configured to perform the decapsulation check and also send Hellos on at least the default set of VLANs as specified in [RFCprotocol] Section 4.2.3.1. Under normal circumstances, if any of the RBridges connected to a link are configured to send Hellos into the link on fewer than the default set of VLANs, it is recommended that those RBridges implement and use the decapsulation check on their ports connected to that link. Under special circumstances, where it is known to be safe with a high degree of reliability, RBridges may be configured to send Hellos on fewer VLANs than the default without using the decapsulation check. D. Eastlake [Page 10] INTERNET-DRAFT TRILL Header Options 4. No Persistent Loops This section demonstrates that, with reasonable assumptions, the default set of Hellos that RBridges send do not permit the occurence of persistent loops in an RBridge campus. Section 4.1 below divides cases where a frame persistently loops into three categories and show that only one of these can be problematic. Section 4.2 discusses the possibly problematic case from the point of view of a single pair of connected RBridges and provides a sketch of a proof that, for any pair of connected RBridges and under reasonable assumptions, the problematic case cannot persist. Finally Section 4.3 expands this sketch of a proof to an aribtrary bridged LAN connected to an arbitrary number of RBridges. 4.1 Categories of Loops An RBridge campus can consist of a large number of RBridges (in principle up to 2**16 - 2 or more if some do not require nicknames) interconnected by LANs that may be bridged. The RBridge ports and any bridges involved could be arbitrarily configured concerning what VLANs they pass, how they treat untagged frames on frame receipt and for what VLANs they strip VLAN tags on transmission. A persistent loop would be a frame that cycled indefinitely, although it might, at various parts of that cycle, be tagged with different VLANs and might be in TRILL encapsulated form or native form. Persistent loops can be divided into three categories as follows: 1. The first category of persistent loop would be one within a bridged or unbridged LAN between RBridges or end stations. The looping frame could be any type of frame, native, TRILL, or control. This category is the concern of IEEE 802.1 bridging standards that solve this potential problem by forwarding frames, when they are forwarded, in accordance with one of several variations of the spanning tree protocol. While transient loops can occur due to loss of spanning tree BPDUs or topology changes that are not immediately detected, spanning tree prevents persistent loops unless unsafe bridge options, such an inhibiting the transmission of BPDUs, are used. 2. The second category of persistent loop would be one of TRILL frames persistently transiting the same set of at least two RBridges. The frames cannot loop in between RBridges as that would be a category one loop discussed above. Also, there is no way for core TRILL IS-IS frames to loop as they only go one RBridge hop and are never forwarded by an RBridge. So such a loop would have to be of a TRILL data or TRILL IS-IS ESADI frame among RBridges. D. Eastlake [Page 11] INTERNET-DRAFT TRILL Header Options Such persistent loops cannot occur because TRILL uses IS-IS, which does not produce persistent loops in the forwarding of unicast frames or in the trees constructed for the distribution of multi- destination frames. In addition, all TRILL data and ESADI frames have a TTL that must be decremented by at least one each RBridge hop and the frame discarded, rather than forwarded, if the TTL is reduced to zero. Therefore no individual frame can persistently loop. Although not necessary to avoid persistent loops as herein defined, RBridges further inhibit possible temporary looping of multi-destination TRILL frames through the adjacecny checks, including the reverse path forwarding check, made on arriving TRILL data or ESADI frames. 3. There remains only one further category for persistent loops. In category 1 above, we discuss why there cannot be persistent loops within the possibly bridged LANs which connect RBridges. Therefore the loop must involve frames sent between RBridges. In category 2 above, we discuss why there cannot be persistent loops of TRILL frames being transmitted between RBridges. Therefore, any persistent loop must involve, at least in part, non-TRILL frames transmitted between RBridges. There are only two non-TRILL types of frames, control frames and native frames. Control frames are transmitted only one RBridge or bridge hop and are not forwarded so they cannot loop. Therefore, any persistent loop must involve a native frame sent from one RBridge to another RBridge. Note that native frames do not have TTL protection. Section 4.2 below gives a sketch of a proof that native frame type 3 persistent loops cannot occur by considering a single pair of RBridges on a link. Section 4.3 goes into excruciating detail extending this to an arbitrary set RBridges connected to an arbitrary bridged LAN. 4.2 Analysis for a Single Pair of RBridges It is shown above that any persistent loop in an RBridge campus must involve a native frame sent from one RBridge to another. These must be separate RBridges as it is a fundamental assumption of the Ethernet service model that a frame transmitted on an Ethernet link will not be received by the transmitter. For there to be a loop, the receiving RBridge must actually accept the frame and forward it in encapsulated or native form. An RBridge D. Eastlake [Page 12] INTERNET-DRAFT TRILL Header Options only accepts a native frame if it is appointed forwarder on the port for the frame's VLAN. If it is not the appointed VLAN-x forwarder for the native frame, the native frame is discarded and not forwarded in any way. An RBridge never transmits native frames unless it is appointed forwarder for the frame's VLAN on the port where the frames are transmitted. Thus, for their to be a loop involving native frame transmission between RBridges, both would have to be appointed forwarder on the link. However, they would not necessarily have to be appointed for the same VLAN. For example, the transmitting RBridge or some bridge along the way could be stripping VLAN tags and some later bridge or the receiving RBridge could insert a different VLAN tag or associate the frame with a different VLAN. Can this situation occur? The primary defenses against such dual appointed forwarder situations are, as described in [RFCprotocol] Section 4.2.3.1, the DRB and its appointer forwarder determinations, which are mediated by TRILL IS-IS Hellos. By default, the ports on which Hellos are transmitted include any port where an RBridge is an appointed forwarder. Hellos are sent out such a port for each VLAN for which the RBridge is appointed forwarder. Assume the RBridge sending the native frame is RBs and the RBridge receiving it is RBr. Since a native frame is getting from RBs to RBr, we assume that a Hello sent in the same VLAN will also get from RBs to RBr and arrive with the same VLAN as the native frame. (This might not be true if successive bridge/RBridge ports were configured so that the Outer.VLAN was stripped and then frames were assigned a VLAN based on protocol with different VLANs for TRILL frames (VLAN-T) and for a possibly looping native frame (VLAN-n). Such a situation would not necessarily cause a loop but could if other conditions were met including that no VLAN-n Hellos were being sent from RBs and received by RBr. In any case, we assume that this is not the situation.) It will be clear to RBr from this Hello it receives from RBs that RBs considers itself to be the appointed forwarder as there is a flag in the Hello for this purpose. If the Hello is received with a different Outer.VLAN ID from its Inner.VLAN ID, then VLAN mapping is occurring and, as stated in [RFCprotocol] Section 4.2.3.1.3, native frames received by RBr with either of those VLAN IDs will be discarded. Thus there can be no loop with VLAN mapping. Without VLAN mapping, RBr will receive Hellos from RBs indicating that RBs believes itself to be appointed forwarder for the VLAN of the native frame. This will cause RBs to inhibit its appointed D. Eastlake [Page 13] INTERNET-DRAFT TRILL Header Options forwarder activity and discard the native frame, so no loop is formed. 4.3 Analysis for on Arbitrary Bridged LAN When a link provides full bi-directional connectivity between the RBridges connected to it, each such RBridge can see the Hellos sent by the others on that link. In that case, the selection of the one DRB on the link and the decisions by that DRB as to appointed forwarders are straightforward. However, the exact situation on an arbitrary bridged LAN connecting multiple RBridges can, in the worst case, be much more complex than this. We will model the transmission of Hellos between the N RBridges connected by an arbitrary bridged LAN as the existence of a pipe between each pair of RBridges. Thus there are N*(N-1)/2 such pipes. When an RBridge sends a Hello, it is pushed into all the pipes terminating at that RBridge. Each pipe passes frames tagged with an arbitrary subset of legal VLAN IDs. In general, the set of VLANs passed is different in each direction through the pipe. TRILL IS-IS Hellos have the VLAN on which they are sent embedded in the body of the Hello. In this section, we will initially assume that no VLAN mapping is occurring. With this assumption, we need not worry about Outer.VLAN tags getting stripped or added by ports. By the time a TRILL IS-IS Hello arrives at RBridge specific code as shown in [RFCprotocol] Figure 4.3, it will have had a VLAN ID associated with it. The no-VLAN-mapping assumption implies that this will necessarily be the VLAN ID with which it was transmitted. Consider the set of N RBridges connected to a bridged LAN: RB1, RB2, ... RBn which we will denote as {RB*}. (Any RBridge ports which are disabled or have no enabled VLANs do not count as a connection to the link to which they are physically attached.) These RBridges can be strictly ordered by their priority to become DRB. This priority is an unsigned 55-bit integer consisting of the RBridge's 7-bit priority to become DRB (the IS-IS Hello header DIS priority) concatenated with its 48-bit port MAC address. (There actually should be only 54 significant bits as the group bit in the MAC address should be zero.) Assume, without loss of generality, that RB1 is the highest priority to become DRB. It will specify a Designated VLAN in its Hellos and will specify the adjacencies that it sees on its Designated VLAN in the Hellos that it sends on that VLAN. The set of RBridges receiving Hellos from RB1 ( h{RB1} ) on any VLAN will see that RB1 is DRB, will defer to RB1 since, by construction, they are of lower priority, and will announce RB1 as the DRB in all of their Hellos. If they have the Designated VLAN enabled on the port on which they receive a Hello D. Eastlake [Page 14] INTERNET-DRAFT TRILL Header Options from RB1, they will send such a Hello on the Designated VLAN on that port. The normal IS-IS mechanisms will establish IS-IS adjacencies between this subset of the RBridges with connectivity to RB1 over its Designated VLAN. Thus they will be able to exchange TRILL data, LSPs, etc. In the normal case, where the bridged LAN conforms to the assumptions in [RFCprotocol] Section 2.3, this will be all of the RBridges connected by this bridged LAN. It is only in the case of badly configured bridges, that is, configurations which violate the the assumptions in Section 2.3, that the discussion below in this section is relevant. There may be other RBridges in h{RB1} that can see Hellos from RB1 on one or more VLANs but cannot establish an IS-IS adjacency with it on the Designated VLAN as above and are orphaned from the link on that port. This can occur for any of three reasons: (1) because the Designated VLAN is not enabled on the port in question, (2) because, although the Designated VLAN is enabled, it has no connectivity through the bridged LAN from the port in question to RB1, and (3) although there is connectivity over the Designated VLAN from the port in question to RB1, there is no such connectivity in the other direction. The set of RBridges which receive Hellos from the RBridges which receive Hellos from RB1, that is from the set of RBridges two "Hello hops" over the link from RB1, is denoted h*2{RB1}. RBridges in that set which are not in h{RB1} and are not RB1 itself cannot receive Hellos directly from RB1 and so will be unable to establish adjacency with RB1 but will see RB1 announced as the DRB. If they were to simply believe that and announce it in their Hellos, we would have the possibility of a live-lock. For example, assume the initially RBy is in h*2{RB1} but is not RB1 and is not in h{RB1} and RBx is in h{RB1}. If RBx and RBy each believe the others Hello announcement that RB1 is DRB, they would continue to believe that even if RB1 dropped off the link or was reconfigured to have lower priority. To break this live-lock, an RBridge believes and defers to the DRB announcement in a Hello it receives only if the receiving RBridge is lower priority than the RBridge actually sending the Hello. If the announcing RBridge is higher priority than the receiving RBridge, they do defer to the announced DRB, RB1 in this case, and announce it in their Hellos. There may be additional RBridges three Hello hops from RB1, that is in h*3{RB1}, but which are not RB1 or in h{RB1} or h*2{RB1} which are similarly affected, if they are lower priority than at least one of the RBridges from which they receive a Hello showing RB1 as DRB, and so on. If very limited connectivity via various VLANs exists and the relative priorities were just right, deference to RB1 can continue to propagate and could, in the worst case, require N-1 Hellos steps for the last and lowest priority RBridge to get word that it should defer to RB1. The entire set of RBridges connected to the particular D. Eastlake [Page 15] INTERNET-DRAFT TRILL Header Options bridged LAN and deferring to RB1 is denoted h**{RB1}. There may be RBridges connected to the bridged LAN which are not in h**{RB1}, that is in the set {RB*} but not in the set h**{RB1}}. Such RBridges may have no direct or indirect knowledge of RB1 and thus could not defer to it or may receive Hellos showing RB1 as DRB only from RBridges of lower priority which they do not honor to avoid live-lock as explained above. If this set is not empty, there will be one RBridge in this set that is highest priority to be DRB, say RBi. We can now perform the same analysis above leading to the conclusion that there will be a set h**{RBi} of RBridges which defer to RBi. There are several possibilities for connectivity between the h**{RB1} and h**{RBi} sets: 1. It may be that there is no connectivity at all between RBridges in h**{RB1} and h**{RBi} in which case each of these sets is connected to what is, for all practical purposes, a separate link. In this case it is loop safe that there is a separate DRB for each (RB1 and RBi) and there may be a different appointed forwarders in each set for the same VLAN. 2. Alternatively, there may be some unidirectional or bi-directional connectivity between one or more RBridges in h**{RB1} and h**{RBi}. However, in no case could there be connectivity from a higher priority RBridge in h**{RB1} to a lower priority RBridge in h**{RBi} as that would cause the lower priority RBridge to defer to RB1, leave h**{RBi}, and join h**{RB1}. However, other possible connectivity is still potentially dangerous. In particular, connectivity over VLAN-x between two RBridges that are both VLAN-x appointed forwarders for that VLAN causes a loop unless one of the appointed forwarders is inhibited. There are three possibilities: 2a. Unidirectional connectivity from a lower priority RBridge in the set with the lower priority DRB ( h**{RBi} ) to a higher priority RBridge in the set with a higher priority DRB ( h**{RB1} ). 2b. Unidirectional connectivity from a lower priority RBridge in the set with the higher priority DRB to a higher priority RBridge in the set with a lower priority DRB. 2c. Bidirectional connectivity as in 2b. The danger possible in 2a through 2c is solved by providing that while a higher priority RBridge is receiving Hellos on VLAN-x from a lower priority RBridge where the lower priority RBridge is an appointed forwarder for VLAN-x, the higher priority RBridge does not encapsulate native frames off the link or decapsulate native frames onto the link for VLAN-x. This is one reason why all RBridges, by default, send Hellos on all VLANs for which they are appointed forwarder. D. Eastlake [Page 16] INTERNET-DRAFT TRILL Header Options Even outside of h**{RB1} and h**{RBi}, there may be additional RBridges connected to the bridged LAN. If so there would be one of them with highest priority, say RBj. We can then repeat the above analysis and see that there is a set h**{RBj} of RBridges deferring to RBj. As above, if there is no connectivity between any RBridge in h**{RBj} and any RBridge in either h**{RB1} or h**{RBi}, then these populations of RBridges can act independently without risk of a loop. However, if there is connectivity on VLAN-x from a VLAN-x appointed forwarder in h**{RBj} to one in h**{RB1} or h**{RBi} then the higher priority of the conflicting appointed forwarders inhibit any encapsulation or decapsulation any VLAN-x native frames off of or onto the link. This process can be continued as long as their remain RBridges connected to the bridged LAN in question which are not yet found to be part of a set of RBridges deferring to a DRB. The method of construction for these sets outlined above means that the sets will be produced in order of declining priority of the set's DRB. By construction, they can be no persistent connectivity, unidirectional or otherwise, from a higher priority RBridge in a set with a higher priority DRB to a lower priority RBridge in a set with a lower priority DRB as it would cause the lower priority RBridge to switch sets. Any of these sets of RBridges can safely act independently if they have no connectivity over the bridged LAN to any RBridges in any other set. Whenever there is connectivity over VLAN-x between two RBridges that are appointed VLAN-x forwarder, the higher priority RBridge of the two does not encapsulate or decapsulating VLAN-x native frames off of or onto the link. The addition of VLAN mapping, ignored in the analysis above, makes more complex loop possible. For example, if mappings form a cycle, there could be loops in the campus where a frame is decapsulated from VLAN-x, encapsulated as VLAN-y, then decapsulated from VLAN-y and encapsulated as VLAN-x (x->y->x) or longer loops going through more VLANs. However, as specified in [RFCprotocol] Section 4.2.3.1.3, when VLAN mapping is detected, both the "from" and "to" VLAN IDs are disabled at the detecting RBridge. Thus, a loop cannot be formed via a VLAN mapping path through a bridged LAN between RBridges because the mapping would inhibit processing of frames in the receiving RBridge. D. Eastlake [Page 17] INTERNET-DRAFT TRILL Header Options 5. Security Considerations This document provides additional informational notes related to RBridges and the TRILL protocol but not directly related to security. For RBridge base protocol security considerations, see [RFCprotocol]. 6. Normative References [RFCprotocol] - "Rbridges: Base Protocol Specification", R. Perlman et al, draft-ietf-trill-rbridge-protocol-08.txt, July 14, 2008, work in progress. 7. Informative References [802.1ak] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks / Multiple Registration Protocol", IEEE Standard 802.1ak-2007, 22 June 2007. [802.1D] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges", IEEE Standard 802.1D-2004, 9 June 2004. [802.1Q] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", IEEE Standard 802.1Q-2005, 19 May 2006. 8. IANA Considerations This document requires no IANA actions. This section should be deleted before publication. D. Eastlake [Page 18] INTERNET-DRAFT TRILL Header Options Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Additional IPR Provisions The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright (C) The IETF Trust 2008 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Author's Address Donald E. Eastlake 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA D. Eastlake [Page 19] INTERNET-DRAFT TRILL Header Options email: d3e3e3@gmail.com Expiration and File Name This draft expires in February 2009. Its file name is draft-eastlake-trill-notes-00.txt. D. Eastlake [Page 20]