Hi,
Last week I published an updated version of
draft-wilton-netmod-refined-datastores-01
<https://datatracker.ietf.org/doc/draft-wilton-netmod-refined-datastores/>that
proposes an alternative datastore architecture to that proposed in
draft-schoenw-netmod-revised-datastores-01
<https://datatracker.ietf.org/doc/draft-schoenw-netmod-revised-datastores/>
These two drafts came out of the discussions related to the opstate
problem, and the differences effectively represent some of the points on
which the adhoc design team didn't reach consensus on.
Fundamentally, both of these drafts provide an architecture to solve the
same problem, and hence there are quite a few similarities between the
drafts:
1) both drafts split the running configuration datastore into the
abstract concept of separate intended configuration and applied
configuration datastores.
2) both drafts introduce a new "operational state datastore" (but with
different contents and semantics).
3) both drafts suggest how the I2RS ephemeral state would fit into the
architecture (but in different ways)
4) both drafts introduce the concept of system created config true nodes
in the "operational state datastore", and both drafts agree that these
nodes exist outside the applied configuration.
From my understanding, I think that the following are the key points
where the two drafts differ, and hence were input from the WG is
particularly desirable:
1) draft-schoenw refines (or perhaps redefines) the NETCONF definition
of the "running configuration datastore" to be just the clients
persistent intended configuration. draft-wilton gives this datastore a
new name (i.e. persistent configuration) and keeps the "running
configuration datastore" defined as the combined intended + applied (and
supported in a mostly backwards compatible way).
2) draft-schoenw defines the intended config and applied config as
regular datastores, that clients would optionally be able to query and
interact with in the same way as for regular datastores. Conversely,
draft-wilton defines both intended config and applied config as
"abstract datastores", meaning that although a server could expose them
as regular datastores, but there is no requirement to, instead it is
proposed that the information contained within them would be made
available via an optional YANG metadata extension to the other
datastores (e.g. along the lines described in
draft-wilton-netconf-opstate-metadata-00
<https://datatracker.ietf.org/doc/draft-wilton-netconf-opstate-metadata/>).
3) draft-schoenw defines the applied configuration as a datastore
defined separately from the "operational state datastore". draft-wilton
treats the "applied configuration" as a subset of the config true leaves
in the "operational state datastore". This particular difference has a
couple of key implications:
3a) In draft-schoenw the config true leaves in the "operational state
datastore" do not represent the configuration that has been applied, but
instead represent the operational state of the device, but overlaid
(where possible) onto the config true schema nodes. E.g. a device might
have a config true "ethernet speed" leaf that is set to "auto" in the
"applied configuration datastore", but that would be set to the actual
speed of the interface (e.g. 10Gbits/s) in the "operational state
datastore".
In draft-wilton, the config true leaves in the "operational state
datastore" represent the exact applied configuration plus system created
entries. In the same ethernet speed example, the "ethernet speed"
config true leaf would be set to "auto" in the "operational state
datastore", and a separate config false leaf also in the "operational
state datastore" would be used to represent the actual speed of the
interface (which may also need to be expressed using a different
datatype anyway). Separate config false leaves are only required where
the system state could differ from the configured leaf value (i.e. as is
the case for NETCONF/YANG implementations today that return running
configuration + separate config false state nodes for operational state).
3 b) Because draft-schoenw defines the applied configuration as a
separate datastore, this requires that clients that want to learn of the
applied configuration have to interact with the separate applied
configuration datastore. With draft-wilton, clients only need to
interact with the operational state datastore + optional metadata to
learn of the applied configuration.
4) draft-schoenw introduces the concept of active/inactive
configuration, this is not currently considered in draft-wilton.
5) draft-schoenw proposes that ephemeral configuration is handled after
applied configuration, and is handled as extra input into the
operational state datastore. draft-wilton proposes ephemeral
configuration to be part of both the intended and applied configuration
for the system and hence handled more like a separate optional
datastore. draft-wilton defines that the "operational state datastore"
also contains the applied ephemeral configuration and ephemeral
operational state.
6) draft-wilton defines how statistics are handled as part of the
"operational state datastore".
Juergen, I have tried to keep this as an objective comparison between
the two drafts. Of course, If I have misrepresented any of the points
of draft-schoenw in any way then please correct my comments above.
Comments from WG participants is welcome.
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
