On 28/Jan/20 09:45, Saku Ytti wrote:
> We should learn to crawl before we take rocket to proxima centauri.
Agreed!
>
> You don't need ML/AI to find problems in your network, using algorithm
> 'this counter which increments at rate X stopped incrementing or
> started to increment 100 times s
On 27/Jan/20 22:30, adamv0...@netconsultings.com wrote:
> Very good point Robert,
> There are indeed two parts to the whole automation story
> (it' obvious that this theme deserve a series of blog posts, but I keep on
> finding excuses).
>
> The analogy I usually use in presentations is the l
On 27/Jan/20 00:18, Robert Raszuk wrote:
>
> Without proper automation in place going way above basic IGP, BGP,
> LDP, BFD etc ... you need a bit of clever automation to detect it and
> either alarm noc or if they are really smart take such router out of
> the SPF network wide. If not you sit a
On 26/Jan/20 22:46, adamv0...@netconsultings.com wrote:
> You nailed it Mark,
> My opinion is that this new NetDevOps/NetOps initiative is the biggest
> blunder of the networking industry.
> If as a network engineer/architect you have some coding skills well good for
> you,
> But are programmin
On Tue, 28 Jan 2020 at 11:19, Robert Raszuk wrote:
> So at t0+N I record how many packets entered my system. (We are already at
> loss here as RE can generate packets unless you add to this RE outbound
> packets). Then at t0+N+uS (uS) delta of switching via fabric you record
> number of packe
> And I think almost no one is collecting data in such a manner
> that it's actually capitalisable, because we can keep running the
> network with how how we did in 90s, IF-MIB and netflow, in separate
> systems, with no encrichement at all.
Spot on !
Btw Saku - you keep suggesting measuring delt
On Mon, 27 Jan 2020 at 22:30, wrote:
> Then nowadays there's also the possibility to enable tons upon tons of
> streaming telemetry -where I could see it all landing in a common data lake
> where some form of deep convolutional neural networks could be used for
> unsupervised pattern/feature l
> From: Robert Raszuk
> Sent: Sunday, January 26, 2020 10:18 PM
>
> Hi Adam,
>
> I would almost agree entirely with you except that there are two completely
> different reasons for automation.
>
> One as you described is related to service provisioning - here we have full
> agreement.
>
> The
On Mon, 27 Jan 2020 at 00:18, Robert Raszuk wrote:
> The other one is actually of keeping your network running. Imagine router
> maintaining entire control plane perfectly fine, imagine BFD working fine to
> the box from peers but dropping between line cards via fabric from 20% to 80%
> traffi
Hi Adam,
I would almost agree entirely with you except that there are two completely
different reasons for automation.
One as you described is related to service provisioning - here we have full
agreement.
The other one is actually of keeping your network running. Imagine router
maintaining enti
> Mark Tinka
> Sent: Friday, January 24, 2020 2:32 PM
>
> On 24/Jan/20 12:10, Saku Ytti wrote:
>
> > In my opinion we do roughly the same thing, the same way in networks,
> > with the same protocols since my start of career in 90s, very little
> > has changed and you could drop competent neteng f
On 24/Jan/20 12:10, Saku Ytti wrote:
> In my opinion we do roughly the same thing, the same way in networks,
> with the same protocols since my start of career in 90s, very little
> has changed and you could drop competent neteng from 90s to today and
> they'd be immediately productive. Compare
On Fri, 24 Jan 2020 at 10:33, Mark Tinka wrote:
> Since about 2012, every time we've felt we've come close to finding an
In my opinion we do roughly the same thing, the same way in networks,
with the same protocols since my start of career in 90s, very little
has changed and you could drop compe
13 matches
Mail list logo
