Re: [netmod] schema mount open issue #1

[Ladislav Lhotka <[e-mail]>]

Lou Berger píše v Po 28. 08. 2017 v 08:54 -0400:
> 
> On 8/28/2017 7:35 AM, Martin Bjorklund wrote:
> > 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.  
> 
> okay, I think we're getting to the crux of this issue!  I certainly
> didn't see this (that a schema-mount root node is *not* represented in
> the data, but only in the schema) stated in
> draft-ietf-netmod-schema-mount.  In fact, I read the text as saying just
> the opposite:

I don't think so, it just says that an (existing) node in the parent schema gets
the mount-point label. The mount-point extension itself generates no extra node.

If we used schema node identifiers denoting the mount points instead of the
extension (as I proposed earlier), there would be no additions to the schema
proper, so this confusion couldn't arise.

> 
>    The basic idea of schema mount is to label a data node in the parent
>    schema as the mount point, and then define a complete data model to
>    be attached to the mount point so that the labeled data node
>    effectively becomes the root node of the mounted data model.
> 
> Why don't you think an MP should be represented in the data (tree)?
> 
> In our example usage
> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we
> include the mount point as a node in the data.  You're saying that this
> doesn't line up with your expectation, right?
> 
> Can you please take a look at it and see if we have any other disconnects?

This is really scary. How can we expect poor data modellers to understand the
concept if we have such fundamental disconnects, after so many hours of
discussing it?

Lada

> 
> > 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.
> 
> <rest trimmed>
> 
> Lou
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67