[j-nsp] any way to do group inheritence only if parent exists?

[Chuck Anderson]

On Thu, May 21, 2020 at 07:56:10AM +0300, Saku Ytti wrote:
> Hey Chuck
> 
> > set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600
> > set interfaces apply-groups ND6
> >
> > then all irb interfaces get a "family inet6" with link-local
> > addressing created and the nd6-state-time setting applied.  How do I
> > inherit the nd6-stale-time setting only if there is already a
> > configured "family inet6" so I don't get IPv6 link-locals on IRBs
> > where I only want IPv4?
> 
> As far as I know, you can't. I'm sure if you push this at JNPR they
> are able to support it via 'family <inet6>'. However as it is today,
> <inet6> only works for user input, not for parameters or keywords,
> which I suspect is not actually that huge change in parser.
> So if this would in in parser:
> 
> set family ?
> <family>   Interface protocol family
> 
> Then you could do 'family <inet6>' and it would only apply when that
> family exists. However, now as it's not user-input, it doesn't work
> and I don't think there is a way.

Is Phil Shafer reading?

> Having said that, configuration groups in junos are really great tool,
> while usually people use them to avoid repating themselves, I think
> perhaps even better use-case is to use them as namespaces, for
> example, put all your standard static config in 'template' namespace.
> So you you can programmatically do this:
> 
> edit groups template
> delete
> load merge relative https://nms/junos.template
> commit and-quit
> 
> Leaving all device-specific config intact, while normalising all generic config.

Another great use (thanks to Phil Shafer for the suggestion) is to use
configuration groups combined with user classes as a finer-grained
access control mechanism for automation.

set system login class AUTO-PREFIX-LIST permissions configure
set system login class AUTO-PREFIX-LIST permissions view
set system login class AUTO-PREFIX-LIST permissions view-configuration
set system login class AUTO-PREFIX-LIST allow-commands junoscript
set system login class AUTO-PREFIX-LIST allow-configuration "(groups AUTO-PREFIX-LIST policy-options .*)"
set system login user autoprefix class AUTO-PREFIX-LIST

set policy-options prefix-list LIST1 apply-groups AUTO-PREFIX-LIST
set policy-options prefix-list LIST2 apply-groups AUTO-PREFIX-LIST
set policy-options prefix-list LIST3 apply-groups AUTO-PREFIX-LIST

The lists are populated by NETCONF script that cannot access any other
"policy-options" config, but can still create/delete new lists whose
names are not known beforehand:

set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 10.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 20.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 30.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 10.20.20.20/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 20.20.20.20/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST3 30.20.20.20/32

> And further, don't use configuration groups, at all :) Do it all on
> NMS side, so that you are less reliant on vendor tools and
> limitations. Then you have as much flexibility on them as you wish and
> it works for all your vendors.

Any NMS(es) you recommend?  This one looks interesting:

https://napalm-automation.net/enms-hackathon-project-presentation/

and it is still under development.