> On 21 Dec 2015, at 16:05, Robert Wilton <rwil...@cisco.com> wrote: > > Hi Lada, > > On 21/12/2015 13:55, Ladislav Lhotka wrote: >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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 <kwat...@juniper.net> >>>>> 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. > > 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. > > 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. 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
