Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Michael Thomas <mike () mtcc com>]

On 11/19/21 7:38 AM, Owen DeLong via NANOG wrote:
> Actually, CIDR didn’t require upgrading every end-node, just some of them.
>
> That’s what made it doable… Updating only routers, not end-nodes.
>
> Another thing that made it doable is that there were a LOT fewer end-nodes
> and a much smaller vendor space when it came to the source of routers
> that needed to be updated.
>
> Further, in the CIDR deployment days, routers were almost entirely still
> CPU-switched rather than ASIC or even line-card switched. Heck, the
> workhorse backbone router that stimulated the development of CIDR
> was built on an open-standard Mutlibus backplane with a MIPS CPU
> IIRC. That also made widespread software updates a much simpler
> proposition. Hardly anyone had a backbone router that was older than
> an AGS (in fact, even the AGS was relatively rare in favor of the AGS+).

I don't think you can overstate how ASIC's made changing anything pretty 
much impossible. I'm not sure exactly then the cut over to ASIC's 
started to happen in the 90's, but once it did it was pretty much game 
over for ipv6. Instead of slipping an implementation into a release 
train and see what happens, it was getting buy in from a product manager 
that had absolutely no interest in respinning silicon. I remember when 
Deering and I were talking to the GSR folks (iirc) and it was hopeless 
since it would have to use the software path and nobody was going to buy 
a GSR for its software path.

It's why all of the pissing and moaning about what ipv6 looked like 
completely missed the point. There was a fuse lit in 1992 to when the 
first hardware based routing was done. *Anything* that extended the 
address space would have been better.

Mike