Re: Single vs many solution(s)

Alex,

> Summarizing a bit:
> 
> Monday, May 12, 2003, 8:36:43 AM, Yakov Rekhter wrote:
> > To avoid disappointing you the WG immediately needs to start the
> > discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS
> > over GRE, or MPLS over IPSec.
> 
> > Likewise the WG immediately needs to start the discussion on L2TPv3
> > vs LDP based signaling.
> 
> > Likewise, the WG immediately needs to start the discussion on BGP
> > vs Radius based auto-discovery.
> 
> If the goal of the WG is to produce the IETF Standards for L2 VPNs, I
> think the WG should indeed be discussing which mechanisms should be
> chosen as mandatory to implement. Not requiring a mandatory one will
> affect interoperability, and more than one mandatory mechanism per
> function are just not needed--one is enough. If folks believe other
> (optional to implement) mechanisms would really add value, I don't
> think anyone would object. The key point here is if we want
> implementations of the IETF standard to interoperate, we need to
> define the minimal function set to be supported.
> 
> Monday, May 12, 2003, 10:08:22 AM, Yakov Rekhter wrote:
> > Agreed. In fact, I don't quite understand why some folks on this
> > list insist that the IETF should be in the business of making
> > business decisions...
> 
> I don't think anyone is trying to insist on that, quite on the
> contrary. I think there's a general agreement that the IETF should NOT
> be making business decisions, and the disagreement is in which
> decisions are business and which are technical.
> 
> If we come here believing that the IETF is nothing but a market
> battlefield, then we can call any situation where more than one
> existing implementation is available a "business issue", and agree
> that trying to resolve it would cost too much blood, so "the market"
> should pick the one that they like more.
> 
> If instead we believe that the IETF is an engineering organization,
> where we come to work together on something we can later use to
> interoperate in SP networks (even though we may have our own existing
> implementations), I think we should be ready to sit down, talk to each
> other and try to build consensus on what should that IETF Standard be.
> 
> Which mindset do we choose?

The one that reflects reality, and not the one that reflects wishful
thinking. With this in mind the following from Ross' e-mail answers
your question.

   The reality is that neither the IETF nor any other 
   standards body is good at choosing between major approaches. When 
   we have tried to do this (or when any other standards group has tried
   this) we have failed more often than succeeded. Where we have let more
   than one major approach be progressed, we have succeeded most of the
   time (although usually most of the approaches eventually go away). 
   
   Standards groups such as the IETF are very good at taking any one well 
   defined solution and working out all of the details. If there are two main
   approaches, then we are very good at having two groups of people 
   progress the two approaches. This allows vendors to build interoperable 
   solutions. This is essential for data communications networks to 
   progress and to work well. Where there have been more than one
   approach progressed, the competition between approaches have made
   the proponents of each approach improve their approach as much as
   possible and has given us better standards. 
   
   If we look at some examples from history, there is a very clear trend 
   that progressing two or slightly more approaches works out okay. Bad 
   approaches go away because they don't work well when deployed (for 
   example, scaling might be difficult, or stability might be lacking). 
   Trying to pick one winner in a heavily politicized large group just
   doesn't work. Committees aren't very good at figuring out where there 
   are going to be problems. 

Yakov.