The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.

Assuming you’re talking about the NCS 5500, I thought the whole point of that platform was that it wasn’t using Cisco proprietary ASICS and was just using Broadcom chips with IOS-XR wedged on it anyway to give it the appearance of being a budget competitor to the ASR9K while lacking the majority of the feature set because ... it’s not using Cisco’s proprietary ASICS that support all those features.

Also, they have full ipv6 routing and switching support. So does the C6500, which is ancient (and still in production in many places)

The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.

And v6 has some serious second system syndrome going on (aka we’ll dramatically fix all the stuff we wanted to do better last time, ignoring real world constraints), and the adoption shows. It was clearly designed to be a either or replacement (aka cleanroom, start fresh with this), but that’s not how real world upgrades tend to work. I keep wanting to use v6, but every time I do, it quickly ends up having to get turned off because of something broken somewhere in some product I have little choice in using or interacting with and v4 (even with tons of terrible NAT) still keeps chugging along.

Momentum is shifting of course - this isn’t a steady state forever thing - but man, ugh.

You can do both.

> And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.

It depends on whether you actually want to fix it.

> The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.

Yes, which is very different from being unable to get the equipment you'd need.

And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.

The question was about what the company can do, talking about external constraints, so I don't really care how purchasing departments work for that topic.

> And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.

For smaller companies, yes. Except the argument was that smaller companies could get them already, while Amazon would exhaust the world supply.

Once we move into the realm of companies that make their own markets, it doesn't matter what "most people" do. Those companies can make their own choices and get whatever they want made.

But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected?

The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall.

And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.