> On 24 May 2016, at 15:20, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>>
>>> On 24 May 2016, at 14:52, Martin Bjorklund <[email protected]> wrote:
>>>
>>> Ladislav Lhotka <[email protected]> wrote:
>>>> Martin Bjorklund <[email protected]> writes:
>>>>
>>>>> Ladislav Lhotka <[email protected]> wrote:
>>>>>>
>>>>>>> On 23 May 2016, at 14:30, Lou Berger <[email protected]> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
