Subject: Re: BFD MIB

From: venkatesan mahalingam <[email-masked]>
Date: Fri, 27 Aug 2010 00:36:48 +0530

Hi,
Can you please update the latest information on this mail thread?

IMO, instead of duplicating the BFD session specific informations (Tx,
Rx intervals, BFD mode, Authentication types, session role, etc.,) at the
client application (MPLS, RSVP) level, like bfdSessIpMapTable (IP map table
for session), we can have tables for LSP map table, PW map table, MPLS-TP
MEG/MEP map tables at the BFD mib itself.

Any thoughts?

This will reduce the burden for client applications and no need to inherit
the client application specific default BFD config. parameters while the
client application triggers the BFD session.

If we follow this, we may have to see the BFD session running for neighbor,
LSP, PW, MEG/MEP at the BFD level, not at the client application level.
I think, this should be OK.

Having the BFD session triggering from the BFD table and the client
application level triggering will certainly introduce the burden on the
users of the application.

We may have limited configuration options at the application level, this may
force the user to modify the client triggered BFD session at the BFD level
for additional configurations OR user may directly configure the BFD mibs
with all the configuration options at the BFD level for applications, we may
need to indicate the BFD session index to the application.

Which mode (BFD mib triggered/Client application triggered/both) is
recommended for LSP/PW/MEG level proactive monitoring?

Thanks,
Venkat.
To: Vishwas Manral <vishwas.ietf at gmail.com>
Subject: Re: BFD MIB
From: Jeffrey Haas <jhaas at pfrc.org>
Date: Sun, 21 Mar 2010 12:49:08 +0000
Cc: rtg-bfd at ietf.org
Delivered-to: rtg-bfd at core3.amsl.com
In-reply-to: <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com>

List-archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-help: <mailto:[email-masked]?subject=help<[email-masked]?subject=help>>

List-id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>

List-post: <mailto:[email-masked] <[email-masked]>>
List-subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <
mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>>

List-unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <
mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>>

References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a at mail.gmail.com>
<20100320165553.GC31380 at slice>
<77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com>
User-agent: Mutt/1.5.18 (2008-05-17)

--------------------------------------------------------------------------------

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.)

On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote:
> 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.

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.

> 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.

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

-- 
Best Regards,
Venkatesan Mahalingam.