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

----- Original Message -----
From: "Mikael Abrahamsson" <swmike@swm.pp.se>
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 Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>