After a couple of last posts on this blog, discussion have happened, questions asked, and… went somewhat unanswered at the time. Questions went largely around use cases, where SDN would benefit from close interoperation with IP/MPLS domain.
Admittedly I didn’t come up with anything good at the time; however, I did later, was ready to post yesterday but then WordPress bots-in-charge decided that my blog was behaving oddly (“Oh, noes! Look out, he’s got READERS all of the sudden! The Horror!”), is probably breaching their TOS, and blocked it. We’re back today, with apologies and a message that “the system should not have done this”, so life’s good, at least until next time. This highlights problem with some of cloudy services, which is a good topic for a rant; but I digress.
Now, back to the use case. I think it is best explained with a diagram, so here it is:
Here we have a Service Provider, who operates their own Data Centres (one shown), and a L2/L3 VPN WAN network, which they sell to their customers. WAN connections are terminated with Demarc devices, owned and operated by the SP, and installed at customers’ premises. Customers connect their LAN segments (either via their own routers or directly) to ports on Demarc units.
For clarity, things under control of the SP are coloured in light blue.
Now, SP’s compute hosts run Open vSwitch (OVS), and so do their Demarc units. OVS instances establish p2p communications with each other, and create isolated distributed network segments, in this diagram – Red, Green and Purple. These segments are presented at customer’s sites as VLANs, and inside the SP’s compute as port groups, to which VMs are connected.
Note that in the diagram above, nothing stops the SP from providing a network segment Yellow, which, for example, is only present at Customer’s sites A and B, but not inside SP’s Data Centre, and which is used by the Customer for some other things.
Now, let’s have a look at the possible benefits of such arrangement:
- SP can easily provide customer with a very flexible connectivity arrangement, which can even be configured for self-service reconfiguration (1). All that needs to happen is SP’s provisioning systems to adjust flow tables in OVS instances in Demarc units, driven by a customer self-service portal. I think this is a big thing, considering how people are expecting everything to happen instantly.
- SP does not need to have Carrier Ethernet service network for this to work. L3 VPN will work just fine.
- This arrangement solves problems associated with VPLS and VLAN ID transparency – while in many cases a single VPLS instance can transport mix of tagged and untagged traffic, “true” separation based on VLAN IDs does not happen, and all BUM traffic is delivered to all VPLS sites, whether they want it or not. Not anymore.
So, this is where I see closer cooperation between OVS/SDN and IP/MPLS would be totally in order. We’re dealing with a WAN, and this is where bandwidth availability and faults are a serious consideration.
Now, to the bad news.
I’m not sure there are too many devices out there in the market that are sized right to be a Demarc (it needs to be fairly small and quite cheap) which have or can have OVS running in them. The ones I’m aware of have way too many ports and obviously haven’t been designed to be a Demarc.
Not holding too many fingers crossed for dear Vendors to step in, but none the less, it would be nice.
(1) In the case when bandwidth allocation on access links doesn’t need to change.