On 04/06/2022 22:57, Kent Watsen wrote:
Hi Robert,3) I wish more modules would following the pattern of having the global protocol accessible tree be defined via a "uses" of a grouping defined in the module. In another recent project, I had to hack the topology modules defined in RFC 8345 (to convert the containers to groupings) to enable a multiplicity of "abstract network topologies" to be configured. The assumption that only a single global instance is ever needed is proving to be invalid in my work time and again./me puts the co-author hat on.The multiplicity is already built-in into the model by the fact that network topologies is a top-level list.Would you mind sharing the use case what requires multiplicity of the built-in multiplicity?I know this sort-of is a re-hash of the ietf-interfaces discussion, but while there the use-case is well understood, I wonder what equivalent is there for networks/topologies.I appreciate that the model supports a multiplicity of topologies, and can see that it could support my needs, but my issue seems to arise in the intersection of the following desires:1) a server that supports multi-tenancy 2) each tenant being able to define a number of topologies 3) each tenant only being able to see their own topologies 4) the server not supporting object-level access control5) the data-model being schema-mount like, whereby each tenant-instance contains *all* tenant nodes (e.g., all leafrefs are relative paths that never go above the tenant's subtree.
Right, so the problem really is a combination 4) and 5). 4 is dictating use of some ACL model where you (warning: conjecture) can filter on a global prefix. 5 dictates that prefix is not formed through the use of RFC8528 schema mount -- hence you form that via something like
import ietf-network { prefix nw; }
list tenants {
key name;
uses nw:networks;
}
Two issues with addressing this issue through remodeling as groupings are:
1. leafrefs cannot use absolute addressing, opening a can of interop worms
2. technology-specific augments no longer have a single target, leading
to an NxM explosion (N = technologies, M = ietf-network grouping
instantiations)
The first is an annoyance, the second is a major problem solved (semi-reasonably?) through RFC8528...
The thing is: RFC8345 is very much a 'turtles all the way down' modeling exercice. Turning 'container networks' into 'grouping networks' still leaves you with that gap we call "augments target instantiations, not definitions" -- e.g. after introducing those groupings you mentioned you then proceeded to duplicate all technology augments to make them work with all them instantiations, right?
I really think you should fix your server (to supported at least 4) :) Regards, Robert
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
