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

[Greg Daley]

Hi Erik,

Sorry about not knowing the right terms to use.

I'll try to adopt the ones you used.

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> Given that each trill network interfaces with a legacy 802.1 LAN,
>> some work to choose a good root for the 802.1D spanning-tree in each
>> LAN would be useful to reduce the aggregate traffic load on the network.
> 
> 
> Ah - sorry for the misunderstanding.
> Exactly what makes sense in this case has to do with both the details of 
> how rbridges interact with bridges, and what network topology gets 
> deployed.

Yes, definitely.

I'd be interested to see if the model is applicable though,
so that I can determine if I need to go off and do more analysis
of the potential benefits.

>> This doesn't require modification to the 802.1D mechanism, except
>> that devices which know they are closer to the ingress/egress of
>> the network can make their chances better.
>>
>> The original idea I had was before my rbridge awareness (notice that
>> the router R in the network wasn't considered).  Where trill routers
>> are present, they have direct knowledge that they are at the edge
>> of a LAN, and are potential ingress/egress points.
> 
> 
> Hmm - a term like "TRILL routers" might be a bit confusing.
> We need to be able to discuss networks which have
>  - L2 endpoints
>     IP hosts
>     IP routers
>  - Existing bridges
>  - TRILL devices (aka rbridges)
> 
> When I want to draw diagrams showing routers R1, R2, bridges (B1, B2, 
> ..), hosts (H1, H2, ..) I've found it useful to pick another letter for 
> the hybrid TRILL devices, so I've used "T".
> But a term like "trillers" for these devices is a bit odd. I guess we 
> could use Rbridges and name them RB1, RB2, etc.

OK, I'll put T, for Trill or Terminus Bridges... or something.

>> It's possible to use trill's routing protocol on the legacy LAN
>> to elect which of the trill routers will be the most preferred root
>> (rather than for exchange of link state).
> 
> 
> 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.
> 
> Do I understand your case correctly?

Yes.

> Note that RB1 and RB2 needs to elect one of them to be the forwarder 
> between the sub-topology and the rest of the LAN, to make sure that the 
> learning tables in the bridges don't flap from seeing packets from the 
> same source MAC address sometimes come from RB1 and other times from 
> RB2. The bridges will then forward packets based on the port they 
> learned the MAC address on, i.e. back towards the RB that forwarded 
> packets "in".
> 
> Depending on the bridge topology "below" RB1 and RB2, it might very well 
> make sense to have the RSTP root bridge be close to RB1/RB2.
> It might even make sense to have RB1/RB2 to act as a bridge on the lower 
> interface so that itself can become the root bridge.

This is what I was thinking was particularly applicable to Trill.

> But a lot of this depends on the topology and traffic patterns "below" 
> the RBs in the figure.

Indeed. That's the case.

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).

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

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.

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.

>> 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 didn't understand this part.

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 not sure if the RB as Root Bridge idea is always beneficial, but
would it be worth looking into?

Greg