Thursday, May 10, 2018

SD-WAN: Come on guys, lets use that data!

Ariel Liguori 7:06 PM

I had the opportunity to participate in the latest MPLS SDN NFV World @Paris 2018, and need to say I've saw a lot of SD-WAN gear around and had the opportunity to talk with some technical experts regarding their solutions.

The main goal of this post is to point some considerations I'd found during this week, if you feel that you company is the exception to this list please feel free to ping me and let's have a talk :)

Being that said this are the missing points I found and want to summarize in order to help those companies in their roadmap development:

- Big Data, really? - Lot of vendors claims that their SD-WAN solution has a built-in analytics and big data backend in order to get lot of information that will be useful for advanced reporting and metrics. That is not a lie for sure but the issue im still finding here is that no single vendor is using that data to do a feedback cycle to the system. What does this means? Imagine that you have a lot of information of the BW usage for customer links and (after a while) you can do basically two simple actions:

Detect real time high-usage/packet drop/service degradation/SLA not met/etc
Predict or even prepare the network for future loads

Well that's great, but if you're only showing information there is no feedback in the cycle and your system can't adapt and even if you're showing us a degradation NO action is being done. Think about self service customer systems that can show the end user that their links are degraded and shows an action to remediate the issue, that is real usage and integration of the monitoring/telemetry of your system and provides real useful features. Being that said we can tackle down our second point, prediction and why not start thinking on AI. The information this systems are generating should not be used only for fancy reporting, the most important value for the data is his understanding inside the context, basically for us this means being able to use it to predict network patterns and take actions based on the behavior (yes.. if you're thinking about intent drive networks this goes that path, at the end we want the network to behave in a particular way). Unfortunately this is not happening for **any** SD-WAN solution.

- Analytics and controller disaggregation - More on the topic I've just described before, most of solutions presents a controller UI and platform and a complete different platform for the analytics and monitoring solution, in some cases there is no even an integration from a common portal (really). But the key point here is not that they're not under the same UI, the important missing feature is the lack of communication between those two systems (this for sure is one of the causes of the no feedback we just mentioned). Note that I've mention that only some of them are failing this point, some of them have the analytics module already connected to the controller but still no valuable use of that data. Maybe a key point to mention here is that the analytics system for networks are still being modeled in a legacy way and there is no way to ask for behavior or to trigger data about policy compliances (some of them have solved this by creating service policy that are met by reaching or not some defined tresholds, this is not for sure a meaningful API but well at least is just a start).

- Interop - Last but definitely not least important is the controllers interop, and also here I want to point two completely different issues that are related to inter-operability:

SDN vs SD-WAN Controllers: Let's imagine you're living without any worries relying on your SDN controller, now the small brother cames into play and guess what... that new SD-WAN controller doesn't have a clearly defined way on how to talk against your running SDN-C. Moreover, you realize that some of the vendors are using their own specific way to do it, some of them have not even consider the use case and other relies on same old BGP to interact each other (however I was not able any doc supporting this #Versa or Juniper SD-WAN)
Tie to a vendor and live with that - Guess what, you have chosen a specific vendor, you have their hardware running and their SD-WAN Controller software, but now you realize that your hardware must not be tied to your software solution (highly coupled solutions are avoided far before objected oriented programming), well.. luck there, once you have elected your vendor they are not enforcing/developing a white-box roadmap, at this early stage they are closing the doors to develop their solution and let it grow till the market demands for open-sourced solutions (we have lived this in the past, right?)

Well those are pretty much my thoughts on this topic, feel free to think other way and demonstrate the opposite, I'm open to hear back from you and to discuss this :)

Article By: Ariel Liguori

CCIE DC #55292 / VCIX-NV / JNCIP "Network Architect mainly focused on SDN/NFV, Openstack adoption, Datacenter technologies and automations running on top of it :) "