IPv6 woes - RFC

Michael Thomas mike at mtcc.com
Tue Sep 14 20:51:10 UTC 2021


On 9/14/21 1:06 PM, Owen DeLong wrote:
>
>
>> On Sep 14, 2021, at 12:58 , Michael Thomas <mike at mtcc.com 
>> <mailto:mike at mtcc.com>> wrote:
>>
>>
>> On 9/14/21 5:37 AM, Eliot Lear wrote:
>>>
>>> 8+8 came *MUCH* later than that, and really wasn't ready for prime 
>>> time.  The reason we know that is that work was the basis of LISP 
>>> and ILNP.  Yes, standing on the shoulders of giants. And there 
>>> certainly were poor design decisions in IPv6, bundling IPsec being 
>>> one.  But the idea that operators were ignored?  Feh.
>>>
>> I wasn't there at actual meetings at the time but I find the notion 
>> that operators were ignored pretty preposterous too. There was a 
>> significant amount of bleed over between the two as I recall from 
>> going to Interop's. What incentive do vendors have to ignore their 
>> customers? Vendors have incentive to listen to customer requirements 
>> and abstract them to take into account things can't see on the 
>> outside, but to actually give the finger to them? And given how small 
>> the internet community was back while this was happening, I find it 
>> even more unlikely.
>>
>
> You’d be surprised… Vendors often get well down a path before exposing 
> enough information to the community to get the negative feedback their 
> solution so richly deserves. At that point, they have rather strong 
> incentives to push for the IETF adopting their solution over customer 
> objections because of entrenched code-base and a desire not to go back 
> and explain to management that the idea they’ve been working on for 
> the last 6 months is stillborn.
>
But we're talking almost 30 years ago when the internet was tiny. And 
it's not like operators were some fount of experience and wisdom back 
then: everybody was making it up along the way including operators which 
barely even existed back then. I mean, we're talking about the netcom 
days here. That's why this stinks of revisionist history to me.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210914/a0b04352/attachment.html>


More information about the NANOG mailing list