Hi Lada,
On 21/12/2015 13:55, Ladislav Lhotka wrote:
Juergen Schoenwaelder <[email protected]> writes:
On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <[email protected]> wrote:
I’m struggling a bit to understand what is motivating you to ask this question.
That is, as a tool vendor, I wouldn’t think that any decision made here
would affect you immediately. My expectations are that any impact to
YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations
would only opt-in when needed - a pay as you grow strategy. But herein
perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF
needs to be backwards compatible with respect to existing deployments. Did we
miss it or is it too obvious?
It may be obvious for many of us but for the sake of completeness I
prefer to have this backwards compatibility assumption explicitely
stated.
+1
[as a chair]
As last call comment, there seems to be support for adding a requirement to the
opstate-reqs draft to state that solutions supporting said requirements MUST be
backwards compatible with respect to existing deployments. Do we have WG
consensus to add this as a requirement to this draft? Are there any
objections? Please voice your opinion before the last call cutoff date (Dec 30).
[as a contributor]
I’m unsure if it makes sense to call it out in this draft, in that it seems
universally applicable, but I don’t see any harm in it either and thus do not
object.
Kent
[As Co-chair]
Given the tall hill we climbed to get to this point on the
requirements, I
want to be clear that there needs to be very significant support to change the
requirements
in any significant way. We went round and round the drain on settling on these
requirements, and
people had a whole host of reasonable opportunities to add this during those
times. I want to point out that while this statement may seem subtle, slipping
this in at the last minute could have a profound impact on solutions built from
these requirements, so I want to be sure everyone involved has through through
this kind of change.
—Tom
Tom,
I think Andy is talking about applicability - to which kind of servers
do these requirements apply. For example, if it takes more time on a
certain class of devices to retrieve the difference between applied
and intended config than it takes to turn intended config into applied
config, then these requirements may not be applicable (since by the
time you have finished retrieving the difference it has vanished).
I think it is not only matter of synchronisation delays between intended
and applied configuration. I have serious troubles understanding how
these concepts map to the class of devices I am mainly interested in.
Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
server that supports intended and applied config. Assume the server
implements modules of the acl-model family so that firewall rules can be
configured through NETCONF/RESTCONF. Great.
Now an admin runs "iptables" to manipulate netfilter rules in the
kernel. How does it affect the applied and intended configurations?
A. The change isn't reflected in applied configuration. Then applied
configuration is no more "…, the configuration state which is
currently being used by server components (e.g., control plane
daemons, operating system kernels, line cards)."
B. The change is reflected in applied but not in intended
configuration. This violates requirement 1 sub D, and also it may be
impossible to map the kernel changes back to the configuration.
For sure, these problems exist also with the good old "running", but I
think the migration to intended-applied would just make things worse.
If I understand your example correctly, then the complexity in your
scenario is that what is actually written in the hardware is controlled
by two independent management entities. Is that right?
If so I think that your scenario is outside what could be reasonably
expected to be defined by a standards specification.
Ideally, all of the related configuration would be managed by the same
YANG data model, in which case I would expect that your problem would
disappear.
Pragmatically, I suspect that you can't do that, in which case I would
model the opstate requirements as only applying to the YANG part of the
configuration. I.e. the ACL model is in applied configuration applied
if it is regarded as being a valid input to what is being programmed
into the system. What is actually programmed in the forwarding filter
depends on both the accepted ACL YANG configuration and also the other
independent configuration.
Thanks,
Rob
Lada
Andy, did I get this right?
/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]
https://www.ietf.org/mailman/listinfo/netmod
