<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So we know at least two vendors going down this path ;)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ausnog-bounces@lists.ausnog.net [mailto:ausnog-bounces@lists.ausnog.net] <b>On Behalf Of </b>Damien Holloway<br><b>Sent:</b> Monday, 30 April 2012 6:19 PM<br><b>To:</b> Glen Turner<br><b>Cc:</b> ausnog@lists.ausnog.net<br><b>Subject:</b> Re: [AusNOG] OpenFlow (was: Narelle with the first ever web server)<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I do work for Juniper, but thought though to add 2c in case it wasnt well known...<o:p></o:p></p></div><div><p class=MsoNormal><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> <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif";background:white'>[Juniper] ... is making the source code that drives its </span><a href="http://www.openflow.org/wp/learnmore/"><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#A148A1;border:none windowtext 1.0pt;padding:0cm;background:white;text-decoration:none'>OpenFlow</span></a><span style='font-size:9.0pt;font-family:"Arial","sans-serif";background:white'> 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> <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Apr 30, 2012 at 1:04 PM, Glen Turner <<a href="mailto:gdt@gdt.id.au" target="_blank">gdt@gdt.id.au</a>> wrote:<o:p></o:p></p><p class=MsoNormal>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><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>-- <br>Regards<br><br>Damien<br>_______________________<br>Damien Holloway<br>+852 6793 0450 mobile<br><br><o:p></o:p></p></div></div></body></html>