Subject: [rbridge] Tie breaking in trees

From: Radia Perlman <[email-masked]>
Date: Thu, 04 Jun 2009 17:47:48 -0700

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

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 5 Jun 2009 17:53:24 -0400

On Thu, Jun 4, 2009 at 8:47 PM, Radia Perlman<[email-masked]> wrote:
> ...

I prefer this alternative. It is safe to multipath multi-destination
frames across parallel one-hop links that are configured to be P2P. So
I see no reason to add complexity at the receiver by requiring to it
reject such frames on all but one of such P2P links.

Thanks,
Donald

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 07 Jun 2009 16:41:50 -0700

Strongly disagree. See my earlier response to Radia's original email,

Dinesh
> reject such frames on all but one of such P2P links.
It is not safe because IIC will have to be allowed on multiple 
interfaces. What you're suggesting is adding more complexity.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 07 Jun 2009 16:38:55 -0700

Radia,

> links, the one with the numerically largest pseudonode ID is preferred".
I want this i.e. (a) followed by (b). The alternative that you suggest 
below for (a) will make IIC inordinately expensive to implement in 
hardware. The alteranate check will have to allow frames for not only 
the adjacent Rbridge but all other Rbridges that are upstream from 
multiple interfaces. I strongly disagree with the alternate text below,

Dinesh

---

From: Dinesh G Dutt <[email-masked]>
Date: Sun, 07 Jun 2009 19:00:57 -0700

I used what may have been a unknown terminology. IIC means incoming 
interface check, what is referred to in the spec as RPF check. So, 
please replace IIC in my previous emails with RPF check. Apologize for 
the confusion,

Dinesh

---

From: James Carlson <[email-masked]>
Date: Mon, 8 Jun 2009 08:59:27 -0400

> 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              <[email-masked]>
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
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 10 Jun 2009 14:24:16 -0700

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: [email-masked] 
> [mailto:[email-masked]] 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:

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Jun 2009 08:30:45 -0400

> would make sense to only allow one of those.

Yep; that's what has to happen.

> active, then they can use link aggregation.

The only significant problem with that assertion is that it assumes
that the links are of a sort that can be aggregated.  I know that the
initial deployments (ours included) will all be TRILL-over-Ethernet,
but I do think it's a bad idea to assume that this will _always_ be
true.  Protocols (good ones at least) tend to have long lives, and
need to adapt.

(A minor problem is that handling aggregation by LACP is a pain.  It
requires manual configuration and maintenance.  If we detect and
handle aggregates appropriately in TRILL, then that's one more selling
point for RBridges over regular bridges: you just wire them up, and
they work.  No questions asked.)

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 12 Jun 2009 00:23:35 -0400

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
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Sun, 14 Jun 2009 13:05:56 -0700

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:

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.