[rbridge] Tie breaking in trees

[Radia Perlman]

(I just reread the spec, which is why I have these last few questions).


There's a section in the spec that is about tie-breaking, which has to 
be somewhat
revised since it conflicts somewhat with a recent feature we put in, 
which is
to allow path splitting multicast rooted at the same root. The paragraph in
the spec that I think needs to change is as follows:

"  If there are two or more equal lowest cost adjacencies between two
  RBridges, then between adjacencies established by P2P Hellos and
  adjacencies established by TRILL-Hellos, the P2P adjacencies are
  preferred; between TRILL-Hello links, the adjacency with the lowest
  Designated IS LAN ID (pseudonode) is preferred; and between P2P
  links, the adjacency with the lowest Extended Circuit ID is
  preferred. Such tie breaking only affects the two RBridges connected
  by such equal cost adjacencies. The tie breaking determines which of
  the tied links to send multi-destination traffic on and on which of
  them to permit receipt of such TRILL frames.
"

First, to review tree-building, especially now that we've added the feature
of multiple trees from the same root (using different nicknames).

To build a tree from a particular nickname, all RBridges need to
build the same tree. The tree will be a shortest-path tree from the
root, using different tie-breakers for equal cost links based on "tree 
number",
so that multiple trees from the same root will choose different links.

The tie-breaker is based on the 7-byte ID of the parent. That means that
there is no tie-breaker for links that have no pseudonode. No-pseudonode
links include
pt-to-pt links and pseudonode-suppressed LAN links. The spec currently
treats all those links between R1 and R2 as a single link from the
point of view of RBridges other than R1 and R2.

I believe that for "real" pt-to-pt links, there is no reason to do a 
specified tie-breaker.
For traffic being forwarded from R1 to R2, it seems as though R1 should be
able to send on any of the links, just like it would for unicast. But I 
think
there was some controversy over doing that, so the wording I will suggest
below is selecting a single link for all multicast that selects that 
pair of RBridges.

I'd suggest the following wording instead for the paragraph at the
top of the note, which
would be discussing a packet arriving from neighbor R2, on a tree, say 
T, for which
the non-pseudonode link to R1 is in that tree, and the ingress RBridge, 
say Ri, passes
the RPF check for tree T on link (R1-R2). This is only relevant to
the endnodes of the R1-R2 link.

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

**********
An alternative would be to replace a) with:

a) most preferred are those established by P2P Hellos. If there
are one or more of those, R1 is allowed to transmit on any of those,
and R2 is required to accept from any of those.