[rbridge] Existing issues in root bridge selection for LANs.

[Erik Nordmark]

Greg Daley wrote:


>> If you are assuming that the RSTP protocol terminates at the rbridges, 
>> then you end up with a sub-topology of the LAN with e.g.
>>
>>     <rest of LAN up here>
>>      |                |
>>     RB1              RB2
>>      |                |
>>      -------------------
>>      |    |      |
>>     H1    H2     R1
>>
>> Where the line is the middle is made up of bridges.
>> Thus the issue is where RSTP places the root bridge in this 
>> sub-topology of the whole LAN.


> My guess (still not checked generally) is that if more traffic is
> flowing into and out of one RBridge, then it will be the best place
> to have a root (for scalability and traffic dimensioning purposes).

That's probably the case.

> Your diagram is a useful one, since it illustrates non-Trill capable
> routers in the network.

Yes, but my figure, repeated below, might not be that representative for 
a real network:
 >>     <rest of LAN up here>
 >>      |                |
 >>     RB1              RB2
 >>      |                |
 >>      -------------------
 >>      |    |      |
 >>     H1    H2     R1

I real enterprise LAN of reasonable size is probably going to have some 
edge switches connecting to hosts, and a layer of distribution switches, 
which connect to the routers. So a more natural picture would be with 
the routers on "top", perhaps connected to the RBs without any 
intervening bridges:

       R1        R2
        |         |
       RB3       RB4
        | \     /  |
        |  \   /   |
      <rest of LAN up here, with additional "leafs" like the one below
      attached to it>
       |                |
      RB1              RB2
       |                |
       -------------------
       |    |
      H1    H2

> In those situations the Internet Router is likely to be the best
> root bridge of all, and its adjacent bridge is likely to not be a Trill
> device, and is not likely to be able to automatically configure.

But if the toplogy is more like the picture above, then there is no 
issue with a 802.1D spanning tree between R1 and RB3 etc.
You'd still have a bridge spanning tree for the ("----") bridged 
sub-topology at the bottom, but for that one getting the root close/at 
the RB is good enough.

> Here it's likely that the root bridge will have to be selected manually,
> although there may be a case for automatic root bridge selection on
> one of the Trill devices, over default preference devices if it is
> likely to be a big traffic generator.

There is still the option to do manual things, but it is worth while to 
think of what LAN topologies look like today, and whether TRILL can 
automatically come up with a reasonable thing for such topologies.
The topology between the RBridges is already handled by using the 
link-state routing protocol, and your suggestion to handle the "leaf" 
bridged sub-topologies by placing their root bridge at/close to the RB 
is a good one.

>>> Alternatively, if no routing protocol is explicitly used on the legacy
>>> LAN, routers within the trill cloud which know they are attached to the
>>> same legacy LAN can determine from their trill routing knowledge which
>>> is the best root.
> 
> I was thinking that if the trill devices are connected to the same trill
> cloud ("above" the RBs in the diagram), they could do the root
> preference election on the "above" side, based on link-state
> knowledge from the "below" LAN.
> 
> This was basically an off-the-cuff idea though.  It's probably better to
> run the lot on the "below" side to handle disjoint Trill domains
> connecting to the same legacy LAN.

I'm still failing to draw the topology from your description. Sorry.
(Perhaps you can glue me in off-line.)

> I'm not sure if the RB as Root Bridge idea is always beneficial, but
> would it be worth looking into?

I think so.
I think we also need to figure out how to get smooth failover when RB1 
fails and we want the designed bridge for the sub-topology to become 
RB2, and have the bridges quickly discard their learned information 
which points at the dead RB1.
Having the designated RB look like the root bridge to the rest of the 
bridges (or look like the shortest cost to the root bridge) is one way 
to make the failover smooth for the bridges.
But there might be other ways to accomplish this.

    Erik