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) 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 tony...@tony.li" <
> lsr-boun...@ietf.org on behalf of tony...@tony.li> 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
> 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
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> ___
> Lsr mailing list
>
