Living in the underlay

Mainly Networking, SDN, Automation, Datacenter and OpenStack as an overlay for my life

Thursday, May 10, 2018

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

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:

  1. Detect real time high-usage/packet drop/service degradation/SLA not met/etc 
  2. 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:
  1. 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
  2. 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 :) "

Wednesday, April 11, 2018

Embrace API not SDK, but don't reinvent the wheel

I'm having lot of discussion with my students and colleagues regarding this topic and want to start by clarifying this question that someone made few time ago:

"Why do you teach Cobra SDK for CCIE DC curricula instead of pure raw REST API?"
The answer was quite simple "Is in the official curricula/blueprint and you need to master it"  but it has some drawbacks and I feel that some other things needs to be considered here:


  • Embrace API: The freely way to operate is to use pure REST API and automate as you wish the service (at the end we want to cover some use case that serves some purpose and that can be considered a service for an specific end user - engineer, customer, etc- ). If you understand and comprehends how the API is structured and works it would be quite easy to automate that specific gear moreover you can even start thinking like that box/system ;) [1]
  • SDK is a huge toolbox, use it wisely: The SDK just provides you a toolbox to quickly start coding without messing around with a **huge** API set, but even if it seems the easy way there are some caveats to consider: The SDK packages common operations into functional boxes (methods) for you to consume, however that doesn't mean that all your pretty weird use cases will be covered/reflected into the SDK [Even if they say that the SDK reflects the API, I've not met a single SDK from a network vendor that covers their full set of API operations into the SDK and lets not even start talking about documentation..].
  • Don't reinvent the wheel: If you're planning to move towards a pure REST API model i'm happy for you (really, not sarcastic) but consider: are you going to encapsulate the specific device on your specific package/model? If the answer is yes for each specific device my first response would be "why not to use the SDK on the first time?" since you are deploying the same thing with a less code power than the vendor. if the answer is yes but not to a specific device but to a specific role in network we are start talking about good design choices ;) don't tie your code to a specific gear, make it independent and more on this...
  • Don't repeat the past: If you're planning to use pure REST API to talk to a network device and you're thinking the legacy way you will end up in multiple API calls (being multiple equals to the lines of CLI commands that you need to enter in the device configuring by hand). So basically you will be doing old school network in a fancy way, why not starting asking devices about a desired state? (intent)
  • Code a service not a function: Creating a [script/program/api] to do a specific task such as create vlan, trunk it, enable a protocol or even to do a correlate serie of tasks is not the same than creating a service, the aim of your code should be the service automation since network automation is well covered by many sources but service automation is specific to your business/use case (please have in mind that even if there are a lot of powerpoint $#$%$# around the probability that your use case is not a standard covered one is near to 99.99999%)
Being all that said I really think that more needs to be done in order to correct instruct the way that some organizations are taking towards network automation, more over an intent based think is need definitely in order to not fail to repeat the history and do legacy network automation in the new era.



By the way for those who still asks me if I provide some network automation course for DC or generic network programming is Yes and is not based on any SDK, it's not part of the CCIE DC training and is covered in the Network Programmability course (more info ping me directly, linkedin or trough ie-bootcamps :) )


[1] Some vendors, and want to remark that shamely only some of the full network vendors ecosystem,  creates their UI or EndUser systems based purely on the consumption of their own boxes REST APIs.
, , , , , , , , , , , , , , , , ,

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 :) "