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
REQ: GET 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
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
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
[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: 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]]
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
