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