[AusNOG] OpenFlow (was: Narelle with the first ever web server)

[Darren Ward (darrward)]

I think that's the general approach of all vendors implementing OpenFlow
- to open API's or SDK's rather than massive control plane and element
changes

 

There's a drive for a standard API interface as well so that the
management plane can function in a non-proprietary method as well,
though I imagine that will be in the standard process for a while but
ultimately that will provide some pretty interesting functionality

 

So we know at least two vendors going down this path ;)

 

From: ausnog-bounces at lists.ausnog.net
[mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Damien Holloway
Sent: Monday, 30 April 2012 6:19 PM
To: Glen Turner
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] OpenFlow (was: Narelle with the first ever web
server)

 

I do work for Juniper, but thought though to add 2c in case it wasnt
well known...

http://newsroom.juniper.net/press-releases/juniper-networks-delivers-ope
nflow-application-to--nyse-jnpr-0813497 

 

[Juniper] ... is making the source code that drives its OpenFlow
<http://www.openflow.org/wp/learnmore/>  application, built on the
Junos(r) Software Development Kit (SDK), accessible to its SDK
developers in order to expand the available toolset for enhancing
network flexibility and programmability. 

 

 

 

On Mon, Apr 30, 2012 at 1:04 PM, Glen Turner <gdt at gdt.id.au> wrote:

On 26/04/12 19:46, Narelle wrote:

> My issue is that if you don't build a framework that incorporates the
> various realms of network management, from the element management
layer
> up, it will be uncontrollable. Havocsville.

OpenFlow as a technology is useful for a few things:
 - Google are using it for better WAN traffic engineering
 - Big Switch Networks are using it to ease provisioning of
  data centre networking
 - it was invented to allow science users to avoid non-wirespeed
  middleboxes without compromising campus security
 - separating hardware and software, allowing the two to be
  purchased separately, hopefully for a much lower all-in cost.

Another of those things is very much reduce the number of management
touch points in a network. In that sense BGP/LDP/STP/OSPF/... is very
much the target. The aim being to reduce the engineering effort to
implement a network interior from one protocol per forwarding method per
forwarding device to one protocol per control plane (with many
forwarding devices). A hash-based protocol (as the P2P protocols quite
successfully use) is obviously the prime candidate for distributing
information between the OpenFlow controllers, leaving little remaining
role in a network interior for the current alphabet soup of control
plane protocols.

It's clear that OpenFlow will change network management -- from "monitor
what I have done" to "this is my design, deploy it, measure it, tune
it". With the implication that you'll never manually touch a
non-erroring network element.

I do think it's rather early to be asking for frameworks. Worryingly, I
am not sure we'll ever get them. One of the downsides of OpenFlow is
that there is much less need for interoperability specifications, as
interoperability isn't done at the protocol level. So paradoxically
vendor lock-in could increase rather than decrease -- except that you'll
be locked into your software supplier not your hardware supplier. (Cisco
and Juniper, this is why you want to put OpenFlow on your gear -- not to
allow other people's software to run, but to allow your software to work
on other people's gear, locking in your software revenue).

> Yes, it's meant to be a layer 1/2 solution but it is blowing
> away layers 3-4 (at least) in the process.

It probably best to think about OpenFlow as allowing programming access
to the TCAM. Just as a TCAM can forward frames by matching L2 or L3
headers against the TCAM contents then so can OpenFlow. But the
populating of that TCAM is under the control of a OpenFlow program. That
program need not use traditional L2 (STP, LDP) or L3 (OSPF, BGP)
considerations to populate the TCAM.

For example, you could use a OpenFlow program to inhibit traffic to a
Session Border Controller where the SBC hadn't seen any SIP traffic to
establish the call. The SBC manufacturer would provide the program and
it would use a possibly-undocumented protocol with the SBC. You can see
that deploying this feature then becomes more like systems
administration than network engineering (and whilst I am critical of
OpenFlow for ignoring the lessons learnt from large systems
administration, I think that software deployment is easier than network
engineering).

What is missing from OpenFlow at the moment is the ability to run
programs in the forwarding plane. It's clear that this is needed, if
only to parse upper layer headers. At the moment that needs to be done
by the TCAM forwarding those packets into the control plane. Of course
the control plane only has a limited bandwidth/latency to the forwarding
plane, and so in practice you can only get traffic statistically, not
parse every packet. Stats are enough for traffic engineering, but not
for all applications.

Personally, I am quite excited by the thought of OpenFlow+ -- my working
life has been blighted by woeful firewalls and OpenFlow with some
forwarding plane smarts gives a solid wirespeed, "real hardware" (not a
PC) foundation for firewall software.

I have thought about running a OpenFlow tutorial at the QUESTnet
conference, but I'm worried that I won't get the numbers to make it
worth the considerable effort to develop. Is there any interest in this
at an actual hands-on level?

Cheers, glen
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog





 

-- 
Regards

Damien
_______________________
Damien Holloway
+852 6793 0450 mobile



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20120430/4a2c751b/attachment.html>