I support the draft. I also support Jeff's idea to re-use existing sub-code(s).
1 possible comment: the length of the "Shutdown Communication" field seems implied from the length of the data field, rather than being explicitly indicated. If so, it seems that we are closing the possibility to advertise additional data/usage, in some future. What about adding a TLV format? Thanks, --Bruno > From: Jeffrey Haas Sent: Thursday, November 17, 2016 2:37 AM > To: Job Snijders > Cc: i...@ietf.org; grow@ietf.org > Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the > peer's syslog > at shutdown > > 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 > > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
