Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Peter Hessler <[e-mail]>]

On 2016 Nov 19 (Sat) at 20:26:25 +0000 (+0000), Neil J. McRae wrote:
:I just wish I thought we had the luxury of lazy operations like this!
:

I have about 4 peers where they have exactly this kind of lazy
operators.  Some of them are big enough to know better.

I want this, because they at least look at the "show neighbor" output
before freaking out and spamming all of our support contacts.


:Neil 
:
:> On 19 Nov 2016, at 19:41, Job Snijders <[e-mail]> wrote:
:> 
:>> On Sat, Nov 19, 2016 at 05:23:15PM +0000, Neil J. McRae wrote:
:>> It's a wonderfully useless solution when it could be a wonderfully
:>> useful solution - it's just more  operational noise that we already
:>> have and we will start filtering like everything else. 
:> 
:> What's really useless is hyperbole argumentation. :-) Don't forget to
:> recognise that your network operations might differ from how other
:> people operate their network.
:> 
:> A common pattern:
:> 
:>    supplier: "2 weeks from now at 18:00 UTC we will do maintenance XYZ on router ABC, this work is tracked in V-NOC-24789244"
:>    *two weeks pass*
:>    *supplier starts the work*
:>    *customer sees BGP session with router ABC go down*
:>    customer calls supplier's NOC: "hey my session is down, whats up!?"
:> 
:> If in the above scenario the customer had seen "V-NOC-24789244 maintenace started" in their syslog (where they started their
:> investigation), the customer would search for the V-NOC-24789244 string
:> in their mailbox and all details would become clear. I think this is
:> useful and a good starting point.
:> 
:> I suspect that where Neil is coming from, the customer would have
:> already parsed the maintenance notification 2 weeks before the
:> maintenance work, and added that to their organisational-wide calendar,
:> pre-silenced alerts, drained the traffic away, etc.
:> 
:> The "shutdown" draft is not a replacement for efforts such as
:> https://www.maintenancemanager.org/ - but maybe, when "shutdown" is more
:> ubiquitously available, it could be a component in such maintenance
:> manager toolchains.
:> 
:> Maybe in 2 or 3 years time we'll revisit the topic and based on that
:> operational experience define a taxonomy and create a structured
:> approach. Maybe the structured approach will be entirely out-of-band
:> (companies posting yang to each others' maintenance API endpoints?).  I
:> think the free form approach is an excellent starting point to see (and
:> immediately benefit) how a tool like this is used in the wild.
:> 
:> Kind regards,
:> 
:> Job


-- 
It's bad luck to be superstitious.
		-- Andrew W. Mathis