Re: [Idr] BGP MIBv2 discontinuity objects

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
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr