I was discussing this very same issue here at the ODL Yangathon
yesterday. Others are stumbling onto this same issue.
--Tom
> 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",
> "198.51.100.0/25"
> ]
> },
> "PID2" : {
> "ipv4" : [
> "198.51.100.128/25"
> ]
> },
> "PID3" : {
> "ipv4" : [
> "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
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
