--Mobile post--
Meru gets confused about control-plane versus management-plane functionality in one of their recent blog posts. (I am not linking to the blog post because I don't want to help drive traffic to potentially the worst Wi-Fi article in a long time).
There are many things wrong in the blog, and I won't bother to go through them point by point. But I'll highlight one that hasn't been mentioned on Twitter discussions yet. I'm also posting this on my site since they've already demonstrated that they won't publish comments that disagree with them on their own blogs or have a real discussion about their position. They just want to blast marketing FUD.
They state: "...'what' the control-plane function provides is much more important than 'where' the function resides. Therefore the model you choose (local, WAN, cloud, private cloud, virtual, AP) should have no bearing on the functionality of your Wi-Fi."
What?! Are they really serious?! This is inherently wrong because a control-plane outage has operational impact on the network. That's why enterprise network admins spend so much time designing WAN architecture and redundant controller architectures.
If I were an enterprise customer, I would seriously be questioning the ability for Meru to understand customer requirements at this point, let alone build products to meet them.
Cheers, out!
Andrew
Andrew,
ReplyDeleteThanks for posting this area where we can leave comments regarding Meru's blog "To Control or Not to Control" found here: http://blog.merunetworks.com/blog/2013/05/to-control-or-not-to-control/
Meru has obviously decided not to post our (dozens of people from the looks of it on Twitter) comments, so this gives us a common area to voice our opinions. I've started a new blog of my own where I've posted my comments (too long for your blog comments engine).
http://tmblr.co/ZcX71slnRmGV
Thanks again for your awesome blog amigo!
Devin
The only difference with this post and Meru's latest blog is that we can post comments. Andrew, your post is as much marketing FUD as Meru's. Not surprising since you and your boss Devin are working for a WLAN vendor that really offers only one control plane architecture. This is your differentiator and you certainly don't want it diminished.
ReplyDeletePersonally (also working for a WLAN vendor), I agree with the above statement from Meru. Sure, some architectures require redundant controllers to provide a highly available control-plane, while others don't or even can keep on working when the control plan is down. So is the 'where' the control plane function reside really a deciding factor in itself?
Customers look for cost effective Wi-Fi solutions that meet their needs (high availability, auto-RF, VoWLAN, BYOD, whatever...) and their environment first and formost. Some Wi-Fi solutions will better address the needs of some customers, while others will better address the needs of other customers. There's no single solution that's always superior, independently of the customer needs.
Hence, I have to agree with Meru: what the Wi-Fi solution provides is more important than the 'where' the control-plane resides.
Regards,
Francis
Hi Francis,
DeleteMy comments are not directed at the whole controller or controller-less issue. More to the point, I found Meru's blog post to be dismissive of proper network design and architecture even where controller redundancy is concerned. There article seemed to me to be de-emphasizing "proper" network design for redundancy. 'Where' the control-plane resides is of huge importance to customers because it has implications on network availability.
For Meru to state that 'where' the control-plane functionality resides (hence the model) has no bearing on the functionality of your Wi-Fi network is blatantly false. I can pick out numerous examples where the control-plane architecture detracts from functionality of the Wi-Fi network itself. One example, Cisco FlexConnect and all the features that it is missing.
To write such a flippant remark and disregard real-world network design considerations is disingenuous. Network administrators have to very carefully consider 'where' the control-plane resides and make choices and trade-offs that mean the most sense to meet their needs. This includes control-plane architecture (model), redundant controller design, WAN redundancy/latency/bandwidth, etc.
Let's not make this a vendor debate, because frankly it's not about that. This discussion is simply about proper network design for high availability no matter the architecture. And 'where' the control-plane resides has HUGE implications for customers.
I'd happily welcome your comments on the real subject of my post, not what you "read into" the post.
Cheers,
Andrew
P.S. - Although I now work for a vendor, most of my career has been spent on the customer side dealing with network design and architecture among other things. I find it ignorant when people assume my position just because I happen to work where I do at the moment. Engage in more meaningful conversation within the Wi-Fi community and you will quickly see that I rally behind what's best for the industry and customers, even if that goes for or against any single vendor, my current employer included. I'd offer you to join us on Twitter. You can find my handle clearly linked on the right-hand column of this blog.
Also, thanks for taking the time to login and take credit for your opinion Francis. You're always welcome to aire your opinions here as long as you have solid reasoning behind them!
DeleteCheers,
Andrew
Understood Andrew. And I agree with you about proper network design for high availability and all. I just didn't read Meru's blog the same way you did. I didn't find that Meru meant the network design wasn't important, just that it wasn't as important as the Wi-Fi service itself. For example, to me, what's important is that the WLAN must be highly available. If that requirement is met (and all others of course), does it really matter if there are controllers, if the solution is controller-less, if it has a distributed control plane, or make use of virtual controllers? That's how I read it anyway.
DeleteI've always enjoyed and appreciated your contribution to the community via your blog. But what really got me going in your latest post is your comment 'They just want to blast marketing FUD'. ALL vendors do. That's marketing. Although in this specific case, I don't see much FUD. As vendor representatives, we can certainly debate whether the controller/controller-less conversation is relevant and all, but I don't think we should blame other vendors of doing marketing FUD, at least not when they're not directly attacking competitors with misleading information.
Cheers,
Francis
OH SNAP!
ReplyDeleteIf you are going to leave comments, please make them worthwhile :) I value real, genuine opinions on the topic at hand.
DeleteAlso - if you can't take the time to login and take credit for your comments, it must not be worth reading. Please don't use / hide behind "Anonymous". How boring! :)
Cheers,
Andrew
Without a Wi-Fi controller how do you identify traffic and enforce changes to qos markings or traffic priority for wireless traffic? This can be delivered into a controller less solution right; but would the access point have the hardware power and capacity to offer gigabit forwarding rates with layer 4 to layer 7 visibility and possibly control?
ReplyDeleteAdd on about 50 associated clients for good measure.
Most access points, and it does not matter the vendor use relatively cheap ARM based CPU's inside their Access points with good radio hardware, good antennas and Wired asics.
I would like to see in the real world a controller less solution that has complete feature parity with a controller solution and works at the same scale.
Also when you have a 5000 access point network, 1500 access switches and a small staff who manages this; ensuring vlan tag's are properly assigned everywhere and technicians at remote sites do not swap cables around to different switch port's is not a fun job. Controller less is great but it does not work for everyone.