Hi Andy,
Thanks for the review and comments, please see inline ...
On 03/09/2015 22:50, Andy Bierman wrote:
On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I've posted a new experimental draft, that proposes a potential
different solution for handling applied configuration, for
possible discussion at next week's interim meeting on opstate.
Comments before hand are welcome.
This is better than the "config" and "state" containers at least.
Multiple schema nodes to represent the same object in different states
doubles the complexity of the module.
Agreed.
Considering 97% + of devices
don't need this stuff, that's just not worth 2X the cost.
Not sure that I agree with the the 97% figure, but I don't have any
concrete data to go on ...
However, it is important that the schema be stable.
The way an <rpc-reply> is parsed cannot really depend on an <rpc> that
was sent earlier. But a leaf like <mtu> will either be represented as
a leaf
or as a container in the <rpc-reply>, depending on
the <with-config-state> parameter that was sent in the <rpc>.
Generally, I would prefer it if an <rpc-reply> could be processed
independently of the <rpc> request (e.g. perhaps by embedding the
request data in the response).
However, it seems to me that you already need to know the context of the
request to be able to semantically process the reply.
E.g. I would expect that you would need to know what the request is,
what filters are in effect, when any of the get-default options are in
effect (since that changes the meaning of the data returned for some
config nodes).
So, I appreciate that if can't be a generic parser cannot be used, then
a client would need to perform a lookup of the request context before
parsing the reply. But it doesn't feel like this is a particularly hard
problem.
I appreciate sec. 7. It is good to relate the solution back to
the requirements (even if that list seems to be growing every week).
I have not personally seen the problems in the requirements list.
Some Cisco devices (that I haven't directly worked with) use an eventual
consistency configuration model, and would probably more naturally fit
into a split intended/applied config model proposed by the Open Config
group. Further, I suspect that more of the new developed devices may
adopt this approach in future.
The delay between intended and applied is usually milliseconds,
sometimes seconds.
For many of the smaller config changes that I agree that they might only
take a second or two.
But for large scale config changes (e.g. 1M+ lines of config) then it
can take 1-30 minutes to apply the configuration and ensure that all of
the hardware is programmed. For these systems, I can see that there is
a benefit to be able to see exactly what configuration is in effect at a
given point in time.
I suspect that one of the reasons that the global Internet works so well
is because the routing protocols adopt an eventual consistency model,
e.g. the global routing table being in constant flux. So I can also
certainly see the appeal of adopting an asynchronous eventual
consistency configuration model where 10,000's of devices are being
managed and the network is being constantly dynamically optimized for
the demands being placed on it.
I don't agree that we need to diagnose line cards that are not plugged in.
The operator should figure this out some other way (e.g. entity-mib).
OK, what about a linecard that has crashed, or failed to boot, or
suffered a hardware failure?
Ultimately, the operator (which in this scenario will probably be a
machine) needs to able to correlate a failure back to the operation that
it was trying to achieve in the first place. The related-state
statement in Kent's draft helps here, but for an asynchronous
configuration model there needs to be a way to indicate errors in
applying that configuration that previously could have been returned as
<rpc-error>'s in the <rpc-reply> of the original <edit-config> request.
It is not clear how long this data will indicate 'in progress'.
Most of the time, <cfg-intended> and <cfg-actual> will be the same.
Agreed.
(This basically triples the size of a <get-config> response)
I don't see why any enum other than 'diff-cfg-only' would be used.
OK.
This is how I would also expect the <get-state> operation to work in
Kent's draft.
I may be misunderstanding Kent's draft (I'll send comments on it
separately), but I read the <get-state> operation as only returning
"config false" nodes and hence doesn't help with the intended config vs
applied config problem.
It would really help if you included the YANG module you want to
standardize. There are a couple examples but no formal definition.
OK. I'll try and also write that up. My excuse is that I spent quite a
lot of August on PTO and hence have only had a couple of days to write
this idea up.
Thanks again for the comments,
Rob
Thanks,
Rob
Andy
-------- Forwarded Message --------
Subject: New Version Notification for
draft-wilton-netmod-opstate-yang-00.txt
Date: Thu, 3 Sep 2015 13:31:00 -0700
From: [email protected] <mailto:[email protected]>
To: Robert Wilton <[email protected]> <mailto:[email protected]>,
Robert Wilton <[email protected]> <mailto:[email protected]>
A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.
Name: draft-wilton-netmod-opstate-yang
Revision: 00
Title: "With-config-state" Capability for NETCONF/RESTCONF
Document date: 2015-09-03
Group: Individual Submission
Pages: 22
URL:https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00
Abstract:
This document proposes a possible alternative solution for handling
applied configuration state in YANG as described in draft-openconfig-
netmod-opstate-01. The proposed solution, roughly modelled on the
with-defaults NETCONF/RESTCONF capability, aims to meet the key
requirements set out in draft-openconfig-netmod-opstate-01 without
the need for YANG module authors to explicitly duplicate
configuration nodes in both configuration and operational containers.
This draft does not address the issue of co-location of configuration
and operational state for interfaces, nor does it provide a NETCONF
mechanism to retrieve operational data separately from configuration
data.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available attools.ietf.org
<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
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
