Subject: [netmod] Schema mount questions

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 May 2016 16:44:21 +0200

Hello,

1) Will mounted YANG modules be listed in the base
ietf-yang-library? Even the mounted ones?

2) What does conformance to a YANG  module e.g. ietf-system mean
now? Do we need to load the module at the top level, or is it
enough to mount it “somewhere” in the containment tree?

3) If the answer to 2) is it can be mounted anywhere, which
modules must be present at the top level? E.g. ietf-yang-library?

4) If a new list entry is created can it introduce a completely
new module never heard of before in the network element?

5) IMHO allowing such dynamic introduction of new YANG modules
into a network element, with flexible mountpoints, flexible set of
modules at each mountpoint, a flexible set of deviations and
features for each mounted module makes discovery actual available
schema tree difficult. I think we are providing to much
flexibility, over-complicating the issue. Some more static
mounting solution that can be read from YANG modules instead of
run-time data would be easier.

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 May 2016 11:03:12 -0700

On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel <[email-masked]>
wrote:

> Hello,
>
> 1) Will mounted YANG modules be listed in the base ietf-yang-library? Even
> the mounted ones?
>

Does the server providing the mounted modules claim conformance
to those models?

IMO YANG mount breaks the "YANG API contract" if even 1 tiny
property is ignored, due to mounting.

I asked for a conformance enum of 'none' or 'other' for this exact purpose
but
the WG did not think it was possible for a server to do anything
other than implement or import a YANG module.

E.g, we are building a special server "library-mode" that just
provided\s the library and get-schema for every module.
They will all be listed as 'imported' (so that enum essentially
becomes 'other')

2) What does conformance to a YANG  module e.g. ietf-system mean now? Do we
> need to load the module at the top level, or is it enough to mount it
> “somewhere” in the containment tree?
>

It means the same if the server returns "implement"
Mounting the module violates the contract because the
module clearly defines /system as a top-level node.
Any other location is non-compliant.

3) If the answer to 2) is it can be mounted anywhere, which modules must be
> present at the top level? E.g. ietf-yang-library?
>

IMO the YANG contract only supports the data placement explicit
in the module.

> 4) If a new list entry is created can it introduce a completely new module
> never heard of before in the network element?
>

??

this is fine for "anydata"

5) IMHO allowing such dynamic introduction of new YANG modules into a
> network element, with flexible mountpoints, flexible set of modules at each
> mountpoint, a flexible set of deviations and features for each mounted
> module makes discovery actual available schema tree difficult. I think we
> are providing to much flexibility, over-complicating the issue. Some more
> static mounting solution that can be read from YANG modules instead of

mount is way over-engineered  but schema-defined mount-points don't really
help.
A nested "root" works and has a use-case.  Everything else is extra
and an implementation choice without any real use-case.  YANG is already
complicated and slow. mount and sym-links makes it worse.

regards Balazs

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: wangzitao <[email-masked]>
Date: Fri, 6 May 2016 02:49:23 +0000

Hi all,

I think one important question is how to flexibly use “Schema mount”.
Currently, it support mount the modules which be listed in the ietf-yang-library.
But how to extend the mount? Or how to support other modules (these not include in yang library)?
One example is draft-rtgyangdt-rtgwg-device-model:

       module: network-device
          +--rw ietf-yang-library
          |
          +--rw interfaces
          +--rw hardware
          +--rw qos
          |
          +--rw system-management
          +--rw network-services
          +--rw oam-protocols

Do we need to model an “oam protocols library” first,

and then augment the Schema Mount YANG Module to get a “mount-oam-library” to support mounting the oam protocols library?

Best Regards!

-Michael

发件人: netmod [mailto:[email-masked]] 代表 Andy Bierman
发送时间: 2016年5月6日 2:03
收件人: Balazs Lengyel
抄送: [email-masked]
主题: Re: [netmod] Schema mount questions

On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

1) Will mounted YANG modules be listed in the base ietf-yang-library? Even the mounted ones?

I asked for a conformance enum of 'none' or 'other' for this exact purpose but
the WG did not think it was possible for a server to do anything
other than implement or import a YANG module.

2) What does conformance to a YANG  module e.g. ietf-system mean now? Do we need to load the module at the top level, or is it enough to mount it “somewhere” in the containment tree?

3) If the answer to 2) is it can be mounted anywhere, which modules must be present at the top level? E.g. ietf-yang-library?

4) If a new list entry is created can it introduce a completely new module never heard of before in the network element?

??

5) IMHO allowing such dynamic introduction of new YANG modules into a network element, with flexible mountpoints, flexible set of modules at each mountpoint, a flexible set of deviations and features for each mounted module makes discovery actual available schema tree difficult. I think we are providing to much flexibility, over-complicating the issue. Some more static mounting solution that can be read from YANG modules instead of run-time data would be easier.

mount is way over-engineered  but schema-defined mount-points don't really help.
A nested "root" works and has a use-case.  Everything else is extra
and an implementation choice without any real use-case.  YANG is already
complicated and slow. mount and sym-links makes it worse.

regards Balazs

Andy

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 May 2016 09:45:05 +0200

Hi Balazs,

> 1) Will mounted YANG modules be listed in the base ietf-yang-library?

Currently, they aren't. However, I sent it as an open issue to the
mailing list (no response so far):

https://www.ietf.org/mail-archive/web/netmod/current/msg15737.html

I do see a value in being able to determine the overall schema outside
any management protocol context.

>
> 2) What does conformance to a YANG module e.g. ietf-system mean now?
> Do we need to load the module at the top level, or is it enough to
> mount it “somewhere” in the containment tree?

I think this would depend on whether the client supports schema mount or
not. If it does, then it must iteratively construct the data model, and
the conformance will then be relatively strict - unless we use anydata
at a mount point.

>
> 3) If the answer to 2) is it can be mounted anywhere, which modules
> must be present at the top level? E.g. ietf-yang-library?

It's not that any module can be mounted anywhere, the server specifies
the schema. Yes, yang-library has to be present, then schema-mount
module, and all modules listed at the top-level YANG library.

>
> 4) If a new list entry is created can it introduce a completely new
> module never heard of before in the network element?

I *think* that if the list is a mount point, then yes - a new instance
of YANG library can be provided for the new entry.

> network element, with flexible mountpoints, flexible set of modules at
> each mountpoint, a flexible set of deviations and features for each
> mounted module makes discovery actual available schema tree difficult.
> I think we are providing to much flexibility, over-complicating the
> issue. Some more static mounting solution that can be read from YANG
> modules instead of run-time data would be easier.

I fully agree, that's why YSDL was much more conservative in this
respect: all modules need to appear in the top-level YANG library, and
there is just an extra specification of the hierarchical organisation of
subschemas.

Lada

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

---

From: Robert Varga <[email-masked]>
Date: Mon, 9 May 2016 10:59:56 +0200

On 05/05/2016 04:44 PM, Balazs Lengyel wrote:
> mounted module makes discovery actual available schema tree difficult. I
> think we are providing to much flexibility, over-complicating the issue.
> Some more static mounting solution that can be read from YANG modules
> instead of run-time data would be easier.

Unfortunately, there is at least one use case, where the organization of
'the world' is a run-time rather than modeling-time property, hence the
discovery process needs to be driven by data available in run-time.

That use case is important for things like OpenDaylight, but may not be
important when talking directly to "simple" network elements, e.g. those
which can be statically modeled.

Bye,
Robert

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 9 May 2016 11:30:14 +0200

> On 09 May 2016, at 10:59, Robert Varga <[email-masked]> wrote:
> 

Either way, schema mount isn't really about modeling-time but rather about session-time. I would prefer that the server publish the complete schema upfront, as a part of the "contract" with the client.

> which can be statically modeled.

One option is to have separate mechanisms for the simple and complex cases.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 May 2016 15:27:28 +0200 (CEST)

> Does the server providing the mounted modules claim conformance

No, which is why they are not listed in the base ietf-yang-library.

> property is ignored, due to mounting.

Agree.

> It means the same if the server returns "implement"

Yes.

> module clearly defines /system as a top-level node.

No, mounting doesn't break the contract, since the contract (base
ietf-yang-library) doesn't mention these modules.

> Any other location is non-compliant.

I agree it would be non-compliant to list a mounted module in the base
ietf-yang-library.  This is why mounted modules are not listed.

> IMO the YANG contract only supports the data placement explicit

Agreed.

> mount is way over-engineered

What do mean when you write "mount"?

> but schema-defined mount-points don't really
> help.
> A nested "root" works and has a use-case.

This is all the current schema mount does.

> Everything else is extra

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 May 2016 08:02:34 -0700

On Mon, May 9, 2016 at 6:27 AM, Martin Bjorklund <[email-masked]> wrote:

> Do we

OK -- good.

> must be
> module
> each

This is the only variant I support.

Renaming or relocating data (changing the ancestor path to the first root)
is way too complicated and not relevant to a programmatic interface.
This can be done in the presentation layer of the controller or application.

Andy