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

[Job Snijders <[e-mail]>]

On Sat, Nov 19, 2016 at 11:09:27PM +0100, Robert Raszuk wrote:
> Those who do not automate may not even look at the syslog at all. I
> those cases as Jared said adding it to sh bgp neig may help with the
> risk of having the screen scraping parsers broken.

Hypothetical operators come in all shapes and sizes, but we've had a
show of hands here from a set of actual operators who find this
functionality useful in their daily workflow, and expect their peers
would as well. 

There is a wide range of scenarios that are addressed by the proposal in
it's current form, including:
    
    * An engineer actively troubleshooting a router connected to a large
    Internet Exchange wishing to tell the rest of the peers a human is
    on it (and avoid the mail flood of "you're flapping!")

    * An automated system "enriching" the session termination with ticket
    related metadata to allow a user exploring a log to find context
    
    * A set of default messages that could be implemented by a vendor
    depending on which cli command triggered the shutdown to
    transparently enrich the remote side with information
    
It is essentially an incarnation of the old 'wall' command from UNIX,
with users substituted by peers, and the delivery mechanism being BGP.
The aim is to enable an inter-domain version of:

    # echo "brb, kernel update" | wall

Nothing more.
    
Any implications on screenscrapping are an artifact of implementation,
and vendors seeking a consistent machine-parsable CLI can send the
message directly into the log instead of modifying the output of a CLI
status description command. JunOS is a good example of how
screenscraping can be avoided with their "| output xml" feature.
Shutdown will be just another leaf in such XML output.

This proposal does not aim to solve all challenges of inter-domain
operations orchestration, but to specifically provide a tool to annotate
an unexpected event to ease the triaging process by a human operator. 

In its current form, it provides an ideal fit for this purpose, while
leaving enough flexibility to experiment with structured communications
for those who intend to use BGP for general inter-domain operations
orchestration signaling.

> As to what's the point of this discussion ... is to not change format
> of NOTFICATION as per 4271 yet define someting even if not structured
> to be machine readable.

We're updating 4486, please try to keep up.

Kind regards,

Job