Hi Andy, Not sure if you were referring to the example/explanation I tried to provide (maybe Michel had something else in mind), but here I go.
> Le 12 juin 2015 à 23:57, Andy Bierman <[email protected]> a écrit : > > Hi, > > Here is the "JSON for YANG" draft: > https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt > <https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt> > > The long form (module-name:local-name) is only used > at the top of a sub-tree and where the module namespace changes > (due to an augment from another module). > > The data is hierarchical and the parser is required to maintain > the current module scope. It should be possible to omit the module > identifier is nested data, except for nodes that start a new > module scope. Ok, that sounds perfectly in line with the module ID/data node ID and the long form/short form we’ve been discussing with Michel. > > Is this what you have in mind? > For YANG Hash (that has no module identifier) > every nested node ID needs the full 30 bits, > but this is not required for managed IDs. If you have your YANG hash ID behave in a structured way (e.g. stop being a hash..), then you don’t need to send the full 30 bits. If I take the following example (which is a strange case just for the sake of it): REQ: GET example.com/mg?select <http://example.com/mg?select>( [5, 2049, 2, 3, 4, 4097, 2, 3, 4, 2053, 2055, 6] ) That would resolve to requesting the following YANG IDs: long form = module ID / short form 5 = 0 / 5 2049 = 1 / 1 2050 = 1 / 2 2051 = 1 / 3 2052 = 1 / 4 4097 = 2 / 1 4098 = 2 / 2 4099 = 2 / 3 4099 = 2 / 4 2053 = 1 / 5 2055 = 1 / 7 2054 = 1 / 6 Of course, that is not (directly) related to the way the YANG parser processes the YANG modules. It is a way to parse the select option, and is straightforward. Consecutively, element by element apply something of the form: if (full_id & 0x3FFFFC00) > 0) { current_module_ID = full_id >> 10; } else { full_id = (current_module_ID << 10) & full_id; } Of course, that could be optimized, but for the sake of clarity we can leave it like this for the moment. Best, Alexander > > > Andy > > > > > > On Fri, Jun 12, 2015 at 2:42 PM, Alexander Pelov > <[email protected] > <mailto:[email protected]>> wrote: > Michel, > > >> Le 12 juin 2015 à 23:10, Michel Veillette <[email protected] >> <mailto:[email protected]>> a écrit : >> >> I Alexander >> >> I don’t see any issues with your proposal of using module ID 0 as aliases. >> The only constrain is that aliases need to be at the start of the select for >> a GET and at the start of the payload for a PUT. > > Yes, I suppose you should always start with aliases, but that doesn’t sound > like a strong constraint to me, so it’s seems like the perfect solution. > >> >> The last things we need to sort out, is the instance selector (keys) in the >> context of a select query parameter containing multiple data nodes. >> >> Let assume the following: >> · A CoMI client need to select 3 data nodes (Data node ID 2049, 2 >> and 3) >> · For the first data node, three values need to be provided as keys >> (e.g. 1, "ipv4", "10.0.0.51 "), see draft-vanderstok-core-comi-06 page 22. >> · For the third data node, one integer value need to be provided as >> keys (e.g. 22). >> >> If we include these keys in the select query parameter encoded in CBOR, the >> result might look as follow: >> >> REQ: GET example.com/mg?select <http://example.com/mg?select>( >> [[20491,"ipv4","10.0.0.51",2], 2, [3,22]] ) > > Just a small typo (missed a coma after 2049, right?): >> REQ: GET example.com/mg?select <http://example.com/mg?select>( [[2049, >> 1,"ipv4","10.0.0.51",2], 2, [3,22]] ) > > And yes, seems quite straightforward and reasonable to me. If I understand > correctly, the format you use is the following: > The select parameter accepts a single integer (long form data ID) or an > array. In the latter case, each element of the array may be either an integer > (e.g. data ID), or an array in the form [data ID, key1, key2, …, keyN]. The > data ID may be absolute (e.g. long form), or relative to the module of the > previous data ID. > > This seems quite expressive, simple and compact. I wonder if we’re missing > something, as it really does seem to have quite a lot of nice > characteristics. > > Best, > Alexander > > >> >> In the current draft, the CoMI server need to support two encoding for each >> selector, CBOR encoding in the payload and text in the keys query parameter. >> With this proposal, both use cases are encoded using CBOR. >> >> What do you things? >> >> <image001.jpg> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> [email protected] <mailto:[email protected]> >> www.trilliantinc.com <http://www.trilliantinc.com/> >> >> >> From: Alexander Pelov [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: 12 juin 2015 15:26 >> To: Michel Veillette >> Cc: Pascal Thubert (pthubert); Andy Bierman; [email protected] >> <mailto:[email protected]>; [email protected] <mailto:[email protected]> >> Subject: Re: [6tisch] Reserve space for aliases >> >> Hi Michel, >> >> You’re right. As I mentioned in my previous mails, I’m pretty happy with the >> compression of IDs we’ve achieved until now, so aliases are not as a >> pressing issue. >> >> The thing is, if they can be implemented at (almost) zero cost, then some of >> the use-cases become quite interesting. >> >> You actually provide a very good case with the select option. I’ve not >> thought if it will present some other difficulties, but I actually think it >> facilitates the use of aliases (and I mention this only because it will help >> me also understand the semantics of your proposal of the select option). >> >> If I take the example you provide: >> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] >> ) >> >> The parameters 2,3,4 are actually relative to the module ID of the first >> one. So, if I try to generalize this (please correct me if I’m wrong), I >> would imagine something like: >> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4, >> 4097,2,3,4] ) >> To resolve to getting module ID=1, relative node IDs=1,2,3 and 4, and module >> ID=2 and relative node IDs =1,2,3 and 4. >> >> This means, that specifying a GET example.com/mg?select >> <http://example.com/mg?select>(1) should resolve to module ID=0 and relative >> node ID=1. This requires absolutely no additional processing from the node. >> >> So, this leaves us back to the initial idea of the aliases. All short node >> IDs are relative to a module ID (so that the long form ID can be >> interpreted). Module ID=0 is reserved, and can be used for aliasing if the >> device wishes to support it. >> >> Does this break some of the things along the way? >> >> Best, >> Alex >> >> >> >> Le 12 juin 2015 à 18:57, Michel Veillette <[email protected] >> <mailto:[email protected]>> a écrit : >> >> Hi Alexander, hi Pascal >> >> I want to emphases the following points >> >> · The use of the select query parameter encoded in CBOR support of >> 63 modules with optimized message size instead of only 3 for the base64 URI. >> If the 6TiSCH module ID is allocated within these 63 IDs, there will be no >> message size optimization provided by the aliases mechanism. >> This make the introduction of aliases less urgent. >> >> · The message size of the select query parameter encoded in CBOR >> should be equal or smaller compared to the base64 URI. >> However, the select query parameter encoded in CBOR support a wider range of >> values without size penalty (16 bits instead of 12, 32 bits instead of 30) >> Furthermore, CoMI devices won’t have to support two type of encoding >> depending if IDs are part of the command vs. payload. >> >> For example: >> >> Assuming module ID 2 >> Assuming data node ID 1, 2, 3, 4 (long form 2049, 2050, 2051) >> Assuming “,” separator to select multiple data nodes >> >> Base64 approach: >> REQ: GET example.com/mg/gB <http://example.com/mg/gB> (3 bytes; 1 >> byte for the “/”, 2 bytes for “gB”) >> >> CBOR approach: >> REQ: GET example.com/mg?select <http://example.com/mg?select>(2049) >> (4 bytes; one byte for the CoAP option, 3 for 2049 encoded using CBOR) >> >> Base64 approach: >> REQ: GET example.com/mg/gB,C,D,E <http://example.com/mg/gB,C,D,E> (9 >> bytes; 1 byte for the “/”, 8 bytes for “gB,C,D,E”) >> >> CBOR approach: >> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] >> ) (8 bytes; 1 byte for the CoAP option, 1 for the CBOR array, 3+1+1+1 >> bytes for the IDs) >> >> >> <image001.jpg> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> [email protected] <mailto:[email protected]> >> www.trilliantinc.com <http://www.trilliantinc.com/> >> >> >> From: Alexander Pelov [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: 11 juin 2015 17:06 >> To: Pascal Thubert (pthubert) >> Cc: Andy Bierman; Michel Veillette; [email protected] >> <mailto:[email protected]>; [email protected] <mailto:[email protected]> >> Subject: Re: [6tisch] Reserve space for aliases >> >> Hi Pascal, >> >> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[email protected] >> <mailto:[email protected]>> a écrit : >> >> Dear all: >> >> This looks like the problem of local namespaces, which is the reason why >> MPLS switches labels. >> The user may access a limited set of resources from a number of servers, and >> servers are read by many users. >> You cannot ensure that you have a single alias space that satisfies them all. >> >> Great analogy! And yes, sadly you cannot satisfy them all, at least not with >> all devices. >> >> >> >> >> So ,what if the user had its own set of aliases and the server also had its >> own set of aliases? >> >> The aliases could be mapped in a table like a uSAP and a pSAP are mapped >> across layers. Broadly: >> - First time a user requests a resource in a server, it comes with a tuple >> (userid, useralias, fullname) >> - The server responds with (serverid, serveralias, userid, user alias). >> >> Actually, I think that this could be worked out in CoMI also. Instead of >> fullname you could provide the YANG id (module ID + data node ID) and do the >> mapping. User alias would be the special aliased YANG id. User ID, however, >> could be a little bit more tricky - how do we ensure that it is consistent? >> Use the IP address of the client could be doable, but we’ll have to include >> the UDP port just in case someone runs two clients on the same machine. >> >> >> >> >> >> After that, if the server is a constrained device then the user talks to >> the server with (serverid, serveralias) and the user maintains a switching >> table for the resource it uses on various servers. >> If the user is the constrained device and the server is not, the user could >> talk with (userid, useralias) and the server maintains a switching table. >> >> For large servers, the server may allocate aliases dynamically based on what >> it is being asked. We’d then need to talk about alias update or revocation, >> probably in terms of session and lifetime. >> >> Does that look usable? >> >> You are pointing out an interesting question. I would think (but maybe I’m >> mistaken), that the client should have the leading role in figuring out >> what’s happening. The idea is the following: >> >> The client checks if the server supports aliasing, with the possible options: >> S1) no aliasing >> S2) static/server-defined aliasing >> S3) dynamic/single alias mapping >> S3.1) mapping already defined >> S3.2) no mapping defined >> S4) dynamic/per client alias mapping >> >> Then, the client can take action, depending on its own capabilities and the >> response of the server. E.g. a unconstrained client could obtain the alias >> mapping if it is static (or if there is a single alias mapping in place) and >> cache it locally. So, there will be the following correspondence : >> >> Given: >> C1) constrained client >> C2) unconstrained client >> >> We have: >> C1 + S1) no aliasing, nothing to do >> C1 + S2) and C1 + S3.1) if the alias mapping is known, use it. otherwise, >> ignore >> C1 + S3.2) and C1 + S4) define alias mapping >> >> C2 + S1) no aliasing, nothing to do >> C2 + S2) and C2 + S3.1) if the alias mapping is known, use it. otherwise, >> learn it >> C2 + S3.2) and C2 + S4) define alias mapping >> >> I would say that the analogy you made with MPLS corresponds quite a lot to >> the C2+S4 case. Personally, I would be most interested into having one >> client configure one alias mapping to all servers in the network (e.g. the >> managing entity), which will profit most from saving several bytes on each >> message exchange. Everyone else could use the standard IDs, which we’ve >> already managed to shrink significantly. >> >> Indeed, with structured module ID + data node ID (20 bits + 10 bits), YANG >> URI compression, and long form/short form, we’ll have quite a lot of gain. >> Reserving module ID = 1 for aliases and maybe writing a short draft on how >> the aliasing is implemented seems feasible, where we can cover the exact >> mechanism of alias definition, and client/server interaction. >> >> Alexander >> >> >> Pascal >> >> From: 6tisch [mailto:[email protected] >> <mailto:[email protected]>] On Behalf Of Andy Bierman >> Sent: vendredi 5 juin 2015 20:55 >> To: Michel Veillette >> Cc: [email protected] <mailto:[email protected]>; Alexander Pelov; [email protected] >> <mailto:[email protected]> >> Subject: Re: [6tisch] Reserve space for aliases >> >> >> >> On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette >> <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Alexander >> >> I have some concerns about allowing CoMI client(s) the control of the list >> of aliases. >> This approach work fine for the first CoMI application (e.g. 6TiSCH) but >> what do we do with the subsequent CoMI application? >> >> One possible solution is that each CoMI client send a list of (alias, data >> node ID) to the CoMI server. In this case, the CoMI client might receive an >> error if one or multiple of these aliases are already reserved. >> >> A second possible solution is that each CoMI client send a list of (data >> node ID) and get a list of (alias, data node ID) from the CoMI server. In >> this case, CoMI clients will have to deal with a mix population of aliases. >> >> The proposed solution need to scale to a multi-vendors, multiple >> applications environment. >> With this is mind, do you have any alternative solutions to propose? >> >> >> >> Does this approach allow each client to have a different set of aliases, >> so the server has to maintain a configured mapping for each client? >> This seems like a lot of overhead and NV-storage requirements >> on the server. >> >> Changing the schema identifiers based on which client is >> sending the request seems like a complicated design change >> from RESTCONF, NETCONF, or SNMP, where there is only >> 1 schema tree which is not dependent on the client identity. >> >> >> Andy >> >> >> >> >> <image001.jpg> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> [email protected] <mailto:[email protected]> >> www.trilliantinc.com <http://www.trilliantinc.com/> >> >> >> From: Alexander Pelov [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: 5 juin 2015 12:03 >> To: Michel Veillette >> Cc: Andy Bierman; [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: Re: Reserve space for aliases >> >> Hi Michel, >> >> >> Le 5 juin 2015 à 17:17, Michel Veillette <[email protected] >> <mailto:[email protected]>> a écrit : >> >> Hi Alexander >> >> In your presentation at 6TiSCH, you propose the following data node ID >> structure. >> >> • 32 bits YANG ID >> – 20 bits for module ID (assigned by IETF) >> – 10 bits for data node ID (generated deterministically) >> >> Based on this structure, we can reserve module ID zero for aliases. >> >> >> I was just summarizing what was discussed on the discussion in CoMI. >> Actually, it is 30 bits YANG ID, but that’s for purposes to be consistent >> with the YANG hash and I don’t mind keeping it 30 bits. >> >> >> >> If we want to minimize both the network an node resources require by this >> alias mechanism, we can map an entire module to this space. >> This can be implemented by a single integer resource (e.g. leaf >> alliassedModule { type uint32 } ) >> This approach require 4 bytes per CoMI server accessed. >> >> >> It is possible to map an entire module to the alias space and this is up to >> the operator. However, if you load two modules which redefine the same alias >> you will loose the benefit from it. Maybe it would be interesting to be able >> to specify that you want the aliases from THIS specific module to be used. >> >> If the /mg/0 alias is reserved for managing the aliases, this could be >> simply saying: >> POST /mg/0 >> { >> "source_uri" : "/mg/BAA" >> } >> >> where /mg/BAA is the YANG id of the module (20 bits module ID + 10 bits set >> to 0). This way, the server will know: OK, get the alias mapping from the >> YANG scheme of module with ID = B (as defined by the IETF). >> >> Or, you can dynamically configure the mapping: >> POST /mg/0 >> { >> YANG_id : alias, >> YANG_id : alias, >> YANG_id : alias >> } >> >> >> If we want a more complex but more flexible aliases mechanism, your proposed >> map of (allias, YANG ID) seem the solution. >> However, we have to consider that this structure can be as large as 1250 >> bytes per CoMI server accessed if limited to 256 aliases. >> >> This is assuming you need a separate mapping for each server. I would >> suppose that in a network you’ll have a single alias mapping (maybe two?) - >> after all, you’re trying to optimize the management of your devices >> (servers). So, typically you’d map all 6tisch devices with aliases 1-10 >> (channel, slot, etc.) and use that on them, and on all other you’d access >> the full ID. >> >> Best, >> Alexander >> >> >> >> <image001.jpg> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> [email protected] <mailto:[email protected]> >> www.trilliantinc.com <http://www.trilliantinc.com/> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
