Subject: [rbridge] Multicast root observation

From: JR Rivers <[email-masked]>
Date: Sat, 17 Apr 2010 12:21:54 -0700

All-

I've been reading through the TRILL spec(draft-ietf-trill-rbridge-protocol-16.txt), and I've come across a
mechanism that seems like it might cause operational confusion (or perhaps even errant behavior).

Specifically, in section 4.5 (page 54), there is a paragraph which I've copied below.

  In addition, the RBridge RB1 having the highest root priority
  nickname might explicitly advertise a set of s trees by providing a
  list of s nicknames. In that case, the first k of those s trees will
  be computed. If s is less than k, or if any of the s nicknames
  associated with the trees RB1 is advertising does not exist within
  the LSP database, then the RBridges still compute k trees, but the
  remaining trees they select are the highest priority trees, such that
  k trees are computed.

If a network administrator has decided to enact the "distribution tree root advertisement" mechanism (which is reasonable in structured networks), then it seems that the absence of a specified nickname in the LSP database should NOT allow an RBRIDGE that is not in this list to be used as a root.

More formally, it seems that this list should be the complete set of allowed distribution tree roots.  In this case, k should be the smaller
of... 
a) the number of list nicknames in the LSP database
b) the smallest "max trees" advertised any RBRIDGE in the TRILL network

JR

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

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 18 Apr 2010 11:27:32 -0400

Hi JR,

On Sat, Apr 17, 2010 at 3:21 PM, JR Rivers <[email-masked]> wrote:
>
> All-
>
> I've been reading through the TRILL
> spec(draft-ietf-trill-rbridge-protocol-16.txt), and I've come across a
> If a network administrator has decided to enact the "distribution tree
> root advertisement" mechanism (which is reasonable in structured networks),
> then it seems that the absence of a specified nickname in the LSP database
> should NOT allow an RBRIDGE that is not in this list to be used as a root.
> More formally, it seems that this list should be the complete set of allowed
> distribution tree roots.  In this case, k should be the smaller
> of...

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.

It seems clear enough what should happen if the number of trees to
compute specified by the highest priority RBridge 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. 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
=============================
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: JR Rivers <[email-masked]>
Date: Mon, 19 Apr 2010 12:06:40 -0700

Donald-

Thanks for your comments.  I've embedded my thoughts into yours below.

Cheers,

JR

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

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

> Since, in that case, you have to calculate a tree not on

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 20 Apr 2010 15:58:04 -0400

Hi JR,

On Mon, Apr 19, 2010 at 3:06 PM, JR Rivers <[email-masked]> wrote:
> ...
>>> ...

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

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

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.

=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street   +1-508-634-2066 (home)
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge