[j-nsp] ACX50xx l2circuit counters

Saku Ytti saku at ytti.fi
Tue Jun 21 06:34:07 EDT 2016


On 21 June 2016 at 13:24, Mark Tinka <mark.tinka at seacom.mu> wrote:

> I would not say it's better, but the vendors have much more leeway in
> fixing issues when it's their own silicon vs. something they can't
> change after it enters the box.

I don't understand. In either case, nothing can be fixed in the
hardware after it enters the box.

> The ME2600X from Cisco, which is/was a good little FTTH box, was such
> for me. I ended up ditching it because they could not do a lot of things
> I expected due to the Broadcom chip they had in there. Suffice it to
> say, the box was pulled from the portfolio a year later.

This can be said to pretty much every ASIC/pipeline box, they can't do
everything.

> I look at both; now as much as the future.

This is certainly part of the reason vendors don't want to communicate
openly, if customers decide product is inferior based on the logo on
the chip. I guess same reason why they don't document clearly the
limitations, they know that lot of customers won't actually use the
boxes like that, but might not buy the box out of fear if the issues
were listed.
Vendor's openness depends on customers doing informed, fact based decisions.

> The point is that if the chip was designed in-house from the ground-up
> (which the vendors can admit to), and that features can be flexibly

Which we already determined, we can't really know if it's true or not.

> manipulated in-house (which the vendors can admit to as well), I'm fine
> with that. It has worked for me thus far.

It can't be manipulated after the hardware has been made. It does what
it can do.

> In-house design does mean external IP was not used. It means that
> feature and forwarding performance have the vendor's stamp of approval,
> which I have never got from a vendor when they 100% outsource the silicon.

Are you implying Cisco would say to you they don't give you feature
and forwarding performance stamp of approval to ASR9k, because it's
not their chip? If this is the communication you receive, I can
understand your position.

-- 
  ++ytti


More information about the juniper-nsp mailing list