[rbridge] Ingress Rbridge and FTAG again
Dinesh G Dutt
ddutt at cisco.com
Mon Oct 23 10:54:34 PDT 2006
Good Morning Joe,
Joe Touch wrote:
> Anything not stated explicitly in the charter is out-of-scope, UNLESS it
> is needed to support something in the charter indirectly. This isn't a
> matter of "permitted unless prohibited" - the point of the charter is to
> constrain the scope. It's also not a matter of "once you open the spec,
> anything is on the table"; that's not how charters work.
I read the latest version of the P&AS at
http://www.isi.edu/touch/pubs/draft-ietf-trill-prob-01.txt. I fail to
see anything that precludes adding a source RBridge in the packet frame.
I also do not see anything that prevents using multiple shared trees to
address the case of maximal link utilization for multicast. Since
maximal link utilization is a part of the P&AS and the current solution
of using source-Rbridge-based trees is not as efficient as multiple
shared trees, FTAG addresses this requirement directly. Sure, you can
attempt to alleviate the current situation by trying to build multple
source-Rbridge-based trees, but FTAG provides a mechanism to do it
better and also enables a host of other functionalities, that do not
have to be called out in the charter.
In short, I'm unable to see how the addition of the two fields that
Silvano & I are proposing requires a revisit or update of the charter.
Since we're trying to address real-life problems (which includes
troubleshooting), I continue to perceive a lack of technical merit in
the arguments against addition of the two fields. I also continue to
want to hear other voices in favor of or against the proposal and the
reasons for their positions.
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge