Re: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

[Martin Bjorklund <[e-mail]>]

Hi,

There is some overhead attached to a module.  In the extreme case,
each module could have a single node, this is clearly problematic.  It
is harder to know where to find the node you're looking for, and it is
harder to get node path right if every node may have a new
namespace/module-name.

Rather than collecting 1-4 "things" in a batch, which would introduce
delays, would it be possible to simply re-publish a single module with
all these augmentations?

A variant of this could be to have a single main module that just
includes a bunch of sub-modules (one per augmentation), and let each
new document add a new submodule and at the same time re-publish the
main module with a new include statement.  Perhaps even have IANA
maintain the main module?


/martin


Christian Hopps <[e-mail]> wrote:
> Hi YANG Doctors,
> 
> So I started a thread on the LSR mailing list (included below) about
> including small modules to augment the base protocol modules inline
> with the small feature drafts that modify the protocol (typically
> adding TLVs and some config). We probably publish 1-4 of these per
> year. An opposing opinion was expressed that we should batch these
> features into meta-modules to avoid creating "too many" modules. I
> don't know what too many is, and I pointed out that to a client
> there's really no difference between N modules and 1 module with N
> optional features (they all show up as capabilities).
> 
> So to quote Acee here:
> 
> 	"Let's have a discussion on YANG doctors list on the merits of a small
> 	module per feature vs an aggregate model with features."
> 
> There are process issues that are outside the scope of YANG (e.g.,
> will it cause too many authors on a document, delays caused by
> batching etc).. but we're curious if there are any reasons particular
> to YANG to do or avoid one or the other.
> 
> Thanks,
> Chris.
> 
> > Begin forwarded message:
> > 
> > From: "Acee Lindem (acee)" <[e-mail]>
> > Subject: Re: [Lsr] When to augment LSR base YANG modules...
> > Date: March 31, 2019 at 5:09:32 PM EDT
> > To: Christian Hopps <[e-mail]>, Yingzhen Qu
> > <[e-mail]>
> > Cc: Susan Hares <[e-mail]>, Rob Shakir <[e-mail]>,
> > "[e-mail]" <[e-mail]>, Tony Li <[e-mail]>
> > 
> > Hi Chris, Yingzhen,
> > 
> > Let's have a discussion on YANG doctors list on the merits of a small
> > module per feature vs an aggregate model with features.
> > 
> > We can try this as an experiment. Perhaps, we can get a permanent
> > dispensation to the 5 author rule if every draft needs someone YANG
> > fluent and familiar with the base OSPF and ISIS models.
> > 
> > Thanks,
> > Acee
> > 
> > On 3/31/19, 3:41 PM, "Christian Hopps" <[e-mail]> wrote:
> > 
> > 
> > 
> >> On Mar 31, 2019, at 1:31 PM, Yingzhen Qu <[e-mail]>
> >> wrote:
> >> 
> >> There are many small feature drafts in LSR, for example:
> >> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ it only
> >> adds H-bit to router-lsa.
> >> 
> >> For sure we want models to be modular, but not too many tiny
> >> pieces. Maybe we should combine a few small features like H-Bit into
> >> one module?
> > 
> >    But why?
> > 
> >    Delaying the publication of the management definition until some (so
> >    far as I can tell) arbitrary number of features has been collected
> >    negatively impacts users. What do they gain in return?
> > 
> >    Thanks,
> >    Chris.
> > 
> >> 
> >> Thanks,
> >> Yingzhen
> >> 
> >> From: Lsr <[e-mail]> on behalf of Susan Hares
> >> <[e-mail]>
> >> Date: Sunday, March 31, 2019 at 7:15 AM
> >> To: 'Rob Shakir' <[e-mail]>, "'Acee Lindem (acee)'" <[e-mail]>
> >> Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
> >> <[e-mail]>, 'Christian Hopps' <[e-mail]>
> >> Subject: Re: [Lsr] When to augment LSR base YANG modules...
> >> 
> >> Rob and Acee:
> >> 
> >> I agree that with Rob that it is a generic problem that you must have
> >> a robust way to version and revise the Yang models.  This is true for
> >> configuration, operational data, and dynamic data stores.  The netmod
> >> modeling is focusing on configuration at this time.
> >> 
> >> It is critical to determine how the base models yang models prepare
> >> for augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key
> >> models.  Since our protocols are augmented based on capabilities,
> >> augmentation based on the same capabilities for models makes the most
> >> sense.  We can review info/data, and code functionality based on the
> >> key senses.
> >> 
> >> If we have good versioning of the base model, can revise both the data
> >> model and the capability independently.  If we utilize the grouping of
> >> data models based on the versioning, automatic deployment of this work
> >> can occur.
> >> 
> >> Acee and Chris has been actively participating on the versioning
> >> discussion in netmod’s work on versioning.  I’m sure they can report
> >> if they feel the support his there for this type of version.
> >> 
> >> BGP and rtgwg can integrate this type of version prior to the upcoming
> >> WG LC.
> >> 
> >> Sue
> >> 
> >> 
> >> From: Lsr [mailto:[e-mail]] On Behalf Of Rob Shakir
> >> Sent: Saturday, March 30, 2019 2:00 PM
> >> To: Acee Lindem (acee)
> >> Cc: [e-mail]; [e-mail]; Christian Hopps
> >> Subject: Re: [Lsr] When to augment LSR base YANG modules...
> >> 
> >> I think this is a generic challenge that has to be solved across all
> >> protocols -- and relies on a robust way to version and revise YANG
> >> modules in the IETF.
> >> 
> >> In OpenConfig, as we're very lightweight for pushing a new revision,
> >> since we're just specifying new versions of modules, adding new
> >> features to an existing module is pretty trivial. They can be done as
> >> a minor revision if there's no backwards incompatible changes.  It
> >> seems better, to me, to ensure that there is common logic for how one
> >> splits up modules, to make things actually usable for developers
> >> trying to consume them, rather than needing to understand when and
> >> where in the IETF a feature was developed.
> >> 
> >> That being said -- this means one should probably expect each LSR base
> >> module to be revised with most new LSR RFCs. With the current agility
> >> of the review and publication process -- I'm not sure that is
> >> realistic either.
> >> 
> >> r.
> >> 
> >> On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <[e-mail]>
> >> wrote:
> >> Speaking as WG member:
> >> 
> >> For many of the new LSR WG documents, we are already included both
> >> OSPF and IS-IS encodings in a single document. Now, we have agreed
> >> that documents requiring simple BGP-LS changes will also include the
> >> BGP-LS encoding. Given this, I don't want to add another requirement
> >> for publication of a WG document. This would also add additional
> >> reviews to the document. You've all heard the expression "divide and
> >> conquer", while let me introduce the corollary, "consolidate and
> >> stagnate".
> >> 
> >> Additionally, I agree with Yingzhen's comment that it is not clear
> >> that we want a separate YANG module for every OSPF/IS-IS feature.
> >> 
> >> Thanks,
> >> Acee
> >> 
> >> On 3/29/19, 4:33 AM, "Lsr on behalf of [e-mail]"
> >> <[e-mail] on behalf of [e-mail]> wrote:
> >> 
> >> 
> >>    Chris,
> >> 
> >>    One concern is simply one of scale: doing this will increase the size
> >>    of the document.  At what point do things become sufficiently awkward
> >>    that we want to have a separate, concurrent document.
> >> 
> >>    In other words, if the requirement is for concurrent delivery, is
> >>    co-location really a requirement?
> >> 
> >>    Regards,
> >>    Tony
> >> 
> >> 
> >>> On Mar 29, 2019, at 9:17 AM, Christian Hopps <[e-mail]>
> >>> wrote:
> >>> 
> >>> 
> >>> The base YANG modules for IS-IS and OSPF both include operational
> >>> state to describe TLV data. During the discussion about OSPFv3's
> >>> version of this data, I brought up the issue of when and how the base
> >>> modules should be augmented to add new TLV types to the model,
> >>> suggesting it be done inline and with the RFC that adds the new
> >>> feature/functionality to the protocol.
> >>> 
> >>> I'll go farther here and say this should apply to all the YANG
> >>> required for management of the new feature, and it should all be added
> >>> inline with the feature (i.e., in the same draft). In other words new
> >>> features/functionality should include the YANG augment required to
> >>> manage said features/functionality.
> >>> 
> >>> This has been suggested/tried previously with SNMP with varying (low)
> >>> levels of success. The difference here is 1) YANG additions (a new
> >>> module perhaps just augmenting the base) is easy, whereas SNMP
> >>> wasn't. Additionally, operators weren't using SNMP to fully manage
> >>> functionality (e.g., not doing configuration) so a requirement for
> >>> extra work was harder to justify. Operators *do* want to fully manage
> >>> their networks/servers with YANG though.
> >>> 
> >>> The argument against this during the meeting was that it would create
> >>> many small modules. I don't find this compelling (i.e., "so"? :)
> >>> 
> >>> Assume I'm an operator -- the actual consumer of this management
> >>> stuff:
> >>> 
> >>> - If I'm going to use this new feature X, I need to be able to manage
> >>> - it. So I need it YANG for it. Not only do I need any new TLV data in
> >>> - the operational state, but I need the configuration and any other
> >>> - operational state right along with it. Otherwise each vendor has to
> >>> - add new YANG to their vendor modules, or the feature is useless to
> >>> - me. I can't use something if I can't turn it on.
> >>> 
> >>> - I don't care about having many smaller modules that augment the base
> >>> - module -- at all. Quite the opposite actually, when new functionality
> >>> - is accompanied by it's own module it provides me a simple way to see
> >>> - if that functionality is present as the module will be present in the
> >>> - YANG capabilities announced by the device.
> >>> 
> >>> I'd be interested in hearing reasons we (as a WG) shouldn't just
> >>> expect a YANG module (even if it's small) to be included with drafts
> >>> that add new functionality.
> >>> 
> >>> Thanks,
> >>> Chris.
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lsr
> >> 
> >>    _______________________________________________
> >>    Lsr mailing list
> >>    [e-mail]
> >>    https://www.ietf.org/mailman/listinfo/lsr
> >> 
> >> 
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lsr
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lsr
> > 
> > 
> > 
>