On 2017-10-06 23:11, Xufeng Liu wrote:
During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the case when the operator or client software needs to retrieve the object contents pointed by a leafref.
For example, given the following simplified TE tunnel model,
+--rw te
+--rw explicit-paths
| +--rw explicit-path* [name]
| +--rw name string
| +--rw explicit-route-object* [index]
| +--rw index uint32
| +--rw explicit-route-usage? identityref
+--rw tunnels
| +--rw tunnel* [name]
| | +--rw name string
| | +--rw paths
| | | +--rw path* [name]
| | | +--rw explicit-path? ->
../../../../../explicit-paths/explicit-path/name
when the client tries to retrieve a tunnels information based on the tunnel
name, the get operation returns a list of leafrefs pointing to the paths of
the tunnel.
Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?
JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".
--Per
The client needs to issue at
least one more get operation to retrieve the path information about the given tunnel. The request is to combine these two operations into one.
In the RDBMS SQL world, join can be used when SQL select is performed, but
NETCONF/YANG currently does not have this capability.
Wed like to ask whether such a request is considered reasonable.
If the request is reasonable, the next question is how to proceed. This seems to be a protocol issue rather than YANG modeling issue. Is it acceptable to add a new operation to achieve such a
<get-data> operation with expanded leafrefs?
Comments and suggestions are appreciated.
Thanks,
- Xufeng
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
