On Thu, May 21, 2015 at 9:32 AM, Michel Veillette < [email protected]> wrote:
> Hi Peter > > > > We seem effectively to be on the same intersection (YANG, CBOR, YANG hash) > but still on the opposite side of the street. > > The core difference seem to be the expected data struture implemented by > the CoMI server. > > All your solutions all based on flat hash table represented below. > > > > > > All my solutions are all based on a hash table per module context represented > below. > > > > Both solutions rely equally on the YANG module writer to solve any hash clashes within 1 module. The advantage of a module-id is that if this is done, no re-hash is needed at all. How is a Data Node ID encoded? Not sure how that works. The cost of the module-id is really in the message encoding. What if the protocol allowed the client to discover a set of module-name to local-module-number mappings that can be used as the module-id in messages? The client has to store the module name anyway (that is 'Module ID' since modules are not assigned numbers). The extra storage is 1 number (16 bits?) per module, per server. Maybe 32 bytes per server. Would that be too much? I would like the module-id approach if the encoding was a number instead of a string. Andy > > This alternate data structure enable a different set of solutions such as: > > > > · Access using either the “Data Node ID” alone (if unique) or > “Module ID” + “Data Node ID” > NOTE: When a clash exist, an alternate “Data Node ID” can be returned by > the CoMI server for subsequent requests using the “Data Node ID” alone. > > > > · Access to all data nodes of a module > NOTE: The CoMI server know which data nodes are part of which module and > can return those if a query parameter (select) ask to do so. > > > > · Ability to support a mix managed/unmanaged model where some > modules may use manage Data Node IDs and others may use YANG hashes > NOTE: If we also want to support managed and unmanaged “Module ID”, we can > use a special character like # to differentiate between them. > Module ID prefixed by # can be unmanaged module name, Module ID not > prefixed by # can be IANA registered module ID. > The advantage will be to minimize the overhead associated to some popular > modules. > Within a module, all data nodes need to be either manage or unmanaged > > > > · Most importantly, this data structure enable different methods > which avoid the need to implement a rehash list, its retrieval and storage > > > > I’m open to compromise on multiple aspects of the solutions (support of > not of managed Module ID, managed Data node ID, specific message format and > query parameters). > > However, I will have hard time to compromise on this fundamental > difference. > > > > About “OK, but the message overhead argument remains.” > > > > · On the CoMI server side, I don’t consider that adding a dozen > of “Module ID” and splitting the hash table in pieces represent an > unacceptable overhead, especially if we remove the rehash list. > > · On the protocol side, if we allow access using the “Data Node > ID” alone and if we return an alternate “Data Node ID” in case of a clash > for subsequent requests seem to me more efficient than retrieving a rehash > list. > > > > 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: 21 mai 2015 05:27 > To: Michel Veillette > Cc: [email protected]; Andy Bierman; [email protected]; Core > Subject: RE: [core] CoMI rehashing > > > > 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 > > > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
