Re: [Idr] BGP MIBv2 discontinuity objects

["Joan Cucchiara" <[e-mail]>]

Hi Jeff,

See inline below.


----- Original Message ----- 
From: "Jeffrey Haas" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>
Cc: "Dan Romascanu (E-mail)" <[e-mail]>; "David Ward" 
<[e-mail]>; <[e-mail]>; "MIB Doctors (E-mail)" 
<[e-mail]>
Sent: Sunday, July 06, 2008 11:24 PM
Subject: BGP MIBv2 discontinuity objects


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

So want to make sure we agree that the value of the bgpAfPathAttrIndex
OBJECT can change if the peer goes away and comes back (or changes from an
Established state to some other state and then back to Established), do you 
agree?

Further, assuming that the object's value changes (due to reasons as stated 
in the previous paragraph),
the value of the bgpAfPathAttrIndex INDEX  does NOT change, do you agree?

So to restate my question, when the value of the object
changes, the object and the index contain different values,
what purpose does this object serve at this point?

In other words, there might be a better way to show a relationship
between these two rows (i.e the row containing the OBJECT and the row using
the OBJECT's initial value as an INDEX), but first I need to understand what 
the
intent is supposed to be because the MIB as written is unclear wrt intent.




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

Agreed.


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

If counters can miss information such that they are NOT incrementing when 
they
normally would,  then this is a discontinuity.

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

I'm not concerned with whether or not implementations reset counters.
I'm trying to isolate situations where counters miss counting/incrementing.

So, for a "BGP instance" restart,  InUpdates and InTotalMessages are
affected.  So, the peer is sending, but the router is likely missing these 
messages
since it is busy restarting BGP.  Another way to think of this is that the 
related
Out counters on the peer would be incrementing, but these are not able to be
processed by this router as In counts.

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

Since there are only Counters for UPDATE Messages, could you specify what
is included in the Total Counters?  I am wondering how a developer would 
know
what to include here.  Are the messages counted by this counter
going  to change as more BGP extensions are developed?

If these counters are specific for Route Flapping, then maybe that should be
the focus.

>> [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*

Thanks.

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

Okay.

   -Joan

> -- Jeff 

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