[190951] in North American Network Operators' Group
Re: NFV Solution Evaluation Methodology
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Thu Aug 4 11:23:47 2016
X-Original-To: nanog@nanog.org
Date: Thu, 4 Aug 2016 08:23:42 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Mark Tinka <mark.tinka@seacom.mu>
In-Reply-To: <51fc7ceb-ed11-4b88-64ee-d88925399908@seacom.mu>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu 2016-Aug-04 08:20:58 +0200, Mark Tinka <mark.tinka@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,=
=20
I see SDN/NFV being to network operations as DevOps/CI/CM/containers are to=
=20
dev and systems. Both are bringing in new tools and such, but ultimately=
=20
they *require* solid automation and having your house (systems, processes=
=20
workflow) in order to be able to deploy, with the hype train providing=20
budget allocation and sufficient buy-in to get it to fly.
You can do network automation and service provisioning without NFV and=20
centralized SDN controllers, and you can do CM and good tooling without=20
going headlong into DevOps. Obviously SDN/NFV and DevOps have their own=20
pieces that layer on top of that (e.g. control plane / forwarding plane=20
separation and commoditization of the forwarding hardware in the former;=20
development model and "culture" in the latter), and you have to sift=20
through the hype and buzzword bingo to find what if any of that would=20
deliver value in your environment. But, that doesn't mean we can't benefit=
=20
=66rom the advances and possible standardization in tooling and automation=
=20
that come along for the ride.
>
>Mark.
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--kfjH4zxOES6UT95V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJXo13+AAoJEFsnhBAb2KmA1ToP/0RYpA8ocd30y0eMi9zXS1Rs
Tzc/1Qdc8Rr48FYqPR4M7ohQhbBSdlqe/vD0Ne4EbIE05FhXvfQ1iycUWcpu8Mck
Y5zT1Wimqb81MJZOEDhpq+w3HA3iCeBnO2wTsaLHz0l81OM/VapSCNEjp2pV/jJu
f+3bShafPTo4xSoEzmsUcX7/M4UGWENAljbpZAKq5vYeIlByNQTko4eyECDTRT1P
rt/mMPgT16j99AH9yxXLICx3W4PykQ683OU6uMbmUjgK8/C9mIb8hcRlcBDThNxS
ihzwzLOm6HHxSkuPRvnOE4NJ05pc3K5aqbICu5Xpfj+cdbeT3kmrrLKtgea/ZtUC
CyuoaOmCg/hQ39Oqwr/WdUJVnt/sapHvf7Z137pqeeN3pPH3GyGiuajYqMr2v6ad
BfVMv6FuXWjqNXbVaoUz02J7Fsq+zTBmLdRCNh1m9uIntQGryrIFBvhENmJws39q
djKA3GPFoeYiVW7FAatAiD99jDOhCLkehI0lc3XRa7fnMNhhA48L2nn/1aHtsckk
A2QN2B7pGdo0kbc4D0kvh95Fl15RLIvIjwXpfc3O6ENaNf6EAfzO+h4I6kv4ZgNk
Eb0/rRmdVzvKaHajQAf2fYklITMc/Dp3Pmdyi9J2MdK1yTIEXjO1P1DJMDtl5Kro
AS1V2et74ctyEayUKdto
=OKhJ
-----END PGP SIGNATURE-----
--kfjH4zxOES6UT95V--
