RE: Single vs many solution(s)

Yakov

I think the phrase "Vendors, being interested in making money" from the
message below sums it up nicely;-)

Perhaps standardisation and interoperability may only be "marginally
important" to some large vendors that have the luxury of a large installed
customer base, or to some providers where a non-standard feature is the only
fix to a unique requirement.

However, I would suggest that for large operators looking at the
*possibility* of using MPLS as their next co pkt-sw core, standardisation
and interoperability would be extremely important. The L2 MPLS VPN solutions
are not just quick 'value add features' (which I think some people seem to
perceive them to be, due to the fact that they can be deployed using
existing networks and protocols with minimal changes).

L2 MPLS VPNs offer operators the *potential* to migrate existing co pkt-sw
services (i.e. ATM, Frame Relay) onto a single platform that one might
expect to be around for another 20 years or so to justify its investment. I
would suggest that proper standardisation (especially at the architectural
level) is a prerequisite for protecting this investment.

Richard

 > -----Original Message-----
 > From: Yakov Rekhter [mailto:[email protected]]
 > Sent: 27 May 2003 15:34
 > To: [email protected]; [email protected]
 > Subject: Re: Single vs many solution(s) 
 > 
 > 
 > Folks,
 > 
 > I think that the following message is quite relevant to the 
 > discussion.
 > 
 > Yakov.
 > -----------------------------------------------------------------
 > Date:    Fri, 23 May 2003 10:04:39 EDT
 > To:      [email protected]
 > From:    Frank Kastenholz <[email protected]>
 > Subject: The One True Path To Nirvana
 > 
 > Folks,
 > I hate to inject a bit of reality into this but
 > whether the IETF decides to bless one-and-only-one
 > way to do FOO with the high-honor of "Standards Track
 > RFC" or allows multiple ways is only marginally
 > important.
 > 
 > Vendors, being interested in making money, try to
 > differentiate their products. The Offical IETF
 > Mantra in this regard is that vendor differentiation
 > arises out of things like quality. While true, it is not
 > the complete truth. Vendors will also have with their
 > own protocols as alternative ways to do FOO. The vendor's
 > marketing people will then tout their proprietary FOO
 > Protocol as "better" than the standard in various ways.
 > The proprietary FOO Protocol might even be what the 
 > vendor tried to get made a standard but failed (and
 > now there might be an installed base...)
 > 
 > Second, customers (bless their checkbooks and capex budgets)
 > sometimes what something that's not the standard. It could
 > have been something that was a candidate for standardizing
 > but didn't make it. It could be something that the customer
 > came up with. It could be some set of requirements that
 > the customer has (or thinks they have) that are not met
 > with the standard, requiring some non-standard-FOO.
 > 
 > Having multiple levels of standard really doesn't have
 > any effect on what vendors do or what customers want.
 > If the deltas from one level to the next are "just
 > bugfixes" then that's how they are treated by vendors.
 > If there are substantive changes in function (function-x
 > is available in proposed std, but not in draft, or vice
 > versa) then the implementation becomes the union of all
 > standard-levels, with config switches and the like. In other
 > words, the propose/draft/full hierarchy is little more than
 > feel-good self-gratification on the part of The Process Experts.
 > 
 > Btw, before I get roasted for heresy
 > a) There are always exceptions where things happen
 >    differently. When the right things happen, it's
 >    like winning the lottery. Enjoy it, but don't count
 >    on it
 > b) This is not a state of affairs that I find particularly
 >    desireable.  It is a state of affairs that does exist,
 >    however, and pretending that it does not exist is foolish.
 > 
 > So, the short answer is that multiple-competing-FOOs is
 > a fact of life. We live with it. We deal with it. Whatever
 > the IETF does, it will not go away. 
 > 
 > That said, what the IETF _can_ do is to make the problem
 > easier to deal with by
 > - getting the technical quality of things as high as we
 >   can as early as we can. That means -00 of the draft,
 >   if possible (yes, I know it won't happen, but the sooner,
 >   the better)
 > - getting drafts and changes and RFCs through the system
 >   faster (without sacrificing quality).
 > Ideally, -00 of the ID comes out 1 week after the first BOF
 > and there are no changes made to it, ever.
 > 
 > 
 > 
 > Frank Kastenholz
 > 
 > This is all my personal opinion and does not have anything to do
 > with what my employer says, thinks, does, etc.
 > 
 >