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

[Andy Bierman <[e-mail]>]

On Tue, Jun 11, 2019 at 8:40 AM Italo Busi <[e-mail]> 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)
>
> 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
>
>
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


> -----Original Message-----
> From: tom petch [mailto:[e-mail]]
> Sent: domenica 2 giugno 2019 13:09
> To: Italo Busi <[e-mail]>; Tarek Saad <[e-mail]>;
> Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [netmod] [Teas] Key collision between configured and
> ephemeral list entries
>
> ----- Original Message -----
> From: "Italo Busi" <[e-mail]>
> 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:[e-mail]]
> > Sent: mercoledì 29 maggio 2019 17:22
> > To: Rob Wilton (rwilton) <[e-mail]>; tom petch
> <[e-mail]>; Italo Busi <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > 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)"
> <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> On Behalf Of tom petch
> >     Sent: 29 May 2019 12:04
> >     To: Italo Busi <[e-mail]>; [e-mail]
> >     Cc: [e-mail]
> >     Subject: Re: [Teas] [netmod] Key collision between configured and
> ephemeral list entries
> >
> >
> >     ----- Original Message -----
> >     From: "Italo Busi" <[e-mail]>
> >     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:[e-mail]]
> >     Sent: mercoledì 29 maggio 2019 10:42
> >     To: Italo Busi <[e-mail]>; [e-mail]
> >     Cc: [e-mail]
> >     Subject: Re: [netmod] Key collision between configured and
> ephemeral list entries
> >
> >     <inline>
> >
> >     Tom Petch
> >
> >     ----- Original Message -----
> >     From: "Italo Busi" <[e-mail]>
> >     To: <[e-mail]>
> >     Cc: <[e-mail]>
> >     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 : [phone]
> >     Email : [e-mail]
> >     [cid:image002.png@01D5149F.354EF420]
> >
> >     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:[e-mail]]
> >     Sent: venerdì 24 maggio 2019 23:13
> >     To: Igor Bryskin <[e-mail]>; Rakesh Gandhi
> <[e-mail]>; Xufeng <[e-mail]>; Vishnu Pavan
> Beeram <[e-mail]>; Italo Busi <[e-mail]>
> >     Cc: [e-mail]
> >     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
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>