NFV Solution Evaluation Methodology

Thu Aug 4 15:23:42 UTC 2016

On Thu 2016-Aug-04 08:20:58 +0200, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>On 3/Aug/16 18:11, jim deleskie wrote:
>
>> I struggled with this whole SDN/NVF/insert marketing term for a while at
>> first, until I sat down and actually though about.  When I strip away all
>> the foo, what I'm left with is breaking things down to pieces and and
>> putting logo blocks together in a way that best suits what I'm doing.  It
>> is really going back to the way things were a long time ago in the days of
>> 12/2400 baud models and 56k frame relay.  It doesn't help vendors vendors
>> that want to sell you over priced foo for features you don't really need.
>> It lets you, if you have clue build your own right bits. It will see some
>> vendors evolve, new vendors of their brand of foo appear and some vendors
>> die, but end of day, its no different then most of were doing back in the
>> "good ol days"
>
>The way I see it, the whole SDN/NFV talk has finally devolved into
>automation (separating the control and data plane is sooooo 2013).
>
>Automation is not new - a lot of networks have been automating for a
>long time now, albeit in custom ways that only worked for them... ummh,
>rephrase: was not tested in other networks.
>
>The reason I see SDN/NFV becoming a thing is just to have a standard way
>of automating. That's it.

That somewhat mirrors my take on it.  At the risk of being flamed to hell, 
I see SDN/NFV being to network operations as DevOps/CI/CM/containers are to 
dev and systems.  Both are bringing in new tools and such, but ultimately 
they *require* solid automation and having your house (systems, processes 
workflow) in order to be able to deploy, with the hype train providing 
budget allocation and sufficient buy-in to get it to fly.

You can do network automation and service provisioning without NFV and 
centralized SDN controllers, and you can do CM and good tooling without 
going headlong into DevOps.  Obviously SDN/NFV and DevOps have their own 
pieces that layer on top of that (e.g.  control plane / forwarding plane 
separation and commoditization of the forwarding hardware in the former; 
development model and "culture" in the latter), and you have to sift 
through the hype and buzzword bingo to find what if any of that would 
deliver value in your environment.  But, that doesn't mean we can't benefit 
from the advances and possible standardization in tooling and automation 
that come along for the ride.

>
>Mark.

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160804/fa2a6414/attachment.sig>