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

[Jeffrey Haas <[e-mail]>]

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

Ones that possibly shouldn't be changed:


:         1        Maximum Number of Prefixes Reached

This one is fully specified.

:         4        Administrative Reset

I'm not sure returning something here makes sense.  This seems to be more
the "clear bgp neighbor" case.  Unless you think adding information about
why the user did the clear makes sense.

:         5        Connection Rejected

Here's where things get a little odd.  You should get one of the other
subcodes on clear.  If you're preventing it from coming back up, this code
may be returned.  This means that even if you're storing the last received
string, it might be overwritten by this.

:         7        Connection Collision Resolution
:         8        Out of Resources

I suspect these shouldn't return anything.

> 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. 

IMO, they more likely failed as low priority features that couldn't get past
product managers.

If, especially the existing code points are re-used and don't alter existing
implementation conformance, I suspect this draft would be closer to a
trivial modification that has a better chance of getting shipped quickly.

I also have to ask about:

:    As of today these vendors have produced an implementation of the
:    Shutdown Communication:
: 
:    o  ExaBGP

And exactly which code point did you squat on to do the prototype? ;-)

(I'm not exactly concerned about this since it's local in impact but you'd
think after the discussions this week...)

-- Jeff