Re: BFD MIB extension for MPLS-TP

[Sam Aldrin <[e-mail]>]

Hi Jeff,

Thank you for your comments. Please see inline for my replies to your questions.
Agree to all of your suggestions and comments.

Cheers
Sam

Sent from my iPad

On Jan 8, 2012, at 4:42 PM, Jeffrey Haas <[e-mail]> wrote:

> [Mostly writing as an individual contributor.]
> 
> On Thu, Dec 15, 2011 at 08:17:24PM -0800, Sam Aldrin wrote:
>> We have submitted a new draft, BFD MIB extensions to support MPLS-TP, prior
>> to IETF82 at Taipei.
>> 
>> The draft is located at
>> http://datatracker.ietf.org/doc/draft-vkst-bfd-mpls-mib/
>> 
>> 
>> We have presented the draft in MPLS WG to get feedback from that WG.
>> 
>> As there was no WG session at Taipei, we are seeking feedback from BFD WG
>> over the mailing list.
>> 
>> 
>> The MIB extension is fairly simple and adds few new objects to extend the
>> exiting BFD MIB and support BFD sessions over TP tunnels. Please provide
>> your feedback and comments, so that, we could take it forward and ask to
>> make it a WG document.
> 
> My first comment is that the object names in this MIB seem to strongly
> suggest that this is a general extension MIB for BFD rather than are adding
> MPLS-TP specific objects to the BFD MIB.  E.g.:
> bfdExtObjects
> bfdSessExtTable
> etc.
> 
> I would strongly suggest the object names be more specific in alluding to
> MPLS-TP.
%sam - agree. We will be changing the object names appropriately. As we are extending to support MPLS in general, not just TP, we will change accordingly.
> 
> SessionMapTypeTC should similarly note that it is associated with both BFD
> and MPLS-TP.  Also, if there's any chance that this TC will see re-use, it
> should be placed in its own MIB at some point in the future.  IMO, it's fine
> to leave it in this document for a few iterations for refining the MIB.
%sam - nod.
> 
> bfdSessExtTable contains read-create objects but is INDEXed on the BFD
> session table rather than AUGMENTing it.  As such it needs its own RowStatus
> and StorageType objects.
%sam - yes, we missed adding those objects. Will do so in our next version.
> 
> bfdSessExtMapType and bfdSessExtMapPointer should probably get useful DEFVAL
> entries that install an inactive row if the MIB user inadvertantly do a
> createAnd* operation.  This may suggest that a map type of "none" may be
> required.
%sam - good catch. We will be make appropriate changes.

> 
> -- Jeff