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

Greg Hankins <ghankins@mindspring.com> Wed, 16 November 2016 14:54 UTC

Return-Path: <ghankins@mindspring.com>
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 74B5C129639; Wed, 16 Nov 2016 06:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=ghankins@mindspring.com header.d=mindspring.com
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 t-vfpc_OOh-h; Wed, 16 Nov 2016 06:54:36 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DB112940C; Wed, 16 Nov 2016 06:54:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=khhOqeneRQnEkxSxVyO5aQiZ72dnoJ96kSviK4IaHKH9fX+8wN8w8n7FE2lRLOAw; h=X-Authentication-Warning:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-ELNK-Trace:X-Originating-IP;
Received: from [24.125.34.202] (helo=deathraid.twoguys.org) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <ghankins@mindspring.com>) id 1c71bO-0004h7-1F; Wed, 16 Nov 2016 09:54:18 -0500
Received: from deathraid.twoguys.org (localhost.twoguys.org [127.0.0.1]) by deathraid.twoguys.org (8.14.4/8.12.11) with ESMTP id uAGEsGnD027576; Wed, 16 Nov 2016 09:54:16 -0500
Received: (from ghankins@localhost) by deathraid.twoguys.org (8.14.4/8.14.4/Submit) id uAGEsGF3027575; Wed, 16 Nov 2016 09:54:16 -0500
X-Authentication-Warning: deathraid.twoguys.org: ghankins set sender to ghankins@mindspring.com using -f
Date: Wed, 16 Nov 2016 09:54:16 -0500
From: Greg Hankins <ghankins@mindspring.com>
To: Job Snijders <job@ntt.net>
Message-ID: <20161116145416.GA27144@nokia.com>
References: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20161116061556.GG1073@dhcp-9341.meeting.ietf.org>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4d140ed259708326c51d3c05d63f5b6c31350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.125.34.202
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/185-yTBD2eaiUuXDrXJnrJzO6zY>
Cc: idr@ietf.org, grow@ietf.org
Subject: Re: [Idr] 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: Wed, 16 Nov 2016 14:54:39 -0000

I like the idea, and I think it solves an immediate network operator problem.
I also like the concept of keeping it simple.  

There are a few ongoing efforts to standardize maintenance
notificatications[1], so I suggest that the format and content of the
message be explicitly noted as out of scope and left to the operator.
Though there shouldn't be anything to prevent the operator from using a
common maintenance notification format.

Greg

[1] This one comes to mind:
https://www.peering-forum.eu/system/documents/40/original/20150923_1000_barry_odonmovan_EPF10-INEX-B_ODonovan-MaintenanceNotifications_final.pdf
https://www.maintenancemanager.org/

-- 
Greg Hankins <ghankins@mindspring.com>

-----Original Message-----
Date: Wed, 16 Nov 2016 15:15:56 +0900
From: Job Snijders <job@ntt.net>
To: grow@ietf.org, idr@ietf.org
Subject: [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's
	syslog at shutdown

Hi GROW,

>From an operational perspective it is really useful if you can drop a
line in the peer's syslog which covers why you shutdown a BGP session.
A common use case is to provide a reference between the shutdown event
and an emailed maintenance notification, or maybe you want to make an
emotional statement.

Fictional IOS example:

	o00.frnkge02.de.bb#conf t
	Enter configuration commands, one per line.  End with CNTL/Z.
	o00.frnkge02.de.bb(config)#router bgp 65001
	o00.frnkge02.de.bb(config-router)#neighbor 129.250.6.5 shutdown "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb"

Fictional OpenBGPD example:

	[job@kiera ~]$ bgpctl neighbor down AS15562_scarlett_IPv6 "I hate you, depeered"
	request processed
	[job@kiera ~]$

In the above examples, the other side might find something like this in
their logs:

	Nov 16 00:20:41 frankfurt-router 589711: RP/0/RSP0/CPU0:Nov 16 00:20:41.653 : bgp[1059]: %ROUTING-BGP-5-ADJCHANGE : neighbor X.Y.Z.A Down - Peer closing down the session (VRF: default) (AS: 35994) (Shutdown Communication: "Maintenance [V-NOC-248244242] software upgrade o00.frnkge02.de.bb")

or perhaps:

	Nov 16 06:59:50 herpaderp bgpd[99938]: neighbor 165.254.255.1 (AS15562_scarlett_IPv4): received notification: Cease, shutdown communication: "I hate you, depeered"

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.

Out of all the moments in the lifecycle of BGP interactions, I believe
that the 'shutdown' moment is the most critical one to decorate with
some freeform text. This is low hanging fruit and as should be treated
accordingly. There other moments where one might want to chat with the
neighbor, but those are out of scope for this document, you can always
call or email them!

Previous attempts such as draft-ietf-idr-advisory-00 and
draft-ietf-idr-operational-message-00 failed to deliver for various
reasons (feature creep comes to mind), therefore we are trying to do
this as simple as possible. 

Kind regards,

Job


----- Forwarded message from internet-drafts@ietf.org -----

Date: Tue, 15 Nov 2016 21:30:15 -0800
From: internet-drafts@ietf.org
To: Jakob Heitz <jheitz@cisco.com>, Job Snijders <job@ntt.net>, John Scudder <jgs@juniper.net>
Subject: New Version Notification for draft-snijders-idr-shutdown-00.txt

A new version of I-D, draft-snijders-idr-shutdown-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:		draft-snijders-idr-shutdown
Revision:	00
Title:		The Shutdown Communication BGP Cease Notification Message subcode 
Document date:	2016-11-15
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-snijders-idr-shutdown-00.txt
Status:         https://datatracker.ietf.org/doc/draft-snijders-idr-shutdown/
Htmlized:       https://tools.ietf.org/html/draft-snijders-idr-shutdown-00


Abstract:
   This document defines the BGP Cease NOTIFICATION message "Shutdown
   Communication" subcode for operators to transmit a short freeform
   message to describe why a BGP session was shutdown.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr