>From a data-modeling perspective, it makes sense to be able to define maps. For instance, one can envision said information being used during code-generation for in-memory and persisted datastores.
*If* it is not required that the JSON encoding be a JSON map, your yang
module could create a derived type:
typedef map {
type list;
}
container network-map {
map entry {
key "pid";
leaf pid {
type string;
}
leaf-list ipv4 {
type inet:ipv4-prefix;
}
leaf-list ipv6 {
type inet:ipv6-prefix;
}
}
}
I actually just tried this (see attached file), but pyang complains:
pyang --strict alto-test.yang
alto-test.yang:7: warning: imported module ietf-inet-types not used
alto-test.yang:25: error: type "list" not found in module alto-test
alto-test.yang:30: error: unexpected keyword "map"
RFC 6020 doesn't limit which types can be used in a typedef statement, so
this might be a bug in pyang...
Kent
From: "Y. Richard Yang" <[email protected]>
Date: Tuesday, September 30, 2014 at 1:31 PM
To: "[email protected]" <[email protected]>
Cc: IETF ALTO <[email protected]>
Subject: [netmod] Key-value data structures in YANG/JSON encoding
Hi all,
A few of us are doing an exercise of defining a YANG module to express the
ALTO protocol (RFC7285). Multiple problems come up and here is one problem
we encounter.
First, the context. A design decision of the ALTO protocol is to use
key-value stores (maps), which are different from lists or containers.
Many large-scale systems are designed based
on key-value stores, and many programming frameworks provide hash maps.
A particular example of using key-value map is the network-map, which is
defined as a key-value store to enforce that each named endpoint address
group has a unique name. A specific
example is in Section 11.2.1.7 of RFC 7285
(http://www.rfc-editor.org/rfc/rfc7285.txt):
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24 <http://192.0.2.0/24>",
"198.51.100.0/25 <http://198.51.100.0/25>"
]
},
"PID2" : {
"ipv4" : [
"198.51.100.128/25 <http://198.51.100.128/25>"
]
},
"PID3" : {
"ipv4" : [
"0.0.0.0/0 <http://0.0.0.0/0>"
],
"ipv6" : [
"::/0"
]
}
One way to express this in YANG is the following:
===example YANG===
list network-map {
key "pid";
leaf pid {
type string;
}
leaf endpoint-address-group ... {
// ...
}
}
==================
Following the currently defined json encoding, the output will be:
{
"network-map" : [
{
"pid" : "PID1",
// ...
},
{
"pid" : "PID2",
// ...
},
{
"pid" : "PID3",
// ...
}
]
}
But this not what we want, because it is using an array, not a map. One
does not have to use an array to store the map.
We see two possibilities, if to produce the output. One is in the encoding
process: define such
outputs on matching a template:
list MyList {
key x;
leaf x {
type string;
}
leaf y {
...
}
}
The second is that maybe this should be resolved in YANG; i.e.,
introducing a new data type (beyond list, container), but something like
key-value store, say
named map:
map MyMap {
key my-key {
...
};
value my-value {
}
}
Note that the second mapping involves work if the key type is not a simple
type (say string or numbers). A typical approach in some software
framework is to
define a hash function on key.
We have discussed the issue with Lada, and now take the issue to the
mailing list. If anyone else has encountered similar problems, please let
us know. We also want to get a sense of any interest in introducing the
data type in YANG. Any comments will
be appreciated.
Thanks!
Richard
alto-test.yang
Description: alto-test.yang
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
