I have no idea where to even start - this article was written by someone who has no large scale IPv6 deployment experience. There are errors upon, back-to-back, errors in what's assumed and the expected results and assertions with the vendor (Juniper) and the protocol operation (IPv6).
I'm not surprised that it's towards the top of HN but it shows the relative understanding of the HN crowd with regard to complex network related topics.
I'm pretty familiar with "complex network related topics" - and I think this is the most interesting IPv6 related post on HN in 2+ years (there may have been others that got by me).
I"m curious - are you someone with "large scale IPv6 deployment experience?" - in particularly, how would you have approached their issues regarding MLD snooping and TCAM exhaustion?
It may be interesting, but my point was that there is nothing in this article to learn from with the exception of problematic code from a network vendor.
Yes - I am. I deployed a 4 state IPv6 overlay servicing 250k subscribers on one of the very first (fully rolled out) DOCSIS 3 HFC networks in the US. I was responsible for the security and performance of the architecture. This rollout started in 2010. The TCAM exhaustion was self inflicted based on the hints of design throughout the article and the original authors understand of MLD is, just generally, incorrect unfortunately.
This comment would be better if instead of insulting its audience, it taught them something. Many people here would appreciate a chance to improve their "relative understanding".
As it is, although it alludes to questions of substance, it doesn't actually say anything about them, and therefore is just noise.
I think that is a very telling point in and of itself. I've sat on the boundary between the devops / security and networking world my entire career. I know many people who are great at *nix and tooling of backend infrastructure but choose to ignore the plumbing, and complexity contained within, the planning and architecture that can make the pieces above it that much more successful. When I read an article like this there are blatant points that showcase how green the OP is with regard to networking. I happen to have an advantage in this space and the point being is that I don't claim any expertise in compiler design, never will. However - it pays to bring people in to help. While you only see the story from the OPs perspective there's an entirely different side from the vendor most likely (probably around fundamental design if I had to throw a dart).
Sure, I knew I'd get downvoted for the post - but sometimes that's a calculated position to show a point, and my point is - sometimes you need help, this article was very one-sided and rife with flaws. Not something I generally expect to read on HN - but I know there is likely a lot of that out there that I "just miss" because I know that I don't know.
I have no idea where to even start - this article was written by someone who has no large scale IPv6 deployment experience. There are errors upon, back-to-back, errors in what's assumed and the expected results and assertions with the vendor (Juniper) and the protocol operation (IPv6).
I'm not surprised that it's towards the top of HN but it shows the relative understanding of the HN crowd with regard to complex network related topics.