Re: [netmod] leafref to lists that contain system-controlled entries

[Robert Wilton <[e-mail]>]

Hi Jason,


On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>
> Hi all,
>
> There are a few threads on the mailing list that touch on the concept 
> of system-controlled resources (mostly list entries):
>
> https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
>
> https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
>
> https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0
>
> A few drafts & RFCs also refer to the concept:
>
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
>
> https://tools.ietf.org/html/rfc7223
>
> Several vendor implementations have list entries (instance data) that 
> are populated by the server and can be referenced (leafref) from other 
> places in the configuration.  These system entries are useful 
> pre-created policies, interfaces, etc that can then be used (and 
> referred-to) by operators in their explicit configuration.
>
> If those entries are only expected to exist in the <operational> 
> datastore, then in theory any references to them in user created 
> configuration will cause a validation problem in the candidate/running 
> (missing leafref target).
>
> One solution discussed in the mailing lists is to change every 
> reference to lists that could contain a system created entry to a 
> “require-instance false” leafref. But then some useful validation is 
> lost.  In many cases the model is more correctly “require-instance 
> true” but the set of targets includes the system create entries.
>

I agree that this is not a good general solution for system created 
configuration that is always expected to exist on the device because 
some of the useful validation is lost.

But I think that this solution does work well were the system created 
entries are truly dynamic in nature, e.g. it seems to work well for the 
topology YANG module where the topology may be explicitly configured, 
but would more normally be learned dynamically from protocol 
interactions, or perhaps be configured via a dynamic configuration protocol.

> Another solution discussed is to have the system created entries 
> appear in the <intended> datastore (as part of template/expansion).  
> That would make validation pass on the intended datastore, but then 
> the candidate/running/startup datastores would not be valid (would be 
> missing leafref targets if any part of the config refers to system 
> created entries).  THis sounds similar to the problem that has been 
> discussed in the past about the fact that templates (in the running) 
> basically mean the running/candidate aren’t necessarily valid (until 
> after template expansion, which means only the intended would be valid).
>

I think that this solution is OK, but not necessarily ideal.

As you say, it means that <running>/<candidate>/<startup> may not be 
valid, which I see as quite a big down side.  Longer term, I think that 
it would be a good aim to allow the configuration to be validated off 
the device, if a client desired to do so.


> Another approach could be to actually have those system created 
> entries show up in running/candidate. That would ensure that 
> references to those entries are valid. But if the whole concept of 
> templates just cause the running/candidate to not be valid anyways 
> maybe we wouldn’t worry about the invalid aspect of references to 
> system created list entries ?
>

I know that quite a few implementations do this today, but I'm generally 
not a fan of the system modifying <running>.  It seems that an overall 
architecture is much cleaner if <running> has a single source of truth 
and hence can be exclusively controlled by the client.

But I also like the approach where the client (rather than the device) 
explicitly writes these default entries into the configuration, if they 
are referenced elsewhere by the configuration, to make the configuration 
"complete".  E.g. if part of the configuration references the loopback0 
interface then also explicitly add the necessary loopback0 configuration 
to instantiate the "loopback0" interface.  When this configuration is 
pushed to the device (i.e. using merge or replace operation semantics) 
then the system should silently accept/ignore the explicit configuration 
to create the loopback0 interface if it already exists on the system.


At the moment, IETF, and other SDOs are busy defining standard YANG 
models, but for those models to end up being truly generic they also 
need to have consistency about which bits of configuration are always 
expected to implicitly exist on the device.  E.g. considering the 
example above of configuration referencing loopback0: if some systems 
automatically create a loopback0 interface and others do not, then a 
generic configuration needs to handle both scenarios.

If IETF standardizes YANG configuration templates, then perhaps it would 
be good to investigate whether some of these "useful default system 
properties" could instead be embodied into one or more standard device 
templates?  These templates could then be explicitly referenced in the 
<running> configuration.  This may allow <running> to be small, but 
still allow it to be "complete" and able to be validated off the box.

Thanks,
Rob


> Rgds,
>
> Jason
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod