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
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
{
25601 : {
2 : " leafA1 value",
3 : " leafA2 value "
26625 : " leafA3 value "
}
}
RES: 2.05 Ok
[cid:[email protected]]
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: 5 juin 2015 16:10
To: Andy Bierman
Cc: Michel Veillette; [email protected]; [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
