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
On Tuesday, August 2, 2016, Kasper Adel <karim.adel@gmail.com> 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.
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 <cb.list6@gmail.com> wrote:
On Tuesday, August 2, 2016, Kasper Adel <karim.adel@gmail.com> 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.
On Tue, Aug 2, 2016 at 10:16 PM, Eric Kuhnke <eric.kuhnke@gmail.com> 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)
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 <tm mo> 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
On Wednesday, August 3, 2016, Randy Bush <randy@psg.com> 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 <tm mo> 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
On Wed, Aug 3, 2016 at 8:20 AM, Ca By <cb.list6@gmail.com> wrote:
On Wednesday, August 3, 2016, Randy Bush <randy@psg.com> 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 <tm mo> 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
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 <morrowc.lists@gmail.com
wrote:
On Wed, Aug 3, 2016 at 8:20 AM, Ca By <cb.list6@gmail.com> wrote:
On Wednesday, August 3, 2016, Randy Bush <randy@psg.com> 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 <tm mo> 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
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. Mark.
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, 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@slabnet.com pgp key: B178313E | also on Signal
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. :)
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 <cb.list6@gmail.com> wrote CB
Ps. Also, simpler > complex. Lots of $ in this statement.
participants (10)
-
Ca By -
Christopher Morrow -
David Barak -
Eric Kuhnke -
Hugo Slabbert -
jim deleskie -
Kasper Adel -
Mark Tinka -
Randy Bush -
Valdis.Kletnieks＠vt.edu