Hi,
This is becoming a long thread, and it is already recurring theme. It is a
quite interesting and perhaps necessary discussion, but I think a summary of
the questions at hand is in order.
Question 1: Data store validity according to current RFCs
Some of the debate concerns what current RFCs say about data store validity. I
believe it is stated quite clearly in RFC 8342 (NMDA), and is supported by RFC
7950 (YANG 1.1) as well as earlier works that:
a) Datastores that MUST be valid for edit-config/edit-data to succeed are
:running, :intended, :startup
b) Datastores that MUST be valid for commit to succeed are :candidate (and
private candidate datastores, as far as they are being discussed)
c) Datastores that do not need to be valid are :operational, :system, :learned,
:default and other dynamic configuration datastores
Question 2: Validity relation between :running and :intended
Pre-NMDA there is no difference between :running and :intended, so if one is
valid, the other is valid too. Simple. With NMDA, some transformations between
the two are allowed. Implementations will most certainly want to validate only
once for each edit-config/edit-data/commit, so should that be on :intended or
:running?
I think validating either one works fine, but on one condition: that the
transformations applied guarantees that the validity of the datastores stay
interlinked. If :running is valid that implies :intended is valid. And also, if
:intended is valid, that implies :running is valid.
This requirement obviously puts some rather serious constraints on what you can
do. Server implementors will have to be rather restrictive on what
transformations are applied between :running and :intended, or they will have
to be a little more cautious about what YANG constraints they proclaim in the
server's YANG interface. Any YANG constraints need to be general enough to
apply to both :running and :intended.
Nobody forces a server implementor to declare any constraints (that they may
feel are difficult to uphold) in their YANG interfaces. But if this means the
server often uses its right to "randomly" refuse configuration change without
apparent reason, as seen from a YANG perspective, we may be headed back to the
dark SNMP ages again even if this is allowed by current RFCs.
Question 3: Proposed changes to NMDA-validity model
There have been some proposals to change the NMDA (and also YANG 1.1) validity
model in various ways. In several proposals the idea is that the YANG
constraints should apply only to :intended, or to :intended merged with the
:system datastore in some way or other (where :system may or may not refer to
the :system datastore as described in NMDA).
Since this question is not about agreed upon RFC contents, it is a matter of
opinion, taste and architecture.
As you may be aware, I have voiced rather strong skepticism around changing the
validity model, but please allow me to nuance and explain this stance a little.
I believe one of the real values brought to network management by NETCONF/YANG
is the introduction of clearly documented and trustworthy management interfaces
with predictable behavior. If we change the validity of the YANG interface
description to only apply to :intended, what do we know about the rules of
:running? A client cannot write to :intended, but has access to :running
(possibly only indirectly through :candidate or :startup).
Currently there is no formal way for a device to describe what the
transformation step between :running and :intended does, so in principle the
client has no way of knowing what rules apply to :running. We're back to the
lawless land of SNMP. What most clients would do is either to start reading up
on vendor specific interface descriptions in english (bye bye automation level
3 and higher), or assume the YANG interface description is relevant for
:running anyway and hope for the best. Not very attractive IMO.
Another reason to keep the YANG constraints relevant for :running is that this
is what a fair amount of pre-NMDA clients (rightfully) assume.
I can see two paths forward, if we want to separate the validity of :intended
from :running. Either servers will need a way to describe the transformations
done between the two, so that clients can figure out what is valid or not for
themselves. Or we will need to introduce separate YANG descriptions for
:running and :intended. Realistically, I expect this could would be done with
some sort of YANG extensions that declare which constraints that do not apply
to :intended, or which additional constraints should be placed on it.
Question 4: Datastore validity with respect to hardware/environment
In YANG, great care has been taken to design it such that it is possible to
express formal validity constraints only within the upcoming configuration.
Specifically, it is not possible to express constraints towards the current
configuration, nor to the operational state. This is no accident, and was done
in order to allow clients to reason about, generate and communicate the desired
configuration without knowing much about the server implementation or current
(and ever changing) state. This avoids many of the horrors of SNMP.
Despite all of the careful design above, NETCONF/YANG allows a server to reject
any configuration change for any reason, so it is clearly possible to implement
validity constraints based on current configuration, operational state or
anything else. This obviously includes currently available hardware resources.
A server that gets a configuration for a theoretically possible, but currently
non-existent interface ge4711 can thus react in one of two ways:
a) Either the configuration is rejected on the basis of the relevant hardware
not being present. This constraint could never be expressed in the YANG, so
unless the client has some sort of (vendor specific) way of knowing which
hardware resources are present, it could not have known whether the
configuration request would succeed or fail. Well, NMDA aware clients might be
reading :operational to have an idea about what interfaces are physically
present (a few milliseconds ago, anyway).
b) Or else the configuration is accepted despite hardware not being present.
Obviously the configuration will not make it into :operational, but the server
can indicate this situation with some operational data, and possibly
notification.
c) One middle variant of this are the servers that modify their own :running
datastore spontaneously ("autoconfig") to add and remove configuration as
hardware resources are brought in and out of the system. This behavior gives
clients a way to know what hardware is present, but they need to be told about
this (vendor specific) behavior outside the realm of YANG, and it's not always
easy for a client to deal with the spontaneous changes.
Question 5: Hardware, :system, :running and references in between
Current RFCs (see Question 1) state clearly that any constraints (e.g.
leafrefs) in :running have to be fulfilled by configuration in :running. The
system-datastore draft is proposing resolve-system as a mechanisms where the
server can assist aware clients in filling in/copying missing pieces of the
(e.g. hardware) configuration. What happens when :running is referencing
hardware which has been removed may not be entirely clear yet. Other RFC change
proposals (see Question 3) may also be relevant.
Question 6: Copying TPM keys into :running
This thread started with the realization that "the requirement of copying keys
[and] certificates into running doesn't seem ideal". Clearly, copying things
from TPMs into running is a nuisance for clients, a usability problem (what if
the key changes on the TPM outside of :running?) and a potential security
problem. As far as I can see, there is no requirement in NETCONF/YANG to do any
of this copying. A simple reference to the contents (not unlike if the keys
were inserted hardware) in the TPM should be fine. It's simply a matter of
modeling appropriately in the relevant YANG modules.
Sorry for the long response in the middle of an IETF week. :-)
Best Regards,
/jan
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
