Hi Michel,
> Le 8 juin 2015 à 16:35, Michel Veillette <[email protected]> > a écrit : > > Hi Alexander > > The proposed “long form, short form” is incompatible with the concept of > aliases since the short form ID space is the same as the proposed aliases ID > space. We will have to choose one or the other. In the following example, IDs > 1, 2, 3 is the short form within the module ID 25, not alias 1, 2, 3. “long > form, short form” add some extra overhead compared to aliases, however this > approach have multiple advantages: > · Allows compression of all modules, not just a small subset of IDs > (20 or 256 IDs) > · Do not require an initial handshake for aliases discovery or > configuration > · Can be implemented using the same simple rules as RESTconf Ok, I see what you mean. Indeed, there could be a way to have both aliases and the long form, short form, but maybe it becomes a little bit clumsy, and the goal is to avoid complexity. In your proposal, the module ID = 0 is reserved for the compression prefix, and I agree that this will be more generic than simply leaving it for the aliases. However, I would still consider that there are interesting cases where aliasing can be applied. There are two possibilities to reconcile them: 1) reserve data node ID < 24. Module ID=0 + data node IDs < 24 can then be used for the aliasing (if needed). The specification of this can be out of CoMI or with the simple mechanism I described in the previous mail. 2) reserve module ID = 1 (or /mg/g0) for aliasing. Maybe this would be the best solution, as it only increases the alias URI with 1 character compared to the initial proposal. I would go with 2), as it has the same merits of the aliases (can be standardized very simply, at no cost for devices), and is only based on reserving a module ID for this purpose. It keeps the possibility to use the compressed YANG id + long form / short form. > > REQ: GET example.com/mg/GQB <http://example.com/mg/GQB> > > RES: 2.05 Content (Content-Format: application/cbor) > { > 1 : { > 2 : " leafA1 value", > 3 : " leafA2 value " > 26625 : " leafA3 value " > } > } > > About the meta information such as the list of modules and the list for > streams. This should be implemented using YANG modules , “ietf-yang-library” > and “ietf-restconf-monitoring” or equivalent. We don’t need to create special > behaviours or special query parameters to implement this meta data. > > http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26 > <http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26> > > ietf-yang-library:modules/module/name > ietf-yang-library:modules/module/revision > ietf-yang-library:modules/module/schema > ietf-yang-library:modules/module/namespace > ietf-yang-library:modules/module/feature > ietf-yang-library:modules/module/conformance > ietf-yang-library:modules/module/submodule/name > ietf-yang-library:modules/module/submodule/revision > ietf-yang-library:modules/module/submodule/schema > > http://www.netconfcentral.org/modulereport/ietf-restconf-monitoring > <http://www.netconfcentral.org/modulereport/ietf-restconf-monitoring> > > ietf-restconf-monitoring:restconf-state/capabilities/capability > ietf-restconf-monitoring:restconf-state/streams/stream/name > ietf-restconf-monitoring:restconf-state/streams/stream/description > ietf-restconf-monitoring:restconf-state/streams/stream/replay-support > ietf-restconf-monitoring:restconf-state/streams/stream/replay-log-creation-time > ietf-restconf-monitoring:restconf-state/streams/stream/encoding/type > ietf-restconf-monitoring:restconf-state/streams/stream/encoding/events Ok, great! Thanks for pointing this out - there is no need to reinvent the wheel. 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/> > > > From: Alexander Pelov [mailto:[email protected]] > Sent: 7 juin 2015 05:21 > To: Michel Veillette > Cc: Andy Bierman; [email protected]; [email protected] > Subject: Re: Reserve space for aliases > > Hi Michel, > > That sound great! Having the short form (10 bits data node ID) and long form > (20 bits module ID + 10 bits data node ID), can save quite a lot when dealing > with more than isolated data items, as you point in your example. > > As I mentioned earlier, having your moduleID+0000000000 can be used as YANG > id for the module, which can provide meta-information on the loaded module. > For example, if you issue a request against that ID and receive Resource not > found, then the module is not loaded (but this of course should not be the > way to discover it). Is this useful? If there is need for module versioning, > the YANG module ID can be used to obtain the versioning information. Having > deterministic data node IDs can be used to have versions of the same module > (e.g. adding new leafs, new containers, etc.) - removing things out will > require new module ID. > > In addition to having reduced data requirements (in URIs and CBOR), having > the fixed YANG module IDs helps locate some special resources. > E.g. module ID: > aliasing : 18 bits = 0 + 00 > full YANG module ID = AAAA (compressed to A) > YANG meta-data module: 18 bits = 0 + 01 > full YANG module ID= AAAg0 (compressed to g0) > Reserved for future use: 18 bits = 0 + 10 and 18 bits = 0 + 11 > > The YANG meta-data module can provide all necessary meta-information, e.g. > mod.uri, the loaded modules, their versions, and so forth. This keeps the > separation between aliasing and meta-information. Note, that the meta-module > YANG scheme will be published with a normal assigned YANG module ID, which > will be mapped to the /mg/g0, e.g. changing the meta-data a couple of years > down the road is possible with or without versioning. > > I also don’t think it would be a good idea to have complex aliasing > mechanisms, and this should be further discussed. It will be very useful for > managed networks. The /mg/A resource should be kept as light as possible. For > the moment I think there are only two necessary pieces of information that > need to be given by it: hash-value of the contents of the mapping and URI to > extract the full mapping. The mapping can be obtained from the meta-data > (/mg/g0 or .well-known/core). The simplest mechanism to be used is the > following: > > 1) If no aliases are defined, then the client can POST a new alias mapping > 1.a) the alias mapping expires after a timer (default value = 1h, which > can be overridden by the client) > 1.b) upon timer expiry, the alias mapping is deleted > 1.c) the timer can be extended with a keep-alive POST from any client > 2) An alias mapping cannot be altered or deleted by a client. > > The reasoning behind this is the following: A node becomes ‘managed’ by a > client, and the client registers this. If a different client tries to POST > new configuration it will receive a 4.03 Forbidden. > > This actually makes configuring and implementing aliases really > straightforward. Upon discovery of a node, a client can directly POST to > /mg/A, and if it receives: > - "4.04 Not Found", then aliasing is not supported > - "4.03 Forbidden", the alias mapping is already defined (by someone else) > - "2.01 Created" - alias defined > - "2.04 Changed" - alias timer updated > > If the /mg/g0 is accepted as YANG meta-data module pointer, then the actual > alias mapping can be retrieved from there. > > Best, > Alexander > > > > > Le 5 juin 2015 à 23:43, Michel Veillette <[email protected] > <mailto:[email protected]>> a écrit : > > Hi Alexander and Hi Andy > > I thinks we can avoid the support of a complex aliases mechanism and still > archive the same level of message compression. > The solution consists of supporting two forms of data node identifier, the > same way as RESTconf. (e.g. ietf-system:current-datetime vs. current-datetime) > > The long form will consist of the ID format proposed by Alexander (2 > reserved bits, 20 bits module ID, 10 bits data node ID). > The short form will carry only the data node ID (10 bits data node ID). > The long form will be used only when needed. > > Let assume we have these two modules: > > module a { > > container containerA { > leaf leafA1 { type string}, > leaf leafA2 { type string} > } > } > > module b { > import a { prefix a; } > > augment "/a:containerA" { > leaf leafA3 { type string} > } > } > > Let assume we have these assigned IDs: > > > ID > Full ID > Base64 > module a > 25 > > > container containerA > 1 > 110010000000001 = 25601 > GQB > leaf leafA1 > 2 > 110010000000010 = 25602 > GQC > leaf leafA2 > 3 > 110010000000011 = 25602 > GQD > module b > 26 > > > leaf leafA3 > 1 > 110100000000001 = 26625 > GgB > > A GET can be implemented as follow: > > REQ: GET example.com/mg/GQB <http://example.com/mg/GQB> > > RES: 2.05 Content (Content-Format: application/cbor) > { > 1 : { > 2 : " leafA1 value", > 3 : " leafA2 value " > 26625 : " leafA3 value " > } > } > > A PUT can be implemented as follow: > > REQ: PUT example.com/mg <http://example.com/mg> > { > 25601 : { > 2 : " leafA1 value", > 3 : " leafA2 value " > 26625 : " leafA3 value " > } > } > > RES: 2.05 Ok > > > <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 16:10 > To: Andy Bierman > Cc: Michel Veillette; [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: Re: Reserve space for aliases > > Hi Andy, > > You are right that if we start considering multiple clients, each of which > trying to use its aliases the things become.. les optimal. And if no caution > is taken - can spell trouble. > > The point is, your default behavior should be to use the normal ID. However, > in some cases, you may decide that you’re going to be having quite a lot of > exchanges with the same ID, so yes, you can redefine the alias mapping. > > However, you are right that we need to take care of eventual race conditions. > Indeed, in 6TiSCH and other managed networks it may not happen (which alone > is sufficient for me to have this « golden » IDs be left out of the « > randomly allocated », or « eternally locked to a specific ID » resources). > > Having the /mg/A resource provide the meta-information can help solve a lot > (all?) of the problems. (in my past mails I referred this as /mg/0 but I > meant /mg/A, sorry) > > The first requirement for a client is to query the /mg/A resource. > There, you can get the meta-data concerning the aliases, including the hash > of the alias mapping, the mapping itself (if necessary), and the updater > (identified by a token). I’m wondering if there could be added a validity of > the mapping. A client can change the mapping ONLY if it is the last updater > (hash+token match), or if the validity has expired. If the server has a way > of keeping time it can track the validity itself. Otherwise, it can be a > constant datetime after which the resource is considered expired and any > client can update the resource. > > Just to be sure, I’m talking about clients, which are capable enough to keep > track of some context about the servers it controls OR a client in a > particular kind of network, which knows that some things are just expected to > be there and there is no way for them to happer otherwise. > > ***************** > ** The default way of doing things should always be to use the normal IDs.** > If you want to be optimal (in some way), get /mg/A, and if you understand it > - use it. If there’s nothing, POST whatever you like, but be sure that you > have enough resources to remember what you’re doing. > * > * If you want to set a different configuration in each of your 10M nodes, > then well you should have the storage to remember all of them. > ***************** > > By the way, I was thinking of something quite interesting, which can come > supplement the node ID aliasing. Actually, I think that the 20 bits + 10 bits > YANG id really opens a lot of perspectives (will try to write that up > tomorrow). > > The major point is that when the data node ID = 0, the module ID can be used > as a resource to obtain meta-information on the module. For example, its > version. This way, if you update a YANG module with a new one, which only > appends elements, you will not need to request a new managed ID. GET > /mg/moduleID?keys=version (with data node ID=0) and you know what is your > module really capable of. > > Also, the special place of /mg/A can actually become an entry point for most > of the information related to CoMI (to be discussed.. I have no strong > feelings on this). It can, for example, provide the mod.uri, and other > information. The only information that remains truly necessary to be fixed in > /.well-known/core is the entry point to the CoMI interface (e.g. /mg). > Afterwards, everything can be determined from /mg/A with queries > (/mg/A?keys=mod.uri+alias.uri) > > Best, > Alexander > > PS. > As if data node aliasing is not enough… module ID aliasing (this one is > really very low in my priorities and I’m mentioning it only for completeness): > > The first 12 bits take 2 URI characters and 2 bytes in CBOR. Having 10 bits > for the data node ID leaves 2 interesting bits in the module ID part… So we > can have module aliases as well (albeit only 3). > > That is, in URI encoding, > 0x00000000-0x000003FF -> data node aliasing > 0x00000400-0x000007FF -> aliased module 1 > 0x00000800-0x00000BFF -> aliased module 2 > 0x00000C00-0x00000BFF-> aliased module 3 > > Implementation-wise, its really easy: upon request, if the module ID = > aliased module ID 1, replace the module ID part, so no need to map the entire > module ID / data node ID space. > > But really, that much optimization? Even if it seems straightforward, I would > like to see use cases that could benefit from this before actually > considering it. > > > > Le 5 juin 2015 à 20:55, Andy Bierman <[email protected] > <mailto:[email protected]>> a écrit : > > > > > 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
