On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On 21 Dec 2015, at 17:42, Robert Wilton <rwil...@cisco.com> wrote: > > > > Hi Lada, > > > > On 21/12/2015 16:05, Ladislav Lhotka wrote: > >>> 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. > > 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. > > The concept is applicable to all systems. There will be non-zero elapsed time on any system between the time of the request and the time the config is applied. The amount of time is purely an implementation detail. Many servers accomplish this task in under 1 second for a typical edit. Whether this elapsed time is an operational problem or not really depends on the deployment. Lada > Andy > > > > > 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
