Re: [Idr] BGP MIBv2 discontinuity objects

"Joan Cucchiara" <jcucchiara@mindspring.com> Wed, 16 July 2008 19:27 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817E63A6919; Wed, 16 Jul 2008 12:27:03 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9D43A683C; Wed, 16 Jul 2008 12:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4X02lhCJ1I1; Wed, 16 Jul 2008 12:27:00 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id B30AE3A681A; Wed, 16 Jul 2008 12:27:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=npGfFoQjFqrEXWi7x0mENGvq+G+5G9K1lLlQETq96M1oVfMDPUyxpw5xB5XWlsn4; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [141.154.115.63] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1KJCev-0006IN-3R; Wed, 16 Jul 2008 15:27:29 -0400
Message-ID: <001e01c8e779$fd90e650$6601a8c0@JoanPC>
From: "Joan Cucchiara" <jcucchiara@mindspring.com>
To: "Jeffrey Haas" <jhaas@pfrc.org>
References: <06f701c88b5b$22622000$6601a8c0@JoanPC> <20080503223750.GG23560@scc.mi.org> <00f801c8b542$2d1a0c90$6601a8c0@JoanPC> <20080611022929.GA633@slice> <012201c8de39$63ca17b0$6601a8c0@JoanPC> <20080707032451.GC10534@slice> <006b01c8e680$fba55d20$6601a8c0@JoanPC> <20080715145455.GA1072@slice>
Date: Wed, 16 Jul 2008 15:27:30 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654f042a339c4e221e00e06bb52e1d9bc933ae9702e2e88ebc7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 141.154.115.63
Cc: "Dan Romascanu \(E-mail\)" <dromasca@avaya.com>, David Ward <dward@cisco.com>, "MIB Doctors \(E-mail\)" <mib-doctors@ietf.org>, idr@ietf.org
Subject: Re: [Idr] BGP MIBv2 discontinuity objects
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Jeff and I talked on the phone about this one, sorry but there was
some misunderstandings which were best clarified by an actual conversation.

I'll try to recap as best as I can, and Jeff can correct me if I'm wrong, 
but
the upshot is the bgpAfPathAttrIndex OBJECT (contained in the bgpNlriTable)
and the bgpAfPathAttrIndex which serves as a single index for 
bgpAfPathAttrTable
should originally contain the same value to show a relationship between
the row in the bgpNlriTable and the bgpAfPathAttrTable.  After a 
discontinuity
the value of the bgpAfPathAttrIndex (used as an index in the 
bgpAfPathAttrTable) does
not change, BUT the bgpAfIndex OBJECT in the bgpNlriTable could change.

For those implementations where the bgpAfPathAttrIndex OBJECT in the 
bgpNlriTable
changes after a discontinuity, the relationship
between the NLRI  (Network Layer Reachability Information)
and the related Path Attribute information is lost.
This means that the bgpAfPathAttrIndex OBJECT's
new value should not be the same value as any bgpAfPathAttrIndex in the 
bgpAfPathAttrTable, so
if the intention is that the NLRI and the Path Attributes are not related, 
checking needs to be
done.   This will be stated more clearly.

Additionally, if implementations want to keep the relationship between the 
NLRI and the
Path Attributes, then implementations should  "save" the value of
the bgpAfPathAttrIndex OBJECT with NLRI information (this is not saved in 
the MIB but in
some data structure) and in the event that
the same NLRI comes back, the original value of the bgpAfPathAttrIndex 
OBJECT can be used
so that the relationship between the NLRI and bgpAfPathAttrEntry is 
preserved.

   -Joan

----- Original Message ----- 
From: "Jeffrey Haas" <jhaas@pfrc.org>
To: "Joan Cucchiara" <jcucchiara@mindspring.com>
Cc: "Jeffrey Haas" <jhaas@pfrc.org>rg>; "Dan Romascanu (E-mail)" 
<dromasca@avaya.com>om>; "David Ward" <dward@cisco.com>om>; <idr@ietf.org>rg>; "MIB 
Doctors (E-mail)" <mib-doctors@ietf.org>
Sent: Tuesday, July 15, 2008 10:54 AM
Subject: Re: 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