Musings

SDN across domains in the WAN – a novice look

buraglio | 85 | | , ,

There has been a flurry of discussion on SDN in the WAN lately, specifically, why and how.  Brent Salsbury laid out a few use cases here.  The why seems pretty straightforward.  I do believe it will happen, however, the how is the interesting part.  Admittedly, I’m a tad of a greenhorn in the SDN space, I’ve made it work in a lab, I participate as much as I can in the working groups and I attempt (poorly) to keep up.  
SDN, and likely OpenFlow, is in our roadmap at work.  Doing SDN in the data center is well documented and fairly well tested. Stanford has it all over their campus LAN and Google is pushing it around their walled garden WAN on custom built hardware.  None of this is new.  
The interesting bit is how do you do it across multiple administrative entities? 
As I said before, I’ll never claim to be an SDN expert, so I need to break this down into simple pieces for my limited mind to comprehend.  
BGP solved this years and years ago, how is that accomplished?  Can any of these bits be re-used (why re-invent the wheel)?

My caveman mind wants to break this down into requirements:

This can likely be controlled by access between peers via an access control mechanism of some sort, i.e. place software limits on how much a given peer can provision in your network, which can be broken down into:

  • Number of circuits
  • Types of circuits (MPLS, VLAN, DWDM Waves, etc.)
  • Bandwidth per circuit
  • Duration of circuit (path TTL, permanent?)
  • Number of devices involved per circuit
  • Types of SDN (OpenFlow versions, OSCARS, etc)
  • Probably more stuff

How can this be done?  I don’t currently know enough to answer that question, but I suspect it may require a little bit of work in adding a peering framework between control planes (SDN controllers) not unlike how BGP works.  To put this in familiar terminology, for example,

  • Route maps could be replaced by permissions maps or even an ACL of some sort to establish the abilities of each peer.  
  • Peers would need to agree (configuration-wise and politically) on what abilities can be exchanged before peers could operate, programmatically agree on parameters before any changes can be made.
  • Security parameters would need to be met for the peers to establish to contain the control plane traffic in a safe way, much like an MD5 across a BGP peering.

If this sounds like a tall order, I’ll wager you’re right and I’ll also bet that before it happens we’ll have a Blu Ray vs HD-DCD or VHS vs Beta throw down of SDN protocols.  
Folks have been trying to do this for years, the DRAGON project tried this years ago and did a decent job.  Our Arlington, VA site was one of the original build outs of it. OSCARS is doing similar stuff and is actively working across ESnet. Internet2 ION is another attempt.
These have all had their effect on the Research and Education networks, but to be adopted acrossm and more importantly between, service provider networks, there needs to be ways to do them elegantly and securely.  There is nothing that a SP hates more than risk, and without these control mechanisms, there is a pretty large amount of risk. 
It’s reasonable to think that this may be there and I’m just missing it, since I am admittedly a novice in the SDN world, but if by chance I have not missed it because it’s not there, it needs to be addressed.  

Recommended for You

5 thoughts on “SDN across domains in the WAN – a novice look”

  1. Brent Salisbury · Edit

    Nice thoughts Nick. The SP is moving quickly on this. You keyed in on the part that is such a question mark. How do inter-domain exchange information safely and usefully. Good thing is the content providers have been doing similar things for a long time. When I click post your site will do an OAUTH to Google. APIs and open source might be the ticket. Awesome post.

  2. billowens · Edit

    This is a good description of the breadth of the problem, but there are places where it is very, very deep. Your description is focusing on one possible outcome, just talking about building Layer 2 circuits between two (or more) networks. Do you think that’s a worthwhile end, or are you thinking about true ‘SDN peering’ that would include some degree of delegated control of network elements as well? As a network engineer I might be satisfied with a simple Ethernet VLAN, but a researcher’s application could require the installation of specific flow rules on every port along my path. And I would make the claim that past history has demonstrated the difficulty of even the simple VLAN model.
    To date, the serious efforts to implement some kind of multi-domain dynamic circuit networking in the R&E world have fallen into two categories: a dynamic core surrounded by static, manually-configured access networks, or a federation of networks managed by a single control plane, with all the participants subject to the central authority. Both of those models have been proven to work and to have a level of complexity that, while perhaps not optimal, is within our grasp. I’m not at all sure that the fully-generic model of interoperating autonomous circuit networks is really practical; perhaps if the set of services is made so simple and straightforward that it reduces to a lowest common denominator. The holy grail of peering between multiple autonomous networks that allows full programmability of the resultant path is something that I think will remain a distant dream.

  5. Bill Z Walton · Edit

    Today, I went to the beach with my kids. I found a sea shell and gave it to my 4 year old daughter and said “You can hear the ocean if you put this to your ear.” She placed the shell to her ear and screamed. There was a hermit crab inside and it pinched her ear. She never wants to go back! LoL I know this is totally off topic but I had to tell someone!|

Comments are closed.