Subject: [rbridge] Ingress Rbridge and FTAG again

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 23 Oct 2006 14:18:44 -0400

Dinesh,

	Let me expand on what Joe said.

	There is a current proposal on the table, actually fairly
far along in development.  Because this exists, you and Silvano 
are obliged to show cause as to why this current proposal is not
sufficient to solve the problems we've decided to address - as a
working group, and as documented in the WG charter.

	This is not what you have done.  Instead, you suggest that
the solution you offer is better, because it also solves another 
set of problems.  This other set of problems is not currently in
the charter, hence the fact that your solution might be a better
answer from the perspective of solving these other problems is
not relevant, and the argument based on these other problems is
not sufficient to justify discarding what has been the consensus
solution to date.

	If we were to discard each solution as it comes to a point
of some level of maturity in favor of a solution that also might
address new problems, we will get nothing done.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
--> Sent: Monday, October 23, 2006 1:55 PM
--> To: Joe Touch
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 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
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->