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

Job Snijders <job@ntt.net> Sat, 19 November 2016 19:41 UTC

Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD11295E6; Sat, 19 Nov 2016 11:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level:
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3th3N0hpOKN; Sat, 19 Nov 2016 11:41:44 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E7C129576; Sat, 19 Nov 2016 11:41:44 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1c8BW9-0008fl-SP (job@us.ntt.net); Sat, 19 Nov 2016 19:41:43 +0000
Date: Sat, 19 Nov 2016 20:41:38 +0100
From: Job Snijders <job@ntt.net>
To: "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Message-ID: <20161119194138.GG47336@dhcp-9d92.meeting.ietf.org>
References: <FBD63625-3E82-44AC-9318-D6B6DFE86082@domino.org> <CAO367rVSyeBcJnt8yogV27POyS3VwWGCqgmD3ex79dUPN-Misg@mail.gmail.com> <CA+b+ER=EFuQ8L_A4VtdzWna4ZNM-rhPo8gXURaN2s3WAykrL+w@mail.gmail.com> <CAO367rX9gBfNHgqmy0NqiNMGkjzLRATj6PdiDYk_M1fAQx5s8g@mail.gmail.com> <CA+b+ERkMsCGhyHsttjq0Pout0vrAvGQ6F+HaTxr8=78YMeRFOA@mail.gmail.com> <58306620.4000308@foobar.org> <319AD952-C571-4085-8D56-C06A51F021E3@domino.org> <CA+b+ERnQ8FQXxJ6No6GUr9mdp7APRkULqsGbKf5bAigp34TvmQ@mail.gmail.com> <CAO367rW_TuXsMNJBanAc2gL66TW8s4p2u5zDKfHER5rb1rk7-Q@mail.gmail.com> <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <058F756D-3A68-4AA6-A9DC-63A1BF9A5184@domino.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-gTcQBGSO5kcrArHX0rcOcyoV_4>
Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Nov 2016 19:41:45 -0000

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