[c-nsp] Cisco 8000

[Saku Ytti]

On Fri, 20 Dec 2019 at 10:12, Mark Tinka <mark.tinka at seacom.mu> wrote:

> 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.

If you maintain relationship with BRCM or whoever, even if you don't
buy direct, you can do that. But of course tons of customers of
different vendors already do and already signal this is requirement so
this is something Jericho can do. Jericho can do quite many lookups
and has excess lookups in typical implementations for future use.
Newer BRCM pipelines even have unassigned ALUs so instead of respin,
vendor can just start using those ALUs.

Btw. exactly same problem exists in PTX, because
ingressACL => ipLookup => QoS scheduling => forwardingACL => egressACL
=> QoS rewrite

You recover DCU/SCU at ipLookup, by the time you'd use that to remark
at forwardingACL, QoS is already done. However paradise is 500Mpps
lookup with 333Mpps for forwarding, so there is 170Mpps margin for
recirculation, so this could be implemented in PTX at cost of
recirculation.

So I fail to see vendor/merchant different here, I continue to see
run-to-completion and pipeline difference here. And indeed merchant
(particularly Jericho) does have flexibility now Cisco and Juniper
equivalent pipelines do not have, simply because they get requirements
from a wider audience.

-- 
  ++ytti