Hi Lada,
On 21/12/2015 16:05, Ladislav Lhotka wrote:
On 21 Dec 2015, at 16:05, Robert Wilton <[email protected]> wrote:
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?
Right, and this is quite typical for systems where users have access to a
standard Unix shell and/or can install software on their own.
If so I think that your scenario is outside what could be reasonably expected
to be defined by a standards specification.
Why? Such systems could also benefit from NETCONF/RESTCONF and standard data
models.
Sure. But I don't see how you can standardize against a configuration
system that probably isn't strongly specified itself.
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.
It can be managed by the same YANG models as other devices, one can just never
think that what's in the configuration is also what the system uses. The only
(reasonably) reliable source for the latter is the /proc filesystem, which
actually comes close to the definition of applied configuration - only its data
model is generally very different.
Personally, I would think that a device knowing what configuration it is
actually running should be the desired and default expectation, and not
being able to provide this is a deficiency.
Somehow the operator needs to be able to figure out whether a device is
doing what it is supposed to be doing. I don't think that it is really
reasonable to just force this problem on to the operators and tell them
that they need to figure it out themselves. This would mean that each
and every operator that needs to interact with that device either has to
accept that either they don't know what it is actually doing, or they
have to independently implement a similar solution to figure it out.
Pragmatically, I suspect that you can't do that, in which case I would model
the opstate requirements as only applying to the YANG
Yes, it is not realistic.
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.
Sure, but then applied configuration is of no use.
That's not entirely true.
The operator still knows that the system is actually acting on the
configuration that the user intended, it just doesn't mean that it has
necessarily been programmed into the forwarding plane. That is subject
to the other independent configuration allowing the ACL YANG
configuration is in effect.
E.g. in the following ASCII Art diagram, then if A was the YANG config,
then they would know that has been successfully applied, even though
they don't know about your other configuration 'B', or what ends up in
the forwarding plane (derived state) :
A ==\
===> Forwarding plane
B ==/
Without the applied configuration state, the operator knows less
information. I.e. if the forwarding plane hasn't been programmed
correctly then that might be either because the ACL YANG configuration
(A) hasn't been applied or because the independent configuration (B)
interferes with it.
Thanks,
Rob
Lada
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/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
