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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
