Subject: [rbridge] Ingress Rbridge and FTAG again

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 23 Oct 2006 17:02:40 -0400

Radia,

	I agree, and these questions are essentially a re-statement
of the question: 

"Do we want to add the requirements implied in this work to the
 TRILL WG charter?"

	If we do, then we open the floor to other proposals for how
to solve those additional problems.  This is - I believe - the 
main reason why none (or at least very few) of the comments made
so far have been along the lines of "how good is this particular
proposal at meeting these additional requirements."

	There have been off-line discussions along those lines, and
- until we decide that this new set of problems is something we do
want to solve, in this version of TRILL - then off-line is where 
any such discussion belongs.

	As a participant in the process, what I see is that someone
can waltz in from the side-line with an alternative proposal and
try to stretch the problem we're trying to solve to fit their own
particular solution.  That is usually not allowed in the IETF.

	If there is a genuine need to deal with the other problems 
that are now being raised, then - as you say - we need to decide
that.

	And then we can start to design solutions to a new problem
statement, which will then include these new problems.

--
Eric

--> -----Original Message-----
--> From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] 
--> Sent: Monday, October 23, 2006 4:17 PM
--> To: Gray, Eric
--> Cc: Dinesh G Dutt; Joe Touch; rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 
--> > 
--> > 	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
--> > 
--> 
--> With the caveat that I have not been following the 
--> discussion (I'm still travelling with limited opportunity 
--> for email),
--> although Eric's statement is true---that constantly 
--> changing for something slightly better means things never 
--> converge---I
--> don't think the layout of the shim header is that big a 
--> change. So if changing it means that TRILL will be
--> suitable for more things, or more likely to be adopted, 
--> then it seems prudent---but it should be decided very quickly.
--> 
--> For each of the proposed fields, how valuable is each one? 
--> Are there places that will adopt TRILL with those, and
--> would not without them? Are there places that would adopt 
--> TRILL with the MPLS-like header, but wouldn't without it?
--> 
--> Radia
-->