[rbridge] Tie breaking in trees

[Anoop Ghanwani]

I think the more common case would be to run
LACP and establish a LAG (link agg group) so
that TRILL/IS-IS are only aware of a single link
between the two RBridges.

Today, for multicast with a single tree, we
pretty much have to have loop-free connectivity.
2 links between 2 Rbridges is effectively a loop.
STP would have broken that by blocking one of those.
Likewise, since we compute a tree for multicast, it
would make sense to only allow one of those.
If someone really wants to have the multiple links
active, then they can use link aggregation.

(I don't feel strongly about this one way or 
another, though.)

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> Sent: Monday, June 08, 2009 5:59 AM
> To: Dinesh G Dutt
> Cc: Donald Eastlake; TRILL/RBridge Working Group
> Subject: Re: [rbridge] Tie breaking in trees
> 
> Dinesh G Dutt writes:
> > It is not safe because IIC will have to be allowed on multiple 
> > interfaces. What you're suggesting is adding more complexity.
> 
> It's actually not hard to do in hardware.  All you need is a settable
> input interface identifier (on each physical interface) for the RPF
> check that defaults to the ID assigned to that interface.  Allow the
> routing protocol to set the ID to be the same on each link when
> parallel links are detected by Hellos.
> 
> Breaking multiple parallel links so that they don't work by default
> seems like a bad thing to me.  I'd rather have us just rely on
> implementors: if you can't get parallel link behavior right due to
> hardware limitations, then exercise some discretion in your
> implementation by shutting down extra links automatically, and
> notifying the administrator that you're unable to handle the requested
> configuration.
> 
> In fact, that should be true for all obscure implementation
> limitations, and we shouldn't have to write it into any specification.
> If you detect that you're in a sitation you can't support, then
> disable and/or shut yourself down in some suitable implementation-
> specific manner.  That's just "network equipment design 101."
> 
> Roping that area as off-bounds for all _other_ implementors who don't
> have the same problems seems a bit too limiting to me.
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>