RE: Single vs many solution(s) (LONG reply)

>I don't think the IETF is making business decisions. Vendors are free to develop proprietary solutions and service providers are free to deploy them. However, a standards body should develop one solution as THE standard.
>
>...
>Peter

This is ignoring 17 years of IETF experience, and more than 20 years of 
standards experience. 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. 

I apologize that this message is quite long. However, to make a good
choice in this area it is important to understand a bit of history, and so
I have written down some historical examples below (there are more). 

For one example let's consider routing protocols. If we have tried back 
in 1986 (when the first four IETF's were held) to pick a single standard 
routing protocol then we would have picked RIP. This would have been 
over the strong objections of a few of us from BBN, but would have 
happened anyway because the great majority of implementers would 
have supported RIP for the simple reason that it is easy to implement. 
Also, it is possible to have lots of "fun" trying to come up with various 
ways to fix the very poor dynamic behavior of RIP in a large network. 
Thus means that at the time there were a number of researchers who 
has various fixes which they could have proposed to go along with RIP 
as THE standard routing protocol.

Fortunately, at the time we didn't think that it was necessary to pick
a single routing protocol. Instead we waited a few years, and then 
decided to do so. At the first meeting to do so, there was a great
debate between advocates of link state routing protocols (such as
OSPF, IS-IS, and the "New Arpanet Routing Algorithm" which was
deployed by BBN in the Arpanet in approximately 1979), versus 
advocates of distance vector routing algorithms (such as RIP, IGRP,
or the old Arpanet routing algorithm, used prior to 1979). This debate
sort of went on for a while, and didn't appear to be about to resolve. 

If we had had to pick one solution, it is entirely possible that we 
might have picked distance vector, which in retrospect would have
been a mistake. Instead Phill Gross (original chair of the IETF) 
allowed two working groups to be created -- one to define a link 
state routing protocol, and one to define a distance vector routing 
protocol.  This was very much consistent with Phill's general
approach of allowing more than one approach to be developed -- an
approach which was instrumental in resolving differences and which
was a BIG part of why the IETF became successful in the first place
(there were other much less successful task forces prior to creation 
of the IETF). 

So, eventually we *did* pick one interior routing protocol (for routing 
within a routing domain), which was OSPF. At the time there was 
some controversy between OSPF versus IS-IS as the proposed 
standard IETF routing protocol (both are link state protocols, and 
actually relatively similar in many ways). However, the politics were
pretty clearly slanted towards OSPF, so we managed to finally pick 
one protocol. Did this matter? If you look carefully you will notice 
that the result was that we now have **TWO** interior routing 
protocols deployed widely in the Internet. In fact IS-IS is used in 
very slightly more than 50% of the largest ISPs. Picking one
protocol didn't do us any good. 

Regarding inter-domain protocols, we had somewhat more difficulty
picking a single standard. There was some opposition to BGP in
high places. The result was that we were not able to pick a single
protocol until long after it was obvious to pretty much everyone that 
BGP was the right protocol to use. The failure to pick a single protocol
didn't do any harm in terms of stopping us from ending up with one
protocol.

The first time that I attended any standards meeting was an IEEE
802 meeting in 1980. I had been warned that standards meetings 
were quite boring. In fact nothing could have been further from the 
truth: This was *THE MEETING* at which IEEE 802 was going to 
decide between CSMA/CD versus Token Bus as *THE* standard 
for local area networks. There were large number of presentations 
on the subject all week, which was the cumulation of many months 
of similar debate. Finally at the end of the week the big vote took 
place. I don't remember the exact numbers, but it was something 
like 8 votes for one approach, 9 votes for the other approach, and 
30 abstentions. We all sat there and stared at each other for a 
minute or so ("It was finally over"). Then someone stuck up his 
hand and said essentially "We just picked the entire future for all 
local area networks for all time based on a vote of 8 to 9 with 30 
abstentions, this can't be right. Let's progress both standards". 
After a little more debate, the proposal to progress both standards 
was passed. 

Now, was this a failure on the part of IEEE 802? Would it have
been better if they had picked Token Bus for the future of LANs
rather than allowing both to progress? Would the credibility of the 
standards process and of IEEE 802 or the economic viability of 
the industry been improved if they had made this decision?

No, of course not. The economic and technical realities of the
market have been very good at picking Ethernet -- CSMA/CD. 
Making decisions like this is just something that a standards 
body is not capable of doing well. 

Ross