Re: [netmod] schema mount open issue #1

[Martin Bjorklund <[e-mail]>]

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

The mount point itself is not a node.  So the client will just see
some mounted top-level nodes.  If you require that all mount points
have disjoint sets of modules, then this could work.  But I assume
that this is not the case.

> > 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)

Why is that?  Why not have them in the same container?

Hmm, maybe in general it is better to not mix mounted data with normal
data in the same container.

> so the container serves no purpose and
> just adds to the path unnecessarily.

Well, its presence would inform the client about which mount point is
used, so I don't think it is unnecessary.

> >>> 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
> 



/martin