github-actions[bot]
commented
1 month ago This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.
PR #543 contains some recommendations related to the validation of the existence of leafs pointed to in leafref paths.
There are a number of potential concerns with the text in PR #543. I've tried to break it down into smaller finite discussion points (although many of these overlap).
(A) It wasn't clear (at least to some) whether an implementation is allowed to validate leafref target existence by default.
(B) Not validating leafref path targets for OpenConfig paths is somewhat creating an "OpenConfig variant" of the YANG language. It is probably worth some further discussions around the impact and implications of that path.
(C) YANG 1.1 already has the "require-instance false" statement that could be used if "soft" leafrefs are desired in certains parts of the models.
(D) For deployments that use a mix of OpenConfig configuration statements and Native configuration statements (e.g. to fill in some holes/gaps), it would likely be operationally difficult to have a mix of leafref behavior in the system
(E) Defining that a leafref doesn't validate target existence in OpenConfig models may conflict when the OpenConfig statements are mapped to the native internal data model and that internal data model has "hard" leafref behavior.
(F) Is it clear most users of the OpenConfig models in the networking space won't actually want path target validation? An eventual consistency model is a valid approach, but there may also be a desire for some users to fail inconsistent configurations with dangling leafrefs (i.e. I expect my interface to bind to its ACL - I don't really want the interface configuration to complete if the target ACL doesn't exist).
(G) The PR does hint at this, but there are potential significant implementation issues with this change to the interpretation of YANG leafrefs. Some application layers require the leafref target to be present. Changing the behavior to "soft" leafrefs could require non-trivial rework of many app layer modules to be able to handle unresolved references, keep the parent object operationally down until the binding is finally resolved, have hooks to be notified when the binding is resolved in order to come operationally up, have new state information that the parent object is down for reason x (i.e. "interface down, ACL not available"), etc. [Note that doing the opposite, i.e. if an app layer handles soft leafrefs, but the YANG model has hard leafrefs, is much easier. That would purely be handling in the management layer with no impact to the app layer. But making a 'hard leafref" app layer handle a "soft" leafref involves some rewrite of the app layer code.