Re: [netmod] schema mount open issue #1

[Lou Berger <[e-mail]>]

Martin,
	See below.

On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
> Lou Berger <[e-mail]> wrote:
>> 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?
> 
> Suppose a server lists a couple of modules for "vrf-root" and some
> other for "vsi-root" in the /schema-mounts/mount-point list.  How can
> a client tell if a certain NI instance is has the "vrf" modules or
> "vsi" modules?

umm, my understanding is that only one of the cases under a choice can
be present in the data (tree) at a time so the client *can* only see one
 mount point {vrf-root, vsi-root or vv-root} node and all the mounted
schemas will be under that '-root' node.  What have I missed?


> 
> In general, when you have a choice with cases, all nodes from all
> cases are disjoint, and the client can tell which case is active by
> checking which nodes are present.
> 
> Wouldn't it be possible to restructure as bit so you have:
> 
>    choice ni-type {
>      container vrf {
>        ymt:mount-point vrf-root;
>        // additional vrf-specific config params goes here
>      }
>      container vsi {
>        ymt:mount-point vsi-root;
>        // additional vsi-specific config params goes here
>      }
>      ...
>    }
> 

Yes, but there will *never* be any additional type specific parameters
in the container (by definition), so the container serves no purpose and
just adds to the path unnecessarily.

> 
>>> 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?
> 
> This gives more flexibility, since several mount points can share a
> single schema.

from my (user) perspective, the parent references are an equally
intrinsic part of the schema and the flexibility adds unneeded complexity.

>  Also, if we had parent-reference per schema, we cannot
> solve the original issue that started this thread.

We/I can live with the current solution (and its overhead), so this
isn't a critical discussion.  Let's focus on the open point covered above.

Thanks,
Lou