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

[Damien Holloway]

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-openflow-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® 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/031c82cb/attachment.html>