multiple keys validation performance

[cnicasio]

We have the following problem:

We have a service "service1", with a Yang model with a list that has multiple keys. Other services have to leafref to "service1" instances. On those services we can build leafrefs to each key in "service1", and we have to add logic to validate that the combination of keys correspond to a "service1" instance:

list service1 {
keys "key1 key2";

leaf key1 {
type string;
}

leaf key2 {
type string;
}
}

Service2 is as follows:

list service2 {
key service2-key;

leaf service2-key {
type string;
}

leaf service1-key1 {
type leafref {
path "/service1/key1";
}
}

leaf service1-key2 {
type leafref {
path "/service1/key2";
}
}

.....
}

As we want the leafrefs for service1 key1 and key2, refer to the same service instance, we must change service2 to something like that:

list service2 {
key service2-key;

leaf service2-key {
type string;
}

leaf service1-key1 {
type leafref {
path "/service1/key1";
}
}

leaf service1-key2 {
type leafref {
path "/service1[key1 = current()/../service1-key1]/key2";
}
}

.....
}

The problem with this code is that if the number of service1 instances is very large, apparently model validation starts to be costly and takes time to compute. Specially with service2 instances deletions.

Anybody has a suggestion on how to redesign the models to avoid this?

Regards

Oscar

[kiran kotari]

have you tried using deref

leaf service1-key2 {
type leafref {
path "deref(./service1-key1)/../key2;
}
}

[cnicasio]

Sorry for the delay in aswering Kiran...thanks for you answer.

Will try that,

[rogaglia · Accepted solution]

Your validation is expensive because you are asking to check a large list. If you  accept more lax validations, there are things that may be possible, in particularly using tailf YANG extensions ("tailf:non-strict-leafref" may be your solution)

tailf:no-leafref-check
This statement can be used to let 'leafref' type statements reference non-existing leafs. While similar to the 'tailf:non-strict-leafref' statement, this does not allow reference from config to non-config.
The no-leafref-check statement can be used in: type.

tailf:non-strict-leafref
This statement can be used in leafs and leaf-lists similar to 'leafref', but allows reference to non-existing leafs, and allows reference from config to non-config.
This statement takes no argument, but expects the core YANG statement 'path' as a substatement. The function 'deref' cannot be used in the path, since it works on nodes of type leafref only.
The type of the leaf or leaf-list must be exactly the same as the type of the target.
This statement can be viewed as a substitute for a standard 'require-instance false' on leafrefs, which isn't allowed.
The CLI uses this statement to provide completion with existing values, and the WebUI uses it to provide a drop-down box with existing values.
The non-strict-leafref statement can be used in: leaf and leaf-list.

tailf:xpath-root value
Internal extension to 'chroot' XPath expressions
The xpath-root statement can be used in: must, when, path, tailf:display-when, tailf:cli-diff-dependency, tailf:cli-diff-before, tailf:cli-diff-delete-before, tailf:cli-diff-set-before, tailf:cli-diff-create-before, tailf:cli-diff-modify-before, tailf:cli-diff-after, tailf:cli-diff-delete-after, tailf:cli-diff-set-after, tailf:cli-diff-create-after, and tailf:cli-diff-modify-after.

[cnicasio]

yes Roque we tried tailf:no-leafref-check and that solved the problem.

Thanks!

[Gastonper]

Hi, I don't get the point of the "tailf:no-leafref-check" statement.

It seems like a temporary fix, just to add values to a leafref type of node that reference to non-existing leaf; and then remove the statement. But if I do that I get an illegal reference error on package reload.

So, if this is a permanent solution to avoid long validation times, why you dont just change the type of the leaf to a string? I am losing the validation anyway.