Martin, See below
On August 23, 2017 2:28:37 AM Martin Bjorklund <[email protected]> wrote: > Lou Berger <[email protected]> wrote: >> Hi Martin, >> >> See below. >> >> >> On 8/22/2017 6:20 AM, Martin Bjorklund wrote: >> > Hi, >> > >> > Lada presented an open issue in schema mount in Prague. (See slide 6 >> > in >> > >> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount) >> > >> > The original problem comes from the NI use case >> > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model). In this >> > use case, interfaces are assigned to NIs by: >> > >> > augment /if:interfaces/if:interface: >> > +--rw bind-ni-name? -> /network-instances/network-instance/name >> > >> > Modules that are mounted within the NI might have references to >> > interfaces. The idea is that a specific NI can only reference the >> > interfaces that has been assigned to it. >> > >> > In schema mount, we have the "parent-reference" XPath expression that >> > in this case will be "/if:interfaces/if:interface". The problem is >> > that this XPath expression will evaluate to a node set that contains >> > *all* interfaces in the system. We would like this to contain just >> > the interfaces assigned to the NI. >> > >> > It turns out that this can be done with a simple change to the >> > "parent-reference" node. If we state that this XPath expression is >> > evaluated in an XPath context where the context node is the node in >> > the data tree where the mount point is defined (instead of "/"), we >> > can use as parent-reference: >> > >> > /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name] >> > >> > Putting this together we'd have: >> > >> > augment "/if:interfaces/if:interface" { >> > leaf bind-ni-name { >> > type leafref { >> > path "/network-instances/network-instance/name"; >> > } >> > } >> > } >> > >> > container network-instances { >> > list network-instance { >> > key name; >> > leaf name { ... } >> > ... >> > container root { >> > // this would be the XPath context root for parent-reference >> > yangmnt:mount-point ni-root; >> > } >> > } >> > } >> >> note that the current NI definition is: > > Yes I saw that. > >> module: ietf-network-instance >> +--rw network-instances >> +--rw network-instance* [name] >> +--rw name string >> +--rw enabled? boolean >> +--rw description? string >> +--rw (ni-type)? >> +--rw (root-type)? >> +--:(vrf-root) >> | +--mp vrf-root? >> +--:(vsi-root) >> | +--mp vsi-root? >> +--:(vv-root) >> +--mp vv-root? > > Note that the extension yangmnt:mount-point can only be present in a > container or list, not in a choice/case. Okay, I missed that restriction in your draft. What's the reason for not allowing mounts under choices/cases? Isn't the resulting path to data nodes indistinguishable when the parent is a list or container? > > But what is the point of a choice with three different mount points? > >> augment /if:interfaces/if:interface: >> +--rw bind-ni-name? -> /network-instances/network-instance/name >> augment /if:interfaces/if:interface/ip:ipv4: >> +--rw bind-ni-name? -> /network-instances/network-instance/name >> augment /if:interfaces/if:interface/ip:ipv6: >> +--rw bind-ni-name? -> /network-instances/network-instance/name >> >> > And in state data: >> > >> > >> > "ietf-yang-schema-mount:schema-mounts": { >> > "namespace": [ >> > { >> > "prefix": "ni", >> > "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" >> > }, >> > { >> > "prefix": "if", >> > "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces" >> > } >> > ] >> > "mount-point": [ >> > { >> > "target": "/ni:network-instances/ni:network-instance/ni:root", >> Can you confirm that with the current definition the target is: >> >> "target": "/ni:network-instances/ni:network-instance", >> >> correct? > > See above; the current definition is invalid. this is going to get really verbose if schema mount's restrictions remain as we'll need a container and target per case mount point case. Looking at this issue leads me to ask the question: why are parent references tied to the mount point vs the schema? Are the parent references always going to the same in order for the schema to make sense. I think this question is separable from the restriction discussion above, but it does help if we stick with the current restrictions. To be clear I'm suggesting: Drop parent-reference from: | +--ro (schema-ref)? | +--:(inline) | | +--ro inline? empty | +--:(use-schema) | +--ro use-schema* [name] | +--ro name | | -> /schema-mounts/schema/name | +--ro parent-reference* yang:xpath1.0 and add it to +--ro schema* [name] +--ro name string +--ro parent-reference* yang:xpath1.0 > >> > "parent-reference": [ >> > "/if:interfaces/if:interface >> > [ni:bind-network-instance-name = ../ni:name]" > > Correction. This should be: > > "/if:interfaces/if:interface > [ni:bind-network-instance-name = current()/../ni:name]" > >> > ], >> Also, can you confirm that if we wanted to cover v4, v6 (for example >> purposes) interfaces-state, the full parent reference list would be: >> >> "parent-reference": [ >> "/if:interfaces/if:interface >> [ni:bind-ni-name = ./ni:name]", >> "/if:interfaces/if:interface/ip:ipv4 >> [ni:bind-ni-name = ./ni:name]", >> "/if:interfaces/if:interface/ip:ipv6 >> [ni:bind-ni-name = ./ni:name]", >> "/if:interfaces-state/if:interface" >> >> correct? > > No it would be: > > /if:interfaces-state/if:interface[ > if:name = /if:interfaces/if:interface[ > ni:bind-ni-name = current()/../ni:name]/if:name] > > etc. > > I.e., the interfaces in -state that that has the same names as the > interfaces in config that has the correct bind-ni-name. okay, nice xpath foo Thanks, Lou > > >> Note that interfaces-state isn't filtered as the bind-ni-name isn't >> present in -state. >> >> > "use-schema": [ >> > { >> > "name": "ni-schema" >> > } >> > ] >> > } >> > ] >> > >> > >> > >> > Note that this does NOT affect the schema that is mounted; it only >> > affects the result of the parent-reference XPath expressions. >> > >> > >> > I think that we should make this change, since it allows for more >> > precise parent-references. >> I'm okay with the change (just want to see the draft moved forward ;-) >> >> Lou >> (As contributor) > > > > /martin > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
