Subject: MIB question - default BFD enable status?

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Aug 2005 16:16:52 -0400

Since I'm now freed from the tyrannies of my company's latest release, I'm
in the process of reviewing the various BFD specificiations.  One
of the questions that came up in during the MIB review was something
that input from the WG would be helpful for:

        bfdAdminStatus OBJECT-TYPE 
           SYNTAX   INTEGER { enabled(1), disabled(2) }         
           MAX-ACCESS   read-write 
           STATUS   current 
           DESCRIPTION 
              "The global administrative status of BFD in this router.  
               The value 'enabled' denotes that the BFD Process is 
               active on at least one interface; 'disabled' disables  
               it on all interfaces." 
           DEFVAL { enabled }  
           ::= { bfdScalarObjects 1 } 

Arguments can be made both ways for this feature to be enabled or disabled
by default.  I believe that, at least in the MIB, it should be disabled.

If you have an opinion, please bring it to the list.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Aug 2005 07:57:23 +0300 (EEST)

> by default.  I believe that, at least in the MIB, it should be disabled.

First off, is there usefulness in creating a read-write mib in the 
first place?

But even if we do, I don't think this global feature is even needed -- 
isn't it enough to have interface, protocol, or other status values 
which the operators can then snmpwalk through ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 11 Aug 2005 15:49:12 -0400

> First off, is there usefulness in creating a read-write mib in the  

     This is a great point, and one which I was hoping to raise (it was
one of Jeff's review comments).  I personally think that r-o is
fine.

> But even if we do, I don't think this global feature is even needed  
> -- isn't it enough to have interface, protocol, or other status  
> values which the operators can then snmpwalk through ?

     I know of at least one implementation that has BFD as a global
configuration.

     --Tom

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Aug 2005 07:54:59 +0300 (EEST)

On Thu, 11 Aug 2005, Thomas D. Nadeau wrote:
>> isn't it enough to have interface, protocol, or other status values which 
>> the operators can then snmpwalk through ?
>

Let's take an analogue.  Does the same implementation have a global 
configuration to enable/disable BGP?  BGP and BFD sessions seem like 
similar beasts, and similar management techniques apply.

I can only see (real) usefulness for session-based controls (and 
"enable BGP/BFD" toggle without session-specific config is quite 
questionable), but others might have different requirements so this 
isn't really a big issue to get too excited about.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 12 Aug 2005 07:46:03 -0400

On Aug 12, 2005, at 12:54 AM, Pekka Savola wrote:

>>> But even if we do, I don't think this global feature is even  
>>> needed -- isn't it enough to have interface, protocol, or other  
>>> status values which the operators can then snmpwalk through ?
>>>
>>
> configuration to enable/disable BGP?  BGP and BFD sessions seem  
> like similar beasts, and similar management techniques apply.

     I fail to see how that matters in the case of single-hop BFD.

> isn't really a big issue to get too excited about.

     When you are talking about single-hop BFD, it indeed
makes sense to configure per box and/or per interface (and
per session).

     --Tom

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Aug 2005 12:00:39 -0400

> isn't really a big issue to get too excited about.

I believe that the ability to configure BFD sessions from within
the MIB to probably be a dead-end.  In order for BFD to function
well it requires strong coordination with other protocols.  In other
words, it doesn't make a good stand-alone protocol.

Thus, as part of my MIB review comments to Tom, I'm suggesting that
many of the read-create aspects of the session table be removed or,
at best, be made read-write.

Arguments the other way would be appreciated during this review period.

-- 
Jeff Haas 
NextHop Technologies