Re: [Idr] BGP Yang modules and core features

["Susan Hares" <[e-mail]>]

Jeff:

Thank you for this great response for the call to input.  Your message saved
me from writing the second email message on "if-feature".   Did we really
have heated debate  - I thought it was a "lively debate" (smile)?    

<chair hat on> 
First would be good to get input from those who have implemented if-features
on impact on setting configs or the dynamic nature (i2rs).    Second,  if
your BGP implementation does not support the BGP Yang modules covered by
both Yang drafts - would you contact me (off-list is fine): 
 
(bgp-yang) draft-zhdankin-idr-bgp-cfg-00
(oc-b gp) OpenConfig 
RFC4271 BGP Protocol Specification [bgp-yang & oc-bgp]
RFC1997 BGP Community Attribute [bgp-yang & oc-bgp]
RFC4456 BGP Route Reflection  [bgp-yang & oc-bgp]
RFC4760 BGP Multiprotocol Specification [bgp-yang & oc-bgp]
RFC3065 Autonomous System Confederations for BGP [bgp-yang & oc-bgp]
RFC2439 BGP Route Flap Dampening [bgp-yang & oc-bgp]
RFC 4724 BGP Graceful Restart [bgp-yang & oc-bgp]
RFC 6811 BGP Origin Validation [bgp-yang]

Jeff raised the issue on the call that some groups of BGP applications may
not support these BGP functions.  The IDR chairs would like to hear from
users or implementers. IMHU - (in my humble understanding)  most open source
implementations support all but RFC6811.  
<chair hat off> 

<Individual contributors hat on>
I think the If-features can be useful for allowing a set of BGP Yang
defined, and allowing nodes/implementations to signal what BGP support the
note has functioning.   If most implementations support these base features,
then including this in a base yang modules is helpful to iplementors.  
<individual contributors hat off> 

Sue Hares 

-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Jeffrey Haas
Sent: Tuesday, February 10, 2015 6:29 PM
To: [e-mail]
Subject: [Idr] BGP Yang modules and core features

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

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr