[Idr] Re: New Liaison Statement, "oLS to IETF on BGP data model"

[Jeffrey Haas <[e-mail]>]

Tom,

[Speaking very firmly as an individual contributor here...]

> On Nov 22, 2025, at 8:20 AM, tom petch <[e-mail]> wrote:
> I was involved with BGP4 and with SNMP Network Management in the years preceding RFC4271 and expected - hoped for - a management RFC to appear soon after.  Since then, I have formed the opinion that there is not enough commonality across implementations for an IETF management model and see the lack of progress with the data model as a symptom of that.  If the I-D does progress, then I think that it needs a clear statement up front about the lack of consensus across implementations of a management model; or we could have models that are not Standards Track that reflect the approach taken by one, or a few, of the implementations.  I do not have a view as to which implementations of network management are most suitable -  I no longer have the exposure I had in the days of producing RFC4271. 
> 
> It may just be that the world of network management has moved on and an SNMP BGP model from the IETF .is no longer appropriate.

The primary failure of the prior BGP MIB v2 work was due to two things:
1. Requirements thrash.  The previous requirement that "configuration must be supported in MIBs" was unfortunately doomed to failure.  
2. "You can't model that cleanly in SMIv2".  While there was push to model the BGP RIB in the MIB, the lack of ability to model structured data made it largely impossible to do a MIB that could do the job.  In many respects, this resulted in vendor implementations for the BGP MIBv2 in enterprise MIBs focusing on simple scalar counters - which is probably all the user base wanted from the effort anyway.  However, see 1 - thrashing requirements.

These two things pushed IETF as a whole to stop requiring MIBs as part of process.  However, YANG wasn't ready to take its place at that time.

Since then, the issue hasn't been a lack of usefulness and supported models in YANG.  We see a lot of it.  But the vendor-neutral stuff was effectively supplanted by OpenConfig work.  That work demonstrates that it is quite possible to model operational state appropriately in YANG.  It, frustratingly, also demonstrates that vendors can be bullied into defining subsets of features that are neutral-enough for configuration purposes for specific profiles.  

IETF work to date for various protocol models focuses on operational state.  It also defines configuration state, but isn't deeply focused on "could you make this work".

The work clearly can be done.  The "why" is the motivational discussion - and a discussion that's only partially appropriate for IDR.

-- Jeff