Acee Lindem (acee) <[email protected]> writes:
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".
If I had to choose between being able to use a feature (management) and supporting BGP-LS inline, I guess I choose management. I don't think this needs to be a one-or-the-other choice though. Please note that this isn't like SNMP, and it's not like creating a base-module that will require lots of revisions and text. Adding a YANG section shouldn't add huge swaths of text, rather a small auto-generated tree diagram (for quick perusal) and the small module definition that augments the base module should be all that's needed. The functionality is being defined in the same document so there's no need to repeat it for the management section. YANG doctor reviews can happen in parallel with other reviews, and this has not been something that holds documents up in my experience at all. The overall document process *does* hold things up so having 2 documents instead of 1 actually creates more opportunity for (superfluous) delay. I think it's worth trying this out to gain some experience and data; we don't have to create a requirement. Indeed, I think that if the management of the new functionality is sufficiently complex that it requires it's own non-trivial amount of work to get right, I think it's reasonable to do this in a second parallel document too.
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.
Why? If you batch things together you then have to add a bunch of conditional "features" that the client has to check anyway. These features are reported through capability entries. IOW, they look just like small modules except now you have 2 entries instead of one (the parent module capability and the feature capability). There's no reduction in complexity by batching, it actually makes things more complex. Thanks, Chris.
Thanks, Acee On 3/29/19, 4:33 AM, "Lsr on behalf of [email protected]" <[email protected] on behalf of [email protected]> 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
