Re: [netmod] compact versus iterative representation of the overall schema

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 
> > On 24 May 2016, at 14:52, Martin Bjorklund <[e-mail]> wrote:
> > 
> > Ladislav Lhotka <[e-mail]> wrote:
> >> Martin Bjorklund <[e-mail]> writes:
> >> 
> >>> Ladislav Lhotka <[e-mail]> wrote:
> >>>> 
> >>>>> On 23 May 2016, at 14:30, Lou Berger <[e-mail]> wrote:
> >>>>> 
> >>>>> Hi Lada,
> >>>>>   I looks like no one really jumped on this one -- so better late than
> >>>>> never ...
> >>>>> 
> >>>>> When looking at the question below, we should consider the uses cases.
> >>>>> I'm particularity interested (as a contributor) in the use case of
> >>>>> nested mounts (NIs mounted within LNEs), as well as the case if models
> >>>>> that will only permit mounting of specific other models vs generically
> >>>>> mounting any model.
> >>>>> 
> >>>>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> with a schema mount mechanism in place, there are two different
> >>>>>> options
> >>>>>> for constructing the overall schema (their combinations are possible,
> >>>>>> too):
> >>>>>> 
> >>>>>> 1. Define schema mount as an extension of YANG library so that it
> >>>>>> defines YANG modules, revisions, features and deviations as before but
> >>>>>> also the way how they are combined into a hierarchical structure of
> >>>>>> schemas.
> >>>>> 
> >>>>> I think this only makes sense if this is scoped in some way.  For
> >>>>> example, with LNEs, the parent/host server may not have visibility
> >>>>> into
> >>>>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even
> >>>>> if
> >>>> 
> >>>> As I understand it, schema-mount is about accessing the LNE models
> >>>> from the parent/host management interface. I believe the real question
> >>>> is whether we want to allow the schema to dynamically change at run
> >>>> time and possibly throw in new modules that the client never heard
> >>>> of. #2 can do it while #1 can't. I am not sure though whether the LNE
> >>>> model really requires something like this.
> >>>> 
> >>>>> does, you have to consider the cases of mounted models contained
> >>>>> within
> >>>>> mounted models.
> >>>> 
> >>>> This is possible either way, provided that the complete schema is
> >>>> known upfront.
> >>> 
> >>> I don't think I have seen a concrete proposal for such a compact
> >> 
> >> YSDL was such a proposal.
> >> 
> >>> format that can handle the case where different instances of a list
> >>> with a mount point have different modules mounted, and some of them
> >>> have mounted models within the mounted models.
> >>> 
> >>> As a concrete example, suppose we have the model
> >>> example-network-manager from Appendix B in
> >>> draft-ietf-netmod-schema-mount-01:
> >>> 
> >>>   +--rw managed-devices
> >>>      +--rw device* [name]
> >>>         +--rw name         string
> >>>         +--rw transport
> >>>         +--rw root      yangmnt:mount-point managed-device
> >>> 
> >>> Now, let's assume that two devices exist, A and B:
> >>> 
> >>>  A  implements:  ietf-interfaces, example-netowrk-manager
> >>>  B  implements:  ietf-system
> >>> 
> >>> In A, there is a managed-device C which implements ietf-interfaces and
> >>> ietf-ip.
> >>> 
> >>> What would this look like in the compact form?
> >> 
> >> The module "example-network-manager" would be modified as follows:
> >> 
> >>   +--rw managed-devices
> >>      +--rw device* [name]
> >>         +--rw name         string
> >>         +--rw transport
> >>         +--rw (root)
> >>            +--:(A)
> >>            +--:(B)
> >>            +--:(C)
> > 
> > But A, B and C are device names (instances).
> 
> So what? A, B and C can be the values of the "name" key, too.
> 
> > 
> > Also, C would be:
> > 
> >  /managed-devices/device[name="A"]/root/managed-devices/device[name="C"]
> 
> Yes.
> 
> > 
> > 
> >> And then:
> >> 
> >>   {
> >>     "ietf-ysdl:schemas": {
> >>       "top-schema": "host",
> >>       "schema": [
> >>         {
> >>           "name": "host",
> >>           "yang-modules": [ "example-logical-devices" ],
> >>           "subschema": [
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/A",
> > 
> > Can the root contain instance information?
> 
> No, it is a schema-node-path, that's why it can contain "choice" and
> "case" nodes. It should be possible to construct the complete schema
> without looking into any instances.

So this approach doesn't work when the instances have different
mounted models?

It is not realistic to change the data model as you did above, since
we'd have to invent a separate container per combination of modules
that possibly could be mounted!


/martin


> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> >>               "schemas": [ "schema-A" ]
> >>             }
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/B",
> >>               "schemas": [ "schema-B" ]
> >>             }
> >>           ]
> >>         },
> >>         {
> >>           "name": "schema-A",
> >>           "yang-modules": [
> >>             "ietf-interfaces",
> >>             "example-network-manager"
> >>           ],
> >>           "subschema": [
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/C",
> >>               "schemas": [ "schema-C" ]
> >>             }
> >>           ]
> >>         },
> >>         {
> >>           "name": "schema-B",
> >>           "yang-modules": [ "ietf-system" ]
> >>         },
> >>         {
> >>           "name": "schema-C",
> >>           "yang-modules": [
> >>             "ietf-interfaces",
> >>             "ietf-ip"
> >>           ]
> >>         }
> >>       ]
> >>     }
> >>   }
> >> 
> >> As long as all modules comprising the schema and their possible
> >> arrangement is known in advance, it should flexible enough. And as I
> >> said, I'd prefer to address this case in schema-mount because the model
> >> of trust between the server and client isn't changed in any way.
> >> 
> >>> 
> >>> BTW, in this case, it is not obvious that the top-level server knows
> >>> anything about the data models mounted by C...
> >> 
> >> But then the top-level server cannot possibly serve data for C.
> >> 
> >> Lada
> >> 
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> 
> >>>>> 
> >>>>>> 
> >>>>>> 2. Apart from YANG Library data, the server just specifies the mount
> >>>>>> points. A client of an NM protocol is expected to fetch a new instance
> >>>>>> of YANG library and/or subordinate mount points as state data from a
> >>>>>> well-known location under each mount point.
> >>>>> 
> >>>>> I think this depends on the use case.  For LNEs, I think this is
> >>>>> right.
> >>>>> For some of the other possible use cases being discussed only a
> >>>>> specific
> >>>>> model can be mounted.
> >>>> 
> >>>> I guess I need some example scenarios demonstrating that #1 cannot be
> >>>> used for LNE.
> >>> 
> >> 
> >> -- 
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
>