On 2019-04-02 12:08, tom petch wrote:
----- Original Message -----
From: "Mikael Abrahamsson" <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
