> On 21 Dec 2015, at 17:42, Robert Wilton <[email protected]> wrote: > > 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. >
Well, only if "strongly specified" means that the ways how the user is allowed to interact with the system are strictly controlled. Open-source system are usually fond of keeping the user empowered. We have to live with it. > >> >>> 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 The operator (using a NETCONF/RESTCONF client) should be able to figure out what the device is doing by inspecting state data. That's why we have the separate *-state trees that often duplicate configuration data. > 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. I think the substantial information is what parameters the system is currently using. If there is no guarantee that applied configuration has this information, then it is IMO much less interesting. I understand that for some systems the intended-applied configuration may be the right thing to do, so it could perhaps be defined as an optional capability. I just don't agree that this concept is universally applicable to all systems. Lada > > 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 >> >> >> >> >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
