<div class="gmail_extra">I do work for Juniper, but thought though to add 2c in case it wasnt well known...</div><div class="gmail_extra"><a href="http://newsroom.juniper.net/press-releases/juniper-networks-delivers-openflow-application-to--nyse-jnpr-0813497">http://newsroom.juniper.net/press-releases/juniper-networks-delivers-openflow-application-to--nyse-jnpr-0813497</a>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12px;line-height:18px;text-align:left;background-color:rgb(255,255,255)">[Juniper] ... is making the source code that drives its </span><a href="http://www.openflow.org/wp/learnmore/" style="padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;outline-style:none;outline-width:initial;outline-color:initial;color:rgb(161,72,161);text-decoration:none;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:initial;font-family:arial,sans-serif;font-size:12px;line-height:18px;text-align:left;background-color:rgb(255,255,255)">OpenFlow</a><span style="font-family:arial,sans-serif;font-size:12px;line-height:18px;text-align:left;background-color:rgb(255,255,255)"> 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.</span>
</div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12px;line-height:18px;text-align:left;background-color:rgb(255,255,255)"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12px;line-height:18px;text-align:left;background-color:rgb(255,255,255)"><br>
</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 1:04 PM, Glen Turner <span dir="ltr"><<a href="mailto:gdt@gdt.id.au" target="_blank">gdt@gdt.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 26/04/12 19:46, Narelle wrote:<br>
<br>
> My issue is that if you don't build a framework that incorporates the<br>
> various realms of network management, from the element management layer<br>
> up, it will be uncontrollable. Havocsville.<br>
<br>
OpenFlow as a technology is useful for a few things:<br>
 - Google are using it for better WAN traffic engineering<br>
 - Big Switch Networks are using it to ease provisioning of<br>
   data centre networking<br>
 - it was invented to allow science users to avoid non-wirespeed<br>
   middleboxes without compromising campus security<br>
 - separating hardware and software, allowing the two to be<br>
   purchased separately, hopefully for a much lower all-in cost.<br>
<br>
Another of those things is very much reduce the number of management<br>
touch points in a network. In that sense BGP/LDP/STP/OSPF/... is very<br>
much the target. The aim being to reduce the engineering effort to<br>
implement a network interior from one protocol per forwarding method per<br>
forwarding device to one protocol per control plane (with many<br>
forwarding devices). A hash-based protocol (as the P2P protocols quite<br>
successfully use) is obviously the prime candidate for distributing<br>
information between the OpenFlow controllers, leaving little remaining<br>
role in a network interior for the current alphabet soup of control<br>
plane protocols.<br>
<br>
It's clear that OpenFlow will change network management -- from "monitor<br>
what I have done" to "this is my design, deploy it, measure it, tune<br>
it". With the implication that you'll never manually touch a<br>
non-erroring network element.<br>
<br>
I do think it's rather early to be asking for frameworks. Worryingly, I<br>
am not sure we'll ever get them. One of the downsides of OpenFlow is<br>
that there is much less need for interoperability specifications, as<br>
interoperability isn't done at the protocol level. So paradoxically<br>
vendor lock-in could increase rather than decrease -- except that you'll<br>
be locked into your software supplier not your hardware supplier. (Cisco<br>
and Juniper, this is why you want to put OpenFlow on your gear -- not to<br>
allow other people's software to run, but to allow your software to work<br>
on other people's gear, locking in your software revenue).<br>
<br>
> Yes, it's meant to be a layer 1/2 solution but it is blowing<br>
> away layers 3-4 (at least) in the process.<br>
<br>
It probably best to think about OpenFlow as allowing programming access<br>
to the TCAM. Just as a TCAM can forward frames by matching L2 or L3<br>
headers against the TCAM contents then so can OpenFlow. But the<br>
populating of that TCAM is under the control of a OpenFlow program. That<br>
program need not use traditional L2 (STP, LDP) or L3 (OSPF, BGP)<br>
considerations to populate the TCAM.<br>
<br>
For example, you could use a OpenFlow program to inhibit traffic to a<br>
Session Border Controller where the SBC hadn't seen any SIP traffic to<br>
establish the call. The SBC manufacturer would provide the program and<br>
it would use a possibly-undocumented protocol with the SBC. You can see<br>
that deploying this feature then becomes more like systems<br>
administration than network engineering (and whilst I am critical of<br>
OpenFlow for ignoring the lessons learnt from large systems<br>
administration, I think that software deployment is easier than network<br>
engineering).<br>
<br>
What is missing from OpenFlow at the moment is the ability to run<br>
programs in the forwarding plane. It's clear that this is needed, if<br>
only to parse upper layer headers. At the moment that needs to be done<br>
by the TCAM forwarding those packets into the control plane. Of course<br>
the control plane only has a limited bandwidth/latency to the forwarding<br>
plane, and so in practice you can only get traffic statistically, not<br>
parse every packet. Stats are enough for traffic engineering, but not<br>
for all applications.<br>
<br>
Personally, I am quite excited by the thought of OpenFlow+ -- my working<br>
life has been blighted by woeful firewalls and OpenFlow with some<br>
forwarding plane smarts gives a solid wirespeed, "real hardware" (not a<br>
PC) foundation for firewall software.<br>
<br>
I have thought about running a OpenFlow tutorial at the QUESTnet<br>
conference, but I'm worried that I won't get the numbers to make it<br>
worth the considerable effort to develop. Is there any interest in this<br>
at an actual hands-on level?<br>
<br>
Cheers, glen<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards<br><br>Damien<br>_______________________<br>Damien Holloway<br>+852 6793 0450 mobile<br><br><br>
</div>