> 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. > > 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. 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. > 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. 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
