Hi,
The network-instances draft (draft-ietf-rtgwg-ni-model) uses YANG mount
to allow relevant parts of the YANG schema to be made available under a
particular network instance (e.g. as per the diagram on section 3.2),
reproduced inline here:
+--rw yanglib:modules-state [RFC7895]
+--rw if:interfaces [RFC7223]
| +--rw bind-network-instance-name="green" string
+--rw network-instances
+--rw network-instance* [name]
+--rw name="green" string
+--rw type? identityref
+--rw enabled=true boolean
+--rw description="The Green VRF" string
+--rw network-instance-policy
| ... (RT=1000:1, RD=1.2.3.4)
+--rw root? yang-schema-mount
+--rw yanglib:modules-state [RFC7895]
+--rw if:intefaces [RFC7223]
+--rw mm:network-services
+--rw nn:oam-protocols
+--rw oo:routing
+--rw pp:mpls
My assumption is that the mounted YANG modules are just providing
alternative paths in the schema for the same underlying data nodes that
are also available without going via the schema-mount path. I further
presume that datanodes could be read/written in both places (of course
subject to NACM), and that any changes to data nodes made in one place
must be immediately reflected in both places.
To give a concrete example, assuming that "eth0" was bound to
network-instance "foo" then:
network-instances/network-instance[name="foo"]/root/interfaces/interface[name="eth0"]
would be pointing to the same actual data node as /interfaces/interface[name="eth0"].
Is my interpretation of how schema mount is anticipated to work in this
scenario correct?
If my understanding is correct then this would seem to imply:
- semantic validation of the the datatree can be performed by ignoring
schema mounted nodes altogether.
- leafrefs logically exist independently of the schema mounted nodes.
- leafrefs viewed under a schema mount can, in some cases, be
simplified to look like the reference is local within the mounted schema
tree, but in the case that I'm considering here, it isn't obvious to me
that all such leafrefs must necessarily never reference nodes outside of
this subtree.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
