Hi All,
AFAICT from the conversation so far the erratum is incorrect as written.
However, it looks to me as if there should be a correction to the DESCRIPTION
instead. Specifically,
OLD:
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
NEW:
state from some other state. The current values of
bfdSessDiag MUST be included. The two instances of
If I’ve gotten it wrong (very likely) please help me get it right. (And if I’ve
gotten it right please say so!)
(And then the same again for bfdSessDown.)
Thanks,
—John
> On Mar 16, 2025, at 3:11 PM, Jeffrey Haas <[email protected]> wrote:
>
> Goutham,
>
> On Sun, Mar 16, 2025 at 10:45:24AM +0530, .Goutham V Jain wrote:
>> Hi All,
>> The current issue with using SessDiag or SessState as the objects in
>> the notification, we would only know the state of the session. But It will
>> not help the trap receiver identify the exact session which has seen a
>> transition in state. With Session Index in the trap object, the trap
>> receiver will be free to fetch the specific OID or the complete row to
>> indicate the current status of the BFD Session to the end user.
>
> Sorry if my text below isn't clear. Please run a SNMP GET for BFD to help
> you understand this if this additional text isn't helpful.
>
> If you were to fetch a specific instance of bfdSessDiag, since it is in a
> table, it uses an index for each instance.
>
> The index for this table is the bfdSessIndex.
>
> Thus, the two objects returned in the notification are two leaf instances of
> a bfdSessDiag, which includes the bfdSessIndex in its OID. You thus have
> the bfdSessIndex as part of the key for each object (the start and the end
> range) and the value for that OID for each of those instances.
>
> While it may be more intuitive to have simply sent two bfdSessIndex objects
> so that the value of the two object OIDs is the start and end of the range,
> the practice of using other objects where the index is embedded in the table
> as a notification object is common SNMP MIB practice to provide more
> information.
>
> -- Jeff
>
>>
>> Thanks
>> Goutham
>>
>> On Sat, Mar 15, 2025 at 5:11 PM Jeffrey Haas <[email protected]> wrote:
>>
>>>
>>> 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
>>>
