Hi Michel,
We are not far apart, it seems to me.
There is one thing left in my view:
- Server returns new hash value to client, or
- Client reads new hash value from a supporting file (called
"clash-file")
The supporting file is introduced to remove storage requirements from
server, such as: data node name, name extension, module name, hashes.
And it makes rehash handling for large clients (storing the data node
names) and for small clients (storing module names only) similar.
The "clash-file" is still needed when the server returns the new hash
value to store data node name and name extension.
By returning the new hash value the server is burdened with the module
name storage.
few comments below in
<pvds2> comment </pvds2>
Peter
Michel Veillette schreef op 2015-05-20 17:46:
[MV] Inline
see below, some preliminary comments.
Peter
Michel Veillette schreef op 2015-05-19 21:49:
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.
<pvds>
Nice to know that we are on the same track </pvds>
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
<pvds>
Is this a subject for CoMI draft?
May be address this in another draft?
</pvds>
[MV] Minimally, the strategy used to address internal module clashes
should be described clearly in the CoMI spec.
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".
<pvds>
The reason is different; I was worried about upgrades of servers, the
specification left open that the old hash value of a data_node was
rehashed, and a new data-node with the original hash was added.
Clients could then access another data node with the old hash value.
</pvds>
[MV] The side effect of not requiring upfront loading of the "rehash"
list is nice feature.
<pvds2>
Some text in the draft is needed anyway to motivate the CoMI re-hash
specification
</pvds2>
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)
<pvds>
Your proposal increases data traffic permanently when a clash has
occurred, and needs the storage of module names in server as well.
With rehashing, the "clash_file" overhead happens only once after the
reload of the server.
BTW the /mg string in URI is removed when possible.
</pvds>
[MV] This overhead is not necessary permanent.
[MV] The CoMI server may return a rehash value in the payload which
can be used for subsequent accesses.
[MV] This way, we cut the extra exchange and the state machine
associated with it.
<pvds2>
Interesting.
But somewhere the rehash needs to be done
Not clear what this means in message exchanges
</pvds2>
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.
<pvds>
You mean server or client, or both?
and what is device configuration? the set of data nodes that are
accessible, or the values of all accessible data-nodes?
</pvds>
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
}
}
<pvds>
Do you want a dump of all values of all accessible data nodes?
[MV] Yes, backup and recovery this is a core feature of NETCONF and
should be supported at lower scale using CoMI
The proposed syntax does not logically follow from ITEM 2), because
rehashing is compulsory, and you will have two hashes pointing to the
same value belonging to the same data node.
[MV] I the model I'm proposing, each module have its own hash table,
both the "module name" + "hash value" is used to identify a data node.
<pvds2>
OK, but the message overhead argument remains. The CoMI design criterion
is to produce small message sizes and small servers.
You rightly also introduced the concern for storage space in clients.
Actually our table examples are there to show feasibility and explore
table info needs.
A server or client is free to structure tables as it wishes.
</pvds2>
When using rehashing, a (smaller) flat table with "hash value : data
node value" is returned.
Alternatively, I can see a request that returns for all clashed hashes
the information: old hash, module name, new hash; but that means
storing module names in server as well.
</pvds>
I hope this approach represents a win/win solution which avoid the two
contentious items:
- IANA module ID registration
- rehash and "clash_file"
<pvds>
The "clash-file" is only accessed by a client when a reload of the
server (how often does that happen?) leads to hash clash (probability
<
10^-4)
</pvds>
In summary:
In this solution there is no more rehash value, no "clash_file".
We just use the "module name, YANG hash" as unique identifier.
<pvds>
This is then optional next to the compulsory rehashing?
</pvds>
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
