IEEE: Software-defined Networks

[Louis Mamakos]

Can it happen?  Sure.  Can you live with it happening?  Huh, maybe, maybe not.

There's something else that's been around, called G-MPLS.  This extends MPLS traffic
engineering done in packets switches into the optical transport layer.  The fantasy is 
that when you want to provision a flow, and there's not enough capacity on the existing
trunks between your routers, then the whole mechanism can cause new optical paths
through an agile optical transport network to spring into existence and poof!  You can break
lots more stuff, all at once.

Ok, so you can maybe convince yourself it all "works", but if you have a problem that
large in a carrier network, sometimes the organization is shaped differently enough
that the guys running the optical transport are disjoint from the guys running the
layer-2/3 MPLS/IP networks.  Having boundaries is a good thing, especially when the
economics and operational realities are very different. 

SDN could be very useful, under the right circumstances and use cases.  But it doesn't
magically change the economics of running a large network.  It does potentially unchain
the software feature set for crazy stuff you want to do from hardware vendors, but in 
exchange for that, you also get finger-pointing.  Maybe that's OK, but you have to
manage it.

Like the G-MPLS thing, there's all these possible features and capabilities, but
what subset of those are useful commercially for the market to adopt vs. doing
a Ph.D. thesis on?  Still early days in many respects.  It brings a powerful capability
to your toolset, but you have to make sure you don't put an eye out trying to use it.

louie
wa3ymh


> On Dec 11, 2014, at 6:44 PM, Alex Fraser <beatnic at comcast.net> wrote:
> 
> Rob are you saying it will never happen or it can't happen now (with the current state of the art)?
> 
> Rob Seastrom wrote on 12/9/2014 5:00 PM:
>> 
>> Andre Kesteloot <akesteloot at gmail.com> <mailto:akesteloot at gmail.com> writes:
>> 
>>> [[http://theinstitute.ieee.org/static/special-report-software-defined-networks <http://theinstitute.ieee.org/static/special-report-software-defined-networks>]]
>> At work we professional cynics often make joking reference to
>> "Software Defiled Networks".  People like to talk about magic fairy
>> lands where the application signals the network as to how much
>> bandwidth it needs and then gets it provisioned on the fly.  The
>> unfortunate reality is that the developers have no idea what happens
>> on the other side of their API call.  Down that path lies trouble
>> tickets that say things like "I asked you for 100 Mbit/second and ping
>> is only showing 40 milliseconds.  What's wrong?".
>> 
>> Particularly in IEEE-land, for obvious reasons, they think of SDN in
>> terms of layer-2 pipes and OpenFlow.  That's the wrong way to think of
>> SDN.  The right way to think of it is in terms of business-as-usual
>> networking with database-driven configuration pushing.  For the love
>> of God don't separate your control plane from your data plane - yes,
>> they did it in SS7, but that's about a bajillion orders of magnitude
>> less complex than running an IP network.
>> 
>> It's occasionally useful to be able to make packets flow against
>> gravity, such as in load balancing and network monitoring
>> applications.  It's a great way to deploy firewall rules across your
>> network (and hopefully not shoot yourself in the foot in the process).
>> In short, automation tools with humans doing the steering.
>> 
>> In some ways we've been doing "SDN" for years.  BGP-based realtime
>> blacklists have been around for over 15 years.  SNMP (paleo-SDN if you
>> think of it in the right terms) is closer to 25.  Then there's the
>> DOCSIS OAMP interface which has been around for 15 years or so and
>> allows the $12/hr phone representitive to provision your cablemodem
>> while-u-wait.
>> 
>> In short, ignore the hype.
>> 
>> Layer 3 - It Scales.
>> 
>> -r
>> 
>> _______________________________________________
>> Tacos mailing list
>> Tacos at amrad.org <mailto:Tacos at amrad.org>
>> https://amrad.org/mailman/listinfo/tacos <https://amrad.org/mailman/listinfo/tacos>
>> 
> 
> 
>  -- 
>    \\\\\\\\\\\\\\\\-----++++*0*++++-----//////////////////
>        No electrons were harmed in the creation of this message
>          --------------------------------------------------------
>  ~~~********************Alex Fraser********************~~~
>          --------------------------------------------------------
> [[[[[[~~^^^#___=>>>```/\/\**O**/\/\```<<<=___#^^^~~]]]]]]
> _______________________________________________
> Tacos mailing list
> Tacos at amrad.org
> https://amrad.org/mailman/listinfo/tacos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://amrad.org/pipermail/tacos/attachments/20141211/fe10695f/attachment.html>