TRILL Working Group Radia Perlman INTERNET-DRAFT Intel Labs Intended status: Informational Donald Eastlake Huawei Anoop Ghanwani Brocade Expires: October 4, 2011 April 5, 2011 RBridges: Multilevel TRILL Abstract This is an informational document describing issues and comparing advantages and disadvantages of various possible approaches to extending TRILL to use multiple levels of IS-IS. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Acknowledgements The helpful comments of the following are hereby acknowledged: David Michael Bond and Dino Farinacci. R. Perlman, et al [Page 1] INTERNET-DRAFT RBridges: Multilevel TRILL Table of Contents 1. Introduction............................................3 1.1 TRILL Scalability Issues...............................3 1.2 Improvements Due to Multilevel.........................4 1.3 More on Areas..........................................4 1.4 Terminology and Acronyms...............................5 2. Multilevel TRILL Issues.................................6 2.1 Non-zero Area Addresses................................6 2.2 Aggregated versus Unique Nicknames.....................7 2.2.1 More Details on Unique Nicknames.....................7 2.2.2 More Details on Aggregated Nicknames.................8 2.2.2.1 Border Learning Aggregated Nicknames...............9 2.2.2.2 Swap Nickname Field Aggregated Nicknames..........11 2.2.2.3 Comparison........................................11 2.3 Building Multi-Area Trees.............................12 2.4 The RPF Check for Trees...............................13 2.5 Area Nickname Acquisition.............................13 2.6 Link State Representation of Areas....................13 3. Area Partition.........................................15 4. Multi-Destination Scope................................16 4.1 Unicast to Multi-destination Conversions..............16 4.2 Selective Broadcast Domain Reduction..................17 5. Co-Existence with Old RBridges.........................18 6. Summary................................................19 7. Security Considerations................................19 8. IANA Considerations....................................19 9. References.............................................20 9.1 Normative References..................................20 9.2 Informative References................................20 R. Perlman, et al [Page 2] INTERNET-DRAFT RBridges: Multilevel TRILL 1. Introduction The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using [IS- IS] link state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLANs and IP derived multicast groups. Devices that implement TRILL are called RBridges. Familiarity with [RFCtrill] is assumed in this document. 1.1 TRILL Scalability Issues There are multiple issues that might limit the scalability of a TRILL-based network: 1. the routing computation load, 2. the volatility of the LSP database creating too much control traffic, 3. the volatility of the LSP database causing the TRILL network to be in an unconverged state too much of the time, 4. the size of the LSP database, 5. the hard limit of the number of RBridges, due to the 16-bit nickname space, 6. the traffic due to upper layer protocols use of broadcast and multicast, and 7. the size of the end node learning table (the table that remembers (egress RBridge, VLAN/MAC) pairs). Extending TRILL IS-IS to be multilevel (hierarchical) helps with some of these issues. IS-IS was designed to be multilevel [IS-IS] [RFC1195]. A network can be partitioned into "areas". Routing within an area is known as "Level 1 routing". Routing between areas is known as "Level 2 routing". The Level 2 IS-IS network consists of Level 2 routers and links between the Level 2 routers. Level 2 routers may participate in one or more areas, in addition to their role as Level 2 routers. Each area is connected to Level 2 through one or more "border routers", which participate both as a router inside the area, and as a router inside the Level 2 "area". Care must always be taken that it is clear, when transitioning between Level 2 and a Level 1 area in either direction, which (single) border RBridge will transition the frame between the levels. R. Perlman, et al [Page 3] INTERNET-DRAFT RBridges: Multilevel TRILL 1.2 Improvements Due to Multilevel Partitioning the network into areas reduces the size of the LSP database in each router, and stops volatility of the topology in one area from disrupting other areas. Allowing TRILL to utilize IS-IS's hierarchy solves issues 1 through 4 above, but does not necessarily help the other 3 issues (hard limit of 16-bit RBridge nicknames, traffic due to upper layer protocols using multicast, and size of end node learning table). However, partitioning the network into areas facilitates a technique described in Section 4 to limit the broadcast domain for some traffic, thus reducing problem 6 (traffic due to upper layer protocols use of broadcast and multicast). We propose two alternatives of hierarchical or multilevel TRILL. One we call the "unique nickname" alternative. The other we call the "aggregated nickname" alternative. In the aggregated nickname alternative, border RBridges replace either the ingress or egress nickname field in the TRILL header of unicast frames with an aggregated nickname representing an entire area. The aggregated nickname alternative has the following advantages: o it solves the 16-bit RBridge nickname limit, o it lessens the amount of inter-area routing information that must be passed in IS-IS, o it greatly reduces the RPF information (since only the area nickname needs to appear, rather than all the ingress RBridges in that area), and o it enables computation of trees such that the portion computed within a given area is rooted within that area. The unique nickname alternative has the advantage that border RBridges are simpler and do not need to do TRILL Header nickname modification. 1.3 More on Areas Each area is configured with an "area address", which is advertised in IS-IS messages, so as to avoid accidentally interconnecting areas. Note that, although the area address had other purposes in CLNP, (IS- IS was originally designed for CLNP/DECnet), for TRILL the only purpose of the area address would be to avoid accidentally interconnecting areas. Currently, the TRILL specification says that the area address must be zero. If we change the specification so that the area address value of zero is just a default, then most of IS-IS multilevel machinery works as originally designed. However, there are TRILL-specific R. Perlman, et al [Page 4] INTERNET-DRAFT RBridges: Multilevel TRILL issues, which we address below in this document. 1.4 Terminology and Acronyms This document uses the acronyms defined in [RFCtrill] and the following additional acronym: DBRB - Designated Border RBridge R. Perlman, et al [Page 5] INTERNET-DRAFT RBridges: Multilevel TRILL 2. Multilevel TRILL Issues The TRILL-specific issues introduced by hierarchy include the following: a. Configuration of non-zero area addresses, encoding them in IS-IS PDUs, and possibly interworking with old RBridges that do not understand nonzero area addresses. b. Nickname management. c. Advertisement of pruning information (VLAN reachability, IP multicast addresses) across areas. Distribution tree pruning information is only an optimization, as long as multi-destination frames are not prematurely pruned. For instance, border RBridges could advertise they can reach all possible VLANs, and have an IP multicast router attached. This would cause all multi-destination traffic to be transmitted to border RBridges, and possibly pruned there, when the traffic could have been pruned earlier based on VLAN or multicast group if border RBridges advertised more detailed VLAN and/or multicast listener and multicast router attachment information. d. Computation of trees across areas for multi-destination frames. e. Computation of RPF information for those trees. g. Compatibility, as much as practical, with existing, unmodified RBridges. The most important form of compatibility is with existing TRILL fast path hardware. Changes that require upgrade to the slow path firmware/software are more tolerable. Compatibility for the relatively small number of border RBridges is less important than compatibility for non-border RBridges. 2.1 Non-zero Area Addresses The current TRILL base protocol specification [RFCtrill] says that the area address in IS-IS must be zero. The purpose of the area address is to ensure that different areas are not accidentally hooked together. Furthermore, zero is an invalid area address for layer 3 IS-IS, so it was chosen as an additional safety mechanism to ensure that layer 3 IS-IS would not be confused with TRILL IS-IS. However, TRILL uses a different multicast address and an Ethertype to avoid such confusion, so it is not necessary to worry about this. R. Perlman, et al [Page 6] INTERNET-DRAFT RBridges: Multilevel TRILL Since current TRILL RBridges will reject any IS-IS messages with nonzero area addresses, the choices are as follows: a.1 upgrade all RBridges to understand non-zero area addresses, a.2 neighbors of old RBridges must remove the area address from IS-IS messages when talking to an old RBridge (which might break IS-IS security and/or cause inadvertent merging of areas), a.3 ignore the problem of accidentally merging areas entirely, or a.4 keep the fixed "area address" field as 0 in TRILL, and add a new, optional TLV for "area name" that, if present, could be compared, by new RBridges, to prevent accidental area merging. In principal, different solutions could be used in different areas but it would be much simpler to adopt one of these choices uniformly. 2.2 Aggregated versus Unique Nicknames In the unique nickname alternative, all nicknames across the campus must be unique. In the aggregated nickname alternative, RBridge nicknames are only of local significance within an area, and the only nickname externally (outside the area) visible is the "area nickname", which aggregates all the internal nicknames. The aggregated nickname approach eliminates the potential problem of nickname exhaustion, minimizes the amount of nickname information that would need to be forwarded between areas, minimizes the size of the forwarding table, and simplifies RPF calculation and RPF information. 2.2.1 More Details on Unique Nicknames With unique cross-area nicknames, it would be intractable to have a flat nickname space with RBridges in different areas contending for the same nicknames. Instead, each area would need to be configured with a block of nicknames. Either some RBridges would need to announce that all the nicknames other than that block are taken (to prevent the RBridges inside the area from choosing nicknames outside the area's nickname block), or a new TLV would be needed to announce the allowable nicknames, and all RBridges in the area would need to understand that new TLV. Currently the encoding of nickname information in TLVs does not allow any aggregation. The information could be encoded as ranges of nicknames to make this somewhat manageable; however, a new TLV for announcing nickname ranges would not be intelligible to old RBridges. R. Perlman, et al [Page 7] INTERNET-DRAFT RBridges: Multilevel TRILL There is also an issue with the unique nicknames approach in building distribution trees, as follows: With unique nicknames in the TRILL campus and TRILL header nicknames not rewritten by the border RBridges, there would have to be globally known nicknames for the trees. Suppose there are k trees. For all of the trees with nicknames located outside an area, the trees would be rooted at a border RBridge or RBridges. Therefore, there would be either no splitting of multi-destination traffic with the area or restricted splitting of multi-destination traffic between trees rooted at a highly restricted set of RBridges. 2.2.2 More Details on Aggregated Nicknames The aggregated nickname approach enables passing far less nickname information and works as follows: Each area would be assigned a 16-bit nickname. This would not be the nickname of any actual RBridge. Instead, it would be the nickname of the area itself. Border RBridges would know the area nickname for their own area(s). The TRILL Header nickname fields in TRILL Data frames being transported through a multilevel RBridge campus with aggregated nicknames are as follows: - When being transported in Level 2, the ingress nickname is the nickname of the ingress RBridge's area while the egress nickname is either the nickname of the egress RBridge's area or a tree nickname - When being transported in Level 1 to Level 2, the ingress nickname is the nickname of the ingress RBridge itself while the egress nickname is either the nickname of the area of the egress RBridge or a tree nickname. - When being transported from Level 2 in Level 1, the ingress nickname is the nickname of the ingress RBridge's area while the egress nickname is either the nickname of the egress RBridge itself or a tree nickname. - When both the ingress and egress RBridges are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields. There are two variation of the aggregated nickname approach. The first is the Border Learning approach, which is described in Section 2.2.2.1. The second is the Swap Nickname Field approach, which is R. Perlman, et al [Page 8] INTERNET-DRAFT RBridges: Multilevel TRILL described in Section 2.2.2.2. Section 2.2.2.3 compares the advantages and disadvantages of these two variations. 2.2.2.1 Border Learning Aggregated Nicknames This section provides an illustrative example and description of the border learning variation of aggregated nicknames. In the following picture, R2 and R3 are area border RBridges. A source S is attached to R1. The two areas have nicknames 15961 and 15918, respectively. R1 has a nickname, say 27, and R4 has a nickname, say 44 (and in fact, they could even have the same nickname, since the RBridge nickname will not be visible outside the area). Area 15961 level 2 Area 15918 +-------------------+ +-----------------+ +-------------+ | | | | | | | S--R1---Rx--Rz-----R2----Rb---Rc--Rd---Re--R3---Rk--R4---D | | 27 | | | | 44 | | | | | | | +-------------------+ +-----------------+ +-------------+ Let's say that S transmits a frame to destination D, which is connected to R4, and let's say that D's location is learned by the relevant RBridges already. The relevant RBridges have learned the following: 1) R1 has learned that D is connected to nickname 15918 2) R3 has learned that D is attached to nickname 44. The following sequence of events will occur: - S transmits an Ethernet frame with source MAC = S and destination MAC = D. - R1 encapsulates with a TRILL header with ingress RBridge = 27, and egress = 15918. - R2 has announced in the Level 1 IS-IS instance in area 16961, that it is attached to all the area nicknames, including 15918. Therefore, IS-IS routes the frame to R2. (Alternatively, if a distinguished range of nicknames is used for Level 2, Level 1 RBridges seeing such an egress nickname will know to route to the nearest border router, which can be indicated by the IS-IS attached bit.) - R2, when transitioning the frame from Level 1 to Level 2, replaces R. Perlman, et al [Page 9] INTERNET-DRAFT RBridges: Multilevel TRILL the ingress RBridge nickname with the area nickname, so replaces 27 with 15961. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 15961, and the egress RBridge field will be 15918. Also R2 learns that S is attached to nickname 27 in area 15961 to accommodate return traffic. - The frame is forwarded through Level 2, to R3, which has advertised, in Level 2, reachability to the nickname 15918. - R3, when forwarding into area 15918, replaces the egress nickname in the TRILL header with R4's nickname (44). So, within the destination area, the ingress nickname will be 15961 and the egress nickname will be 44. - R4, when decapsulating, learns that S is attached to nickname 15961, which is the area nickname of the ingress. Now suppose that D's location has not been learned by R1 and/or R3. What will happen, as it would in TRILL today, is that R1 will forward the frame as a multi-destination frame, choosing a tree. As the multi-destination frame transitions into Level 2, R2 replaces the ingress nickname with the area nickname. If R1 does not know the location of D, the frame must be flooded, subject to possible pruning, in Level 2 and, subject to possible pruning, from Level 2 into every Level 1 area. Now suppose that R1 has learned the location of D (attached to nickname 15918), but R3 does not know where D is. In that case, R3 must turn the frame into a multi-destination frame within area 15918. In this case, care must be taken so that, in case R3 is not the Designated transitioner between Level 2 and its area for that multi- destination frame, but was on the unicast path, that another border RBridge in that area not forward the now multi-destination frame back into Level 2. Therefore, it would be desirable to have a marking, somehow, that indicates the scope of this frame's distribution to be "only this area" (see also Section 4). The issue described at the end of Section 2.2.1 with trees in the unique nickname alternative is eliminated with aggregated nicknames. With aggregated nicknames, each border RBridge that will transition multi-destination frames can have a mapping between Level 2 tree nicknames and Level 1 tree nicknames. There need not even be agreement about the total number of trees; just that the border RBridge have some mapping, and replace the egress RBridge nickname (the tree name) when transitioning levels. R. Perlman, et al [Page 10] INTERNET-DRAFT RBridges: Multilevel TRILL 2.2.2.2 Swap Nickname Field Aggregated Nicknames As a variant, two additional fields could exist in TRILL Data frames we call the "ingress swap nickname field" and the "egress swap nickname field". The changes in the example above would be as follows: - R1 will have learned the area nickname of D and the RBridge nickname of R4 to which D is attached. In encapsulating a frame to D, it puts the area nickname of D (15918) in the egress nickname field of the TRILL Header and puts the nickname of R3 (44) in a egress swap nickname field. - R2 moves the ingress nickname to the ingress swap nickname field and inserts 15961, the area nickname for S, into the ingress nickname field. - R3 swaps the egress nickname and the egress swap nickname fields, which sets the egress nickname to 44. - R4 learns the correspondence between the source MAC/VLAN of S and the { ingress nickname, ingress swap nickname field } pair as it decapsulates and egresses the frame. 2.2.2.3 Comparison The Border Learning variant described in Section 2.2.2.1 above minimizes the change in non-border RBridges but imposes the burden on border RBridges of learning and doing lookups in all the end station MAC addresses within their area(s) that are used for communication outside the area. The burden could be somewhat reduced by decreasing the area size and increasing the number of areas. The Swap Nickname Field variant described in Section 2.2.2.2 eliminates the extra address learning burden on border RBridges but requires more extensive changes to non-broader RBridges. In particular they must learn to associate both an RBridge nickname and an area nickname with end station MAC/VLAN pairs (except for addresses that are local to their area). The Swap Nickname Field alternative is more scalable but less backward compatible for non-broder RBridges. R. Perlman, et al [Page 11] INTERNET-DRAFT RBridges: Multilevel TRILL 2.3 Building Multi-Area Trees It is easy to build a multi-area tree by building a tree in each area separately, (including the Level 2 "area"), and then having only a single border RBridge, say R1, in each area, attach to the Level 2 area. R1 would forward all multi-destination frames between that area and Level 2. People might find this unacceptable, however, because of the desire to path split (not always sending all multi-destination traffic through the same border RBridge). Having multiple border RBridges introduces some complexities: a) calculating the RPF check when a multi-destination frame originates outside the area (which border RBridge injected the frame into the area?) b) calculating the filtering information (which border RBridge will transition the frame into Level 2?) This might be solvable if all RBridges are multilevel aware, however it is difficult to imagine how to ensure that old RBridges would calculate RPF and filtering information sensibly. Ignoring old RBridges for now, various possible solutions are as follows: a) elect one border RBridge for transitioning all multi-destination frames between levels (call that the Designated Border RBridge (DBRB)) b) allow the DBRB to appoint other border RBridges to forward some subset of the inter-level frames. (as the DRB does, on a per-VLAN basis, on a link). Make the appointment information visible to the other RBridges in the area so that they can calculate their RPF and filtering information. If b), then on what basis would the appointment be made? Various possibilities are as follows: o based on VLAN o based on tree root o based on ingress RBridge nickname The more flexibility that is allowed, the more complex the announcement of information becomes, and the more complex the tree database becomes. If appointment is made based on VLAN, then the RPF check would need to be based on (tree, VLAN, ingress nickname), rather than simply (tree, ingress nickname) as it is today. R. Perlman, et al [Page 12] INTERNET-DRAFT RBridges: Multilevel TRILL 2.4 The RPF Check for Trees For multi-destination frames originating locally in R1's area, computation of the RPF check is done as today. For multi-destination frames originating outside R1's area, computation of the RPF check must be done based on which one of the border RBridges (say R1, R2, or R3) injected the frame into the area. An RBridge, say R4, located inside an area, must be able to know which of R1, R2, or R3 transitioned the frame into the area from Level 2. (or into Level 2 from an area). This could be done based on having the DBRB announce the transitioner assignments to all the RBridges in the area. 2.5 Area Nickname Acquisition In the aggregated nickname alternative, each area must acquire a unique area nickname. It is probably simpler to allocate a block of nicknames (say, the top 4000) to be area addresses, and not used by any RBridges. The area nicknames need to be advertised and acquired through Level 2. Within an area, all the border RBridges must discover each other through the Level 1 link state database, by advertising, in their LSP "I am a border RBridge". Of the border RBridges, one will have highest priority (say R7). R7 can dynamically participates, in Level 2, to acquire a nickname for the area. R7 could give the area a pseudonode name, such as R7.5, within Level 2. So an area would appear, in Level 2, as a pseudonode and the pseudonode can participate, in Level 2, to acquire a nickname for the area. Within Level 2, all the border RBridges [for an area] can advertise reachability to the pseudonode, which would mean connectivity to the area nickname. 2.6 Link State Representation of Areas Within an area, say area A, there is an election for the DBRB, (Designated Border RBridge), say R1. This can be done through LSPs within area A. The border RBridges announce themselves, together with their DBRB priority. (Note that the election of the DBRB cannot R. Perlman, et al [Page 13] INTERNET-DRAFT RBridges: Multilevel TRILL be done based on Hello messages, because the border RBridges are not necessarily physical neighbors of each other. They can, however, reach each other through connectivity within the area, which is why it will work to find each other through Level 1 LSPs.) R1 acquires the area nickname (in the aggregated nickname approach), gives the area a pseudonode name (just like the DRB would give a pseudonode name to a link). R1 advertises, in area A, what the pseudonode name for the area is (and the area nickname that R1 has acquired). The pseudonode LSP initiated by R1 includes any information extraneous to area A that should be input into area A (such as area nicknames of external areas, or perhaps (in the unique nickname variant), all the nicknames of external RBridges in the TRILL campus and filtering information such as IP multicast groups and VLANs). All the other border RBridges for the area announce (in their LSP) attachment to that pseudonode. Within Level 2, R1 generates a Level 2 LSP on behalf of the area, also represented as a pseudonode. The same pseudonode name could be used within Level 1 and Level 2, for the area. (There does not seem any reason why it would be useful for it to be different, but there's also no reason why it would need to be the same). Likewise, all the area A border RBridges would announce, in their Level 2 LSPs, connection to the pseudonode. R. Perlman, et al [Page 14] INTERNET-DRAFT RBridges: Multilevel TRILL 3. Area Partition It is possible for an area to become partitioned, so that there is still a path from one section of the area to the other, but that path is via the Level 2 area. An area will naturally break into two areas in this case. An area address might be configured to ensure two areas are not inadvertently connected. That area address appears in Hellos and LSPs within the area. If two chunks, connected only via Level 2, were configured with the same area address, this would not cause any problems. (They would just operate as separate Level 1 areas.) A more serious problem occurs if the Level 2 area is partitioned in such a way that it could be healed by using a path through a Level 1 area. TRILL will not attempt to solve this problem. Within the Level 1 area, a single border RBridge will be the DBRB, and will be in charge of deciding which (single) RBridge will transition any particular multi-destination frames between that area and Level 2. If the Level 2 area is partitioned, this will result in multi- destination frames only reaching the portion of the TRILL campus reachable through the partition attached to the RBridge that transitions that frame. It will not cause a loop. R. Perlman, et al [Page 15] INTERNET-DRAFT RBridges: Multilevel TRILL 4. Multi-Destination Scope There are at least two reasons it would be desirable to be able to mark a multi-destination frame with a scope that indicates this frame should not exit the area, as follows: 1. To address an issue in the border learning variant of the aggregated nickname alternative, when a unicast frame turns into a multi-destination frame when transitioning from Level 1 to Level 1, as discussed in Section 4.1. 2. To constrain the broadcast domain for certain discovery, directory, or service protocols as discussed in Section 4.2. Multi-destination frame distribution scope restriction could be done in a number of ways. For example, their could be a flag in the frame that means "for this area only". However, the technique that might require the least change to RBridge fast path logic would be to indicate this in the egress nickname that designates the distribution tree being used. There could be two general tree nicknames for each tree, one being for distribution restricted to the area and the other being for multi-area trees. Or, alternatively, there would be a set of N (perhaps 16) special currently reserved nicknames used to specify the N highest priority trees but with the variation that if the special nickname is used, the frame is not transitioned between areas. 4.1 Unicast to Multi-destination Conversions In the border learning variant of the aggregated nickname alternative, a unicast frame might be known at the Level 1 to Level 2 transition, be forwarded as a unicast frame to the least cost border RBridge advertising connectivity to the destination area, but turn out to have an unknown destination MAC/VLAN pair when it arrives at that border RBridge. In this case, the frame must be converted into a multi-destination frame and flooded in the destination area. However, if the border RBridge doing the conversion is not the border RBridge designated to transition the resulting multi-destination frame, there is the danger that the designated transitioner may pick up the frame and flood it back into Level 2 from which it may be flooded into multiple areas. This danger can be avoided by putting any multi-destination frame that results from such a conversion on a distribution tree that is restricted to the area. Alternatively, a multi-destination frame intended only for the area could be tunneled (within the area) to the RBridge Rx, that is the R. Perlman, et al [Page 16] INTERNET-DRAFT RBridges: Multilevel TRILL appointed transitioner for that form of frame (say, based on VLAN), with instructions that Rx only transmit the frame within the area, and Rx could initiate the multi-destination frame within the area. Since Rx introduced the frame, and is the only one allowed to transition that frame to Level 2, this would accomplish scoping of the frame to within the area. Since this case only occurs when unicast frames need to be turned into multi-destination as described above, the suboptimality of tunneling between the border RBridge that receives the unicast frame and the appointed level transitioner for that frame, would not be an issue. 4.2 Selective Broadcast Domain Reduction There are a number of service, discovery, and directory protocols that, for convenience, are accessed via multicast or broadcast frames. Examples are DHCP and the NetBIOS Service Location Protocol. Some such protocols provide some means to restrict distribution to an IP subnet or equivalent to reduce size of the broadcast domain they are using and then provide a proxy that can be placed in that subnet to use unicast to access a service elsewhere. In cases where a proxy mechanism is not currently defined, it may be possible to create one that references a central server or cache. With multilevel TRILL, it is possible to construct very large IP subnets which could become saturated with multi-destination traffic of this type unless frames can be further restricted in their distribution. Such restricted distribution can be accomplished for some protocols, say protocol P, as follows: - Either (1) at all ingress RBridges in an area place all protocol P multi-destination frames on a distribution tree restricted to the area or (2) at all border RBridges between that area and Level 2, detect protocol P multi-destination frames and do not transition them. - Place one (or more for back-up) protocol P proxies inside each area. These proxies can than unicast protocol P requests or other messages to the actual campus servers for P and receive responses or other messages from those servers and deliver them within the area via unicast, multicast, or broadcast as appropriate. Such proxies would not be needed if it was acceptable for all protocol P traffic to be restricted to an area. While it might seem logical to connect the campus servers to RBridges in Level 2, they could be placed within one or more areas so that, in some cases, those areas might not require a local proxy server. R. Perlman, et al [Page 17] INTERNET-DRAFT RBridges: Multilevel TRILL 5. Co-Existence with Old RBridges RBridges that are not multilevel aware may have a problem with calculating RPF check and filtering information, since they would not be aware of assignment of border RBridge transitioning. A possible solution, as long as any old RBridges exist within an area, is to have the border RBridges elect a single DBRB (Designated Border RBridge), and have all inter-area traffic go through the DBRB (unicast as well as multi-destination). If that DBRB goes down, a new one will be elected, but at any one time, all inter-area traffic (unicast as well as multi-destination) would go through that one DRBR. However this eliminates load splitting at level transition. R. Perlman, et al [Page 18] INTERNET-DRAFT RBridges: Multilevel TRILL 6. Summary This draft outlines the issues and possible approaches to multilevel TRILL. The alternative involving area nicknames for aggregation has significant advantages in terms of scalability over using campus wide unique nicknames; not just of avoiding nickname exhaustion, but allowing, for instance, RPF checks to be aggregated based on an entire area. Some issues are not difficult, such as dealing with partitioned areas. Some issues are more difficult, especially dealing with old RBridges. 7. Security Considerations TBD 8. IANA Considerations This document requires no IANA actions. RFC Editor: Please delete this section before publication. R. Perlman, et al [Page 19] INTERNET-DRAFT RBridges: Multilevel TRILL 9. References Normative and Informational references for this document are listed below. 9.1 Normative References [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor's queue. 9.2 Informative References None. R. Perlman, et al [Page 20] INTERNET-DRAFT RBridges: Multilevel TRILL Authors' Addresses Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Anoop Ghanwani Brocade Communications Systems 130 Holger Way San Jose, CA 95134 USA Phone: +1-408-333-7149 Email: anoop@brocade.com R. Perlman, et al [Page 21] INTERNET-DRAFT RBridges: Multilevel TRILL Copyright and IPR Provisions Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. R. Perlman, et al [Page 22]