Shedding tears while peeling Nicira’s onion

Digging through my backlog of Nicira-related reading (yes, I know – shame, but I’ve been quite down with flu for the last two days), I came across the Nicira NVP FAQ, where a few things have caught my eye.

Granted that I don’t know some finer details of NVP’s inner functioning, but based on the information that instances of Open vSwitch use (point to point) GRE tunnels to communicate with each other, I found it hard not to wonder about a thing or two in that document.

Let’s have a look, shall we? First cab off the rank, QoS:

NVP provides for:

– Edge enforced, dynamic QoS

Right. Keeping in mind that OVS instances can’t directly know what is going on in the underlying transport network and have to work with the inferred information, if any (like traceroute information, measured transmission performance that can be potentially gleaned if GRE PDUs are time-stamped, and PDU loss), I am finding it hard to work out how could end to end QoS be possibly ensured. Yes, inbound edge admission control and prioritisation at the virtual interface can be achieved, but as soon as the customer data has been packed into GRE PDUs and shipped off to the physical network, all bets are off. If there’s an implicit assumption somewhere that for this to work the underlying physical network has to be not contended, I’ve missed it.

Next up, tunnel state management:

The NVP Controller Cluster dynamically updates the state of tunnel connections between OVS switches through the physical network.

Unless OVS instances use multiple IP address pairs to communicate with each other (where the same pair of OVS would have more than one tunnel between themselves, using different IP addresses), I don’t see what good would “dynamic state of tunnel connections” do. An OVS pair, one tunnel – it is either up or down (or performance degraded). What can you do if it is down, I’m not too sure. Try to re-establish using a different IP address? Where’s the guarantee that it going to work?

Then again, I’m flying somewhat blind here, and maybe this has been solved creatively.

Next up, brodcacst and multicast:

Support for network services including broadcast and multicast

GRE is point to point. This means broadcast and multicast are replicated at head-end, which may or may not be a problem, depending on the applications. Not critical but mildly annoying, just like a bit of sand in sandals. 🙂

Conclusion

As I wrote yesterday, there are things that you just can’t get if you’re “flying high”, and I think that there are some very good synergies that can be had if SDNs could leverage the capabilities present in IP/MPLS transport networks. However, it takes two to tango, and I’ll be curious to see if enough interest materialises from both sides of the fence to make something like this to happen.

P.S. To clarify the context of my musings, I am thinking about a use case of Service Provider who owns and operates both cloud platform and the underlying transport network. In case of an uncontrolled 3rd party transmission in the middle (like the Internet) possible benefits are severely reduced.

— Dmitri

About Dmitri Kalintsev

Some dude with a blog and opinions ;) View all posts by Dmitri Kalintsev

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: