[rbridge] Tie breaking in trees

[Radia Perlman]

So it seems to me that there is some discomfort in requiring accepting 
on multiple links, but as Anoop and
Donald pointed out, this feature could be implemented outside of the spec by

a) doing pairwise negotation for link aggregation, or
b) negotiating the option of load splitting multicast on multiple 
pt-to-pt links with
the neighbor, since it doesn't affect any RBridges other than the pair 
attached to
the multiple pt-to-pt links.

So, it seems like the wording I suggested in the original post on this 
thread would be acceptable, since
I don't think the wording precludes either of the above ways of doing 
multicast load splitting.

So to review, the
wording I'd suggest for replacing that one paragraph is:

"If the tree-building and tie-breaking for a particular tree selects a
non-pseudonode link between R1 and R2, that "R1-R2" link
might consist of multiple links. These parallel links would be
visible to R1 and R2, but not to the rest of the campus (because
the links are not represented by pseudonodes). If this bundle of
parallel links is included in a tree, it is important for R1 and R2
to decide which link to use, but is irrelevant to other RBridges,
and therefore, the tie-breaking algorithm need not be visible
to any RBridges other than R1 and R2. In this case,
R1-R2 adjacencies are ordered as follows, with the
one "most preferred" adjacency being the one that R1 transmits
to R2 on, and the one that R2 accepts traffic from R1 on:

a) most preferred are those established by P2P Hellos,
with tie-breaking among those based on preferring the
one with the numerically highest Extended Circuit ID.

b) next considered are those established through TRILL-Hellos,
with suppressed pseudonodes. Note that the pseudonode is
suppressed in LSPs, but still appears in the TRILL-Hello,
and therefore is available for this tie-breaking. Among these
links, the one with the numerically largest pseudonode ID is preferred".





Donald Eastlake wrote:
> It seems to me that supporting the ability to accept multi-destination
> frames on more than one parallel link, under conditions when this is
> safe (basically that the links are point-to-point), can be an option.
> RBridges would have to support transmission and reception on the one
> link the tie-breaking criterion choose. So it would always be safe to
> send on that one link. If an RBridge supports reception on all the
> parallel links for which it is safe, this can be announced as a
> supported option (an option that would not have to be expressed in the
> frames that might be multi-pathed over those links).
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>