Hi, I am not convinced that aliases are worth all the effort because most (95%?) of the IDs in the payload will only need 10 bits.
Andy On Fri, Jun 12, 2015 at 3:25 PM, Alexander Pelov < [email protected]> wrote: > 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 > > 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( [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]> wrote: > >> Michel, >> >> >> Le 12 juin 2015 à 23:10, Michel Veillette < >> [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( [[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( [[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] >> www.trilliantinc.com >> >> >> *From:* Alexander Pelov [mailto:[email protected] >> <[email protected]>] >> *Sent:* 12 juin 2015 15:26 >> *To:* Michel Veillette >> *Cc:* Pascal Thubert (pthubert); Andy Bierman; [email protected]; >> [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( [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( [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(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]> 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 (3 bytes; 1 byte for the “/”, 2 bytes >> for “gB”) >> >> CBOR approach: >> REQ: GET 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 (9 bytes; 1 byte for the “/”, 8 >> bytes for “gB,C,D,E”) >> >> CBOR approach: >> REQ: GET 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] >> www.trilliantinc.com >> >> >> *From:* Alexander Pelov [mailto:[email protected] >> <[email protected]>] >> *Sent:* 11 juin 2015 17:06 >> *To:* Pascal Thubert (pthubert) >> *Cc:* Andy Bierman; Michel Veillette; [email protected]; [email protected] >> *Subject:* Re: [6tisch] Reserve space for aliases >> >> Hi Pascal, >> >> >> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[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] <[email protected]>] >> *On Behalf Of *Andy Bierman >> *Sent:* vendredi 5 juin 2015 20:55 >> *To:* Michel Veillette >> *Cc:* [email protected]; Alexander Pelov; [email protected] >> *Subject:* Re: [6tisch] Reserve space for aliases >> >> >> >> On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette < >> [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] >> www.trilliantinc.com >> >> >> *From:* Alexander Pelov [mailto:[email protected]] >> *Sent:* 5 juin 2015 12:03 >> *To:* Michel Veillette >> *Cc:* Andy Bierman; [email protected]; [email protected] >> *Subject:* Re: Reserve space for aliases >> >> Hi Michel, >> >> >> >> Le 5 juin 2015 à 17:17, Michel Veillette < >> [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] >> www.trilliantinc.com >> >> >> > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
