On Thu, 27 Jan 2022 at 09:44, Mark Tinka wrote:
> What I do agree with is that the loss of control of operating your
> network yourself does present a risk. But that is a personal position,
Yes. Few comparisons are obviously and exclusively better or worse. It
is attractive to think of them as
On 1/27/22 09:32, Saku Ytti wrote:
I do disagree, if I understood the argument right. If the argument is
'cloud makes no business sense to anyone'.
I don't agree that cloud does not make business sense to anyone. There
is a reason why Amazon, Microsoft and Google are milking it right now,
On Thu, 27 Jan 2022 at 09:16, Mark Tinka wrote:
> > Saving 12 months of opex $ sounds great, except when you lose 18
> > months of opex $ in 2 days completely outside of your ability to control.
>
> I don't disagree.
>
> What this does, though, is democratize access into the industry. For a
>
On 1/26/22 23:04, Christopher Morrow wrote:
It seems like some of the situation is:
"5g/mobile builds include a bunch more 'general machine' resources
which offload a bunch of the work from what was dedicated appliances/etc."
Followed quickly by:
"Well, we don't have the resources/etc
On 1/26/22 21:38, Michael Thomas wrote:
I think for the vast majority of cloud users they'd do a way worse job
at uptime than the providers.
Indeed... I mean, we've seen it with the migration of on-premise
infrastructure into the cloud, en masse, for a number of "corporate"
services.
On 1/26/22 17:10, Tom Beecher wrote:
Those folks also tend to learn hard lessons about what happens when
the Magic Cloud provider fails in a way that isn't possible to
anticipate because it's all black box.
Saving 12 months of opex $ sounds great, except when you lose 18
months of opex
On Wed, Jan 26, 2022 at 2:37 PM Michael Thomas wrote:
>
> I think for the vast majority of cloud users they'd do a way worse job at
> uptime than the providers. Whether that applies to some telcos, I'm not
> sure.
>
>
It seems like some of the situation is:
"5g/mobile builds include a bunch
On 1/26/22 7:10 AM, Tom Beecher wrote:
For some folk, the risk of money cost outweighs the risk of loss of
direct operational control.
Those folks also tend to learn hard lessons about what happens when
the Magic Cloud provider fails in a way that isn't possible to
anticipate
Are you asking for commercial solutions? Free solutions? Open Source?
> On Jan 25, 2022, at 10:46 AM, David Bass wrote:
>
> Wondering what others in the small to medium sized networks out there are
> using these days for netflow data collection, and your opinion on the tool?
>
> Thanks!
Nick,
you can always choose to use nginx if you like, but there’s no reason anyone
else should be forced to.
-mel
On Jan 26, 2022, at 7:55 AM, Nick Suan via NANOG wrote:
While I agree that, yes everything SHOULD support TLS, there's a perfectly good
reason for terminating TLS in
While I agree that, yes everything SHOULD support TLS, there's a perfectly good
reason for terminating TLS in something like (nginx/caddy/apache/etc): X
number of things supporting TLS on their web interface means X number of ways
of configuring TLS. If I terminate it on nginx, there's only
People who advocate TLS lash-ups like nginx front ends remind me of Mr. Beans
DIY automobile security, which started with a screwed-on metal hasp and
padlock, and then continued to a range of additional “layers”. Not
“defense-in-depth”, merely unwarranted “complexity-in-depth”:
Or, when someone dies because their cell phone doesn’t work and can’t do a
simple 911 call anymore when AWS has yet another outage for 2 days.
All those pesky side effects of removing certain functionality that was once
handled locally…
Sent from my iPhone
> On Jan 26, 2022, at 8:11 AM, Tom
>
> For some folk, the risk of money cost outweighs the risk of loss of
> direct operational control.
>
Those folks also tend to learn hard lessons about what happens when the
Magic Cloud provider fails in a way that isn't possible to anticipate
because it's all black box.
Saving 12 months of
Wed, Jan 26, 2022 at 07:21:19AM -0600, Mike Hammett:
> Why is it [TLS] even necessary for such a function?
confidentiality and integrity, even if you do not care about authentication.
I am surprised that question is asked.
The fewer things that are left unprotected, the better for everyone.
On 1/26/22 16:41, Randy Bush wrote:
s/de-risk/re-risk/
it's just a different risk
I should have finished that sentence with "de-risk their infrastructure
spend", because the actual risk is in having to spend money upfront to
build the network.
For some folk, the risk of money cost
> If you stay away from getting stuck in the word "cloud", there is lots
> of value for folk that choose to de-risk their infrastructure,
s/de-risk/re-risk/
it's just a different risk
randy
Once upon a time, Laura Smith said:
> I don't know about anyone else here, but frankly in 2022 TLS support should
> be a first class citizen.
>
> If I have to mess around with running something else as a proxy in front of
> it then that's the end of my software evaluation.
>
> Crypto is no
On 1/26/22 15:29, Mike Hammett wrote:
Like most other things cloud, the value is going to be much harder to
find than the hype.
If you stay away from getting stuck in the word "cloud", there is lots
of value for folk that choose to de-risk their infrastructure, by
letting someone else run
Like most other things cloud, the value is going to be much harder to find than
the hype.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Message -
From: "Michael Thomas"
To: nanog@nanog.org
Sent:
Why is it even necessary for such a function?
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Message -
From: "Laura Smith via NANOG"
To: "nanog@nanog.org list"
Sent: Wednesday, January 26, 2022
‐‐‐ Original Message ‐‐‐
On Wednesday, January 26th, 2022 at 11:08, Eric Kuhnke
wrote:
> elastiflow is extremely easy to run on an httpd listening only on localhost
> and proxy behind a simple nginx TLS1.2/1.3 only configuration listening on
> port 443.
>
I don't know about anyone
elastiflow is extremely easy to run on an httpd listening only on localhost
and proxy behind a simple nginx TLS1.2/1.3 only configuration listening on
port 443.
as are a number of other tools.
On Tue, 25 Jan 2022 at 16:06, Laura Smith via NANOG wrote:
> On Tuesday, January 25th, 2022 at
23 matches
Mail list logo
