> On Mar 31, 2019, at 1:31 PM, Yingzhen Qu <yingzhen...@huawei.com> 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 <lsr-boun...@ietf.org> on behalf of Susan Hares <sha...@ndzh.com> > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' <r...@rob.sh>, "'Acee Lindem (acee)'" <a...@cisco.com> > Cc: "lsr@ietf.org" <lsr@ietf.org>, "tony...@tony.li" <tony...@tony.li>, > 'Christian Hopps' <cho...@chopps.org> > 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:lsr-boun...@ietf.org] On Behalf Of Rob Shakir > Sent: Saturday, March 30, 2019 2:00 PM > To: Acee Lindem (acee) > Cc: lsr@ietf.org; tony...@tony.li; 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) <a...@cisco.com> 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 <cho...@chopps.org> 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
