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 > [image: cid:[email protected]] > > 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
