Martin,
See below.
On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
> Lou Berger <[email protected]> wrote:
>> 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?
>
> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
