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]> 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
