[j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 21/Jun/16 12:34, Saku Ytti wrote:

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

I didn't say fixing issues in the hardware, I said "fixing issues", most
of which can be done via software because the chip was given the ability
to in the first place, based on all the experience the vendor has had in
the industry.


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

I didn't say I want everything, I said it didn't do what I wanted.

Another box did do what I wanted, so I went with that. But more often
than not, the boxes that haven't been able to meet at least 95% of my
requirements tended to be external chips. I can't ignore that however
much I try.


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

I have not been looking at merchant silicon for a long time. Only in the
last 3 years, really, when Cisco were considering it for the ASR920 at
first. Even Cisco, themselves, decided against it because of label depth
limitations when considering their SR implementation for the portfolio.

It might not come out on-list, but I do a lot "fact-based" testing and
research before I decide on purchasing a box. I don't like to get too
much into this detail on-list because things change very quickly in this
area, and there is no point holding on to that data for too long when
your purchasing cycle is high.

I prefer to distill the basics and keep my eye on the prize. I'd not
take my lack of emphasis on the finer details on-list as being ignorant
about how I reach my decisions.

Ultimately, we are running a business, and given my position, I need to
balance that at all times.


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

I'm referring to the preparations that were made beforehand, that
provide some flexibility later on.

Many an in-house chip have been developed without a feature in mind, but
when asked, it could be done because of the initial design. Other times,
even though the chip can support it, the vendor does not want to do it
because they are committing time and resources on the next-generation
platform.

Take Policy Map for the MX, for example. I worked with Juniper for 2
years to develop this feature, and was lucky it could be done on the
Trio because of that design. They can't do it on any other M-series, for
instance, and certainly not the DPC's which are external chips. It's not
a feature they foresaw when developing the Trio, but they managed to
make it work without sacrificing performance after-the-fact.

When I started testing the ME3600X/3800X in 2009, the Nile chip did not
support QPPB. After working with Cisco for 6 months, I managed to
convince them to re-spin the ASIC before they started manufacturing the
box for general shipping. But such opportunities are few and far between
(basically, non-existent), and I wouldn't bank on them being the norm,
ever. Which is why flexibility in the future is easier with an in-house
chip, even if it's not always guaranteed.

The idea is to give yourself the best chance possible, rather than
resigning yourself to binary outcomes.

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

No, it means that I am more inclined to using the ASR9000 in specific
situations and not others, knowing what I know about the platform since
it launched, and where it is today.

It also means I know the right questions to ask (from experience) so I
do not waste my time testing things that don't matter to me.

Mark.