Re: [nznog] NZIX OpenFlow adventures phase 2

Interesting! On the IX the interesting application (to me) you mention is the scale out BGP router (and similar functionality). But this is internal to the IX and just appears as a big router to the customers. If the customers were to start managing flow table entries on the IX fabric to suit their own purposes it could raise hell, thus anything exposed will naturally have to be a product developed by the IX, and consumed by connected providers and their customers. And having to steer traffic based on aggregate flows becomes necessary due those small tables on commodity hardware, which quickly destroys the fine grained control that a lot of people talk about as being a selling point of SDN. This brings you to look at what innovation SDN has brought us so far (at least in public), and it looks like most of the "innovation" will look very similar to existing services just rebuilt with a different control mechanism. These aren't really new services, they're just SDN applications that build analogues of existing services in a different way. Sure they're subtly different, tailored to the needs of the business, and they can be adapted/enhanced to do new tricks quickly by coders. Or they can quickly be extended to parts of the network you couldn't do this on before, e.g. you could wait 10 years for IETF to finish NVo3 or you could just build your own simple equivalent (as people have been doing) and deploy it to your end points/servers yourself. But providing any meaningful east/west connectivity between different SDNs and the applications running on them is going to require some form of standard, falling back naturally to the existing routing protocols. So basically how you make SDN on an IX a publicly consumed feature is pretty interesting if possible. PS: Not to sound like I'm ragging on SDN too much, I'm a fan. If used internally it can make your life easier through simplified and giving you centralized control over your network. It makes using commodity hardware much easier, there's a potential future there where you buy a commodity piece of equipment meeting the hardware specs you need, slot it in your network, it auto discovers the controller, and is automatically integrated into your topology, and so on. We ideally will see a Debian for routers that will run the limited openflow control plane and other things. I'm just having trouble envisioning how east/west can happen without standards, and standard seem somewhat antithetical to SDN which is all about enabling speed and flexibility. On 1/6/2013 4:08 PM, Dean Pemberton wrote:

Hi Andy

A valid question. If a route server was the end goal then a stand alone instance of Bird/Quagga/etc would have done the job just fine. The existing NZIX route servers run Quagga for example. The intention here is to use this as a milestone along the way to understanding what is possible on an IX once you have the entire fabric under OpenFlow control.

While the first steps have been to emulate the existing functionality, the real innovation opportunities will come once the fabric is extended to more locations. These are the areas that we are looking towards now, with work underway to bring additional locations online in the near future.

What could people be missing as exchange operators by not using these tools? Potentially nothing, potentially everything, depends on the operator and how rich a product they want to deliver from their exchange. I know there are IXP operators who are pushing lots of customer driven features into their exchanges, I also know some which treat their IX as just a dumb layer 2 network which people can establish BGP peering sessions over.

One of the issues is however that if you deploy them like that then you can get stuck in a place where it is difficult to deliver any value beyond that. Using traditional deployment models, you are limited to the features that a given vendor has enabled for you. In the most part this will be the set of features demanded by their largest customers, of which New Zealand never features. IXP operators then look at duct-taping features onto the side If you want to do something slightly (or heaven forbid, radically) different, then you end up shopping for a different vendor, or simply out of luck.

OpenFlow and SDN allow IXP owners to develop and deploy the set of features that they believe their customers require and drive innovation independent of how many of a vendor's customers may want that feature.

I like to think of SDN as the Open Source operating system of the networking world. If you can think it, you can build it. Linux has given us an ability to bring new ideas to life that Windows and OSX would never have allowed. It's not for everyone (or every situation) but in the right place, it's unparalleled. SDN is the same.

So back to what I was saying earlier. Maybe you're missing nothing by not using these tools. Maybe you already deliver all the functionality that your customers want. Equally likely though, you may have a whole lot of innovative ideas which you wish you could get implemented. In that case SDN might be a way forward.

I know where I'm heading.

Regards, Dean

On Sat, Jan 5, 2013 at 12:32 AM, Andy Davidson wrote:

...

This is really interesting, thanks for posting your news to the list.

Why did you decide to use an OpenFlow controller rather than Bird, Quagga or OpenBGPd as a route-server ? I am trying to understand your motivations and work out what I could be missing as an exchange operator using these tools.

Andy

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog