Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

From: tom petch <[email-masked]>
Date: Sun, 2 Jun 2019 11:09:26 +0000

----- Original Message -----
From: "Italo Busi" <[email-masked]>
Sent: Wednesday, May 29, 2019 7:00 PM

> Rob, Tarek,
>
> Thanks for following-up this discussion
>
> I like the suggestion to use a prefix string: those who prefers using
one character (e.g., '#') could use a single character string
>
> Regarding the configuration, one possible issue that just jumped into
my mind is what happens when the prefix is (re-)configured by the client
after some ephemeral tunnels have been created ...

Many years ago, there was a similar discussion about interface names
which never really got resolved but which was a factor in driving NMDA.
Some boxes create their own interface names, others have interface names
configured; and with interfaces, there was a need to use a match of the
identifier to add configured attributes to a entry that the box had
created but to create a new entry if there was not a match.  Roll on
multiple datastores.

Which makes me ask; which datastores are we talking about? I know where
entries configured via NETCONF will go but which datastores will hold
the details of these ephemeral tunnels? Needs clarifying IMHO.

Tom Petch

> An alternative solution could be to let the server decide which prefix
to use (server implementation issue) and to provide a read-only YANG
leaf to report this information to the client, such that the client
knows it could not use this prefix for the configured tunnels
>
> My 2 cents
>
> Italo
>
> -----Original Message-----
> From: Tarek Saad [mailto:[email-masked]]
> Sent: mercoledì 29 maggio 2019 17:22
> To: Rob Wilton (rwilton) <[email-masked]>; tom petch
<[email-masked]>; Italo Busi <[email-masked]>;
[email-masked]
> Cc: [email-masked]
> Subject: Re: [Teas] [netmod] Key collision between configured and
ephemeral list entries
>
> Hi Rob,
>
> Inline..
>
> On 5/29/19, 9:05 AM, "Teas on behalf of Rob Wilton (rwilton)"
<[email-masked] on behalf of [email-masked]> wrote:
>
>     Are these ephemeral tunnels created and named by the device
itself?
> [TS]: yes, some of those are auto-created by the device (e.g.
triggered by some local event).
>
>     Possibly using a human readable prefix (or suffix) might be better
than using a symbol.
>
>     E.g. perhaps a prefix of "sys-" as an abbreviation for system.
> [TS]: I tend to agree here. I had suggested making this prefix
configurable - not sure if this brings more trouble.
>
> [TS]: On a similar note, on the controller, some tunnels from
different ingress routers will be reported up to the controller. One way
to avoid collision of same tunnel name existing on multiple ingress
devices, we thought of is for that controller to (automatically) append
the ingress router name (or IP address) before consuming the reported
tunnel into the controller tunnel list. Thoughts?
>
> Regards,
> Tarek
>
>     Thanks,
>     Rob
>
>     -----Original Message-----
>     From: Teas <[email-masked]> On Behalf Of tom petch
>     Sent: 29 May 2019 12:04
>     To: Italo Busi <[email-masked]>; [email-masked]
>     Cc: [email-masked]
>     Subject: Re: [Teas] [netmod] Key collision between configured and
ephemeral list entries
>
>
>     ----- Original Message -----
>     From: "Italo Busi" <[email-masked]>
>     Sent: Wednesday, May 29, 2019 11:02 AM
>
>     Hi Tom,
>
>     Thanks for your reply
>
>     It seems to me that the text you have quoted is from:
>     https://tools.ietf.org/html/rfc7950#section-6.2
>
>     If I can understand correctly, especially for section 6.2.1, this
constraints does not apply to name attributes whose syntax is defined as
a string and used as key of a list, such as the tunnel list defined in
the TE YANG model:
>
>          |  +--rw tunnel* [name]
>          |  |  +--ro operational-state?                  identityref
>          |  |  +--rw name                                string
>
>     My understanding is that a tunnel list entry with a name starting
with '#' can exist in a YANG DS
>
>     <tp>
>
>     Italo
>
>     Ah yes, my misunderstanding.  'string' type is a bit more flexible
i.e.
>
>        The string built-in type represents human-readable strings in
YANG.
>        Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
>        characters, including tab, carriage return, and line feed but
>        excluding the other C0 control characters, the surrogate
blocks, and
>        the noncharacters.
>
>     Plenty of scope there!
>
>
>     If this approach is taken, then I agree that hash is a good choice
as it stands out, unlike, say, underscore which vanishes in the line of
text.
>
>     Tom Petch
>
>     Thanks, Italo
>
>     -----Original Message-----
>     From: tom petch [mailto:[email-masked]]
>     Sent: mercoledì 29 maggio 2019 10:42
>     To: Italo Busi <[email-masked]>; [email-masked]
>     Cc: [email-masked]
>     Subject: Re: [netmod] Key collision between configured and
ephemeral list entries
>
>     <inline>
>
>     Tom Petch
>
>     ----- Original Message -----
>     From: "Italo Busi" <[email-masked]>
>     To: <[email-masked]>
>     Cc: <[email-masked]>
>     Sent: Monday, May 27, 2019 2:16 PM
>     Subject: [netmod] Key collision between configured and ephemeral
list entries
>
>
>     On Friday within the TEAS WG, we have discussed an issue which
seems generic and therefore agreed to ask for guidelines to the Netmod
WG
>
>     In the TE YANG model we have defined a tunnel list with a name
attribute used as a key:
>
>          |  +--rw tunnel* [name]
>          |  |  +--ro operational-state?                  identityref
>          |  |  +--rw name                                string
>
>     See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21
>
>     The issue we are facing is how to avoid name collision between
configured and ephemeral tunnels. In other words, the issue we are
trying to address is how to avoid the client to assign to a configured
tunnel a name which have been already assigned by the server to another
ephemeral tunnel and vice-versa, in particular considering NMDA rules
>
>     We believe that the issue is generic and apply to any configured
and ephemeral list entries
>
>     Has this issue been already discussed/resolved in Netmod WG?
>
>     If not, what is the Netmod WG opinion/suggestion? We are currently
considering the following option:
>
>        Use a special character for ephemeral names - e.g. such names
always are prepended by special character "#"
>        Make the special character changeable by configuration - the
default can be "#" and user can change if they desire..
>
>     <tp>
>
>     If this is to conform with YANG 1.1, RFC7950, then the constraint
is
>
>        Identifiers are used to identify different kinds of YANG items
by
>        name.  Each identifier starts with an uppercase or lowercase
ASCII
>        letter or an underscore character, followed by zero or more
ASCII
>        letters, digits, underscore characters, hyphens, and dots.
>
>
>     No # (hash) anywhere so I suspect that a lot of tooling will fail
in an unpredictable way if it encounters an illegal character in an
identifier.
>
>     Tom Petch
>
>
>     Thanks, Italo
>
>     Italo Busi
>     Principal Optical Transport Network Research Engineer Huawei
Technologies Co., Ltd.
>     Tel : +39 345 4721946
>     Email : [email-masked]
>
>     This e-mail and its attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose
address is listed above. Any use of the information contained herein in
any way (including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
>     recipient(s) is prohibited. If you receive this e-mail in error,
please notify the sender by phone or email immediately and delete it!
>
>     From: Tarek Saad [mailto:[email-masked]]
>     Sent: venerdì 24 maggio 2019 23:13
>     To: Igor Bryskin <[email-masked]>; Rakesh Gandhi
<[email-masked]>; Xufeng <[email-masked]>; Vishnu Pavan
Beeram <[email-masked]>; Italo Busi <[email-masked]>
>     Cc: [email-masked]
>     Subject: Discussion on modelling container TE tunnels in YANG
>
>     The team on "to" list met to discuss this subject topic. Notes
from today's discussion (please add if I missed):
>
>     Name collision between configured and ephemeral tunnels:
>       This is a generic problem in NMDA.
>       How to handle collisions between configured and ephemeral (or
>     auto-created) objects of a list, if the list uses the object
(string
>     based) name as the key?
>       Both configured and ephemeral can have the same object name but
they are different objects - how to avoid such collision.
>      Proposed solution:
>        Option 1:
>        Use a special character for ephemeral names - e.g. such names
always are prepended by special character "#"
>        Make the special character changeable by configuration - the
default can be "#" and user can change if they desire..
>       Others?
>     AI (Italo): to send email to netmod group.
>
>     Container TE tunnels discussion:
>     -          Container tunnels are grouping of tunnels between same
2
>     endpoints to share incoming traffic towards the egress
>     -          Member tunnels of a container tunnel can be
>     auto-created/deleted on-demand and controlled by thresholds
specified under the container
>     -          Some attributes may apply on the container tunnel and
>     inherited down to member tunnels of the container
>     -          Q: Should model allow member tunnel to override
inherited
>     attributes from container tunnel?
>     -          Q: Should all auto-created member tunnels of a
container have
>     the same prefix/suffix - i..e prefix/suffix can be configurable
>
>     Regards,
>     Tarek
>
>
>
>
>
>
>     ------------------------------------------------------------------
------
>     --------
>
>
>     > _______________________________________________
>     > netmod mailing list
>     > [email-masked]
>     > https://www.ietf.org/mailman/listinfo/netmod
>     >
>
>     _______________________________________________
>     Teas mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/teas
>
>     _______________________________________________
>     Teas mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/teas
>
>

---

From: Italo Busi <[email-masked]>
Date: Tue, 11 Jun 2019 15:40:17 +0000

Hi Tom,

My understanding is that the running DS contains only the list entries configured by the client and therefore there is no key collision (the key values are all assigned by the client)

The issue is that the operational DS will contain two types of list entries:
- list entries representing the applied configuration of the list entries in the running DS (the key values are all assigned by the client)
- list entries representing ephemeral list entries representing dynamic configuration (the key values are all assigned by the server)

Without any rule, it is possible that the client and the server assigns the same key value to two different list entries

If, as proposed below, the server assign key values ephemeral list entries using a prefix which is known to the client, the client can assign key values to the configured list entries not using that prefix thus solving any conflict

I think this solution works as long as we understand how to make the client aware of the prefix being used by the server

My 2 cents

Italo

-----Original Message-----
From: tom petch [mailto:[email-masked]] 
Sent: domenica 2 giugno 2019 13:09
To: Italo Busi <[email-masked]>; Tarek Saad <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

----- Original Message -----
From: "Italo Busi" <[email-masked]>
Sent: Wednesday, May 29, 2019 7:00 PM

> Regarding the configuration, one possible issue that just jumped into
my mind is what happens when the prefix is (re-)configured by the client after some ephemeral tunnels have been created ...

Many years ago, there was a similar discussion about interface names which never really got resolved but which was a factor in driving NMDA.
Some boxes create their own interface names, others have interface names configured; and with interfaces, there was a need to use a match of the identifier to add configured attributes to a entry that the box had created but to create a new entry if there was not a match.  Roll on multiple datastores.

Which makes me ask; which datastores are we talking about? I know where entries configured via NETCONF will go but which datastores will hold the details of these ephemeral tunnels? Needs clarifying IMHO.

Tom Petch

> An alternative solution could be to let the server decide which prefix
to use (server implementation issue) and to provide a read-only YANG leaf to report this information to the client, such that the client knows it could not use this prefix for the configured tunnels
> To: Rob Wilton (rwilton) <[email-masked]>; tom petch
<[email-masked]>; Italo Busi <[email-masked]>; [email-masked]
ephemeral list entries
itself?
than using a symbol.
> [TS]: On a similar note, on the controller, some tunnels from
different ingress routers will be reported up to the controller. One way to avoid collision of same tunnel name existing on multiple ingress devices, we thought of is for that controller to (automatically) append the ingress router name (or IP address) before consuming the reported tunnel into the controller tunnel list. Thoughts?
ephemeral list entries
i.e.
YANG.
blocks, and
>     If this approach is taken, then I agree that hash is a good choice
as it stands out, unlike, say, underscore which vanishes in the line of text.
ephemeral list entries
list entries
>     On Friday within the TEAS WG, we have discussed an issue which
seems generic and therefore agreed to ask for guidelines to the Netmod WG
>     The issue we are facing is how to avoid name collision between
configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules
is
by
ASCII
ASCII
>     No # (hash) anywhere so I suspect that a lot of tooling will fail
in an unpredictable way if it encounters an illegal character in an identifier.
Technologies Co., Ltd.
>     This e-mail and its attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended
>     To: Igor Bryskin <[email-masked]>; Rakesh Gandhi
<[email-masked]>; Xufeng <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; Italo Busi <[email-masked]>
(string
2
inherited
container have
------

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Jun 2019 08:54:11 -0700

On Tue, Jun 11, 2019 at 8:40 AM Italo Busi <[email-masked]> wrote:

> Hi Tom,
>
> My understanding is that the running DS contains only the list entries
> configured by the client and therefore there is no key collision (the key
> values are all assigned by the client)
>
> - list entries representing the applied configuration of the list entries
> in the running DS (the key values are all assigned by the client)
> - list entries representing ephemeral list entries representing dynamic
> configuration (the key values are all assigned by the server)
>
> Without any rule, it is possible that the client and the server assigns
> the same key value to two different list entries
>
>
NMDA has the "origin" attribute so that it is clear to clients the source
of the instances
that are being used in <operational>.  It doesn't matter if the data is a
container, a list, etc.
There can be only 1 instance that is being used by the server at a time
(except
for remnant config).

There are no instance naming collisions within <running> or <ephemeral>.
Only if you try to combine them, which is not how it works. The server
chooses
what to put in <operational> and sets the origin attribute accordingly.

> If, as proposed below, the server assign key values ephemeral list entries
> using a prefix which is known to the client, the client can assign key
> values to the configured list entries not using that prefix thus solving
> any conflict
>
> I think this solution works as long as we understand how to make the
> client aware of the prefix being used by the server
>
> My 2 cents
>
> Italo
>
>

Andy

> To: Italo Busi <[email-masked]>; Tarek Saad <[email-masked]>;
> Rob Wilton (rwilton) <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Many years ago, there was a similar discussion about interface names which
> never really got resolved but which was a factor in driving NMDA.
> identifier to add configured attributes to a entry that the box had created
> but to create a new entry if there was not a match.  Roll on multiple
> datastores.
>
> entries configured via NETCONF will go but which datastores will hold the
> details of these ephemeral tunnels? Needs clarifying IMHO.
>
> Tom Petch
>
> to use (server implementation issue) and to provide a read-only YANG leaf
> to report this information to the client, such that the client knows it
> could not use this prefix for the configured tunnels
> >
> > My 2 cents
> >
> > Italo
> >
> devices, we thought of is for that controller to (automatically) append the
> ingress router name (or IP address) before consuming the reported tunnel
> into the controller tunnel list. Thoughts?
> >
> > Regards,
> > Tarek
> >
> >     Thanks,
> >     Rob
> >
> constraints does not apply to name attributes whose syntax is defined as a
> string and used as key of a list, such as the tunnel list defined in the TE
> YANG model:
> >
> >          |  +--rw tunnel* [name]
> configured and ephemeral tunnels. In other words, the issue we are trying
> to address is how to avoid the client to assign to a configured tunnel a
> name which have been already assigned by the server to another ephemeral
> tunnel and vice-versa, in particular considering NMDA rules
> >
> from HUAWEI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Jun 2019 18:01:06 +0200

On Tue, Jun 11, 2019 at 08:54:11AM -0700, Andy Bierman wrote:

> chooses what to put in <operational> and sets the origin attribute
> accordingly.

And for a robust solution, it is good to have an explicit definition
of which entry takes priority if there is a name clash.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Italo Busi <[email-masked]>
Date: Tue, 11 Jun 2019 16:36:08 +0000

Juergen, Andy,

Thanks for your reply

I agree with your statements as long as we consider two sources for the same information/instance. In this case, my understanding is that the same key value is intentionally assigned by the two sources to indicate that they are representing the same information/instance and only one instance needs to be applied within the operational DS

The issue we are trying to solve is slightly different. We have two different instances from different sources and both of them need to be applied within the operational DS, but unfortunately they have got assigned the same key value ...

Italo

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: martedì 11 giugno 2019 18:01
To: Andy Bierman <[email-masked]>
Cc: Italo Busi <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

> chooses what to put in <operational> and sets the origin attribute 

And for a robust solution, it is good to have an explicit definition of which entry takes priority if there is a name clash.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Jun 2019 19:19:00 +0200

> The issue we are trying to solve is slightly different. We have two different instances from different sources and both of them need to be applied within the operational DS, but unfortunately they…

It does not really matter whether the name clash is intentional or
not. Only one can be used and it should be clear which one will be
the winner.

I do understand that you want to design the models so that name
clashes can be avoided and this is likely fine for what you need but
you need to think through all cases.

- Will names not matching the pattern be rejected? If so, what happens
  to existing entries if the allowed name pattern is changed? Or is
  the pattern cast into stone?

- Another option, in principle, is to suggest that names are chosen
  such that they have a low probability to collide. This sometimes
  leads to simpler implementations since clients do not have to
  generate names conforming to some (configurable?) patterns and
  instead create a name with low collision probability and if the
  config does not make it into <operational>, the client handles the
  name clash. Note that some clients may want to tag their entries
  with specific IDs anyway so that they can easily recognize their
  entries, i.e., clients may have other good reasons to avoid
  generating names that have a high probability to clash.

/js

---

From: Italo Busi <[email-masked]>
Date: Tue, 11 Jun 2019 17:43:27 +0000

Hi Juergen,

Thanks for your reply: see some comments of mine in line below

Italo

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: martedì 11 giugno 2019 19:19
To: Italo Busi <[email-masked]>
Cc: Andy Bierman <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

On Tue, Jun 11, 2019 at 04:36:08PM +0000, Italo Busi wrote:
>
> I agree with your statements as long as we consider two sources for
> the same information/instance. In this case, my understanding is that
> the same key value is intentionally assigned by the two sources to
> indicate that they are representing the same information/instance and
> only one instance needs to be applied within the operational DS
>

It does not really matter whether the name clash is intentional or not. Only one can be used and it should be clear which one will be the winner.
[Italo Busi] I agree. This is why I think we need to avoid unintentional name clash.

I do understand that you want to design the models so that name clashes can be avoided and this is likely fine for what you need but you need to think through all cases.

- Will names not matching the pattern be rejected?
[Italo Busi] Good question. I think that the client should be allowed to create entries with intentional name clashes

If so, what happens
  to existing entries if the allowed name pattern is changed? Or is
  the pattern cast into stone?
[Italo Busi] Another good question. My feeling is that the solution would be much simpler if the prefix is decided by the server, communicated to the client and never changed.

[Italo Busi] If the client knows the prefix used by the server, it can pick up a different prefix and use it to tag its own entries. I think this rule is not really complex and it seems much simpler than managing unintended name clashes

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Jun 2019 20:36:30 +0200

On Tue, Jun 11, 2019 at 05:43:27PM +0000, Italo Busi wrote:

> [Italo Busi] If the client knows the prefix used by the server, it
> can pick up a different prefix and use it to tag its own entries. I
> think this rule is not really complex and it seems much simpler than
> managing unintended name clashes

A prefix only helps a little. Once you have multiple clients creating
entries, you will have to handle collisions again. Sometimes solving
the more general case leads to solutions that also work nicely in
simpler special cases.

/js

---

From: tom petch <[email-masked]>
Date: Wed, 12 Jun 2019 09:39:32 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Tuesday, June 11, 2019 7:36 PM

> the more general case leads to solutions that also work nicely in

Picking up on the point earlier about needing a rule about what to do
when a collision occurs, the collision only occurs when the second (or
third?) entry is created and AFAICT that is unpredictable, the
configuration may occur first or the ephemeral one.  If the rule is that
one or the other datastore takes precedence, then you have a name which
changes its meaning at this point, which seems undesirable.

Hence, the only rule I can see being acceptable is that the first one
wins, regardless of which it is,  and the second and subsequent are
rejected as invalid.

But then you cannot rely on the prefix telling you where the name came
from - of course, YANG origin will still be accurate.

Tom Petch

---

From: Italo Busi <[email-masked]>
Date: Tue, 18 Jun 2019 17:24:02 +0000

Hi Juergen,

What is the DS architecture you have in mind with multiple client creating entries?

Are the two clients creating entries in the same <running> DS or in two different <running> DS?

In the latter case, the two clients could also rely on different <operational> DS and therefore can assign the same name to different entries (since they will be instantiated in different DS). There is no need for them to avoid name clash

In the former case, a name clash would cause one client to override the configuration of another client

Are the two clients aware of each other?

I take the opportunity to clarify one point (not sure I have been clear about it). I do not think we need to define any rule which is enforced by the server to avoid name clashes since the server cannot understand whether the name clash is intentional or not. I think we just need to define some known/common/standard rules that allow the client(s) to avoid creating unintended name clashes.

Thanks, Italo

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: martedì 11 giugno 2019 20:37
To: Italo Busi <[email-masked]>
Cc: Andy Bierman <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

On Tue, Jun 11, 2019 at 05:43:27PM +0000, Italo Busi wrote:

> [Italo Busi] If the client knows the prefix used by the server, it can 
> pick up a different prefix and use it to tag its own entries. I think 
> this rule is not really complex and it seems much simpler than 

A prefix only helps a little. Once you have multiple clients creating entries, you will have to handle collisions again. Sometimes solving the more general case leads to solutions that also work nicely in simpler special cases.
	
/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 19 Jun 2019 09:06:55 +0000

Hi Italo,

My interpretation of the NMDA guidelines are thus:

- If multiple clients are writing the same values to <running> then the clients must coordinate between themselves to ensure that the correct values are written to <running>, otherwise the last verified change written to <running> wins.  Locks can be used to coordinate client writes to <running> if required.

- If multiple clients are writing to different datastores, e.g. one client is writing to <running> and another is writing to some form of ephemeral datastore, then the ephemeral datastore definition must specify what mechanism is used to resolve configuration conflicts between configuration datastores.  Naively, my starting point would be to say that configuration in an ephemeral datastore should override configuration that is in <running>.

- If the decision is from a data node configured in <running> and a data node injected by the system into <operational> then it is up to the device to decide how to resolve these (i.e. the system chooses which version of the data node to use, and the result of that decision is tagged in <operational> using the origin metadata).  Generally, I would expect an explicitly configured data node in <running> should take precedence over system generated config, but there might be cases where this doesn't make sense, and perhaps there might be cases where the data model recommends different behaviour.

- I would assume that there is only a single <operational> datastore.  I'm not sure whether NMDA explicitly requires this, but we couldn't think of any scenario where multiple operational datastores would be helpful.

Thanks,
Rob

> From: Teas <[email-masked]> On Behalf Of Italo Busi
> Sent: 18 June 2019 18:24
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: [email-masked]; Tarek Saad <[email-masked]>; Andy Bierman
> <[email-masked]>; [email-masked]
> In the latter case, the two clients could also rely on different
> <operational> DS and therefore can assign the same name to different
> entries (since they will be instantiated in different DS). There is no
> need for them to avoid name clash
> 
> I take the opportunity to clarify one point (not sure I have been clear
> about it). I do not think we need to define any rule which is enforced by
> the server to avoid name clashes since the server cannot understand
> whether the name clash is intentional or not. I think we just need to
> define some known/common/standard rules that allow the client(s) to avoid
> creating unintended name clashes.
> 
> Thanks, Italo
> 
> entries, you will have to handle collisions again. Sometimes solving the
> more general case leads to solutions that also work nicely in simpler
> special cases.
> 
> /js
> 
> --

---

From: Italo Busi <[email-masked]>
Date: Wed, 19 Jun 2019 12:51:02 +0000

Hi Rob,

Thanks a lot for your comments

Your interpretation makes a lot of sense in case of an "intentional" name clash (e.g., when an entry is configured by the client in the <running> DS to configure some intended behavior, like admin status, for an entry injected by the system in the <operational> DS): in this case the same name/key value is used to indicate that the two DS entries are referring to the same entity

My concern is how to avoid "unintentional" name clashes (e.g., between an entry configured by the client in the <running> DS and another entry injected by the system in the <operational> DS) because in this situation the behavior described below is not desirable: the two DS entries are actually referring to two different entities which by accident got assigned the same name/key value

Italo

-----Original Message-----
From: Rob Wilton (rwilton) [mailto:[email-masked]] 
Sent: mercoledì 19 giugno 2019 11:07
To: Italo Busi <[email-masked]>; Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]; Tarek Saad <[email-masked]>; Andy Bierman <[email-masked]>; [email-masked]
Subject: RE: [Teas] [netmod] Key collision between configured and ephemeral list entries

Hi Italo,

Thanks,
Rob

> I take the opportunity to clarify one point (not sure I have been 
> clear about it). I do not think we need to define any rule which is 
> enforced by the server to avoid name clashes since the server cannot 
> understand whether the name clash is intentional or not. I think we 
> just need to define some known/common/standard rules that allow the 
> client(s) to avoid creating unintended name clashes.
> 
> Thanks, Italo
> 
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 19 Jun 2019 14:17:47 +0000

Hi Italo,

Using a prefix (which can also be configured by the user) for the system created objects to avoid name collisions seems reasonable to me.  I wouldn't use a symbol (like #), but instead would suggest a prefix string like "sys-".

But I think that it is appropriate to solve this within the specific data model rather that requiring a system wide solution.

Thanks,
Rob

> From: Italo Busi <[email-masked]>
> Sent: 19 June 2019 13:51
> To: Rob Wilton (rwilton) <[email-masked]>; Juergen Schoenwaelder
> <[email-masked]>
> Your interpretation makes a lot of sense in case of an "intentional" name
> clash (e.g., when an entry is configured by the client in the <running> DS
> to configure some intended behavior, like admin status, for an entry
> injected by the system in the <operational> DS): in this case the same
> name/key value is used to indicate that the two DS entries are referring
> to the same entity
> 
> My concern is how to avoid "unintentional" name clashes (e.g., between an
> entry configured by the client in the <running> DS and another entry
> injected by the system in the <operational> DS) because in this situation
> the behavior described below is not desirable: the two DS entries are
> actually referring to two different entities which by accident got
> assigned the same name/key value
> 
> Italo
> 
> - If multiple clients are writing the same values to <running> then the
> clients must coordinate between themselves to ensure that the correct
> values are written to <running>, otherwise the last verified change
> written to <running> wins.  Locks can be used to coordinate client writes
> to <running> if required.
> 
> - If multiple clients are writing to different datastores, e.g. one client
> is writing to <running> and another is writing to some form of ephemeral
> datastore, then the ephemeral datastore definition must specify what
> mechanism is used to resolve configuration conflicts between configuration
> datastores.  Naively, my starting point would be to say that configuration
> in an ephemeral datastore should override configuration that is in
> <running>.
> 
> - If the decision is from a data node configured in <running> and a data
> node injected by the system into <operational> then it is up to the device
> to decide how to resolve these (i.e. the system chooses which version of
> the data node to use, and the result of that decision is tagged in
> <operational> using the origin metadata).  Generally, I would expect an
> explicitly configured data node in <running> should take precedence over
> system generated config, but there might be cases where this doesn't make
> sense, and perhaps there might be cases where the data model recommends
> different behaviour.
> 
> - I would assume that there is only a single <operational> datastore.  I'm
> not sure whether NMDA explicitly requires this, but we couldn't think of
> any scenario where multiple operational datastores would be helpful.
> 
> Thanks,
> Rob
> 
>