Re: [netmod] schema mount open issue #1

[Lou Berger <[e-mail]>]

Martin,
See below


On August 23, 2017 2:28:37 AM Martin Bjorklund <[e-mail]> wrote:

> Lou Berger <[e-mail]> 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
>