Subject: [rbridge] We have a WG

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 27 Jun 2005 02:10:32 -0700

The IESG approved the TRILL WG last Thursday.
Now we need to put together an agenda for Paris and start working on the 
charter items.

I'll send out more details later,
    Erik

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 27 Jun 2005 15:54:48 -0700

It would be nice to get opinions on remaining issues, and I think each
issue should be in a different email thread, so I'm starting one.

How many spanning
trees should RBridges compute? Given the link state database, they can 
calculate
as many as we want without further protocol messages. The possibilities are:

a) one spanning tree: This is simplest, obviously.

b) one per VLAN: How it would work:
each RBridge announces, in its link state info, which VLANs that
RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
RBridges
(all of them...not just those attached to VLAN A) choose the RBridge, 
RA, that
has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
calculated
with RA as root. THat spanning tree is pruned so that only branches that 
reach
other VLAN A links survive.

Why bother: If only a few links are VLAN A, then this allows more 
optimal delivery
of multicast/unknown frames within the VLAN A broadcast domain.

c) one per RBridge

Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
allows
optimal delivery from source to the receivers of a particular multicast.

Another reason is that it minimizes out of order delivery of packets in the
case when S it talking to D, and initially D is unknown by the RBridges 
and packets
have to be sent over a spanning tree rather than on the shortest path 
from S to D.

********
I personally don't have strong opinions on this. If only a miniscule 
amount of
the traffic is multicast/unknown, then one spanning tree seems good 
enough. If
there's high volume IP-derived multicast applications, then perhaps one per
RBridge would be worth it.

So I guess I'd be inclined to either just have one spanning tree, or one per
ingress RBridge.

And if we did one per ingress RBridge, would it be worth computing all 
those trees
in advance just in case, or only computing one when necessary?

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 28 Jun 2005 17:54:24 +0200

Guillermo Ib??ez wrote:
This is my feedback on the "how many spanning trees" issue.

>a) one spanning tree: This is simplest, obviously. 
The poor performance in the core for multicast is an important argument 
against it. Other possibilities should exist, at least as an option.

>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that

It seems that with this implementation  compatibility (interoperability) 
with bridges running Multiple Spanning Tree Protocol (MSTP) is 
excluded.  If bridges running MSTP exist  in the campus network, they 
must be confined in one or several MST regions with their specific 
VLAN-to-spanning tree instance mappings and,  like happens with STP or 
RSTP, the trees will end at the region boundary with an rbridge. This 
means that there could coexist "regions" running MSTP with their own 
VLANs and multiple spanning trees inside the region, these regions 
inserted between rbridges that use another type (range or IDs) of VLANs. 
My understanding is then that the only VLANs capable of traversing the 
campus end-to-end would be the VLANs handled by Rbridges, as the other 
would be stopped by Rbridges if they are not known by them. 

c) one per RBridge

>have to be sent over a spanning tree rather than on the shortest path 
One tree per bridge is very efficient together with IGMP snooping, 
assuming a core of rbridges. The plus point is that in this case the 
multiple trees can also perform routing of unicast traffic, if used 
together with the MAC address learning mechanism. In other words: 
assuming a core formed by rbridges,  using an spaning tree per rbridge 
may be enough to perform all the routing via minimum paths. This 
requires that the  address learning mechanism works over the trees (the 
trees coincide in opposite directions A to B and B to A, a tricky issue 
when path costs can be equal).  So it seems that there is some 
overlapping or overkillling using multiple spanning trees for 
broadcast/multicast and Dijkstra routing for unicast and simplifications 
are  possible.

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 28 Jun 2005 09:43:55 -0700

You are right that paths will not be the same from A to B as from B to A 
with an A-rooted tree (towards B)
vs a B-rooted tree (towards A), at least if we do a straightforward 
calculation of spanning trees. I think trying
to accomplish symmetric routes might
require source/destination pair route computation. So hopefully we won't 
require symmetric routes.

Radia