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

[Kristian Larsson <[e-mail]>]

On 2019-04-02 12:08, tom petch wrote:
> ----- Original Message -----
> From: "Mikael Abrahamsson" <[e-mail]>
> 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.