[Idr] BGP MIBv2 discontinuity objects

[Jeffrey Haas <[e-mail]>]

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
> DISCONTINUITY DISCUSSION:
>
>>    --
>>    -- Discontinuity
>>    --
>>    bgpDiscontinuityTime OBJECT-TYPE
>>        SYNTAX TimeStamp
>>        MAX-ACCESS read-only
>>        STATUS current
>>        DESCRIPTION
>>            "The value of sysUpTime at the most recent occasion at which
>>             this BGP management instance has suffered a discontinuity.
>>
>>             In particular, tables with abstract indexes such as
>>             bgpAfPathAttrIndex, bgpAsPathIndex and
>>             bgpAfPathAttrUnknownIndex are not guaranteed to contain the
>>             same data across discontinuities."
>>         ::= { bgp 13 }
>>
>
>
> If the value of the indices change
> and can be different from the objects, then what is the point of
> having the objects?

I'm not sure I understand your question.

Fundamentally, the problem is the inability of SMIv2 to represent
complex structured information.  If SMI had retained ASN.1's ability to
have stacked data structures, all of this information would be present
in a single, albeit verbose, table.  This verbosity is notable since BGP
implementations usually implement mechanisms to factor and re-use data
that is present more than once.  For example, while multiple route sets
may all have the same identical set of BGP Communities, it is typically
stored once and reference counted.

Since we are limited to using SMI, the result is that an abstract index
must be used to glue the tables one to another.  This also allows a
given table row to have a many to one relationship to shared data.  E.g.
BgpNlriEntry's bgpAfPathAttrIndex.

> I would like to break this down into a specific discussion
> prior to agreeing on one Discontinuity Object (or more than one).
>
> discontinuity scenarios in BGP4 Protocol:
>
> * SNMP agent restarts (sysUpTime is affected) which is default behavior
> * bgp entity restarts (what you are calling the BGP Management instance?)
>   (assume this is separate from SNMP agent)

It is possible that a BGP instance will share the fate of its SNMP agent
and vice versa but this varies wildly by implementation.

> * peer restarts/lost connection
> * specific session goes from established state to some other state

[These are fundamentally the same.]

While this is a discontinuity of sorts, the behavior of this is well
defined by the BGP specifications.  The base behavior is defined by the
FSM in RFC 4271 and potentially altered by Graceful Restart, RFC 4274.

> The following (I think?) would be affected by SNMP Agent Restarts, bgp 
> Entity
> Restarts, peer restarts, and FSM establish state transition.  Is this
> correct?
>
>
> bgpPeerAfInUpdates
> bgpPeerAfOutUpdates
> bgpPeerAfInTotalMessages
> bgpPeerAfOutTotalMessages

These are affected by SNMP agent restarts and potentially by BGP
Instance restarts.  It is typical for the SNMP agent to fetch these
values from the BGP instance.  While it is possible for the BGP
instance upon restart to maintain their values, this is completely an
implementation detail and may not happen.

> bgpPeerAfFsmEstablishedTransitions

This may be affected by the SNMP agent restarting, the BGP instance
restarting and is altered as a result of BGP peer transitions/restarts.

> [So more of a question for the WG,
> Are the bgpPeerAfInTotalMessages and bgpPeerAfOutTotalMessages
> counters useful? ]

Not speaking for the whole of the working group but some operators use
these values as a metric of BGP "chatter".  This is helpful in
pinpointing specific BGP instances and peering sessions that are "close
to" route flapping.

> [As an aside, the bgpPrefixCountersTable should be renamed to
> remove the word counter since these are actually Gauge32.]

I have renamed these to be bgpPrefixGauges*

> bgpAfPathAttrCounter - Typically, these values are not
> included in MIBs and are calculated by the NMS.  However, if
> this needs to be in the MIB, then
> think that it probably should be a Gauge32, rather than a
> Counter32.

I have made this a Gauge32 and renamed it to bgpAfPathAttrGauge.

Feedback over the years on the MIB had stressed on the ability to
monitor the general size of the routing table.  The prefix gauges
provide one level of monitoring this while the Path Attribute gauge
provides another.  These tables are typically *VERY LARGE* and a full
walk simply to generate this count (which is often available from the
management instance as a scalar courtesy of the BGP instance) puts undue
load on the BGP Instance.

-- Jeff
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr