[Idr] BGP Yang modules and core features

[Jeffrey Haas <[e-mail]>]

IDR,

As a bit of history, I'm the editor/author on the existing BGP MIBs.  The
BGP MIBv2 work stalled out due to no one actually taking their enterprise
implementation and normalizing it with the published draft, leaving it in
limbo. 

During the MIBv2 work, one detail that churned the modeling work was the
necessary "core protocol" details to include in the MIB.  The original goal
was to pick some common core BGP features such as route reflection,
confederations, etc. and include them.  However, it later occurred that 
if implementations did not support these common, but core features that they
would not be able to implement the MIB.  This lead to an effort to
restructure the MIB to include these features as optional extension MIBs.
Eventually, that work was abandoned as simply making things too complex.

In my opinion, SNMP MIBs are awful for this type of modeling and I'm
thrilled that Yang has become a useful language in the IETF.

Why bring up the past?  IDR has recently hosted two interims covering
proposed BGP Yang modules:
https://tools.ietf.org/html/draft-zhdankin-idr-bgp-cfg-00
https://tools.ietf.org/html/draft-shaikh-idr-bgp-model-00

Discussion on the drafts was good.  IMO, there are issues in each that need
some resolution.  One issue in particular generated a bit of heated
discussion during the most recent interim and I thought it worth requesting
input from the broader Working Group.

The two models have slightly different goals: zhdankin is intended to be a
bit more of a complete model to serve as a basis for an IETF IDR model.
shaikh is intentionally covering a restricted but common subset of BGP
functionality in the networks of the authors.  Both potentially offer the
long-term option to be extended for greater completeness; Yang is very nice
about allowing extension modules.

The question I'm raising is the core features present in the modules in the
context of IDR eventually adopting a module as "the IETF BGP module".  In
the forms both of these drafts are in, there is no optional configuration.
As an example, -shaikh includes a ipv4-l3vpn-unicast container.  If you were
communicating with a netconf server implementing the module as specified,
your software would believe that l3vpn-unicast is supported.

Unlike SNMP, we're not stuck with the need for a lot of tricks to determine
if a feature that is present in the model is available on the device or not.
The "if-feature" clause in Yang (RFC 6020, sec 7.18.2) permits the module to
make some of the content conditional based on whether a management
implementation supports that feature or not.  (It is advertised in the
netconf hello statement; netconf RFC 6241, section 8.1.)

Support for various address family (AFI/SAFI) configuration and operational
state are obvious targets to make optional.  "Core" features such as route
reflection, confederations, communities?  This is a much harder argument to
make than it was when I began the BGP MIBv2 work.  Even so, anything not
tagged with if-feature becomes effectively a "mandatory to implement"
component for the management plane.  Certainly you could not implement it,
netconf would return an appropriate commit error or failure on <get> for
operational state that wasn't supported.  However, that'd be inelegant at
best.

It would be good if the WG examines these candiate Yang modules and consider
what they'd want as optional features.  

-- Jeff