Hi,
On 23/12/2015 18:22, Acee Lindem (acee) wrote:
From: Andy Bierman <[email protected] <mailto:[email protected]>>
Date: Wednesday, December 23, 2015 at 11:18 AM
To: Acee Lindem <[email protected] <mailto:[email protected]>>
Cc: Ladislav Lhotka <[email protected] <mailto:[email protected]>>, Kent
Watsen <[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
<[email protected] <mailto:[email protected]>> wrote:
From: Andy Bierman <[email protected]
<mailto:[email protected]>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <[email protected] <mailto:[email protected]>>
Cc: Ladislav Lhotka <[email protected] <mailto:[email protected]>>,
Kent Watsen <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01
On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
<[email protected] <mailto:[email protected]>> wrote:
On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav
Lhotka"
<[email protected]
<mailto:[email protected]> on behalf of
[email protected] <mailto:[email protected]>> wrote:
>
>> On 23 Dec 2015, at 04:06, Kent Watsen
<[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav
Lhotka"
>><[email protected]
<mailto:[email protected]> on behalf of
[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><[email protected]
<mailto:[email protected]>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit
Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the
operational state design and
>>>>>how
>>>>> to structure the models are the two blocking
factors to publish YANG
>>>>> models. If you disagree or don't see this, let
me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that
there is a blocking
>>>> factor that should stop us from publishing
models. There seem to be
>>>> ways to address the requirements without having
to block all work or
>>>> to redo what that we have published. But sure, if
you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how
the proposed split
>>>between intended and applied configuration is
supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models
themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.
I’d like to point out that we also have the
requirement to allow retrieval
of derived-state along with intended-config and
applied-config. This will
require modification to most of the existing YANG
drafts as most now have
separate trees for config and operational state. Note
that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
A NETCONF <get> with a subtree filter can retrieveg both
config and non-config subtrees
at the same time. A new RPC can be added (or existing
<get> RPC extended) to
filter various conditions. I don't see how the YANG data
layout affects the definition
of "rpc" statements in another module.
There is the requirement to be able to do the retrievals but
there is also this requirement:
C. The mappings needs to be programmatically consumable
Now, if the derived-state nodes are located with the
config-nodes, then this is readily satisfied. Another way of
satisfying the requirement may be structural and naming
conventions but this is not as sure as co-location.
There can be meta-data returned (XML attributes) that identify the
additional properties.
This is better co-location since the pattern cannot be
unintentional (as it can with the
config-within-state containers).
This may be an option for published models. However, for models in
development, wouldn’t it be easier to just move the nodes rather than
defining the relationships in meta-data?
Just relying on meta-data to relate config and state would probably add
a lot of relations noise to the models. I would imagine that this would
make the models source YANG files harder to read, and potentially have a
slight negative performance impact in the clients - which may be
important if they have to relate many nodes.
Hence why I think that it is best to use co-location where possible, and
just use explicit meta-data where the nodes are further apart in the
data tree.
This still leaves the question as to what to do with the interfaces vs
interfaces-state. There would seem to be two possible solutions to me:
(1) merge the trees together as per OpenConfig, or (2) add a special
case rule for interfaces. I think that this is an issue that neither
Kent's nor my draft fully addresses.
Thanks,
Rob
Thanks,
Acee
Thanks,
Acee
Andy
Thanks,
Acee
Andy
>
>Lada
>
>>
>> Kent
>>
>>
>>
>>> Lada
>>>
>>>>
>>>>> I hope that nobody really believes that because
some people in IETF
>>>>>(or
>>>>> in any other SDOs) thinks that what those
operators want is a bad
>>>>>idea,
>>>>> those operators will not get what they
request/pay for from their
>>>>>suppliers.
>>>>
>>>> To be fair, those operators also tell us that
they use protocols that
>>>> are not IETF protocols and it remains somewhat
unclear what those
>>>> protocols are we are expected to optimize data
model solutions for.
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder Jacobs University
Bremen gGmbH
>>>> Phone: +49 421 200 3587 Campus Ring 1 |
28759 Bremen | Germany
>>>> Fax: +49 421 200 3103
<http://www.jacobs-university.de/>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>_______________________________________________
>netmod mailing list
>[email protected] <mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
