[rbridge] Multicast root observation

Tue May 11 07:58:46 PDT 2010

Hi JR,

On Tue, May 4, 2010 at 12:47 PM, JR Rivers <jrrivers at cumulusnetworks.com>wrote:

>
> ...
>
> On Apr 20, 2010, at 12:58 PM, Donald Eastlake wrote:
>
> Hi JR,
>
> On Mon, Apr 19, 2010 at 3:06 PM, JR Rivers <jrrivers at cumulusnetworks.com>
> wrote:
>
>
> ...
>
>
> On Apr 18, 2010, at 8:27 AM, Donald Eastlake wrote:
>
>
> Hi JR,
>
>
> On Sat, Apr 17, 2010 at 3:21 PM, JR Rivers <jrrivers at cumulusnetworks.com>
> wrote:
>
>
> ...
>
>
> Well, that's a reasonable point of view. But since the RBridge
>
> specifying the list of tree roots is the same RBridge that is
>
> specifying the number of trees (although the number of trees can get
>
> reduced if there are RBridges in the campus unable to compute the
>
> requested number...), one wonders why it would specify more than the
>
> number of valid nicknames in the list it is providing.
>
> First, there is the case you've enumerated where another RBRIDGE in
>
> the network is not able to support the number of multicast roots in
>
> the list.
>
>
> The second case is one of simplicity.  From an administrative point
>
> of few, you'd like to specify the list of available roots and leave
>
> that list intact, regardless of whether these devices are alive or
>
> not.  You'd image the common scenario would have each of the desired
>
> roots advertising the same list.  Then RBRIDGES are able to
>
> calculate the appropriate trees... clearly, you can't calculate a
>
> tree to a root that is not in your LSP database.  The alternative is
>
> to have the list, as advertised by the highest priority RBRIDGE,
>
> shrink and grow each time one of the desired roots comes/goes.  That
>
> is a lot of fluctuation in a transitioning system.
>
>
> [It's not quite the "highest priority RBridge", although I have been
> using that phrase for simplicity. It's the RBridge that has the
> highest priority nickname, but this only makes a difference if there
> are RBridges with multiple nicknames. For simplicity, I'll continue to
> talk about the "highest priority RBridge".]
>
> I wasn't suggesting that the list should shrink/grow. In particular,
> why would you bother to shrink the list? There is nothing wrong with
> the highest priority RBridge making the list longer than the number of
> trees that RBridge is specifying as the number that should be
> calculated. Even if the highest priority RBridge is specifying that
> number of trees as exactly the list length, you might still have to
> calculate fewer than are in the list due to some RBridges not being
> capable of calculating all the trees. So RBridges have to be able to
> handle the case where the list is longer than the number of trees being
> computed. Presumably the network manager would normally configure the
> list of roots at all RBridge in the campus.
>
> I think the only question is what to do if the number of trees to
> calculate is larger than the length of the list. If there is a list of
> distribution tree roots, the network manager must have configured it
> and will presumably configure other aspects of the campus, including
> the priorities of all the nicknames. It seems to me that, to get the
> behavior you want, where no other roots beyond those listed are used,
> the network manager simply configures all the nicknames not on the
> list to have zero priority. That way they won't be used as a tree root
> (except as a last resort where it turns out to be the only tree)
> because zero priority is a special value indicating that you don't
> want to be a root. If the network manager configures them to have
> non-zero priorities, then non-listed nicknames can be selected, in
> priority rank, to fill in the number dictated by the highest priority
> RBridge, if the list is too short.
>
>
> This is the case that we're talking about.  To make sure we're on the same
> page, my concern with the current spec is the behavior when a list is
> specified and one or more of the list members are unreachable (links down,
> system down, etc).  The current spec indicates that any members in the list
> that are not in the LSP database should be ignored, and the list should be
> filled in by the selection process.  This seems a bit dangerous.  From your
> emails, it sounds like your preferred solution is to configure all other
> Rbridges with a root priority of 0 to avoid this situation.  Experience
> would suggest that this solution can lead to deployment errors.  I've seen
> that distributed protocols/fsms work much more predictably when you
> configure a small number of devices with the desired behavior as opposed to
> configuring a large number of devices to avoid an undesired behavior.
>

Well,  that's reasonable but it doesn't seem too bad to just configure all
the RBridges in the campus with the same list of roots and with priority
zero. (See also my response below...)

To this end, I would re-iterate my suggestion that the spec be modified so
> that when a list is specified, it is definitive and that ONLY Rbridges in
> the list can be selected as distribution tree roots.  This must be
> supplemented with a requirement that any Rbridge that advertises a list must
> be a member of that list (to avoid the no-distribution-tree scenario).
>

Saying that all RBridges that advertise a list of roots have to list
themselves doesn't make it so. Since you still have to handle the case where
this suggested requirement was ignored and you always have to have at least
one tree, I don't actually see much point to the requirement.

The provisions in the current TRILL Proposed Standard were arrived at by
discussions among something like half a dozen active TRILL participants and
there are implementations efforts underway, some of which are, I believe,
close to shipping. So, while I can see some merit to your arguments, unless
other people speak up in favor of your views, I don't think this should be
changed.

As an aside, the spec is a not perfectly clear how the root priority of 0 is
> treated in this situation.  The language from draft 16 is...
>
>    o  A nickname whose tree root priority is zero is never used as a
>       tree root except that if all nicknames have priority zero, the
>       highest priority among them as determined by the tiebreakers is
>       used as a tree root so that there is always guaranteed to be at
>       least one distribution tree.
>
> In the situation where you need to select more than one distribution tree
> root, this requirement can be interpreted in at least two ways...
>
> a) If you have at least one distribution tree root, you must ignore all
> Rbridges with a root priority of 0 during further distribution tree
> selection
>
> b) When you need to select a root, don't use Rbridges with root priority 0
> unless all remaining, unselected Rbridges have root priority 0
>
> Your paragraph above suggests that a) is the correct behavior, so I'd
> recommend that the text be modified to make it extremely clear.
>

You are completely correct that this is not clear. I believe that text
should have started "A nickname whose tree root priority is zero is not
selected as a tree root based on priority, except that if all nicknames have
priority zero, ..." In other words, the list of roots dominates priority,
including priority zero.

Initially, the draft only had priority in it. When the list of roots was
added, I think this text wasn't adjusted.

> It seems clear enough what should happen if the number of trees to
>
> compute specified by the highest priority RBridge [actually
>
> nickanme] is the same or less than the number of valid nicknames it
>
> lists. But consider the corner case when the list has no nicknames
>
> on it that actually exist in the campus. (Perhaps the list is
>
> fairly short and the campus has just partitioned or something...)
>
> In that case, all RBridges have to calculate at least one tree or
>
> the network will not be fully functional.
>
>
> If I understand your scenario correctly, then each RBRIDGE has one
>
> of two views of the world.  In the first, it receives the list from
>
> the highest priority RBRIDGE (I'm assuming that the highest priority
>
> RBRIDGE is a member of the list).  In this case, the RBRIDGE has at
>
> least one multicast root.  In the second case, the RBRIDGE does NOT
>
> receive the list, in this case, it would select the highest priority
>
> RBRIDGE that is sees as the multicast root.
>
>
> There is no requirement that the highest priority nickname be on the
> list of distribution trees the RBridge with that nickname
> advertises. Every RBridge logically advertises a list of tree root
> nicknames, although it might be the null list. Since they are part of
> the link state database, every RBridge in the campus has a copy of the
> list advertised by every RBridge in the campus. Under the procedures
> given, in a quiescent network, they will all calculate the same trees.
>
> Since, in that case, you have to calculate a tree not on
>
> the list, the highest priority such tree, it seems to me that it is
>
> slightly more consistent to calculate additional higher priority trees
>
> if the list is shorter that the number of trees being dictated by the
>
> highest priority RBridge...
>
>
> JR
>
>
> Thanks,
> Donald
>
> PS: By the way, an actual implemention might want to keep around the
> forwarding entries for a tree that it is no longer computing for a
> little while to handle frames still in flight in the campus.
>
> Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street   +1-508-634-2066 (home)
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20100511/287f47ad/attachment-0001.html