[c-nsp] Cisco 8000

[Mark Tinka]

On 20/Dec/19 09:56, Saku Ytti wrote:

>
> This is making huge assumptions. This is assuming that when Leaba
> designed the chips they decided their exit will be vendor acquiring
> them and that decision impacted how the chip is being designed. To me
> this sounds ridiculous notion.

Possibly, but I'm also running a network today. I have to deal with what
is in front of me, plus some reasonable margin of the future.



> Pretty sure what you are actually doing is comparing run-to-completion
> to pipelines, you hear this 'not possible by the chip' all the time
> for vendor own pipelines as well, the only problem is, not many
> vendors have pipeline chips. But run PTX/paradise and you'll run into
> the same thing. It's fundamental that pipelines are less flexible.

Which is why we don't run PTX :-).

On a serious note, there are plenty of things vendor silicon won't do
either. But there is a higher chance they will do more things more
reliably. I can live with that.

When the MX3600X/3800X was being developed back in 2008/2009, we needed
QPPB support for our deployment of IP/MPLS in the Access. Because of the
influence we had on Cisco at the time, we managed to convince them to go
back and re-spin the Nile chip for that platform just before they had
begun full manufacturing, because the original chip couldn't do QPPB.


>
> I mean you rock Cisco, ASR9k is merchant up until lightspeed, yet you
> don't hear a lot about these complaints about ASR9k.

Actually, there are a number of reasons we avoided the ASR9000 in the
customer edge, due to some limitations on the merchant chips they had.
It literally was the only reason the MX480 won that part of our network.

We do, however, use the ASR9001 (the only ASR9000 we have in the
network) for peering. That is until the end of this year, as we are now
running into several resource issues with the box carrying a full table
and maintaining correct routing, and are swapping all of them out for
MX204's in January 2020.

Mark.