Re: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Reshad,

Please see inline …

From: Reshad Rahman (rrahman) <[e-mail]>
Sent: 13 January 2020 23:39
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Subject: Re: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

Hi Rob, all,

PSI.

From: Netmod-ver-dt <[e-mail]<mailto:[e-mail]>> on behalf of "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 10, 2020 at 5:10 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

Points from the meeting what would be good for further discussion.  I think that a lot of these issues are probably still open and require further discussion:


1)     It is clear that we need to standardize supporting different versions of a schema, but do we also want to support different schema families (e.g. vendor vs IETF vs OC)?

a.       My personal view is that it would be good if the model is general enough that this can be described (and I think that it might be useful if there are some examples given in the appendix).

2)     For supporting non-native schema, there seem to be two approaches:

                                                                        i.     always translate into the native schema, reads from say OC convert back from the native schema

                                                                       ii.     store/persist configuration in the external schema (e.g. OC).  E.g. so a get-config on OC would only get back what had been written to the OC schema, not any other schema.

b.      Do we need to describe these two approaches?  For secondary schema does the model need to indicate which method is being performed, or is that purely an implementation detail?
<RR> We could give examples of how this could be implemented but I’m not sure there will be consensus on this. And I’m worried this could be opening a can of worms for no perceived benefit. But maybe there’s no way out of discussing how it could be implemented.
[RW]
Perhaps this could go in an appendix as non-normative text, or may be in the introduction sections?

My concern is that readers will think that this solution is too complex, my thoughts on how to mitigate that are two fold:

  1.  To give implementations a lot of choice in terms of what they choose to support.
  2.  To give some clues on how the version selection could be implemented.

The draft might also need to talk about datastores, in that the secondary-schema probably implicitly create a separate set of datastores (with different schema) that map into the datastores using the primary schema.  The externally visible names of the secondary datastores are effectively the same as the primary datastores that they map to (and are aliasing).

Also from a client perspective, when a client accesses a secondary schema, I think they may want to know whether (i) they are just seeing a subset of the configuration, or (ii) they are seeing all of the configuration translated into that secondary schema.  E.g. if the OpenConfig case, will the client only see interfaces that have been configured in OpenConfig, or will they also see interfaces configured in the native schema?  Given that this could impact client behaviour, can this just be left as an implementation detail?  Maybe this issue should be deferred to a future revision.




3)     Can both of the approaches described in (2) above work for different versions of the schema?  Or must these always be handled by dynamic translation.

4)     What is the schema that the configuration is persisted in?  Should this automatically be tied to the default schema, or should this a separate data node, that could potentially be configurable?

a.      Related to this, how does the system handle changing the default schema?  Can that be done as part of a config request?  Does the connection have to be closed and re-opened?  Or should it be an RPC outside of configuration?
<RR> Should that exercise be left to the reader ☺.
[RW]
Perhaps.  It probably requires further discussion. 😉

What I mean is that some of this could be implementation specific (e.g. what schema is used to persist config).
[RW]
My hunch is that defining an explicit primary schema that is used to persist the configuration probably makes it easier to understand from both a client and server perspective.  I.e. if this doesn’t make the solution too restrictive then having this constraint seems software helpful.

For changing the default schema let’s try to see how it can be done with config request and if that doesn’t fly we go to RPC. One issue with config we had discussed before is that the config for default schema has to be in all schemas.
[RW]
I think that changing the default (primary) schema via direct configuration has various issues (as per my prior reply to Joe) that potentially seem to go away if we use a separate RPC instead.



5)     We need a concise way of describing the relationship between schema and datastores.  The current approach in the model is somewhat verbose, if every datastore needs to be described separately (but is somewhat aligned to YANG library style).

a.      Should we allow schema to only support some datastores (e.g. only operational, or only conventional configuration)?

6)     Do we need secondary schema to have the ability to be defined or described as only being read-only?

a.      E.g. I can see a requirement to allow a client a configure a device using an older version of the schema.  I can also see a requirement of allowing a client to see what the instance data against a older version of a schema would look like in a more current version.  But I’m less convinced of the need to be able to convert a current configuration back into an older format.
<RR> If the secondary schema is read-only then that diminishes its usefulness so we should strive to have it writable. Converting config to an older format shouldn’t be a requirement IMO.
[RW]
I wasn’t intending to require all secondary schema-sets to be read-only, but allow implementations where they want particular secondary schema-sets to be read-only.  E.g. so a device can be setup such that it allows a client to see older config translated into a new config version, but does not support the reverse translation.

Thanks,
Rob



Regards,
Reshad.

Perhaps we can discuss some of these over email, and try and reach consensus, or otherwise we will pick up discussion in next week’s meeting.

Was there anything else that I missed?

Thanks,
Rob


From: Netmod-ver-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Rob Wilton (rwilton)
Sent: 09 January 2020 14:11
To: [e-mail]<mailto:[e-mail]>
Subject: [Netmod-ver-dt] Today's Ver DT meeting

Happy New Year!

From the last meeting I did say that I would work on producing some concrete examples of version selection 😊

I’ve started working on this, but more work is required.  I have attached one example that we can discuss in the meeting, more may be forthcoming before the meeting.

As part of that work, I’ve been thinking more about the default/secondary schema.

As a recap, I think that this is roughly where I am at:


(1)   The default schema:

o   is the schema that is used if a client doesn’t specify a secondary schema during their connection (i.e. NETCONF capabilities negotiation, or RESTCONF path).

o   is also the schema used for the persistent configuration (and the <startup> datastore). [I think that this is probably right, but might need further thought/discussion]


(2)   Secondary schema:

o   are additional schema that clients can choose to use, and are specified during their session (i.e. NETCONF capabilities negotiation, or RESTCONF path).

o   can probably take several forms:

§  A filtered view on the default schema (e.g. if the default schema supported vendor native + IETF + OC schema) then a filtered schema view might just be the OC subset.  This should be simple to support since it broadly equivalent to a subtree filter on any get operations.

§  A translated view on the default schema (e.g. perhaps a different version of a schema),  All reads/writes to a translated schema are converted to/from the default schema.  The configuration is persisted in the “default schema”.

o   It might be useful if some of the secondary schema could be labelled as read-only views on the data.  E.g. it might be reasonable to see the configuration using a secondary schema non native version, but not allow it to be modified.

Attached example:

Example 1, a simple example of a server supporting two schema versions, and the client can choose between which version is used for the primary schema.

-        One question related to this example is what happens to the current configuration if a client changes the default schema to a different version.  Does that configuration also automatically get translated as well?  What happens if that translation fails?

-        Do we need a simpler way to reporting the per datastore schema?  E.g. should we have a special value to identify all datastores, or all conventional datastores?

Thanks,
Rob