Subject: Monitoring BFD sessions

From: Havard Eidnes <[email-masked]>
Date: Tue, 30 Oct 2012 10:31:01 +0100 (CET)

Hi,

I'm maintaining a small software package we use to monitor
certain aspects of our network, and among them I'm monitoring BFD
session states, using a couple of vendors' interim versions of
the BFD MIB (implanted in their own enterprises tree for the time
being).

With one of the vendors I'm observing strange behaviour, in that
almost every time a BFD session goes through an operational
down->up state transition (after first going through an up->down
state transition), the implementation chooses a new BFD
discriminator for the session.

Furthermore, it looks as if the vendor is using the value of the
local discriminator when forming the bfdSessIndex value in the
MIB.

Thus, what my management software sees is that the old BFD
session is removed from the bfdSessTable, and a new entry is
instead created when the session gets reestablished.

I have tried to point out to the vendor that this makes it
extremely difficult to track the state of the BFD sessions
through the administrative lifetime of the sessions, in
particular to automatically measure the downtime duration for the
sessions, and have the "red" alarms for the downed BFD sessions
automatically go "green" when the session gets re-established.
The vendor in question (who shall reman nameless for the time
being), hides behind this clause in the BFD specification (RFC
5880, section 6.3) to defend the current behaviour:

   Note that it is permissible for a system to change its discriminator
   during a session without affecting the session state, since only that
   system uses its discriminator for demultiplexing purposes (by having
   the other system reflect it back).  The implications on an
   implementation for changing the discriminator value is outside the
   scope of this specification.

So my questions here are twofold:

1) Is there a problem with the specifications as written that
   allows an implementor to (in my opinion) totally de-value the
   usefulness of the bfdSessTable?
or

2) Is the implementor in question defending unreasonable
   behaviour which instead belongs in the "implementation bug"
   category?

Best regards,

- Håvard

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 30 Oct 2012 15:15:28 +0100

Hello Havard,

>   behaviour which instead belongs in the "implementation bug"

I think neither nor. The discriminator can change, so it's not a "good number" to be used when tracking the BFD session over a long time.

The information that should be the same for the same session is likely something as [interface, dest-ip-addr]. This uniquely defines your session.

Regards, Marc

--
Marc Binderberger           <[email-masked]>