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.
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 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).
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
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
