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

Jeffrey Haas <jhaas@pfrc.org> Thu, 17 November 2016 02:23 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 731BB1294B5 for <idr@ietfa.amsl.com>; Wed, 16 Nov 2016 18:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lOYSlpl8KXLO for <idr@ietfa.amsl.com>; Wed, 16 Nov 2016 18:23:00 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BE4931293D6 for <idr@ietf.org>; Wed, 16 Nov 2016 18:23:00 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 07E591E369; Wed, 16 Nov 2016 21:25:56 -0500 (EST)
Date: Wed, 16 Nov 2016 21:25:56 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Job Snijders <job@ntt.net>
Message-ID: <20161117022556.GA10478@pfrc.org>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org> <20161117013640.GB6217@pfrc.org> <20161117014215.GI22270@dhcp-9341.meeting.ietf.org> <20161117014701.GE6217@pfrc.org> <20161117015731.GK22270@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20161117015731.GK22270@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yFDwP3_9eh_hedIpsGfft_NHAm8>
Cc: idr@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 02:23:02 -0000

On Thu, Nov 17, 2016 at 10:57:31AM +0900, Job Snijders wrote:
> On Wed, Nov 16, 2016 at 08:47:01PM -0500, Jeffrey Haas wrote:
> > No new subcodes.
> > Add the text to the NOTIFICATION Data section of existing subcodes, when it
> > makes sense and that Data section isn't otherwise specified.
> 
> What will existing, deployed implementations do if they get trailing
> data after a subcode 2? Can you comment on Juniper JunOS?

In a small number of cases where it understands the contents, e.g. max
prefix, hard reset (long lived graceful restart), unsupported capability, it
will print something useful.  Otherwise, it's Data: <hexdump>.

This behavior is generally useful since it means specs like this can happen
and the contents can happen and you can still get some visibility.  I
heartily recommend the practice.

> 
> Equally:
> 
> What will existing, deployed implementations do if they encounter a
> cease subcode they don't recognise? ExaBGP would emit 'unknow reason'.

Same, displaying the subcode and any Data.

Anyway, my general point is the subcodes have existing semantics.  Use those
as much as makes sense.

-- Jeff