Subject: [Lsr] When to augment LSR base YANG modules...

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Mar 2019 09:17:06 +0100

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.

---

From: [email-masked]
Date: Fri, 29 Mar 2019 09:31:36 +0100

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-masked]> wrote:
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 30 Mar 2019 16:14:44 +0000

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 [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Chris,

    
    Regards,
    Tony

---

From: Rob Shakir <[email-masked]>
Date: Sat, 30 Mar 2019 11:00:02 -0700

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) <[email-masked]> 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 [email-masked]" <
> [email-masked] on behalf of [email-masked]> 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.
>
>     > 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"? :)
>     >
>     > - 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.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 31 Mar 2019 02:33:06 -0400

> 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 includ…

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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 31 Mar 2019 09:07:32 +0200 (CEST)

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 Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 31 Mar 2019 09:09:29 +0200 (CEST)

On Sat, 30 Mar 2019, Rob Shakir wrote:

> 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.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 31 Mar 2019 08:53:52 -0400

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.

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 31 Mar 2019 10:14:23 -0400

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:[email-masked]] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: [email-masked]; [email-masked]; 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.

Speaking as WG member:

Thanks,
Acee

On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked] <mailto:[email-masked]> " <[email-masked] on behalf of [email-masked]> wrote:

    Chris,

    Regards,
    Tony

---

From: Yingzhen Qu <[email-masked]>
Date: Sun, 31 Mar 2019 17:31:26 +0000

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 <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Sunday, March 31, 2019 at 7:15 AM
To: 'Rob Shakir' <[email-masked]>, "'Acee Lindem (acee)'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Christian Hopps' <[email-masked]>
Subject: Re: [Lsr] When to augment LSR base YANG modules...

Rob and Acee:

Sue

r.

On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

Thanks,
Acee

On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Chris,

    Regards,
    Tony

    > On Mar 29, 2019, at 9:17 AM, Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
    >
    >
    > [email-masked]<mailto:[email-masked]>

    _______________________________________________
    Lsr mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Christian Hopps <[email-masked]>
Date: Sun, 31 Mar 2019 15:41:37 -0400

> On Mar 31, 2019, at 1:31 PM, Yingzhen Qu <[email-masked]> wrote:
> 

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 31 Mar 2019 21:09:32 +0000

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" <[email-masked]> wrote:

    
    But why?

    Thanks,
    Chris.