Ecosystems cost of additional specs (RE: Please read - proposed WG termination)

It seems that the question of closure of the WG has elicited far more 
active discussion on the CM spec than the revised CM spec actually did :-)

But since this is far afield from the original subject, I've changed the 
subject line.

--On 1. september 2005 12:04 -0700 Michael Krause <[email protected]> wrote:

> In the end, IB HCA implementations can adopt the same techniques as
> Ethernet and deliver the same performance as a connected model without
> the overhead / complexity and ecosystem cost of a new specification.  IB
> already has enough problems getting the basics into the world today.
> Adding in yet another spec isn't going to solve these problems or make
> life easier - too many things within the ecosystem are impacted.

Actually the IETF has a fairly long and robust tradition of standardizing 
stuff that MAY be useful in a very limited context, and later turn out not 
to be terribly useful at all - for a list of some candidates for that 
honor, see draft-lear-newtrk-decruft-experiment-01.

The important questions to ask are, I think:

- What will be the cost of implementing be to willing participants who want 
to implement the extension?
- What will the cost of implementing be to participants who do not wish to 
implement the extension?

If the first one is "high", that may not be a show-stopper; people who want 
to try are welcome to, and they hurt nobody but themselves.

If the second one is "high", or there's a risk that it's high, we shold be 
VERY careful, and perhaps run official experiments before releasing it on 
the standards track - this is traditionally done, for instance, on 
extensions to TCP like ECN, or on extensions to routing protocols.

I can see the argument that for a particular implementation, the cost of 
implementing IPoIB-CM with a large MTU may be high - but since it seems a 
facility that's relatively easy to negotiate for, I don't quite see that it 
has a large ecosystem impact on IPoIB-UD implementations.
If it's a Bad Idea, it may get published, and wither away like so many 
other "proposed standards" that nobody cares about any more.

OTOH, if it's really a Good Idea, the choice is not really between a 
standard and no IPoIB-CM; it's between a standard and multiple, possibly 
incompatible IPoIB-CM variants. Nobody can prevent people from implementing 
from the current draft, assigning their own service-ID(?) and just shipping.

(Of course, there's the "markitecture" problem that some vendors will want 
to claim to have implemented "all relevant standards" - the problem that 
reportedly led some vendors to advertise support for "IP over avian 
carriers" at one point.... but that's a problem that the IETF can't solve, 
and probably shouldn't solve, I think.)

Thoughts?

                     Harald

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFDGAJWOMj+2+WY0F4RAvr3AKCEwRkhydAm+4+4wh0R/TsmchtKvACg73Cz
Tv/86c4RkOcndXo0bgBwoqA=
=UAnQ
-----END PGP SIGNATURE-----