Cool! It us good to know that we are not the only one. Richard On Sep 30, 2014 4:55 PM, "Thomas D. Nadeau" <[email protected]> wrote:
> > 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 > > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
