Re: [Idr] BGP MIBv2 discontinuity objects

Jeffrey Haas <> Mon, 04 August 2008 19:15 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 10AD43A690D; Mon, 4 Aug 2008 12:15:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B48153A695B; Mon, 4 Aug 2008 12:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zivb7qnZO45J; Mon, 4 Aug 2008 12:15:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E60F03A691C; Mon, 4 Aug 2008 12:14:34 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 2C22B244053; Mon, 4 Aug 2008 19:15:02 +0000 (UTC)
Date: Mon, 04 Aug 2008 15:15:01 -0400
From: Jeffrey Haas <>
To: Joan Cucchiara <>
Message-ID: <20080804191501.GA847@slice>
References: <06f701c88b5b$22622000$6601a8c0@JoanPC> <> <00f801c8b542$2d1a0c90$6601a8c0@JoanPC> <20080611022929.GA633@slice> <012201c8de39$63ca17b0$6601a8c0@JoanPC> <20080707032451.GC10534@slice> <006b01c8e680$fba55d20$6601a8c0@JoanPC> <20080715145455.GA1072@slice> <001e01c8e779$fd90e650$6601a8c0@JoanPC>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <001e01c8e779$fd90e650$6601a8c0@JoanPC>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: "Dan Romascanu (E-mail)" <>, David Ward <>, "MIB Doctors (E-mail)" <>,
Subject: Re: [Idr] BGP MIBv2 discontinuity objects
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Following back up to original list:

On Wed, Jul 16, 2008 at 03:27:30PM -0400, Joan Cucchiara wrote:
> 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.

bgpAfPathAttrIndex will show the relationship from the bgpNlriTable
entries and their associated bgpAfPathAttrTable entries.  In the event
of a discontinuity, it is highly desired that if the contents of the
bgpAfPathAttrTable change that indexes are not re-used too quickly since
a given index may then refer to different data.

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

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

Correct.  In particular, where a BGP implementation is capable of
maintaining some state across discontinuities, it should choose indexes
in such a way as to minimize re-use of an index.  The simplest possible
implementation would be to have a monotonically increasing value
(within the bounds of the wrapping of an Integer32) that was used to
for the bgpAfPathIndex.  As long as the last-used value is kept between
discontinuities, this would satisfy the discontinuity concerns.

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

More precisely, when an implementation maintains state for the
bgpAfPathAttrTable (i.e. the path attribute database isn't necessarily
reset) then it MAY keep the same index values.  Entries in the
bgpNlriTable MAY associate themselves with the entries in the
bgpAfPathAttrTable where they match the received reachability.

>   -Joan
Idr mailing list