[rbridge] Ingress Rbridge and FTAG again

[Dinesh G Dutt]

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.

Dinesh

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