Subject: Re: BFD MIB

From: Jeffrey Haas <[email-masked]>
Date: Sat, 20 Mar 2010 16:55:53 +0000

Vishwas,

I'm following up in teh context of version 09 of the BFD MIB.

On Tue, Nov 10, 2009 at 11:19:59AM -0800, Vishwas Manral wrote:
> This is regarding the BFD MIB version 07. I noticed that the sessions
> table has the objects bfdSessDesiredMinTxInterval and other session
> related parameters.
> 
> The issue with this is that because the sessions in BFD are actually
> triggered by protocols outside BFD and in BFD we are unaware of which
> sessions will be created, changing the values of the objects when the
> row create is triggered dynamically from other protocols is not
> possible.

I think you're referring to a few different things here:
1. There is no object that may be queried for an available index number to
   use as the bfdSessIndex.
2. System BFD applications may create BFD sessions where session parameters
   should be outside the control of SNMP SET operations.
3. The text for managing a BFD session via its logical row in the MIB is
   absent.  For example, what operations may be permitted via SNMP SET on
   objects without touching the row's RowStatus object. 

Is this correct?

> Looking at the Cisco CLI it seems to take the parameters on the
> interface basis too. Why is the MIB not aligned to the CLI (even
> though the authors themselves are from the company)?

Specific vendor aside, what do you see missing in the session table with
respect to interfaces?  

> Vishwas

-- Jeff

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 20 Mar 2010 16:31:51 -0700

hi jeff,

you are right. the point i have raised is sessiontable should be read
only in bfd. i do not know what it would mean to have a session row
without a protocol waiting for the session notification. this is one
of the basic flaws in the mib. sessions are learned dynamically and we
cannot configure a row for every possible session.

the second part is that we should allow objects to be configured on a
global or an interface basis so when a session is configured from a
protcol the default value of parameters is automatically inherited. on
seeing the cli from the vendor i mentioned its also done the way i
have mentioned.

i m at the ietf. let us discuss this if you are there too.

thanks,
vishwas

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 21 Mar 2010 12:49:08 +0000

Vishwas,

Unfortunately, I'm not at the current IETF session.

I will admit to some biases against SNMP configuration of protocols based on
my experiences with trying to find use cases for configuring BGP via a MIB.
However, I'm also aware of operators who *do* want things like OSPF
configurable via MIB.  Regardless of our own particular SNMP SET based
prejudices, we must answer two questions:

1. Given the protocol cases where BFD may be fully configured, does the MIB
   support this?
2. Given the protocol cases where BFD may have been configured outside of
   the SNMP system, does the MIB safely support configuration or manipulation
   of those sessions?

Speaking as co-chair of the group for a moment to the BFD MIB authors:  Do
you have specific use cases for SNMP configuration in mind in the BFD MIB?
If not, should we consider moving the bulk of the MIB to read-only?
(This question also goes out to members of the WG that may require MIB
configuration support.)

> cannot configure a row for every possible session.

I agree that we cannot do this for every possible session.  Protocols
requiring bootstrap of discriminator values MUST come from the outside of
MIB configuration.  Given this, what should the current sessiontable show?
One option that is reasonable within the context of SNMP would be to have
the logical row's StorageType be readOnly for rows created by sessions
requiring bootstrap.  Alternatively, permanent, would permit manipulation of
row variables but with potentially serious impacts upon the protocol.

As for "a protocol waiting for the session notification", it would be
reasonable for a protocol-specific MIB to have their session/neighbor/etc.
table AUGMENTed with a BFD peering table.  Such a table would likely have
an "enable BFD" object, and at least one more object which referred to the
bfdSessIndex of the associated BFD session.  Whether the configuration for
the BFD session was part of the augmentation table or in the base BFD MIB is
an implementation detail; I can see configuration scenarios both ways.  The
challenge for the MIB authors is to write text for the BFD MIB supporting
each use case.

By way of supporting the reverse mapping, the BFD MIB could also have a
RowPointer into the appropriate BFD protocol-specific portion of its MIB. 

> seeing the cli from the vendor i mentioned its also done the way i

While I agree that such mechanisms are operationally useful, they are also
vendor-specific forms of convenience.  At a SNMP table level, it is
indistinguishable to have interface-specific configuration templates and to
have the user enter each of the same values from the template into the
appropriate portion of the protocol MIB.  

Putting such templates into the base protocol MIB constrains the
implementation to have a specific form that may be inappropriate to a given
vendor.  In my opinion, that is out of scope for the BFD MIB but certainly
within scope of vendor support in an enterprise MIB.

-- Jeff

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 21 Mar 2010 11:11:40 -0700

Hi Jeff,

I guess now we are exactly on the same page.

Thanks for following up the comments given on the list. I am sure
there still are others which need to be looked at.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 21 Mar 2010 11:12:54 -0700

Hi Jeff,

Just to add, if you look at the LDP MIB and others we will find it
similar to what I have been saying. In LDP the concept is called
entities.

Thanks,
Vishwas

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 21 Mar 2010 12:09:55 -0700

Before we go down the road of configuration we should ask the WG if  
this is needed; it's a lot of work and most SPs queried in the past  
did not want SNMP configuration.

Tom

On Mar 21, 2010, at 11:12 AM, Vishwas Manral <[email-masked]>  
wrote:

> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral <[email-masked] 
> > wrote:
>> Hi Jeff,
>>

---

From: David Ward <[email-masked]>
Date: Sun, 21 Mar 2010 13:02:05 -0700

Tom -

We know for mpls-tp we'll need some way to configure bfd. Snmp or  
netconf or??? Will be required. Can you check the mpls-tp nms reqmts  
draft?

-DWard

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 21 Mar 2010 13:20:08 -0700

I will check but from memory all of the above are allowed.

Tom

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 21 Mar 2010 21:30:53 -0700

Hi Thomas,

If we ever want to allow non-default parameters for a session we have
to allow this.

It now depends whether we want that or not.

Thanks,
Vishwas

On Sun, Mar 21, 2010 at 12:09 PM, Thomas Nadeau <[email-masked]> wrote:
> Before we go down the road of configuration we should ask the WG if this is
> needed; it's a lot of work and most SPs queried in the past did not want
> SNMP configuration.
>
> Tom
>
>
>
>
> On Mar 21, 2010, at 11:12 AM, Vishwas Manral <[email-masked]> wrote:
>
>> Hi Jeff,
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 21 Mar 2010 22:10:16 -0700

That is only true if you assume configuration via Snmp.  While a  
possibility, configuration via other means will achieve the same  
result, and can be reflected in the MIB.

Tom

On Mar 21, 2010, at 9:30 PM, Vishwas Manral <[email-masked]>  
wrote:

> On Sun, Mar 21, 2010 at 12:09 PM, Thomas Nadeau <[email-masked] 
> > wrote:
>> this is
>>>>> I will admit to some biases against SNMP configuration of  
>>>>> protocols
>>>>> based on
>>>>> my experiences with trying to find use cases for configuring BGP  
>>>>> via a
>>>>> MIB.
>>>>> 1. Given the protocol cases where BFD may be fully configured,  
>>>>> does the
>>>>> MIB
>>>>>  support this?
>>>>> 2. Given the protocol cases where BFD may have been configured  
>>>>> outside
>>>>> of
>>>>> Speaking as co-chair of the group for a moment to the BFD MIB  
>>>>> authors:
>>>>>  Do
>>>>> you have specific use cases for SNMP configuration in mind in  
>>>>> the BFD
>>>>> MIB?
>>>>> requiring bootstrap of discriminator values MUST come from the  
>>>>> outside
>>>>> of
>>>>> MIB configuration.  Given this, what should the current  
>>>>> sessiontable
>>>>> show?
>>>>> One option that is reasonable within the context of SNMP would  
>>>>> be to
>>>>> have
>>>>> table AUGMENTed with a BFD peering table.  Such a table would  
>>>>> likely
>>>>> have
>>>>> an "enable BFD" object, and at least one more object which  
>>>>> referred to
>>>>> the
>>>>> bfdSessIndex of the associated BFD session.  Whether the  
>>>>> configuration
>>>>> for
>>>>> the BFD session was part of the augmentation table or in the  
>>>>> base BFD
>>>>> MIB is
>>>>> an implementation detail; I can see configuration scenarios both  
>>>>> ways.
>>>>>  The
>>>>> RowPointer into the appropriate BFD protocol-specific portion of  
>>>>> its
>>>>> MIB.
>>>>>
>>>>> While I agree that such mechanisms are operationally useful,  
>>>>> they are
>>>>> also
>>>>> indistinguishable to have interface-specific configuration  
>>>>> templates and
>>>>> to
>>>>> implementation to have a specific form that may be inappropriate  
>>>>> to a
>>>>> given

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 21 Mar 2010 22:20:22 -0700

Hi Tom,

I agree if we are talking about using CLI or other means to achieve
this we do not necessarily need the MIb to support the same.

However let me tell you, we have customers who want to configure the
same through MIB (that is one of the reasons we have gone into actully
supporting the MIB).

If you are at the IETF we can discuss this as well as all MPLS-TC MIB
which we need to correct and need a non disruptive way to do the same.

Thanks,
Vishwas

On Sun, Mar 21, 2010 at 10:10 PM, Thomas Nadeau <[email-masked]> wrote:
> possibility, configuration via other means will achieve the same result, and
> can be reflected in the MIB.
>
> Tom
>
>
>
>
> On Mar 21, 2010, at 9:30 PM, Vishwas Manral <[email-masked]> wrote:
>
>> Hi Thomas,
>>
>>>> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral
>>>> <[email-masked]>
>>>> wrote:
>>>>>
>>>>> Hi Jeff,
>>>>>
>>>>>> 1. Given the protocol cases where BFD may be fully configured, does
>>>>>> the
>>>>>> MIB
>>>>>>  support this?
>>>>>> indistinguishable to have interface-specific configuration templates
>>>>>> and
>>>>>> to

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Mar 2010 13:22:17 +0000

Vishwas/Tom,

> which we need to correct and need a non disruptive way to do the same.

After you've had your discussion, would you please follow-up to the mailing
list with the general outline of your proposed changes?

-- Jeff

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 23 Mar 2010 17:58:11 -0700

Hi Tom,

I found the second list of changes I had requested (I know most of the
comments on the first list have not been incorporated in the MIB).

Thanks,
Vishwas

On Wed, Nov 11, 2009 at 11:07 AM, Vishwas Manral <[email-masked]> wrote:
> Thanks Zafar. I agree with what Dave mentioned.
>
> Some top level things I have in mind right now besides what I
> mentioned in the mail are:
>
> 1. BFD session table is called bfdSessTable in some places and
> bfdSessionTable at others.
> 2. Take care of non IP BFD too.
> 3. BFD sessions can be single hop in one direction and multihop in others.
> 4. I think for Multiplier we could have a TC.
>
> -Vishwas
>
> On Wed, Nov 11, 2009 at 8:43 AM, Zafar Ali (zali) <[email-masked]> wrote:
>> Hi Vishwas-
>>
>> Acking your email. I am behind in my emails but will reply during next week.
>>
>> Re: earlier comments not addressed- can you please resend the comments? I may have lost them. We will reply and try to close on all of them during next week.
>>
>> Like Dave mentioned, we also need to align the BFD MIBs with the latest version of the base document in the next revision.
>>
>> Thanks
>>
>> Regards... Zafar
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Vishwas Manral
>>> Sent: Wednesday, November 11, 2009 11:30 AM
>>> To: Thomas Nadeau
>>> Cc: [email-masked]; David Ward
>>> Subject: Re: BFD MIB
>>>
>>> Hi Tom,
>>>
>>> Thats great.
>>>
>>> Do you have any comments on the questions I have raised? What
>>> about the other comments discussed on the list, have they
>>> been looked into?
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On Wed, Nov 11, 2009 at 4:06 AM, Thomas Nadeau
>>> <[email-masked]> wrote:
>>> >
>>> >        Thanks for the offer, but we have updated the
>>> document but missed the update deadline.
>>> >
>>> >        --Tom
>>> >
>>> >
>>> >> Hi David,
>>> >>
>>> >> Thanks. I think some of the comments on the list earlier have also
>>> >> not been incorporated either. As the MIB has expired I am
>>> not sure if
>>> >> the authors need help closing the MIB. Do let me know if you need
>>> >> help closing the document?
>>> >>
>>> >> Thanks again,
>>> >> Vishwas
>>> >>
>>> >> On Tue, Nov 10, 2009 at 4:53 PM, David Ward
>>> <[email-masked]> wrote:
>>> >>> Leaving aside the questions specific to a vendor, the MIB
>>> is out of
>>> >>> date after the changes to the specs following IESG
>>> review/comments
>>> >>> and needs another revision.
>>> >>>
>>> >>> -DWard
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>
>