Subject: draft-ietf-bfd-mpls-mib-06 (was Re: Comments on draft-ietf-bfd-mpls-mib-05)

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Sep 2015 13:43:20 -0400

Authors of the BFD MPLS MIB,

Thanks for addressing the majority of my comments during MIB review.  Only a
few items have remained without any response:

- Splitting the TCs into IANA maintained modules.  Do you intend to just
  wait until we have MIB doctor review and see if they require it?

The other items are below and at least need reply.

Beyond addressing these two items, what are the authors' beliefs about the
state of the MIB?  Ready for Last Call and/or MIB Doctor review?

On Tue, Dec 30, 2014 at 12:25:39PM -0500, Jeffrey Haas wrote:
> The bfdMplsSessPerfTable consists only of Counter32 objects.  Practice
> appears to use paired Counter64 "High Capacity" counters.  Are these being
> left out for any specific reason?
> 
> One final comment is that no NOTIFICATIONs are defined for this MIB.  While
> not strictly required, an operator has no indication that a given
> NOTIFICATION in the underlying RFC 7331 MIB is for sessions that may change
> state for reasons having to do with underlying MPLS session association.  
> 
> One possibility that comes to mind to address this is to add a
> recommendation that the bfdSessUp/bfdSessDown NOTIFICATIONS receive an
> additional OBJECTS entry of bfdMplsSessMapPointer.  The one obvious counter
> to such a practice is this may disrupt the low/high range optimization in
> the base NOTIFICATION.
> 
> -- Jeff

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Sat, 19 Sep 2015 01:40:51 -0700

Jeff,

Thanks.

Please see in-line my replies.

-Venkat,

>   wait until we have MIB doctor review and see if they require it?
Yes.

> state of the MIB?  Ready for Last Call and/or MIB Doctor review?
Yes, ready for Last Call, we'll fix the remaining comments as part of Last
Call.

> > left out for any specific reason?
We dont expect a big counter value so, Counter32 is enough.

> > state for reasons having to do with underlying MPLS session association.
As we augment the existing BFD Session MIB for MPLS, whatever notifications
present in BFD session MIB will be applicable for MPLS BFD session also.

> > to such a practice is this may disrupt the low/high range optimization in
Do we really need an additional entry bfdMplsSessMapPointer in the
notification?

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Sep 2015 09:44:49 -0400

Venkat,

> >   wait until we have MIB doctor review and see if they require it?

Understood.  Please note that having been through this sort of thing a few
times, that is the likely recommendation.  It means that we'll end up having
to send the document through a second WGLC as a result.

> Do we really need an additional entry bfdMplsSessMapPointer in the

Need, no.  But consider your user-base.  The lack of correlation between
events in various OAM systems is probably one of the most infuriating things
about the management architecture IETF has put together, especially if
you're trying to operate a network.

If an LSP drops and you lose 100 BFD sessions, you'll get 100 BFD Down
NOTIFICATIONs and perhaps some other notification from another MIB.  If BFD
knows that it's going down due to an MPLS LSP event, it's preferable that it
simply say so.

And should my own employer decide to implement this MIB, including the
additional OBJECT will certainly be my recommendation.

-- Jeff