[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] BGP MIBv2 discontinuity objects
Hi Jeff,
See inline below.
----- Original Message -----
From: "Jeffrey Haas" <jhaas at pfrc.org>
To: "Joan Cucchiara" <jcucchiara at mindspring.com>
Cc: "Dan Romascanu (E-mail)" <dromasca at avaya.com>; "David Ward"
<dward at cisco.com>; <idr at ietf.org>; "MIB Doctors (E-mail)"
<mib-doctors at ietf.org>
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
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr