[netmod] inline mount

Ladislav Lhotka <lhotka@nic.cz> Wed, 07 February 2018 09:32 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B5D5B126BF0 for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 01:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id F-tZg5eiwuoA for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 01:32:24 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name []) by ietfa.amsl.com (Postfix) with ESMTP id 603DB126CC7 for <netmod@ietf.org>; Wed, 7 Feb 2018 01:32:24 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 1C2811820412; Wed, 7 Feb 2018 10:31:11 +0100 (CET)
Received: from localhost (nat-2.nic.cz []) by trail.lhotka.name (Postfix) with ESMTPSA id B97A218203F6 for <netmod@ietf.org>; Wed, 7 Feb 2018 10:31:09 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Wed, 07 Feb 2018 10:32:20 +0100
Message-ID: <87bmh1i1qz.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XwjcExWKM6H0oQTqNVZim_HJvSY>
Subject: [netmod] inline mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 09:32:27 -0000


before proceeding with the schema mount draft, we need to clarify the
concept of "inline" mount because it causes a lot of confusion, and the
current text (in sec. 3.2) clearly doesn't work for NMDA. I believe there
are some hidden assumptions about how it is supposed to work that have
to be made explicit.

In particular, the inline mount seems to require that an instance of the
mount point plus YANG library data be placed in <operational> as a side
effect of creating the corresponding mount point instance in any

Perhaps it would be possible to approach it from the opposite direction
and start with creating the necessary data in <operational> as a result
of an explicit mount event.

For example, when provisioning a new VM instance, the server would "mount"
the following data in <operational>:
- the mount pount instance
- the YLbis data that defines the mounted schema for all datastores
- any other state data that are needed.

The above step basically creates a new system-controlled resource that
can be configured after that in the same way as other system-controlled
resources such as physical interfaces.

The advantage of this approach is that we needn't speculate about
whether and when the embedded YL data magically appears in <operational> -
it is the mount event that does exactly this, and only after that the
mounted resource can be configured. This concept would also be more
alike to the mount operation known from Unix filesystems.



Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67