Re: [netmod] schema mount open issue #1

[Martin Bjorklund <[e-mail]>]

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?

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


> > 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.  Also, if we had parent-reference per schema, we cannot
solve the original issue that started this thread.

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


/martin