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

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 20 Nov 2017 19:49:23 +0530

draft-ietf-idr-bgp4-mibv2 is supposed to address some of the key
deficiencies in the BGP-4 MIB [RFC4273] including the ability to monitor
IPv6 BGP peering sessions and carry IPv6 reachability.

However, that draft expired in 2014. Does anyone know why it didn't
progress further? Is there any other draft or RFC replacing it?

Regards,
Muthu

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 20 Nov 2017 15:14:00 +0000

Hi Muthu,

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

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 20, 2017 at 9:19 AM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] Query on draft-ietf-idr-bgp4-mibv2-15

draft-ietf-idr-bgp4-mibv2 is supposed to address some of the key deficiencies in the BGP-4 MIB [RFC4273] including the ability to monitor IPv6 BGP peering sessions and carry IPv6 reachability.

However, that draft expired in 2014. Does anyone know why it didn't progress further? Is there any other draft or RFC replacing it?

Regards,
Muthu

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 20 Nov 2017 15:36:21 +0000

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

Nick

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 20 Nov 2017 22:15:34 +0530

The IESG statement is about standards-based approaches to configuration,
right? There are deployed SNMP based systems for monitoring that are
crucial for network operation. What is our recommendation towards them?

Regards,
Muthu

On Mon, Nov 20, 2017 at 8:44 PM, Acee Lindem (acee) <[email-masked]> wrote:

> From: Idr <[email-masked]> on behalf of Muthu Arul Mozhi Perumal <
> [email-masked]>
> To: IDR List <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 20 Nov 2017 16:55:22 +0000

Hi Nick, 

As you know, there are vendor-specific MIBs that satisfy the referenced
requirements. However, unless the IDR WG were to agree on one of the
vendor MIBs, it would likely take some time to standardize MIB extensions
to RFC 4273. Given that there is only so much energy in the WG, my opinion
is that the focus should now be on publishing the BGP and VPN YANG models.
However, I would not actively oppose work on IDR MIB extensions.

Thanks,
Acee
P.S. I knew I should have left this E-mail to the chairs ;^)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 20 Nov 2017 17:28:09 +0000

OTOH, I looked at the expired draft and it seems pretty straightforward.
Additionally, there is still work going on in BESS on needed MIBs (e.g.):

https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/

Thanks,
Acee

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Nov 2017 12:47:00 -0500

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