In case you missed it, we hosted a webinar with Craig Connors, Chief Architect for VMware SD-WAN™ by VeloCloud® last week which covered the best questions we received on his Reddit AMA back in December. In addition to reading this post, which outlines the highlighted questions, you can check out the recording of the webinar, which features several interesting questions from the audience.
How would you compare your solution to the competition, both ISP/vendor managed solutions, and customer managed solutions?
Choose an SD-WAN vendor that will:
- Be willing to commit to an SLA that matches your business requirements
- Be able to automatically identify and mitigate issues that happen in the WAN (not just steer around them)
- Be capable of fully automated management using APIs
- Not rely on proprietary hardware that cannot evolve as quickly as networks and software can
From an engineer’s standpoint, what makes you guys stand out versus the other vendors?
Downsides:
- No command line interface (CLI)
- A new experience for most engineers
- Can make some troubleshooting slower
- Lack of “nerd knobs”
- Lack of deep visibility into internals (e.g. QoS)
Upsides:
- A platform built for deep visibility into the network and automated decision making means some classic network problems can be avoided
- More time to work on the “cool stuff”
- API-driven approach means full automation is possible
- Example: A partner who has fully automated provisioning and bring-up was able to deploy ~3,000 sites in one week with no turn backs
There are some issues with utilizing QoS on MPLS; can you detail what the problem is and when it might be fixed?
VMware SD-WAN uses a protocol called VCMP to remediate WAN problems. One fundamental precept of this is that every packet on a path is sequence numbered so that we can ensure in-order delivery and measure/react to packet loss.
Consider the native case today of a VeloCloud tunnel and MPLS with three classes of service: EF, AF11, and AF12.
I sent 30 packets that are intermixed—packet 1 is EF, packet 2 is AF11, packet 3 is AF12, packet 4 is EF, etc… VeloCloud, now part of VMware has tagged these 1-30 and is expecting them in order on the other side. But what if the AF11 class alone is oversubscribed? We’ll instead receive all the EF and AF12 packets first. We detect this as an underlay problem—packets are getting out of order, experiencing jitter and potentially dropped.
We are working to address this by adding a conceptual “sub path” concept inside VCMP. That means within a single tunnel via MPLS, for each class of service, we will track a unique sequence number and loss/latency/jitter measurements. This will allow you to use the two different QoS paradigms together without the issues above.
Where do you see SD-WAN in five years given that vendor proprietary protocols become obsolete once an open standard is agreed upon?
We use standard protocols to integrate a number of services. Most folks in networking would say that there are still top protocols that exist. There’s always a place for that and there’s always going to be vendors who want to drive innovation in a way that makes it difficult to adhere to an open standard because open standards make it really difficult to differentiate, to be novel, and to provide value above and beyond what everyone else is providing.
Because of this we will end up with a mix of the two and there will always be unique protocols but we’ll have to ensure that we always have ways of interconnecting different types of networks.
Have more questions? Ask Craig on Twitter (@egregious) to continue the conversation.
