Joan,
On Tue, Jul 15, 2008 at 09:45:02AM -0400, Joan Cucchiara wrote:
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?
Not exactly. To quote from the MIB:
: Note well that this index is used to distinguish unique
: sets of Path Attributes sent as part of BGP NLRI. The
: implementor is thus encouraged to make this index unique
: per set of all received path attributes. This value may
: be used to index tables in extension MIBs that share the
: property of belonging to the same received Path Attribute
: tuple.
The key words here are "unique sets of Path Attributes". If, by some
feat of chance you receive that set of path attributes from more than
one peer, it is possible that one peer going down may not cause this set
of path attributes to go away.
Thus, this is not only an index that may have a many to one relationship
from a given set of routes from a given peer, it's possible it may be
many to one for multiple peers for a given set of routes from those
peers.
This does not preclude an implementation from creating a single entry in
the tables and having a one-to-one mapping with a distinct
bgpAfPathAttrIndex per route. While such an implementation is possible,
it is not scalable.
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?
In order for the contents of the bgpAfPathAttrTable or other tables
indexed by bgpAfPathAttrIndex to change, one of two things would have to
happen:
- All routes sharing these path attributes will have also changed to
have a new set of shared path attributes. (Possible, but very
unlikely.)
- That set of path attributes ceases to be used for long enough for the
index to be re-used.
In the event of a BGP Instance restart, the indexes *may* (and likely
will)
be re-used. Avoiding this particular scenario is perhaps worthy of some
code but may be very problematic for some implementations due to the
lack of persistance of this index in the data structures. And again,
BGP graceful restart means a peer may restart but the "resources"
allocated
by that peer may stay around.
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?
Simply a pointer to related information in another table.
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 suspect the intent is clear to those who have implemented BGP but
that's clearly not the only audience for this document. Did the above
explanation help and if so, what changes to these objects would you
recommend?
Please note that while merging the contents of the bgpAfPathAttrTable into
bgpNlriTable would likely make this abundantly clear it is a terribly
unscalable solution for MIB walks.
Throughout the course of your MIB evaluation, please keep in mind that the
typical number of route instances received from a eBGP peer is on the
order
of 250,000 routes. This corresponds to 250K entries in the bgpNlriTable,
some smaller number of entries in the bgpAfPathAttrTable (based on shared
attributes across at least the same peer) and a smaller number of entries
in
the bgpAfPathAttrUnknownTable.
This is per-*peer*. Many BGP routers have hundreds of peers.
This means many of the structural design choices in this MIB are meant to
accomodate the required scalability.
* 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.
But not one expected to affect counters.
So, for a "BGP instance" restart, InUpdates and InTotalMessages are
affected.
*May* be affected. This depends on implementation.
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.
Sure. Dropped packets happen. It's a matter of course that a user of TCP
may not be aware that some data has not been received even though it has
sent it. If this was a matter of concern some other protocol than TCP
would
be used.
(As a matter of fact, this is one of the classes of concern that lead to
the
BFD protocol. TCP liveness is not good enough sometimes.)
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?
bgpPeerInTotalMessages OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The total number of messages received
from the remote peer on this connection.
This object has been replaced with
bgpPeerAfInTotalMessages."
REFERENCE
"RFC 4271, Section 4."
::= { bgpPeerEntry 12 }
I see that the bgpPeerAf* versions of these counters do not contain the
REFERENCE section. I'll correct that.
In the context of the reference, the meaning of message is clear. Yes, as
new extensions are defined they are counted since they are in the format
of
a BGP message. Consider RFC 2918 - a new message type. It's still a
message.
If these counters are specific for Route Flapping, then maybe that should
be
the focus.
That would be the focus of another MIB - perhaps one covering RFC 2439.
(Although realistically not. RFC 2439 RFD is not what is deployed.)
-- Jeff