On 08/01/2016 15:42, Ladislav Lhotka wrote:
On 08 Jan 2016, at 16:20, Robert Wilton <rwil...@cisco.com> wrote:
Hi Lada,
On 08/01/2016 12:30, Ladislav Lhotka wrote:
Robert Wilton <rwil...@cisco.com> writes:
Hi Lada,
I think that requirement 1D is fairly key to what is being asked for
here to allow both the user and system to easily relate between what the
operator desires and what configuration the system is actually using,
In a way, system-controlled interfaces are default entries in the
interface list - and the system can certainly be using interfaces with
no configuration installed by NETCONF/RESTCONF clients.
so I wouldn't be particularly keen on loosening this requirement.
OK, but then IMO this intended-applied dualism is of limited
utility. For many systems or services, asynchronicity is not an option,
or isn't important.
I don't really agree. I think that this is plausibly important to anyone who
wants to manage network devices in an automated way.
I am currently working with my colleagues on two use cases:
1. RESTCONF interface to a DNS server that will cover the daemon configuration,
policies for zone signing, and zone provisioning.
2. RESTCONF interface to an OpenWRT-based router.
For neither of them applied configuration seems to add any value.
OK.
Today, when a config request has been processed by NETCONF/YANG then it seems
that the only thing the server actually promises is that it might apply the
configuration at some point in the future. It makes no guarantees as to
whether that configuration has or ever
The server may simply send a reply only after the configuration has been
completely applied.
Yes, the server may do this. But the client cannot rely on that
behaviour for a NETCONF server today.
When I first got involved in the opstate discussions, I mistakenly
thought that when a NETCONF server replies to a request it mean that the
configuration was applied (for some definition of applied). From my
reading of draft-openconfig-netmod-opstate-01 section 4.2, I suspect
that the authors were also under that impression. However, several
folks on the WG alias have made it clear that this behaviour is not
specified by the NETCONF draft.
But the nice thing is, if the server complies with the opstate
requirements draft, then when the client receives a successful reply to
the synchronous configuration request it knows that configuration has
actually been applied successfully. It seems to me that these are the
semantics that your client code probably desires.
Alternatively, perhaps the client code doesn't directly care whether or
not the configuration has been successfully applied because it will
infer it from the operational state. In this case it can make async
requests, with the knowledge that any server should reply to the config
request reasonably expediently.
From a client perspective, either of these two requests seem to be
better than the status quo, where it can infer very little from the
result of a request. Two different server implementations may have very
different behaviour and hence a robust client has to be coded to assume
the least desirable behaviour.
I understand that with complex devices it is not possible or practical to
wait, but in my use cases it is probably just the right thing to do.
For me, it is about what a client can reasonably assume about the
servers behaviour, and I think that the tighter behaviour specified in
the opstate requirements means that servers should behave how clients
expect them to.
will be successfully applied! The expectation is that the operator can infer
from the operational state of the system whether the configuration has been
applied (which may not always be possible).
Personally, if I was an operator coding to NETCONF/YANG then I would prefer a
device that supported the opstate semantics because compliant devices will tell
you what configuration that are actually running. This makes it easier to
control/manage. I.e. I can easily find out if/when my configuration is
applied, and I can easily retrieve any associated operational state. In some
cases this may mean that I don't need to check the derived state at all, in
other cases it may simplify the checking of the derived state that I need to
perform.
Again, regarding sync/async, I would also most likely choose async because I
perceive that it is simpler to code in a robust fashion.
For the ACL example:
Would it be feasible to change the ACL module to use a leafref to the
interface name, with the added constraint that you have to at least
configure the existence of an interface before you can have any
configuration referring to it?
Well, yes, that's how it is supposed to be done now - also, for example,
for stacking interfaces as in Appendix B of RFC 7223.
It is not only extra work: the interface list can be locked, so it may
not be possible to immediately create a dummy interface entry and,
consequently, an ACL rule with that interface cannot be configured. In
this sense, using a string rather than a leafref looks like a reasonable
choice.
Locking is presumably specifically related to the config protocol being used.
As such I don't think that it should be used as a reason to compromise the
structure of data model.
But having looked at the ACL model a bit more closely, and noticing how
input_interface is used, then I agree with Martin, I think that it makes sense
for the reference to be an interface-state-ref.
As Martin pointed out, with YANG 1.1 it would be possible to refer to an
interface entry in state data from configuration. On the other hand,
with "require-instance false" validation won't detect errors in ACL
configuration such as referring to a non-existent interface.
True, but for this particular scenario, it wouldn't be any different from
matching on the wrong IP address (which also can't be validated by the device
in question).
Sure, but my point is that a leafref with require-instance=false isn't that
much different from a plain string.
Yes, it may not tell you much extra over a plain string, but it still
gives a clearer indication as to what the field is.
Thanks,
Rob
Lada
Presumably the ACL is still valid even if the input-interface for one ACE
doesn't exist. Wouldn't it just mean that one particular ACE entry wouldn't
match any packets?
Thanks,
Rob
Lada
Thanks,
Rob
On 07/01/2016 10:20, Ladislav Lhotka wrote:
Hi,
a good use of applied configuration could be to formalize the concept of
system-controlled entries as defined in RFC 7223, routing-cfg, and probably
elsewhere, too.
My idea is that system-controlled interfaces or other entries would appear in
applied configuration, but not in intended configuration until something needs
to be really configured. We could then permit leafrefs from intended
configuration to refer to leafs in applied configuration. One case where this
would be useful is the ACL module, where match conditions refering to
interfaces currently have to use plain strings as references to interface names.
However, the above idea seems to be at odds with requirement 1D in
opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that
the above use case can be supported?
Thanks, Lada
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
