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.
- [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Muthu Arul Mozhi Perumal
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Acee Lindem (acee)
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Nick Hilliard
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Muthu Arul Mozhi Perumal
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Acee Lindem (acee)
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Acee Lindem (acee)
- Re: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15 Jeffrey Haas