Subject: Re: BFD MIB minimizing notifications

From: Rajasekar Kumar <[email-masked]>
Date: Mon, 2 Sep 2013 13:41:41 +0530

Thanks Nobo. There is a possibility that Implementers might miss the point
that sequence of events should not be altered in notifications (or) events
should not be combined/fused when a different event was present in between.
I think this may not be obvious from existing text, especially if
implementer has not done this kind of optimization before. Could some text
be added along with an example in notifications section?

On Wed, Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) <[email-masked]> wrote:

> Hi Rajesekar,
>
> Unless implementation wants to intentionally suppress rapid state
> change(s) and back to original state, it would be incorrect to "fuse" same
> state for same index, meaning there'll be two "up" traps for index 2
> whether you optimize or not.
>
> Without optimization:
> - There will be 5 traps.
> - 1-up, 2-up, 3-up, 2-down, 2-up
>
> With optimization:
> - There will be 3 traps.
> - 1-2-3-up, 2-down, 2-up
>
> > What is considered as roughly the same time? How long should the
> > implementation wait in order to combine the status changes of multiple
> > sessions, before generating a notification?
>
> In general, I would guess that operators do not want the "wait" to be more
> than a second, two at the most.
>
> - Nobo
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Rajasekar Kumar
> > Sent: Wednesday, August 28, 2013 6:26 AM
> > To: [email-masked]
> > Subject: BFD MIB minimizing notifications
> >
> > Hi
> > I am looking at bfdSessUp & bfdSessDown notifications. Draft mentions the
> > below.
> >              "For the
> >              cases where a contiguous range of sessions
> >              have transitioned into the up(4) state at roughly
> >              the same time, the device SHOULD issue a single
> >              notification for each range of contiguous indexes in
> >              an effort to minimize the emission of a large number
> >              of notifications."
> > What is considered as roughly the same time? How long should the
> > implementation wait in order to combine the status changes of multiple
> > sessions, before generating a notification?
> > If I assume that the implementation should wait for some amount of time,
> > the following problem exists.  Suppose there are sessions with indexes
> 1, 2,
> > 3. All of them move to UP state within the waiting time.  Before expiry
> of
> > waiting time, if session index 2 quickly moves to DOWN, then again to
> > UP,  bfdSessUp trap will be generated first for session indexes 1,2,3.
> After
> > this, bfdSessDown will be generated for session index 2.  The result is:
> the
> > order of traps was reversed (With optimization, the order is UP, then
> DOWN
> > trap.  But without optimization, the order would be UP, DOWN, UP)
> > Please let me know if I am missing something.
> > Thanks
> > Rajasekar
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 3 Sep 2013 15:03:10 +0000

Hello Rajasekar,

Think of this trap as a box that takes output form BFD module (state changes) and generates corresponding SNMP notifications. Each SNMP notification allows inclusion of multiple messages (state changes) to minimize number of total SNMP notifications generated. It should, however, be well understood that no messages should be misplaced by this box. "combined/fused" really means this box has misplaced some messages. As for adding more texts, I'm actually not convinced adding lengthy explanations for this aspect will benefit much when it becomes fairly clear once fundamental purpose of BFD MIB is understood by the reader.

With that said, your comment is appreciated.

-Nobo

From: Rajasekar Kumar [mailto:[email-masked]]
Sent: Monday, September 02, 2013 4:12 AM
To: Nobo Akiya (nobo)
Cc: [email-masked]
Subject: Re: BFD MIB minimizing notifications

Thanks Nobo. There is a possibility that Implementers might miss the point that sequence of events should not be altered in notifications (or) events should not be combined/fused when a different event was present in between. I think this may not be obvious from existing text, especially if implementer has not done this kind of optimization before. Could some text be added along with an example in notifications section?

On Wed, Aug 28, 2013 at 7:03 PM, Nobo Akiya (nobo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rajesekar,

Unless implementation wants to intentionally suppress rapid state change(s) and back to original state, it would be incorrect to "fuse" same state for same index, meaning there'll be two "up" traps for index 2 whether you optimize or not.

Without optimization:
- There will be 5 traps.

With optimization:
- There will be 3 traps.
- 1-2-3-up, 2-down, 2-up

> sessions, before generating a notification?
In general, I would guess that operators do not want the "wait" to be more than a second, two at the most.

- Nobo

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> To: [email-masked]<mailto:[email-masked]>
> the following problem exists.  Suppose there are sessions with indexes 1, 2,
> 3. All of them move to UP state within the waiting time.  Before expiry of
> UP,  bfdSessUp trap will be generated first for session indexes 1,2,3. After
> this, bfdSessDown will be generated for session index 2.  The result is: the
> order of traps was reversed (With optimization, the order is UP, then DOWN