On Thu, Mar 13, 2025 at 01:48:57PM +0000, John Scudder wrote:
> Hi All,
>
> MIBs aren’t in my comfort zone and I’m having a hard time sussing this one
> out. I hope one of the authors, or someone with more clue than me, will take
> a look.
I think there's an error here, but the fix is not correct.
> One point is that the DESCRIPTION says "bfdSessDiag MUST both be set equal to
> this new state (i.e., up(4)).” But if I track down what the defined values
> are for bfdSessDiag, what I find is
>
> bfdSessDiag OBJECT-TYPE
> SYNTAX IANAbfdDiagTC
>
> And if I track down IANAbfdDiagTC in RFC 7330, it doesn’t have up(4) as a
> defined value, rather we have forwardingPlaneReset(4).
>
> If we want to set up(4), that’s defined in IANAbfdSessStateTC which maps to
> bfdSessState.
Correct. You've divined part of the problem.
> But then the description goes on to talk about "The two instances of
> bfdSessDiag in this notification indicate the range of indexes that are
> affected”. which doesn’t appear to make sense either in the context of
> bfdSessDiag or bfdSessState, and I suppose is what led the submitter to
> propose bfdSessIndex.
The thing that isn't intuitively obvious here is that SNMP objects are
key/value sets. The indices for a bfdSessState, Diag, etc. are:
bfdSessEntry OBJECT-TYPE
SYNTAX BfdSessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The BFD Session Entry describes the BFD session."
INDEX { bfdSessIndex }
::= { bfdSessTable 1 }
This means that two instances for the corrected sessState, or even the old
buggy sessDiag will contain different indices in their OID which define the
range.
> Finally, if there is a bug to be fixed here at all, it presumably needs to be
> fixed in bfdSessDown too.
That'd be correct.
Now, to read deeply between the lines to see if the intention was really to
use sessDiag or sessState in the objects.
> > Original Text
> > -------------
> > bfdSessUp NOTIFICATION-TYPE
> > OBJECTS {
> > bfdSessDiag, -- low range value
> > bfdSessDiag -- high range value
> > }
> > STATUS current
> > DESCRIPTION
> > "This notification is generated when the
> > bfdSessState object for one or more contiguous
> > entries in bfdSessTable are about to enter the up(4)
> > state from some other state. The included values of
> > bfdSessDiag MUST both be set equal to this
> > new state (i.e., up(4)). The two instances of
As you note above, up isn't a valid value for sessDiag, but for sessState.
A motivation for wanting the Diag value is it gives you some contents of
what is in the protocol's Diag field during the transition. This is far
more valuable for Down than Up.
Additionally, inlcuding sessState in the objects doesn't add any additional
value in the notification because the notification itself is of a type
indicating that we're going up/down.
So, what I think is we have a pair of issues but I'd prefer more input from
the other authors of the MIB:
1. sessDiag is probably correct for the reasons above.
2. The text shouldn't be talking about the values of sessDiag being Up.
However, insisting that the sessions tied to the sessIndex values reported
in both instances being Up is appropriate.
It'd probably also be useful to survey current implemenations to see what
objects are included. My bet would be the sessDiag is what is done even if
the description is off.
-- Jeff
