Hi Andy, > Le 13 juin 2015 à 00:58, Andy Bierman <[email protected]> a écrit : > > 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.
Yes, I must say that in the discussions in the past couple of days really cover many of the cases I was thinking about, so I would tend to agree with you that in most cases aliases can be an overkill. However, you always need to provide at least one long id, which could be avoided, and could be very beneficial for some networks. So, to sum up, if the proposal of YANG ID structure (20 bits module ID + 10 bits data node ID), long form/short form, and ‘select’ option with CBOR encoding is accepted, then 95% of the work is done (and I would be happy with that). I feel that adding a short statement - module ID = 0 is reserved for aliases - and address this in another draft would be the simplest solution (we have to figure out what to do with that module ID = 0 anyways). I’ve already described a pretty straightforward way of managing aliases, the simplest being - static allocation by the server (e.g. upon provisioning / firmware update / etc.). Alexander > > > Andy > > > > > On Fri, Jun 12, 2015 at 3:25 PM, Alexander Pelov > <[email protected] > <mailto:[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] >> <mailto:[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
