Subject: [netmod] escaping mount jail

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 19 Nov 2016 10:48:13 +0100

Hi,

a relatively clean solution to $subj might be to introduce a new XPath function, say parent-root(), for use in instance identifiers (and perhaps also in "must" and "when" expressions). It would return the root node of the parent data tree, and the global root node if used in the top-level tree.

This would allow for defining proxy nodes for reaching nodes of the parent tree, and it would also solve Dean's problem of mapping interface names. For example, one could use this in a LNE tree:

  <interface>
    <name>eth0</name>
    <lne:host-interface>
      parent-root()/if:interfaces/if:interface[name="Ethernet0/1/1"]
    </lne:host-interface>
    ...
  </interface>

Would this work for known use cases?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Nov 2016 11:57:13 -0500

Lada,

    I think there's another way to look at this.  Based on the related
conversation on this topic from the last couple of  weeks, I think there
is a fundamental conceptual addition needed to schema mount.  Basically
it comes down to:

    Unique vs Shared Data

    With Schema Mount, a mount point is used to represent the root
    mode for one or more data models.  Schema mount provides for
    the instantiation of new information that is only accessible
    within the context of the mount point.  Importantly,  data
    within a  mounted subtree can never refer to data outside of
    this subtree.   That is, nodes within the mounted context (the
    mounted "child") cannot refer to data outside (either the
    mounted "parent" or other mount point "sibling" instances). 

    The discussions (including Acee's mail to the list and the
    related public and private threads) highlight that there are
    cases when the same data may need to be shared between parent
    and child models.  Sharing across sibling models may also be
    required, but it may be sufficient to provide the sharing of
    parent information with multiple children rather than define
    additional mechanisms for this special case.

In the context of the draft-ietf-rtgwg-lne-model use case, we addressed
this need for shared data as a special case where, to quote section 3.1:

   Resources assigned to the LNE will be represented in that LNE's
   resource modules. e.g., an LNE's interfaces module will contain the
   interfaces assigned to that LNE from the containing network-device.

Where this would be supported in an "implementation dependent" fashion.

The discussions (including Acee's mail to the list and the related
public and private threads) highlight that the current think on shared
data really needs to be formalized and generalize to fully enable models
such as ni and lne. It also highlights that a simple path based
mechanism, such as my (now OBE) "mod-rewrite" concept or the one below,
really don't seem sufficient to represent the shared data case.

Now there has been previous discussion on sharing local data schema in
the context of the original mount (draft-clemm-netmod-mount) which was
referred to as Alias-Mount.  The key difference in the current use case
is that the same mount point would serve as the root for unique data
(ala schema mount) and shared data (ala alias mount).

The use case for LNE and NI used the extension mount-point (not the list
mount-point in the mount-point-list grouping) .  I think defining a
grouping that contains the extension mount-point, and a list of (parent)
schema to be shared as well as some policy would do the trick.  Using
LNE as an example, the end result would be something like:
    module: ietf-logical-network-element
        +--rw logical-network-elements
           +--rw logical-network-element* [name]
              +--rw name            string
              +--rw managed?        boolean
              +--rw description?    string
              +--rw root?
              +--rw alias-mounts* [name]
                 +--rw name        yang:yang-identifier
                 +--rw readonly?   boolean
                 +--rw filter?     string    // details TBD
      augment /if:interfaces/if:interface:
        +--rw bind-lne-name?   string

Does this sound like a workable direction?

I think that the combined use of alias and schema mount should be
included in a single document (yours) and am happy to work this offline
on this if you agree.  If not, I'll work it within the DT and come up
with a more formal/flushed out proposal.

Lou

(as WG/DT contributor and co-author of the LNE/NI docs)

On 11/19/2016 4:48 AM, Ladislav Lhotka wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Nov 2016 20:12:55 +0100

> On 21 Nov 2016, at 17:57, Lou Berger <[email-masked]> wrote:
> 
> Lada,
> 

Alias mount is a quite different concept which IMO still has a bunch of problems to solve, and I don't want to mix it with schema mount. For the use cases you mention I would very much prefer some kind of explicit link between the parent and child data trees rather than relocate data or schema subtrees. With Martin we are currently discussing my parent-root() XPath function and similar alternatives, and LNE-NI model will certainly be our main focus.

Lada

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Nov 2016 14:20:16 -0500

> Alias mount is a quite different concept which IMO still has a bunch of problems to solve, and I don't want to mix it with schema mount. For the use cases you mention I would very much prefer some…

Thanks Lada.  The nice thing about a shared data mount (with whatever
name we come up with) is that models within the mount point are always
scoped within that mount point and paths are always self contained. 
Such consistency, and limiting the knowledge that a models is mounted,
seems like a real win to me.  I think there are also good parallels for
this in host computing today.

Lou

> Rtg-dt-yang-arch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Nov 2016 20:56:55 +0100

> On 21 Nov 2016, at 20:20, Lou Berger <[email-masked]> wrote:
> 
> 
> 

I think these parallels are about sharing *instance* data whereas schema mount is about combining *schemas*. This is often confused, and that's why I (unsuccessfully) tried to avoid using the term "mount point" for the schema mount case.

Lada

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Nov 2016 15:13:55 -0500

Lada,

On 11/21/2016 2:56 PM, Ladislav Lhotka wrote:
> I think these parallels are about sharing *instance* data 
Sharing selected data (between parent and child)  is exactly the extra
capability that's needed.  I'm happy to call it by a different name, but
continue to think that from the child's perspective having an
inescapable root brings a lot of value/simplicity.

Lou

> whereas schema mount is about combining *schemas*. This is often confused, and that's why I (unsuccessfully) tried to avoid using the term "mount point" for the schema mount case.
>
> Lada
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Nov 2016 21:52:41 +0100 (CET)

>    interfaces assigned to that LNE from the containing network-device.

I think this is the way to go.   And this is what you already have in
your draft.  Do you see any problems with this solution?  Do you agree
that this is the "unique" case?   Do you have an example of where the
"shared" case would be needed?

> really don't seem sufficient to represent the shared data case.

It is not clear to me what requirements the shared data case puts on
the solution.

/martin