[c-nsp] Devil's Advocate - Segment Routing, Why?

Mark Tinka mark.tinka at seacom.mu
Fri Jun 19 14:34:13 UTC 2020


On 19/Jun/20 16:09, Tim Durack wrote:

>
> It could be worse: Nexus ;-(
>
> There is another version of the future:
>
> 1. SP "Silicon One" IOS-XR
> 2. Enterprise "Silicon One" IOS-XE
>
> Same hardware, different software, features, licensing model etc.

All this forking weakens a vendor's position in some respects, because
when BU's are presenting one company as 6,000 ones, it's difficult for
buying consistency.

Options are great, but when options have options, it starts to get ugly,
quick.

Ah well...


>
> Silicon One looks like an interesting strategy: single ASIC for fixed,
> modular, fabric. Replace multiple internal and external ASIC family,
> compete with merchant, whitebox, MSDC etc.

That is the hope. We've been to the cinema for this one before, though.
Quite a few times. So I'm not holding my breath.


>
> The Cisco 8000/8200 is not branded as NCS, which is BCM.

Not all of it - remember the big pink elephant in the room, the NCS
6000? That is/was nPower. Again, sending customers in all sorts of
directions with that box, where now ASR9000 and the new 8000 seem to be
the go-to box. Someone can't make up their mind over there.


> I asked the NCS5/55k guys why they didn't use UADP. No good answer,
> although I suspect some big customer(s) were demanding BCM for their
> own programming needs. Maybe there were some memory bandwidth issues
> with UADP, which is what Q100 HBM is the answer for.

When you're building boxes for one or two customers, things like this
tend to happen.

But like I've been saying for some time, the big brands competing with
the small brands over merchant silicon doesn't make sense. If you want
merchant silicon to reduce cost, you're better off playing with the new
brands that will charge less and be more flexible. While I do like IOS
XR and Junos, paying a premium for them for a chip that will struggle
the same way across all vendor implementations just doesn't track.

Mark.




More information about the NANOG mailing list