[rbridge] Multicast root observation
jrrivers at cumulusnetworks.com
Tue May 4 09:47:03 PDT 2010
Sorry it took so long to get back... thoughts in line.
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.
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).
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.
>>> 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...
> 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.
> 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...
More information about the rbridge