Re: NFV Solution Evaluation Methodology

[Hugo Slabbert]

On Thu 2016-Aug-04 08:20:58 +0200, Mark Tinka  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 so 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: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: NFV Solution Evaluation Methodology

[Mark Tinka]

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 so 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.

Mark.

Re: NFV Solution Evaluation Methodology

[jim deleskie]

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"

-jim

On Wed, Aug 3, 2016 at 11:27 AM, Christopher Morrow  wrote:

> On Wed, Aug 3, 2016 at 8:20 AM, Ca By  wrote:
>
> >
> >
> > On Wednesday, August 3, 2016, Randy Bush  wrote:
> >
> >> > but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
> >> > appliance garbage that can't scale in a cost effective manner and
> >> > replacing it with some software solution on 'many' commodity
> >> > unix-like-hosts that can scale horizontally.
> >>
> >> my main worry about nfv is when they need more forwarding horsepower
> >> than the household appliance  has, and the data plan is is moved
> >>
> >
> this is a scaling problem, and one which points to the need to not do 'all
> of one thing' ('all nfv will solve us!') you may still need other methods
> to load balance or deal with loads which are higher than the nfv
> platform(s) can deal with properly.
>
> In some sense this is the same problem as trying to push too many pps
> through a linecard which you know has a limit lower than line-rate.
>
>
> > out of the control plane and they are not congruent.  we've had too many
> >> lessons debugging this situation (datakit, atm, ...).
> >>
> >>
> seperation of data/control plane ... does require knowledge about what you
> are doing and has clear implications on toolling, troubleshooting, etc.
>
> To some extent this mirrors anycast dns deployment problems. "I made a much
> more complex system, though from the outside perhaps it doesn't appear any
> different." be prepared for interesting times.
>
>
> > Sdn is like authoritarianism and divine creation rolled up into one and
> > sold at 20% premium to easily duped telco types that want to travel to
> > endless conferences
> >
> >
> Sure, you have to know what you are doing/buying... magic doesn't exist in
> this space.
>
>
> >
> >
> >> beyond that, i am not sure i see that much difference whether it's a
> >> YFRV or a SuperMicro.  but i sure wish bird and quagga had solid is-is,
> >> supported communities, ...
> >>
> >> randy
> >>
> >
>

Re: NFV Solution Evaluation Methodology

[Christopher Morrow]

On Wed, Aug 3, 2016 at 8:20 AM, Ca By  wrote:

>
>
> On Wednesday, August 3, 2016, Randy Bush  wrote:
>
>> > but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
>> > appliance garbage that can't scale in a cost effective manner and
>> > replacing it with some software solution on 'many' commodity
>> > unix-like-hosts that can scale horizontally.
>>
>> my main worry about nfv is when they need more forwarding horsepower
>> than the household appliance  has, and the data plan is is moved
>>
>
this is a scaling problem, and one which points to the need to not do 'all
of one thing' ('all nfv will solve us!') you may still need other methods
to load balance or deal with loads which are higher than the nfv
platform(s) can deal with properly.

In some sense this is the same problem as trying to push too many pps
through a linecard which you know has a limit lower than line-rate.


> out of the control plane and they are not congruent.  we've had too many
>> lessons debugging this situation (datakit, atm, ...).
>>
>>
seperation of data/control plane ... does require knowledge about what you
are doing and has clear implications on toolling, troubleshooting, etc.

To some extent this mirrors anycast dns deployment problems. "I made a much
more complex system, though from the outside perhaps it doesn't appear any
different." be prepared for interesting times.


> Sdn is like authoritarianism and divine creation rolled up into one and
> sold at 20% premium to easily duped telco types that want to travel to
> endless conferences
>
>
Sure, you have to know what you are doing/buying... magic doesn't exist in
this space.


>
>
>> beyond that, i am not sure i see that much difference whether it's a
>> YFRV or a SuperMicro.  but i sure wish bird and quagga had solid is-is,
>> supported communities, ...
>>
>> randy
>>
>

Re: NFV Solution Evaluation Methodology

[Ca By]

On Wednesday, August 3, 2016, Randy Bush  wrote:

> > but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
> > appliance garbage that can't scale in a cost effective manner and
> > replacing it with some software solution on 'many' commodity
> > unix-like-hosts that can scale horizontally.
>
> my main worry about nfv is when they need more forwarding horsepower
> than the household appliance  has, and the data plan is is moved
> out of the control plane and they are not congruent.  we've had too many
> lessons debugging this situation (datakit, atm, ...).
>
>

YES!  This 1,000x.

The internet is a very interesting place when viewed from the lense of
Automata theory, greedy self optimizing nodes very similar to
biological systems (including economics ). Very robust since each node is
greedy and self optimizing in its decision making power.  This a
fundamental component of the Internet's suceess.

Some folks talk about sdn controllers and seperating control plane and
forwarding plane. This breaks the ability for nodes to self optimize and
thus undermines a key component of the robustness. It also diverts of the
parallels of biological systems.  Control and forwarding had beeb separate
on the node for almost 20 years now.

Sdn is like authoritarianism and divine creation rolled up into one and
sold at 20% premium to easily duped telco types that want to travel to
endless conferences



> beyond that, i am not sure i see that much difference whether it's a
> YFRV or a SuperMicro.  but i sure wish bird and quagga had solid is-is,
> supported communities, ...
>
> randy
>

Re: NFV Solution Evaluation Methodology

[Randy Bush]

> but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
> appliance garbage that can't scale in a cost effective manner and
> replacing it with some software solution on 'many' commodity
> unix-like-hosts that can scale horizontally.

my main worry about nfv is when they need more forwarding horsepower
than the household appliance  has, and the data plan is is moved
out of the control plane and they are not congruent.  we've had too many
lessons debugging this situation (datakit, atm, ...).

beyond that, i am not sure i see that much difference whether it's a
YFRV or a SuperMicro.  but i sure wish bird and quagga had solid is-is,
supported communities, ...

randy

Re: NFV Solution Evaluation Methodology

[David Barak via NANOG]

Simpler > complex *sometimes*.   It turns out that sometimes the complexity is 
worth it (eg https://youtu.be/-iiXsbrEv3U ).  Perhaps "as simple as possible, 
by no simpler" would be reasonable?

David Barak
Sent from mobile device, please excuse autocorrection artifacts

> On Aug 2, 2016, at 7:08 PM, Ca By  wrote
> CB
> 
> Ps. Also, simpler > complex. Lots of $ in this statement.

Re: NFV Solution Evaluation Methodology

[Valdis . Kletnieks]

On Tue, 02 Aug 2016 19:16:04 -0700, Eric Kuhnke said:
> But but but...  cloud!  THE CLOUD!  Cloudy clouds fluffy white flying
> through the air, you should move everything to the Cloud (tm).

Running the stuff you need to keep your own network running on the cloud?
That's the sort of thing I encourage my competitors to do. :)


pgpkOvBdLFLyb.pgp
Description: PGP signature

Re: NFV Solution Evaluation Methodology

[Christopher Morrow]

On Tue, Aug 2, 2016 at 10:16 PM, Eric Kuhnke  wrote:

> But but but...  cloud!  THE CLOUD!  Cloudy clouds fluffy white flying
> through the air, you should move everything to the Cloud (tm).
>
> Sometimes people forget that *somebody* needs to run the bare metal and OSI
> layer 1 things that physically make up the cloud.
>
>
mr by isn't wrong there are lots of ... over sold things.
but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
appliance garbage that can't scale in a cost effective manner and replacing
it with some software solution on 'many' commodity unix-like-hosts that can
scale horizontally.

-chris
(just a chemical engineer... really)

Re: NFV Solution Evaluation Methodology

[Eric Kuhnke]

But but but...  cloud!  THE CLOUD!  Cloudy clouds fluffy white flying
through the air, you should move everything to the Cloud (tm).

Sometimes people forget that *somebody* needs to run the bare metal and OSI
layer 1 things that physically make up the cloud.


On Tue, Aug 2, 2016 at 7:08 PM, Ca By  wrote:

> On Tuesday, August 2, 2016, Kasper Adel  wrote:
>
> > Hi,
> >
> > I am interested in hearing the approach and thought-process that senior
> > people on NANOG are following when presented with an NFV solution.
> Assuming
> > that the exercise at hand is to consider NFV for future expansions of
> > Firewalls and L3VPNs or stay with the existing model of what is called
> PNF
> > (physical network function)...i.e : classic routers and FWs.
> >
> > There are a lot of factors to consider and Vendors will typically give
> > their biased opinion, so i'm trying to get my head out of their game, to
> be
> > able to think agnostically about the whole thing.
> >
> > 1) Product and Service/Support Cost.
> > 2) Operation Complexity/Learning Curve. (open source products included).
> > 3) X Factors (Those that are never listed but do bite in the back) :
> > Quality, Integration with Classic, Migration, Usability...etc
> >
> > The main goal behind us exploring NFV is the promised cost-saving, so a
> > good method to be able to do the math of whether NFV will save opex/capex
> > or NOT is definitely needed here and i'm trying to gather guidelines from
> > the list.
> >
> > I think its easier to keep this post high-level, and later dig deeper.
> >
> > Cheers,
> > K
> >
>
> Sorry , just a junior person here. Maybe a sr can pipe up later.
>
> But my business cases and associated data points show NFV like SDN
> are snake oil.
>
> If you know your requirements, buy / implement the best value solution. You
> can call it NFV if that makes you feel better.
>
> There is nothing new under the sun. Running DNS or bgp on linux cough... is
> not a new thing.
>
> If you are google or fb and have the best software engineers in the world,
> you can express your requirements to your dev team and they can just build
> it. And support it.
>
> But i see a lot of folks paying premium for sdn/nfv and tooting their own
> horns ... but the needle is not moving
>
> Buyer beware. Ymmv.
>
> CB
>
> Ps. Also, simpler > complex. Lots of $ in this statement.
>

Re: NFV Solution Evaluation Methodology

[Ca By]

On Tuesday, August 2, 2016, Kasper Adel  wrote:

> Hi,
>
> I am interested in hearing the approach and thought-process that senior
> people on NANOG are following when presented with an NFV solution. Assuming
> that the exercise at hand is to consider NFV for future expansions of
> Firewalls and L3VPNs or stay with the existing model of what is called PNF
> (physical network function)...i.e : classic routers and FWs.
>
> There are a lot of factors to consider and Vendors will typically give
> their biased opinion, so i'm trying to get my head out of their game, to be
> able to think agnostically about the whole thing.
>
> 1) Product and Service/Support Cost.
> 2) Operation Complexity/Learning Curve. (open source products included).
> 3) X Factors (Those that are never listed but do bite in the back) :
> Quality, Integration with Classic, Migration, Usability...etc
>
> The main goal behind us exploring NFV is the promised cost-saving, so a
> good method to be able to do the math of whether NFV will save opex/capex
> or NOT is definitely needed here and i'm trying to gather guidelines from
> the list.
>
> I think its easier to keep this post high-level, and later dig deeper.
>
> Cheers,
> K
>

Sorry , just a junior person here. Maybe a sr can pipe up later.

But my business cases and associated data points show NFV like SDN
are snake oil.

If you know your requirements, buy / implement the best value solution. You
can call it NFV if that makes you feel better.

There is nothing new under the sun. Running DNS or bgp on linux cough... is
not a new thing.

If you are google or fb and have the best software engineers in the world,
you can express your requirements to your dev team and they can just build
it. And support it.

But i see a lot of folks paying premium for sdn/nfv and tooting their own
horns ... but the needle is not moving

Buyer beware. Ymmv.

CB

Ps. Also, simpler > complex. Lots of $ in this statement.

NFV Solution Evaluation Methodology

[Kasper Adel]

Hi,

I am interested in hearing the approach and thought-process that senior
people on NANOG are following when presented with an NFV solution. Assuming
that the exercise at hand is to consider NFV for future expansions of
Firewalls and L3VPNs or stay with the existing model of what is called PNF
(physical network function)...i.e : classic routers and FWs.

There are a lot of factors to consider and Vendors will typically give
their biased opinion, so i'm trying to get my head out of their game, to be
able to think agnostically about the whole thing.

1) Product and Service/Support Cost.
2) Operation Complexity/Learning Curve. (open source products included).
3) X Factors (Those that are never listed but do bite in the back) :
Quality, Integration with Classic, Migration, Usability...etc

The main goal behind us exploring NFV is the promised cost-saving, so a
good method to be able to do the math of whether NFV will save opex/capex
or NOT is definitely needed here and i'm trying to gather guidelines from
the list.

I think its easier to keep this post high-level, and later dig deeper.

Cheers,
K