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

 


 From: Harald Tveit Alvestrand [ mailto:[email protected]
<mailto:[email protected]> ]
 Sent: Friday, September 02, 2005 10:42 AM


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.

[dg] I think that the cost is not that high. We're looking at implementing
it. The two major issues are the ones that people already identified: the
per neighbor MTU and the supporting the large frame buffers that are larger
than a 4KB page. Both are OS specific issues (we're specifically looking at
Linux). The large frame buffer, is a problem that exists today even for
Ethernet jumbograms.



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.

[dg] There isn't any cost to people that don't want to implement it.
ipoib-ud and ipoib-cm are supposed to fully interoperate. They will
obviously downgrade to ipoib-ud. So, if one doesn't want to implement  it,
fine, nothing really happens, ipoib-ud will always work.



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.

[dg] Standards are always better than interoperability issues. And, most of
the ipoib-cm is done so far, so I really see value in completing the
standardization work. There is a really good chance that many systems can
benefit from it.

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