Subject: [Idr] MIBs - peer description and prefix limits

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Sep 2008 16:55:04 -0400

I was contacted off-list by Owe Gafford who does work on monitoring
tools for an ISP regarding the BGP MIBv2 work.  He had two comments on
the MIB work:

1. He believes it would be operationally useful to include a text-based
description of a peer.  Since many common router CLIs provide such a
description string as part of their configuration this seems to be a
good match for the MIB as part of the peer table. 

Would there be any concerns with adding an object to the MIB to support
this?  

2. He would like to see support for prefix limits to be visible in the
MIB.  I believe this is probably not appropriate for the base BGP MIB
since it's functionality that's not really covered by RFC 4271 or the
base RFCs that we've previously discussed including in the MIB.  This is
somewhat contradicted by RFC 4486 (BGP Cease Notification Message
Subcodes) which includes a "maximum number of prefixes reached" code
point.

In my opinion, this probably belongs in an extension MIB.  I can be
argued out of this if there's a preponderance opinion in the other
direction.

-- Jeff

P.S.
Aside on MIB status: The work is pending review before the next draft is
issued.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Simon Leinen <[email-masked]>
Date: Fri, 19 Sep 2008 23:58:47 +0200

> Would there be any concerns with adding an object to the MIB to support

No, I think this would actually be useful.

> MIB.

I think this would be useful too.  Although prefix limits may not
really be standardized, they are widely implemented and very widely
used.

(1) and (2) together with the objects in bgpPrefixCountersTable would
make it possible to write useful monitoring tools that require only
SNMP, would be easy to configure, and that could provide useful
diagnostics.

> I believe this is probably not appropriate for the base BGP MIB
> since it's functionality that's not really covered by RFC 4271 or
> the base RFCs that we've previously discussed including in the MIB.

I wouldn't mind seeing this in the base MIB even.  At any rate, that
MIB should probably have a clear description of what the prefix limit
means.  For example, whether it is compared to the number of prefixes
ACCEPTED from a peer (under a given AFI/SAFI) or to the number of
prefixes RECEIVED (but not necessarily accepted).

> This is somewhat contradicted by RFC 4486 (BGP Cease Notification
> Message Subcodes) which includes a "maximum number of prefixes
> reached" code point.

Right.  Looking at bgpAfBackwardTransitionNotification, it seems that
that notification includes the subcode when the other side sends it
(bgpPeerAfLastErrorSubCodeReceived).

But when the prefix limit is tripped on our side, that information is
not included in bgpAfBackwardTransitionNotification, which is a pity.
Shouldn't bgpAfBackwardTransitionNotification include

            bgpPeerAfLastErrorCodeSent
            bgpPeerAfLastErrorSubCodeSent
            bgpPeerAfLastErrorSentText

in addition to

            bgpPeerAfLastErrorCodeReceived
            bgpPeerAfLastErrorSubCodeReceived
            bgpPeerAfLastErrorReceivedText

?

> argued out of this if there's a preponderance opinion in the other

As I said, I'd be more in favor of having this in the base MIB.
What do others think?
-- 
Simon.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr