Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15

Jeffrey Haas <jhaas@pfrc.org> Tue, 28 November 2017 17:43 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9356126B6D for <idr@ietfa.amsl.com>; Tue, 28 Nov 2017 09:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKqiLvgfn8tZ for <idr@ietfa.amsl.com>; Tue, 28 Nov 2017 09:43:31 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6019D12420B for <idr@ietf.org>; Tue, 28 Nov 2017 09:43:31 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 8EFD71E344; Tue, 28 Nov 2017 12:47:00 -0500 (EST)
Date: Tue, 28 Nov 2017 12:47:00 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Nick Hilliard <nick@foobar.org>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20171128174700.GP16871@pfrc.org>
References: <CAKz0y8yesGQrmmLNm4rJL_=W53tr-Kp2OpgqR_q9qkp3rPa2gQ@mail.gmail.com> <D6385A04.DA762%acee@cisco.com> <5A12F675.2030106@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5A12F675.2030106@foobar.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/29lIaw3_ZJGNUAN4It2wiJoDCE0>
Subject: Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Tue, 28 Nov 2017 17:43:33 -0000

On Mon, Nov 20, 2017 at 03:36:21PM +0000, Nick Hilliard wrote:
> Acee Lindem (acee) wrote:
> > The IETF has moved on from SNMP-based management to YANG, refer to this
> > IESG statement:
> > 
> > https://www.ietf.org/iesg/statement/writable-mib-module.html
> 
> the rest of the world is going to take many years to catch up with this
> decision - usable YANG is only beginning to make its way into a small
> segment of high-end kit out there, and there is a large segment of
> market kit where it is likely never to be deployed.
> 
> In the meantime - in this particular situation - we have no means of
> monitoring ipv6 or vrf-enabled bgp sessions, other than screen-scraping.
>  It shouldn't need pointing out that this is a deficit with serious
> operational consequences.

Once upon a time, Sue said to a very new BGP developer: "Hey, I have this
bit of IETF work that needs to be done.  Interested?"

MIB design was a very interesting set of life lessons.  And similarly,
dealing with conflicting opinions about "what belongs in the model".  Mind
you, this was in the day when there some level of insistence that things be
not only monitorable via SNMP, but potentially configurable.

A consequence of a number of these tensions, including the fact that BGP had
an awful lot of optional (but common) features that could be modeled only
with a bit of difficulty in SMI-v2 using abstract indices, meant that there
was a very high degree of *thrash* in the work.  This taxed our MIB doctors
more than a little - thankless work that they still are owed many libations
for.

The big vendors at various snapshot points implemented portions of the 
BGP MIBv2 as enterprise MIBs.  Mostly the useful bits: peering sessions,
counters.  The actual routing table data... yeah, they skipped it.  SNMP is
really an awful hammer to try to grab that stuff from anyway.  And trying to
wedge in all of the different optional things lead to tables of tables...
ick.

mibv2-15 is in a state where most of the big vendors can likely leverage
their enterprise mibs and their existing routing table stuff and do the code
to ship this in reasonable order.  But most aren't interested.  I
occasionally hope to grab the cycles myself to just finish it on my end, but
convincing the rest of product management to do the test and other work
hasn't panned out.

If there's need to actually dust off this MIB, it won't take much work to do
so.  But it'll take quite some convincing, I think.

-- Jeff (author)

P.S. The issue related to the fact that BGP is a maze of optional features
still hasn't been fully resolved in the yang model work that is currently in
progress.  But at least yang let's you do something about having optional
features.