Subject: Re: BFD MIB

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 2 Sep 2010 17:04:27 +0530

Hi All,
Could you please reply to this query?

BR,
Venkat.
On Fri, Aug 27, 2010 at 12:36 AM, venkatesan mahalingam <
[email-masked]> wrote:

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

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 6 Sep 2010 22:35:56 -0700

Hello Venkat, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of venkatesan mahalingam
> Sent: Thursday, September 02, 2010 8:34 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: BFD MIB
> 
> Hi All,
> On Fri, Aug 27, 2010 at 12:36 AM, venkatesan mahalingam 
> <[email-masked]> wrote:
> 
> 
> 	Hi,
> 	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?

Absolutely. MIB support for MPLS BFD is something which is pending.

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

Leaving aside MPLS context, can you elaborate on what is needed beyond
what is already there?

Thanx,
Nobo

> 	 
> 	Thanks,
> 	Venkat.
> 	To: Vishwas Manral <vishwas.ietf at gmail.com 
> <http://gmail.com/> > 
> 	Subject: Re: BFD MIB 
> 	From: Jeffrey Haas <jhaas at pfrc.org <http://pfrc.org/> > 
> 	Cc: rtg-bfd at ietf.org <http://ietf.org/>  
> <http://core3.amsl.com/>  
> 	In-reply-to: 
> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at 
> mail.gmail.com <http://mail.gmail.com/> > 
> 	List-help: <mailto:[email-masked]?subject=help> 
> 	List-id: "RTG Area: Bidirectional Forwarding Detection 
> DT" <rtg-bfd.ietf.org <http://rtg-bfd.ietf.org/> > 
> 	List-post: <mailto:[email-masked]> 
> 	List-subscribe: 
> <https://www.ietf.org/mailman/listinfo/rtg-bfd>, 
> <mailto:[email-masked]?subject=subscribe> 
> 	List-unsubscribe: 
> <https://www.ietf.org/mailman/listinfo/rtg-bfd>, 
> <mailto:[email-masked]?subject=unsubscribe> 
> 	References: 
> <77ead0ec0911101119l60233263ye1d9af1ee1d5287a at 
> mail.gmail.com <http://mail.gmail.com/> > 
> <20100320165553.GC31380 at slice> 
> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at 
> mail.gmail.com <http://mail.gmail.com/> > 
> 	I will admit to some biases against SNMP configuration 
> of protocols based on
> 	   the SNMP system, does the MIB safely support 
> configuration or manipulation
> 	   of those sessions?
> 
> 	requiring bootstrap.  Alternatively, permanent, would 
> permit manipulation of
> 	the BFD session was part of the augmentation table or 
> in the base BFD MIB is

---

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 7 Sep 2010 22:40:35 +0530

Hi Nobo,
Thanks for your response.

What I expect from BFD mib is, application specific mapping table (ex.
bfdSessXXXMapTable where, XXX - application name) to have application
specific extra mib objects and this table should have an association with
the base BFD session table (bfdSessTable) to inherit the base BFD session
properties.
Currently, we support BFD Session IP Mapping Table at the BFD mib.
So, can we have application specific mapping at the BFD mib like BFD session
IP mapping table for other applications also?

Thanks,
Venkat.

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 7 Sep 2010 18:01:39 -0700

Hello Venkat,

That's an intereting suggestion. Thinking about this, adopting deviating
application specific knobs into the spec probably won't fit well into
genericness nature that we are trying to sustain. Rather, they should
remain at the application level IMHO.

Thanx,
Nobo

> From: venkatesan mahalingam [mailto:[email-masked]] 
> Sent: Wednesday, September 08, 2010 2:11 AM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]
> Subject: Re: BFD MIB
> 
> Hi Nobo,
> What I expect from BFD mib is, application specific mapping 
> table (ex. bfdSessXXXMapTable where, XXX - application name) 
> to have application specific extra mib objects and this table 
> should have an association with the base BFD session table 
> (bfdSessTable) to inherit the base BFD session properties.
> 
> So, can we have application specific mapping at the BFD mib 
> like BFD session IP mapping table for other applications also?
> 
> Thanks,
> Venkat.
> <http://gmail.com/> 
> 	>       From: Jeffrey Haas <jhaas at pfrc.org 
> <http://pfrc.org/>  <http://pfrc.org/> >
> 	
> <http://ietf.org/>
> 	> mail.gmail.com <http://mail.gmail.com/>  
> <http://mail.gmail.com/> >
> 	
> 	>       List-archive: 
> <http://www.ietf.org/mail-archive/web/rtg-bfd>
> 	>       List-help: 
> <mailto:[email-masked]?subject=help>
> 	> DT" <rtg-bfd.ietf.org <http://rtg-bfd.ietf.org/>  
> <http://rtg-bfd.ietf.org/> >
> 	
> 	> mail.gmail.com <http://mail.gmail.com/>  
> <http://mail.gmail.com/> >
> 	
> 	> mail.gmail.com <http://mail.gmail.com/>  
> <http://mail.gmail.com/> >
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Sep 2010 01:35:51 +0000

Venkat,

> client application triggers the BFD session.

[Speaking in the role of WG chair.]
The MIB, as currently published, is mostly a MIB targeted for IP BFD.  While
it's a goal to have the MIB be as generic and extensible as possible, it's
also a goal to have the MIB published in a reasonable time period.  If you
could help frame your suggestions in terms of specific changes to the BFD
MIB in order to accommodate the other BFD session mappings that would be
very helpful.

[Speaking as an individual contributor.]
What I believe you want is some way to ease an individual client of the BFD
protocol to be able to bootstrap the protocol without necessarily
duplicating the contents of various BFD MIB tables.  This is a fundamental
headache with regard to SNMP configuration.

Ignoring configuration for a second, it is reasonable that clients of BFD,
e.g. PW's, can provide protocol specific coverage to BFD state by providing
an augmentation table of the bfdSessTable.  There is no need to duplicate
the session table state in a PW MIB, e.g.

> users of the application.

With regard to configuration, this is certainly complicated.  I believe that
the solutions for configuration of BFD and its client are likely to not be a
general MIB issue and may very likely be vendor specific.  If you have
suggestions for infrastructure in the BFD MIB to make this a more generic
mechanism, I suspect the authors will welcome them.

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

LSPs provide a good example of the problem.  Discriminator state must be
first discovered via LSP ping to bootstrap the BFD session.  How would
you expect this behavior to be represented as MIB operations?  In my
opinion, this is not appropriate to model as configuration operations on the
MIB.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Sep 2010 01:37:52 +0000

Continuing my previous response:

> IP mapping table for other applications also?

It is very reasonable for other working groups to provide augmentation MIBs
to the base BFD MIB.  The primary responsibility that the BFD MIB authors
have is to make sure there is sufficient infrastructure in that MIB to
support such augmentation, where reasonable.

-- Jeff