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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp