Re: [Lsr] When to augment LSR base YANG modules...
Hi, I don't know anything about yang (module) so everything looks easy from 1 feet. Yet, my 2 cents. > I think the main requirement (speaking as an operator) is to get the YANG > part (ops+cfg) standardized at the same time. +1 to Stéphane & Christian Whether this is done in the same document or via a normative reference to another document is less of an issue, but I think that many IGP extensions typically require a very small extension to the yang model hence could be done in the same document. > While YANG is easy to write, it could still scare pure IGP guys that are > focused on protocol encodings Probably the first draft could be "hard", but given an existing model/example, I would assume that most IGP extensions would be reasonably similar in term or yang additions. > I'm a bit worried about having too many tiny modules [...] > we have few (or even no) experience today on managing modules revisions I think that we need to start walking to gain experience, and then define yang/whatever extensions to improve on either/both of those problems. On the first point, possibly a meta model could reference a set of tiny models, but regardless of the details, I trust yang people to find a solution. In all cases, I don't think those problems would disappear by taking another path. (except deferring yang extensions for... ever). I don't think that delaying yang revisions every N years would be easier as the authors of the IGP extensions are probably the best persons to define the cfg/operational objects needed for their extensions. In all cases, thank you Christian for raising the point. Regards, --Bruno -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Tuesday, April 16, 2019 9:52 AM To: Christian Hopps; lsr@ietf.org Subject: Re: [Lsr] When to augment LSR base YANG modules... Hi, On one hand, I'm a bit worried about having too many tiny modules (finding the right module name to get the right feature, managing prefixes...). The good thing I see is that we could mandate in each LSR draft the YANG management part so both are published at the same time. While YANG is easy to write, it could still scare pure IGP guys that are focused on protocol encodings -> this implies that people may need to rely on people with YANG skills to write the management section. On the other hand, we have few (or even no) experience today on managing modules revisions, do we also foresee some level of complexity ? The issue I see if we update the main YANG base module is that the timing may be different from the protocol encoding spec. Also, are we ready to publish a revision for each tiny feature ?(why not but who takes the pen ? Speaking as editor of ISIS yang module, I'm not really ready to have the pen to modify it for the rest of my life ;) I think the main requirement (speaking as an operator) is to get the YANG part (ops+cfg) standardized at the same time. Brgds, -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, March 29, 2019 09:17 To: lsr@ietf.org Cc: cho...@chopps.org Subject: [Lsr] When to augment LSR base YANG modules... 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 somet
Re: [Lsr] When to augment LSR base YANG modules...
Hi, On one hand, I'm a bit worried about having too many tiny modules (finding the right module name to get the right feature, managing prefixes...). The good thing I see is that we could mandate in each LSR draft the YANG management part so both are published at the same time. While YANG is easy to write, it could still scare pure IGP guys that are focused on protocol encodings -> this implies that people may need to rely on people with YANG skills to write the management section. On the other hand, we have few (or even no) experience today on managing modules revisions, do we also foresee some level of complexity ? The issue I see if we update the main YANG base module is that the timing may be different from the protocol encoding spec. Also, are we ready to publish a revision for each tiny feature ?(why not but who takes the pen ? Speaking as editor of ISIS yang module, I'm not really ready to have the pen to modify it for the rest of my life ;) I think the main requirement (speaking as an operator) is to get the YANG part (ops+cfg) standardized at the same time. Brgds, -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, March 29, 2019 09:17 To: lsr@ietf.org Cc: cho...@chopps.org Subject: [Lsr] When to augment LSR base YANG modules... 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. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
On 2019-04-02 12:08, tom petch wrote: - Original Message - From: "Mikael Abrahamsson" Sent: Sunday, March 31, 2019 8:07 AM On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: 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. As an operator, I expect to manage my routers using YANG modules. Thus, every feature that is introduced that would provide requirement for management and/or provide operational data needs to have an YANG module come with it, otherwise this new feature isn't useful. I don't want YANG to be second class citizen compared to CLI the way SNMP has been. I also want to avoid having vendor-specific YANG modules if possible. Thus it makes sense to require YANG module with every new work. If this is in the same document or an accompanying document is not of importance to me, as long as it gets the YANG module shows up in roughly the same timeframe as the feature. Mikael Do you have any concern about the number of modules involved i.e. in the practical management on Internet routers, does it matter whether the management comes in the form of 100 or 1000 or ... modules? I don't have any real concerns about that. From a technical perspective I have a hard time seeing this being an issue. From a softer point of view, it might be difficult for a human to overlook many models but similarly it is difficult to overlook very large models (and in particular ones with many features). Thus far I think the models that have been published and the ones that are being worked on, usually have a rather reasonable scope, quite often they encompass a piece of technology. Since we do have a great number of different technologies it does mean quite a few models but it isn't conceptually harder for a human to overlook since the technologies are already there. I have a nagging concern, based on experience with older technologies, that difficulties can arise, and that they are not linear with the number of modules. Is management with YANG more difficult if you have 1000 arbitrary prefixes (or module names or module revision dates) floating around or do the tools hide such details and present a coherent picture to an operator? We have devices today that have in excess of 300 models and I don't really think it affects the way they are being managed versus a device that has one model. Working with multiple revisions could perhaps be challenging. Most of the time I find that we look at a given device type and the models it supports, which will be one given revision of a model and thus we can ignore all else at that point in time. Likewise, does it matter how many features there are, with a Cartesian explosion leading to a five or six digit number of combinations? I don't think the combination means much at all. We try not to deal with features in that way but rather individually which then avoids the combinatorial effect. If anything, my concern would be, not as an operator that would operate a network but rather as a YANG model writer that writing a huge model with a very large number of features probably means I'll never finish writing the model and it will likely become unwieldy. Better to split it up into multiple models using augmentations. Kind regards, Kristian. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
- Original Message - From: "Mikael Abrahamsson" Sent: Sunday, March 31, 2019 8:07 AM > On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: > > > 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. > > As an operator, I expect to manage my routers using YANG modules. Thus, > every feature that is introduced that would provide requirement for > management and/or provide operational data needs to have an YANG module > come with it, otherwise this new feature isn't useful. > > I don't want YANG to be second class citizen compared to CLI the way SNMP > has been. I also want to avoid having vendor-specific YANG modules if > possible. Thus it makes sense to require YANG module with every new work. > > If this is in the same document or an accompanying document is not of > importance to me, as long as it gets the YANG module shows up in roughly > the same timeframe as the feature. Mikael Do you have any concern about the number of modules involved i.e. in the practical management on Internet routers, does it matter whether the management comes in the form of 100 or 1000 or ... modules? I have a nagging concern, based on experience with older technologies, that difficulties can arise, and that they are not linear with the number of modules. Is management with YANG more difficult if you have 1000 arbitrary prefixes (or module names or module revision dates) floating around or do the tools hide such details and present a coherent picture to an operator? Likewise, does it matter how many features there are, with a Cartesian explosion leading to a five or six digit number of combinations? Tom Petch > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > 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
Re: [Lsr] When to augment LSR base YANG modules...
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" wrote: > On Mar 31, 2019, at 1:31 PM, Yingzhen Qu 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 on behalf of Susan Hares > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony...@tony.li" , 'Christian Hopps' > 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) 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" wrote: > > > Chris, > >
Re: [Lsr] When to augment LSR base YANG modules...
> On Mar 31, 2019, at 1:31 PM, Yingzhen Qu 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 on behalf of Susan Hares > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony...@tony.li" , > 'Christian Hopps' > 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) 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" 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
Re: [Lsr] When to augment LSR base YANG modules...
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? The bottom line is we need to keep YANG delivery not falling behind too much. Thanks, Yingzhen From: Lsr on behalf of Susan Hares Date: Sunday, March 31, 2019 at 7:15 AM To: 'Rob Shakir' , "'Acee Lindem (acee)'" Cc: "lsr@ietf.org" , "tony...@tony.li" , 'Christian Hopps' 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) mailto: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<mailto:tony@tony.li>" mailto:lsr-boun...@ietf.org> on behalf of tony...@tony.li<mailto: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 mailto: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 word
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) 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 <mailto: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"? :) >
Re: [Lsr] When to augment LSR base YANG modules...
So to have something to look at while we discuss this I wrote a bare-bones module document for IS-IS reverse metrics: https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00 If you look at the meat of that document and then imagine including it as an appendix or whatever with the functional IS-IS reverse metric document (https://tools.ietf.org/html/rfc8500) it doesn't seem that onerous of an addition. And it makes things very nice for the actual users/operators. Overall publishing time should improve b/c we have 1 document to shepherd through the IETF process instead of 2. And, again, if the YANG module is not straight-forward then having separate documents makes sense to me as well. I think we should give it a try with some small upcoming LSR draft -- we can always rip out the management section if it's causing issues. Thanks, Chris. signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
On Sat, 30 Mar 2019, Rob Shakir wrote: 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.. I have discussed this with Benoit before and I've voiced my opinion that the RFC process of handling YANG modules is very slow and cumbersome and doesn't seem to yield desired results. I think the IETF needs a different process to handle YANG modules that is more agile and speedy. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: 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. As an operator, I expect to manage my routers using YANG modules. Thus, every feature that is introduced that would provide requirement for management and/or provide operational data needs to have an YANG module come with it, otherwise this new feature isn't useful. I don't want YANG to be second class citizen compared to CLI the way SNMP has been. I also want to avoid having vendor-specific YANG modules if possible. Thus it makes sense to require YANG module with every new work. If this is in the same document or an accompanying document is not of importance to me, as long as it gets the YANG module shows up in roughly the same timeframe as the feature. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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) 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 >
Re: [Lsr] When to augment LSR base YANG modules...
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" 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] When to augment LSR base YANG modules...
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
