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

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 6 Jul 2009 12:20:57 +0200

Hi,

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. In my experience more often than not NOC folk try to
determine "did this session go down because something broke on our side?
on peer side? did peer close session because of planned or emergency
work? or was is inconsistent configuration between two sides?". 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. 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.

SOFT-NOTIFY draft provides good foundation for implementing automation
part of what's described above. Integrating ADVISORY draft functionality
into SOFT-NOTIFY (via new or existing TLV) could provide additional info
to operators. 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). 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". This messages could then
be retreived by peer's NOC when they do 'show bgp neighbor X' and will
save both sides effort of handling emails to clarify situation. Even if
the operator doesn't provide extra free-form info, the auto-generated by
router message would already indicate to NOC that session was brought
down intentionally. Details of whether to provide such functionality as
sticky messages could be worked out during draft refinement process.

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

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

Cheers,
iLya

---

From: John Leslie <[email-masked]>
Date: Mon, 6 Jul 2009 14:50:39 -0400

Ilya Varlashkin <[email-masked]> wrote:
> 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...

> 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

   Agreed.

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

> for combined functionality? 

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

--
John Leslie <[email-masked]>