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

Job Snijders <job@ntt.net> Thu, 17 November 2016 03:06 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 88E83129855; Wed, 16 Nov 2016 19:06:38 -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 hj_-M-XEWJy9; Wed, 16 Nov 2016 19:06:36 -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 8AF6B129478; Wed, 16 Nov 2016 19:06:36 -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 1c7D23-000FXw-93 (job@us.ntt.net); Thu, 17 Nov 2016 03:06:36 +0000
Date: Thu, 17 Nov 2016 12:06:32 +0900
From: Job Snijders <job@ntt.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Message-ID: <20161117030632.GO22270@dhcp-9341.meeting.ietf.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20161117013640.GB6217@pfrc.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/iNaMcNyzjTXqM4FeTUiiAMujT3w>
Cc: idr@ietf.org, grow@ietf.org
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: Thu, 17 Nov 2016 03:06:38 -0000

On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > Some might wonder, why "Cease"?
> > 
> > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > message type already allows extra data to be attached, so for most
> > implementations it will be very simple to bolt what is specified in
> > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > cases we are looking at just a handful of lines.
> 
> As I commented elsewhere, changing subcodes ends up being painful from
> a conformance standpoint.  I would honestly not recommend a new
> subcode.
> 
> BGP implementations usually deal with the notification data section
> that may not have information in a format they recognize by simply
> ignoring or making the contents available in something like
> hexadecimal prints.
> 
> What I would suggest is simply take the RFC 4486 subcodes that don't
> already return additional information (e.g. max prefix) and simply add
> this shutdown reason as the data.  From the list of code points,
> here's the ones I would suggest updating:
> 
> :         2        Administrative Shutdown
> :         3        Peer De-configured
> :         6        Other Configuration Change

> <snipped the codes that aren't suitable for decoration>

I checked with Jakob, according to him IOS XR won't choke on a cease
subcode 2 if there is trailing data.

The UI or configuration concept of some operating systems might have
trouble properly sending a 'cease "Peer De-configured"' with trailing
data, so I'd skip that one for now. Same applies for 'other
configuration change'.

>From the looks of it, we can retrofit 'shutdown' under subcode 2 and
forgo requesting a new cease subcode. I think I'd leave 3 and 6 as they
are.

Does anyone object to using subcode 2 for draft-snijders-idr-shutdown-01?

The length of the NOTIFICATION will signal whether there is a shutdown
communication or not.

Kind regards,

Job