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 14:44 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 11B651293DC for <idr@ietfa.amsl.com>; Sat, 19 Nov 2016 06:44:19 -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 Y8Ta2VjnYl8R for <idr@ietfa.amsl.com>; Sat, 19 Nov 2016 06:44:18 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 086EB1288B8 for <idr@ietf.org>; Sat, 19 Nov 2016 06:44:18 -0800 (PST)
Received: by mail3.mlpsca01.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 1c86sI-0004YG-Gf (job@us.ntt.net); Sat, 19 Nov 2016 14:44:15 +0000
Date: Sat, 19 Nov 2016 15:44:08 +0100
From: Job Snijders <job@ntt.net>
To: "Neil J. McRae" <neil@domino.org>
Message-ID: <20161119144408.GC47336@dhcp-9d92.meeting.ietf.org>
References: <37224750-4065-40E3-B6F4-571DED698563@cisco.com> <20161119103226.GN1072@dhcp-9341.meeting.ietf.org> <CA+b+ERkAowcpeCL=_XEX1piNP__TVDdX3Lhvp8qYJSPvivoG1w@mail.gmail.com> <20161119123229.GD4992@skriver.dk> <20161119123645.GB2472@puck.nether.net> <CA+b+ERkFGfcD-RN29Uiynr3Wf3uG7irwk8MaBHxno2AnQ_6kjg@mail.gmail.com> <CAO367rVXN=SNwCEZh03NtM0eTaoSf39pcSaH-ayNsaaOxpi1Kg@mail.gmail.com> <CA+b+ERm=PhfFSBS+UEdKPxGXTvkXdJ-sLzn5d1y2NQ9KVo83NQ@mail.gmail.com> <CACWOCC-kMk3GrPah0AUeBfZJajKpQHU3Ls+yQsPW9JqSyQia-Q@mail.gmail.com> <1AF0DE87-6F3B-4DD7-B23F-AC570E7A088E@domino.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1AF0DE87-6F3B-4DD7-B23F-AC570E7A088E@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/kKnvfOwpavAma4kJFYC245Hz-7w>
Cc: idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
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 14:44:19 -0000

Hi Neil,

On Sat, Nov 19, 2016 at 02:17:14PM +0000, Neil J. McRae wrote:
> Free form is inefficient and will drive less useful outcomes. 
> 
> This becomes bloat because immediately I add to my peering policy that
> we will ignore all of these messages because I can't trigger action on
> them -  any message from the network I want to be able to automate
> something from it like an icon on a NOC display or other notification
> -perhaps that auto looks up the NOC phone number (although that's not
> likely these days!), search the recent emails from that AS; gets the
> peering DB record for that AS or a message that says ignore this cease
> for quantum X - 
> 
> Let's not even start about the language challenges this would present.
> Or the sales droids 1-800-Cheap-transit ;) 

You are free to ignore the free form Shutdown Communication, it is your
network. Your choice does not mean that the shutdown communication tool
should not exist for others who do want to use it.

Different networks are at different levels of automation, some might get
there and require more advanced tools, some don't. I dont think the
language challenges are real, with each of your BGP neighbors you'll
already have an agreement what the preferred language for communication
is. If you receive spam in the 128 octets of the Shutdown Communication,
you can consider shutting down the session on your side too.

Job