Re: [Idr] BGP MIB v2 input

Curtis Villamizar <curtis@occnc.com> Mon, 26 March 2007 16:26 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVs1E-0001wJ-9A; Mon, 26 Mar 2007 12:26:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVs1C-0001vf-Pm for idr@ietf.org; Mon, 26 Mar 2007 12:26:02 -0400
Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVs1C-0002JY-9x for idr@ietf.org; Mon, 26 Mar 2007 12:26:02 -0400
Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2QGIDM6074927; Mon, 26 Mar 2007 11:18:13 -0500 (EST) (envelope-from curtis@occnc.com)
X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2QGIDM6074927
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174925893; bh=nKtEjDpfw0m5ExeN1keSfULb/uQ=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=fDAbwMbYSpgkJQhxrLmRlcnpDO+HL2RrzI jnQltcm3s+V3uGgPDYBNw+OgwtI2SSvyvkeyxGmxplkqBebkh0Qw==
Message-Id: <200703261618.l2QGIDM6074927@workhorse.brookfield.occnc.com>
To: Jeffrey Haas <jhaas@pfrc.org>
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: [Idr] BGP MIB v2 input
In-reply-to: Your message of "Mon, 26 Mar 2007 09:32:50 EDT." <20070326133250.GB8422@scc.mi.org>
Date: Mon, 26 Mar 2007 12:18:13 -0400
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: Bill Fenner <fenner@research.att.com>, idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

In message <20070326133250.GB8422@scc.mi.org>
Jeffrey Haas writes:
>  
> On Mon, Mar 26, 2007 at 06:50:37AM +0100, Bill Fenner wrote:
> > It may be worth breaking this down into areas of limitation of the
> > current MIB:
> > 
> > 1. v6 peer support
> > 2. v6 and other NLRI support
> > 3. 4-byte AS support
> > 4. extra counters desired
> > (Others?)
> > 
> > #1 can be taken care of with a rev of the peer table using
> > the InetAddressType/InetAddress TCs.
> > 
> > For #2, I have a somewhat radical proposal, which is to eliminate
> > the reporting of the BGP table contents via SNMP.  The radical
> > replacement would be a "lookup request" which you do by writing
> > an AFI, SAFI, NLRI to a lookup table, specifying whether you want
> > longest match or all matches, and you read the results from a
> > lookup results table.
> > 
> > (a few reasons for this change:
> > a) It's not very efficient to have an SNMP table with 200k+ rows;
> > b) It's hard to represent, e.g., VPN routes; and
> > c) You probably want to know "what routes do you know for
> > this destination", which is not easy to answer even with the
> > existing indexing, since "destination" is probably a /32 and
> > the prefix in the table is probably not)
>  
> #2 is an intriguing idea. Existing UI implementations already cover
> having multiple "processes" access the routing table simultaneously.
> However, I think this may have some interesting implementation
> headaches.  Could you please comment on them?
>  
> - This would require set/write access to the MIB, correct?  If so,
>   that's one of the things that people expressed serious reservations
>   about for any purpose previously.  If not, are people on board with
>   dynamic queries using get operations where getnext wouldn't work?
> - The results would likely be some sort of dynamically created OID tree
>   for each query.  UIs such as a CLI tend to have reasonably well
>   understood lifetimes for their route table walking routines, but MIBs
>   have a much less well defined interface.  Additionally, if you're
>   running the same query over and over, you may end up with multiple
>   views instatiated which may have excessive overhead.  Further, you
>   don't have any sort of static OID you can use to monitor the state of
>   a particular route.
> - The results of this query would seem to be the same MIB structure as
>   one would have for the entire routing table.  MIB structure-wise, I
>   don't think we save any complexity.
>  
> If these premises are true to one extent or another, that still leads to
> an interesting possibility.  We could still have the necessary query
> objects.  The result would then be a rowpointer to the root of the
> existing routing table's subtree that matched the query.  There would be
> no need to dynamically generate views of the routing table, however
> there would need to be a little intelligence in the querying routine to
> stop walking after you've hit a less specific route.
>  
> > #3 is straightforward, especially since between #1 and #2
> > we're probably changing most of the places you see an
> > AS number anyway.
>  
> The choice I made in the updates was to simply have the base routing
> table be 4-byte aware.  The annoying case is a 2-byte to 4-byte
> transition speaker where three versions of the objects may be present:
> The active derived set, the received 2-byte path attributes and the
> received 4-byte path attributes.  In the interest of simplicity in the
> base MIB, I'm suggesting the additional transitional views be left to an
> extention MIB.
>  
> -- Jeff


Jeff,

Regarding #2 above.

If we are going to play games that allow stateful SNMP access to solve
the routing table dump problem I suggest we create a MIB pseudo write
to take a snapshot of the routing table with a given identifier.  The
snapshot could then be transferred gradually but would 1) provide a
consistent view (atomic operation) of the routing table, 2) incur
little load on the router.  The snapshot would have limited lifetime
and could be refused if load was high (too many NMS stations asking
for snapshots, etc).

For routers that happen to have a fork operation with copy-on-write
semantics this would be a very minimal impact and be similar to the
"gated dump" of olden days.  The forked process would then answer MIB
queries.  Separate memory pages would exist only as a result of routes
that change during the lifetime of the snapshot.

Routers built on more primative OS could implement the snapshot in
some other way, but could incorporate a copy-on-write semantic within
the routing table itself (with some complexity in doing so but that's
their fault for not using a modern OS).

As is (current MIB) from a practical standpoint the BGP routing table
cannot be dumped via SNMP.  Either you have to try to be aggressive
and get it fast, or it changes while being dumped.  I'm not sure if
anyone has implemented a TCP GET-BULK on the entire routing table as a
fork with copy-on-write, but that would have the same effect.  The
process making the TCP transfer could be given a low priority making
the operation atomic yet low impact.  If that is an acceptable
alternative, then no change is needed.

I'm not sure if this addresses one implied requirement (or imagined on
my part?) of #2 above, which is to dump a specific prefix only.  I
thought that would already be possible with GET-NEXT and the existing
ordering used in the MIB.

Disclaimer - I'm far from an SNMP expert.

Curtis

ps - No I don't work for Juniper.  :-)

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr