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

[Erik Nordmark]

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.


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

> 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?

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.
But a lot of this depends on the topology and traffic patterns "below" 
the RBs in the figure.

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

    Erik