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