Re: [Idr] combining drafts SOFT-NOTIFY, INFORM and ADVISORY

[John Leslie <john at jlc.net>]

Ilya Varlashkin <Ilya.Varlashkin at de.easynet.net> wrote:
> 
> operating mid-sized network that spans the globe I see good value in
> having at hands additional info to why certain BGP-related events took
> place. All three drafts (SOFT-NOTIFY, INFORM and ADVISORY) can provide
> this info and in my opinion should be considered for further refinement
> within IDR.

   I tend to agree...

> In my experience more often than not NOC folk try to determine "did this
> session go down because something broke on our side?

   An excellent question...

> on peer side? did peer close session because of planned or emergency
> work? or was is inconsistent configuration between two sides?".

   et cetera...

> Based on the same experience if broken session was result of human
> intervention I doubt that involved person would write significantly more
> useful info than automatically generated message could provide. Yes they
> could write "taking this session down because we need to replace line
> card", but they're likely just to write "emergency work" if anything at
> all.

   Hard to say for sure... I'd like to give them the opportunity.

> On the other hand, router's software could generate predefined message
> and send it to peer if user action will result in session reset or shut
> down. This would be both easier for the side performing work (they don't
> need to type much), and benefical for the peer (they know at least state
> change was due to user action on the other side). Additional free-text
> message would be welcome, but not mandatory.

   Agreed.

> SOFT-NOTIFY draft provides good foundation for implementing automation
> part of what's described above.

   Unfortunately, SOFT-NOTIFY opens several cans of worms by keeping a
session open which currently would be terminated -- meaning that many a
NOC crew will ignore the problem. :^(

> Integrating ADVISORY draft functionality into SOFT-NOTIFY (via new or
> existing TLV) could provide additional info to operators.

   I don't think that is the intent of the folks clamoring for ADVISORY.

> For example, if I shutdown session(s) before planned/emergency work on
> the router by issuing "set neighbor X shutdown', then router can send
> SOFT-NOTIFY message to the peer "session shut down on operator request"
> (probably in standard encoded rather than free-text form).

   That function seems useful, whether or not it involves SOFT-NOTIFY.

> If I'm nice operator I could provide additional info to peer by using
> optional argument to the above command: "set neighbor X shutdown
> 'emergency work. restore eta 15min".

   An implementation detail, of course, but useful, IMHO.

> I would support a draft that adds above described functionality but
> only as integrated solution rather than separate drafts for automated
> router-generated notifications and human-written text.

   I see substantial benefit to a functionality which enables both
automated status-change codes and "human-readable free text".

> Additionally, I think free-form text should not be limited to ASCII-
>only english letters but instead should either use unicode or be at
> least 8-bit transparent (based on previous experience in non-latin
> environment).

   Beware! Internationalization continues to prove itself hard in
practice. We really should permit ASCII-only implementations even if
we go as far as "SHOULD support Unicode."

> Could we, idr wg, not merge all three mentioned drafts into single one
> for combined functionality? 

   I wouldn't object, but consensus to do so hasn't appeared yet.

--
John Leslie <john at jlc.net>