Hi Andy,
On 23/12/2015 21:35, Andy Bierman wrote:
On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton
<[email protected] <mailto:[email protected]>> wrote:
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.
The meta-data is not defined in the YANG models. It is defined for the
protocol.
Co-location doesn't really scale. A system may have candidate,
running, startup,
and even proprietary "state-related" data collections. It would take 3
or 4 copies of the data to
model these datastores inside the data models.
I think that we may be talking across purposes. My comments are
regarding the relationship between operational nodes (aka derived state)
and configuration, as per Acee's comments regarding my draft above.
But IMO any solution that burdens the server with retrieval
requests while the device is busy applying config will only
make the problem worse.
I think that with the OpenConfig model based approach, the assumption is
that they would register to be notified of changes to the datastore
nodes. If it is possible to register for such notifications with an
appropriate level of filtering/granularity then I imaging that a
management client wouldn't necessarily need to ever poll/read the data
(except on corned case scenarios). Instead, it can just rely on push
notifications of the nodes that have changed. I would think that such a
system would be performant.
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.
I looked at your draft.
Thanks.
Is it implemented anywhere?
No. Realistically, I would expect that it would need to gain more
support before anyone would spend time implementing it.
It requires a custom parser that sometimes parses the leaf "foo" as a
YANG leaf
but if the special request is made, then the reply will be returning
"foo" as a container of leafs,
instead of a leaf like normal.
Yes, agreed.
I'm not sure whether you have had the opportunity to look at the version
2 of the draft that I published at the beginning of the week. The main
body of the draft hasn't really changed, but I have added an appendix
with a possible overview of how it might be implemented using attributes
(as you previously suggested). If you have time to review the appendix,
then I would be interested to know whether this is what you had broadly
envisaged.
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.
This is different -- interfaces-state can contain discovered
interfaces that
have not been configured yet.
Yes, of course, but has the downside that it forces a separation between
the configuration and operational state for interfaces.
Personally, ignoring all the backwards compatibility issues, I would
prefer that interfaces and interfaces-state were a combined single list
(as proposed by OpenConfig). E.g. something along the lines of:
- the system can still provide an operational list of discovered
interfaces so that clients can know what is there.
- but management agents would be expected to explicitly configure
(i.e. create an entry for) all interfaces for which it wanted to
retrieve data for.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
