Hi Andy, Hi Peter
A solution based on the use of "module ID, YANG hash" as unique identifier seem
to be promising.
If we can successfully address the items bellow (1 to 3), I believe we can
address the different issues identified without introducing a module ID
registry.
Something I agree it will be nice to avoid.
Issues:
- "clash_file" on the server side
- traffic overhead (handshake to retrieve the "clash_file")
- per-server rehash table overhead on the client side
- string table overhead on the client side to index the "clash_file"
ITEM 1) Hash clashes within a YANG module
We need to describe one or multiple approaches to resolve YANG hash clashes
within a module if this ever happen.
- We can suggest to rename any conflicting data node identifier(s) prior
publishing
- We can introduce a new YANG statement to assign an alternate hash value to an
already published YANG module
- We can also setup a registry to publish alternate hash values to an already
published YANG module
ITEM 2) Traffic overhead
The propose hash clash error is a step in the right direction to avoid the
upfront retrieval of the "clash_file". To completely eliminate the need to
retrieve the "clash_file" , I propose to support the "module name" as an
optional query parameter. This option can be used to access the targeted data
node after receiving a hash clashes error or to avoid hash clashes errors.
For example:
To retrieve data nodes "current-datetime" and "boot-datetime"
Option #1
REQ: GET example.com/mg?select= VNwQI,folNh
(This request may return a hash clash error)
Option #2
REQ: GET example.com/mg?select=ietf-system(VNwQI,folNh)
(This request never return a hash clash error)
ITEM 3) Datastore access
Access (GET and PUT) of the entire datastore is an important feature to allows
backup and restoration of a device configuration. To resolve hash clashes
between modules, I propose to support the concept of module context as describe
in my document (draft-vanderstok-core-comi-06 - MV.docx).
For example:
REQ: GET example.com/mg
RES: 2.05 Content (Content-Format: application/cbor)
{
"module a" : {
365257235 : value
702149626 : {
215993329 : value <--- hash clashes
962191682 : value
},
829222983 : value
},
"module b" : {
215993329 : value <--- hash clashes
},
"module c" : {
993533527 : value
}
}
I hope this approach represents a win/win solution which avoid the two
contentious items:
- IANA module ID registration
- rehash and "clash_file"
In summary:
In this solution there is no more rehash value, no "clash_file".
We just use the "module ID, YANG hash" as unique identifier.
Message size overhead is keep to a minimum and this overhead is optional (at
the exception of the datastore access).
Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected]
www.trilliantinc.com
-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: 19 mai 2015 14:34
To: Michel Veillette
Cc: [email protected]; [email protected]; Core
Subject: Re: [core] CoMI rehashing
On Tue, May 19, 2015 at 8:47 AM, Michel Veillette
<[email protected]> wrote:
> Hi Andy
>
> No, I didn’t try to investigate if YANG hash clashes within existing modules
> exist.
> Multiple of them of proprietary and doing an extensive search is not
> practical.
>
> The point is not to determine if such clashes exist but how the protocol will
> handle them if they do exist.
> The current answer seem to be bad luck, try again, your module can't be
> implemented using CoMI.
>
It is difficult to believe that a 6TISCH CoMI device is too small to store 16K
of strings, but it will be powerful enough to run YANG modules intended for
NETCONF devices such as routers.
There is a very small chance that a module in progress has hash collisions in
it, and the name of a node has to be changed to fix it (before the module is
published).
IMO this is the least painful solution.
> Michel Veillette
Andy
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> [email protected]
> www.trilliantinc.com
>
>
> -----Original Message-----
> From: Andy Bierman [mailto:[email protected]]
> Sent: 19 mai 2015 11:35
> To: Michel Veillette
> Cc: [email protected]; [email protected]; Core
> Subject: Re: [core] CoMI rehashing
>
> On Tue, May 19, 2015 at 8:23 AM, Michel Veillette
> <[email protected]> wrote:
>> Hi Peter
>>
>> Your propose solution doesn't seem to address YANG hash clashes happening
>> within a YANG module.
>>
>> Multiple times in your document, you assume that clashes can't happen within
>> a YANG module.
>> Page 1, "It is assumed that no clashes occur within one module, and by
>> prefixing a module identifier to the hash, clashing hashes can be
>> distinguished"
>> Page 3, "A data node is completely identified by the module identifier and
>> the hash value."
>>
>> We can probaly make this assumption for YANG modules specifically design for
>> CoMI but this is not true for existing YANG modules and future modules not
>> designed with CoMI in mind.
>>
>
>
> Dos this mean you have identified existing YANG modules that would have
> multiple nodes with the same hash value?
> I have not found any so far.
>
> IMO it is much more reasonable to make sure that a YANG module intended for
> use in CoMI does not have any clashes.
>
>
>> =======
>>
>> About "the client creates a "server_table" with entries: <server id, old
>> hash, M_id, new hash> "
>>
>> Let say we have the following two data nodes:
>> /sys:system-state/sys:clock/sys:current-datetime, 355927048
>> /sys:system-state/sys:clock/sys:boot-datetime, 355927048
>>
>
> But these are the wrong hash values.
>
>> Having the following table within the client is not sufficient to
>> distinguate between the "current-datetime" and the "boot-datetime".
>> fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 783481403
>> fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 530731873
>>
>
> The assumption is that modules for CoMI will be checked for hash collisions,
> and the module will be altered to remove any collisions. Since a module has
> about 100 nodes in it and it takes about 70,000 nodes for a 50% chance at a
> collision, it will be quite easy to prevent clashes in a single module.
>
>
>
> Andy
>
>> ========
>>
>> Introducing the concept of "hash clash" error help to avoid the need to
>> retreive the "clash_file" when no clashes exist.
>> However, if we agree that clashes may exist within a YANG module, we are
>> back to square one with the original rehashing mechanism.
>>
>> Michel Veillette
>> System Architecture Director
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> [email protected]
>> www.trilliantinc.com
>>
>> -----Original Message-----
>> From: peter van der Stok [mailto:[email protected]]
>> Sent: 19 mai 2015 03:23
>> To: Michel Veillette
>> Cc: Core; [email protected]
>> Subject: CoMI rehashing
>>
>> Hi Michel,
>>
>> Apologies for reacting so late, but we had many discussions which slowly
>> converged to the solution described in the attachment.
>>
>> WE aim at rehashing when a clash occurs.
>> The client only needs minimal storage space: table with the names of the
>> modules.
>> Per rehash collision, the client only stores old hash, new hash, and
>> module identifier
>>
>> We think that a global module numbering of all relevant modules,
>> administrated by IANA, is a large undertaking.
>> Given the struggle we see elsewhere to save bytes, we think also that we
>> should minimize the payload.
>>
>> Greetings,
>>
>> Peter
>>
>> --
>> Peter van der Stok
>> vanderstok consultancy
>> mailto: [email protected]
>> www: www.vanderstok.org
>> tel NL: +31(0)492474673 F: +33(0)966015248
>>
>> _______________________________________________
>> core mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
