Subject: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 18 Jul 2017 20:46:58 +0000

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.

I presume that it is up to the specification document of the dynamic DS to define the collision resolution between dynamic & conventional.

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 ?

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 concept of storing multiple copies and re-installation is something I2RS wants to avoid.  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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 18 Jul 2017 23:10:52 +0200

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.
>
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-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 18 Jul 2017 22:10:27 +0000

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-masked]]
Sent: Tuesday, July 18, 2017 23:11
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic

Hi Jason,

Some thoughts inline ...

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.

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-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 19 Jul 2017 08:18:44 +0200

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:
> 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-masked]]
> *Sent:* Tuesday, July 18, 2017 23:11
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; 
> [email-masked]
> *Subject:* Re: [netmod] revised-datastores-03: duplicate list entry 
> from conventional + dynamic
>
> Hi Jason,
>
> Some thoughts inline ...
>
>     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.
>
>     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 ?
>
>     I think that also implies that removing one of the copies could
>     cause the ‘re-installation’ of the other (down to the app layer).
>
> 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.
>
>
>       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
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>