Getting the two to tango

In my previous post, I concluded:

…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.

After a bit of a think, I come to conclusion that such integration is already quite possible to a certain extent, and likely with only minimal changes on the NVP side.

It is probably best described in an example: let’s say we’re a Service Provider who operates cloud infrastructure located in several Data Centres and our own IP/MPLS transport network that interconnects them. We would then like to provide our cloud customers with three types of virtual networking services across our multiple Data Centres:

  • A “devil may care” best effort, which runs over unprotected label switched paths. It could at times get contended while network operates normally or can completely die if we lose a major transmission link or a network node that was serving it.
  • A “business class” protected service, with guaranteed uncontended performance when all transport paths are in operation, but which can get a bit squished if a major transmission link or a network node goes belly up.
  • A “first class” service, which is guaranteed its bandwidth at all times.

Now, we associate these three types of network services with a VPRN which connects our Data Centres, and allocate DSCP code points so that we can associate incoming GRE PDUs with the corresponding underlying label switched paths that make the magic happen (unprotected / protected / guaranteed).

The only thing that needs to happen for this to work is for NVP to be aware that it has these three differentiated network services available, and mark GRE PDUs with the corresponding DSCP values accordingly.

Virtualisation customers would then have a choice when creating their virtual network segments, which will be assured by the underlying transport network. Win-win.

Or is it? Given that the scenario above relies on a fairly sophisticated IP/MPLS transport network, it may fly somewhat against one of Nicira’s stated goals of turning transport network into a set of simple IP pipes, running on cheap commodity hardware.

I guess the time will tell what wins out – the desire to be the king of the hill for a day, or the long-term interests of the customers for who’s sake the whole cloudy shabang has been created in the first place.

Traditional clarification: this post assumes that the cloudy end-customers here are the “traditional” Enterprises, who care about VM mobility, flexible multi-VM configurations and service guarantees.

— Dmitri

About Dmitri Kalintsev

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

6 responses to “Getting the two to tango

  • EtherealMind

    The idea of Flow Forwarding is a bit odd but the outcome is that you can configure your FIB to look like tunnels everywhere for specific SRC/DST (thus emulating a circuit network) or you can configure an MPLS type of system to aggregate many flows into a wildcard rule.

    It just depends on how granular your Flow Table is, which is determined by app, controller and good design practices.

    • DK

      > you can configure your FIB to look like tunnels everywhere for specific SRC/DST

      If we’re still talking about NVP/OVS, then I’m not sure how this applies to MPLS transport network. Also, my bet is all traffic between a given pair of OVS looks like a bunch of flows between one pair of IP addresses, which include any and all conversations between virtual segments these OVS instances serve.

      What I’m pitching here is an ability to provide differentiated services for OVS clients by leveraging existing capability of existing IP/MPLS transport networks.

      Please let me know if I missed your point.

  • Ivan Pepelnjak

    Now you got it exactly right. Mark at the edges, queue/drop in the core, like we always did. Not sure NVP can do it today, but it’s not THAT hard to do – use a flow rule in OVS to set outgoing 802.1p bit and change the GRE code to copy 802.1p bits into DSCP bits (hopefully using a lookup table).

    However, I’m not sure this discussion is relevant – don’t try to use NVP as yet another L2 inter-DC extension mechanism. There are well-known well-tested ways we can use to solve that particular problem, and extending L2 subnets to support enterprise craplications is not one of them.

    • DK

      > don’t try to use NVP as yet another L2 inter-DC extension mechanism.

      I think we’re in a situation here when people are trying to fit a technology developed for a very particular use case (private, secured, dynamic networks on top of the Internet) into various gaps that exist around networking related to provision of “cloud services”.

      In other words – we have yet another solution that’s looking for a problem. Another post on this is forthcoming.

      • Ivan Pepelnjak

        Disagree. The problem NVP solves is very real if you’re big enough … and you need to decouple virtual networks from physical transport if you want to have any chance at doing it at scale. They just happen to be using GRE primarily, but they also have CAPWAP and half-baked VXLAN code. NVP/OVS is not about a particular tunneling protocol, it’s about turning 64 kbps voice circuits into Skype.

      • DK

        Apologies for not being clear enough. I’m not saying there’s no problem to solve; what I wanted to say is that NVP, the way it is implemented right now, is not capable of leveraging any sort of smarts of the underlying transport network. Depending on the use case it may not be a problem; however the moment your inter-VM communications hit a spot where there’s a potential for service degradation or failure and you need to deal with service guarantees, then you may wish you had such capability.

        Hope this makes things clearer.

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: