I think that it was in the discussion of priorities later on, where all
configuration in <intended> is effectively assigned a single priority by
I2RS so that it can be compared with any incoming I2RS config events.
If the incoming I2RS config is higher priority then any other I2RS
config, and it is higher than the intended config priority then it
effectively overwrites the current configuration. If I2RS config is
displaced then the appropriate I2RS client is notified that their config
has been removed, so that they an take action if required.
But if the incoming I2RS config is lower then either intended or other
I2RS config then the config operation fails and is rejected.
IIRC (from previous discussions), incoming intended configuration will
always overwrite any conflicting I2RS configuration (regardless of
priority), with the I2RS client notified that the config has been removed.
All of this should be explained in whichever I2RS draft defines their
I2RS specific dynamic datastore.
I don't think that we can anything about this in the revised datatstores
draft because I don't think that the config resolution between dynamic
and intended is necessarily always the same - the behaviour depends on
the specific definition of the dynamic datastore. All the datastores
draft can state is that when a dynamic datastore is defined it should
also define how the config merges in, which is covered by appendix
section A.3 of the draft.
Thanks,
Rob
On 19/07/2017 00:10, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Thx for the quick thoughts Rob.
I2RS has defined that a ‘set’ would fail within the dynamic DS but
they didn’t really consider/specify that a ‘set’ to the dynamic DS
could actually fail due to the existence of something in the
conventional DSes. I suppose a custom DS (like the i2rs ephemeral)
can in theory define whatever behavior they want but it may be odd
that something written to the dynamic DS fails when there isn’t
something higher prio in the dynamic DS itself.
But someone can sort that out if they ever propose a model that is
supported both in a dynamic DS and in a conventional DS (assuming we
don’t want to propose guidelines for that behavior in the revised DS
draft).
Rgds,
Jason
*From:*Robert Wilton [mailto:[email protected]]
*Sent:* Tuesday, July 18, 2017 23:11
*To:* Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>;
[email protected]
*Subject:* Re: [netmod] revised-datastores-03: duplicate list entry
from conventional + dynamic
Hi Jason,
Some thoughts inline ...
On 18/07/2017 22:46, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Hi all,
The discussions about dynamic datastores in I2RS today made me
wonder about a scenario: What if a data model is supported in both
conventional datastores and in a dynamic datastore (as well as
being readable from the operational datastore), and the same list
entry (e.g. interface abc, but with some different parms in the
dynamic entry vs the config entry) has been created in both the
running and the dynamic DS.
Only one of them can appear when reading the operational DS.
Yes.
I presume that it is up to the specification document of the
dynamic DS to define the collision resolution between dynamic &
conventional.
Yes.
But based on the revised DS draft I believe it would be necessary
for the system to keep/store both copies of ‘interface abc’ so
that a <get-data> with source=dynamic would return the dynamic
version of interface abc while a <get-config> (or <get-data>) with
source=running would return the conventional version of interface
abc. Do I have that correct ?
Definitely yes for running. For dynamic, it would depend on the
definition of the specific dynamic datastore, but likely yes.
I think that also implies that removing one of the copies could
cause the ‘re-installation’ of the other (down to the app layer).
This would also depend on the definition of the specific dynamic
datastore.
Most likely, if the dynamic entry is removed, then the conventional
configured value should be re-instated. However, I don't think that
the reverse is necessarily true. E.g. in the dynamic datastore is
I2RS then the initial config event would have failed if it was lower
priority that conventional.
This concept of storing multiple copies and re-installation is
something I2RS wants to avoid.
This is perhaps more related to multiple I2RS clients rather than
between I2RS and the conventional datastores.
But since they have declared that their scope only includes the
use of their models in the dynamic (ephemeral) DS, they won’t have
that behavior.
Rgds,
Jason
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
