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

[Ladislav Lhotka <[e-mail]>]

> On 24 May 2016, at 15:20, Martin Bjorklund <[e-mail]> wrote:
> 
> 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 works in the same way as for interfaces in ietf-interfaces, or routing-protocols in ietf-routing, where different entries arguably have different 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!

As a server implementor, I could augment the example-network-manager with as many case nodes as needed. Alternatively, we could introduce some kind of "dynamic choice" similar to "when". Then the "example-network-manager" could be:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw type?        type-enums
         +--rw transport

and the subschema specification would become, e.g.:

"subschema": [
  {
    "root": "/example-network-manager:managed-devices/device",
    "when": "type = 'device-type-A'",
    "schemas": [ "schema-A" ]
  },
  {
    "root": "/example-network-manager:managed-devices/device/",
    "when": "type = 'device-type-B'",
    "schemas": [ "schema-B" ]
  }
]

Lada

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

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