This issue appears to have become more like issue #5 – should we mark this one a duplicate of the other?
As for this, what does it mean? > > - templates: the intended data model and applied data model are disjoint > > This came up towards the end of the interim, and my understanding is that it > acceptable for any templating solution to have to adhere to that constraint > above. Specifically, would this imply that the flattening of the template would have to now take place at each operational component in the system – as opposed to being flattened by a centralized component (e.g., in the control plane). If so, then I think it might add significant costs to the servers, as then *all* downstream components would have to know how to flatten templates. Related to this, how do we handle the case where the downstream component's native data model is different. For instance, imagine a mixed IP/optical router that has subtended ROADM and optical amplifiers attached. So, when the control plane sends the config to the ROADM, it first converts it to the ROADM's native data model. For this case, in order to present the applied config with the same data model, would the control plane have to perform the reverse mapping? Kent // as a contributor From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Date: Saturday, October 3, 2015 at 11:38 AM To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: Randy Presuhn <randy_pres...@mindspring.com<mailto:randy_pres...@mindspring.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" Hi, So the applied leaf is being used as a complicated boolean? IMO your draft (using attributes similar to with-defaults=report-all-tagged, not containers) is the best compromise because: - the data models are not touched - no datastores are required - the same string is used to identify the data node no matter what state needs to be checked - client has to request the metadata somehow so no impact on clients that do not care about this issue - a single boolean attribute applied="true" is all that is really needed Andy On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Andy, It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only used to indicate whether the configuration represented by the intended-cfg leaf has been applied. But it appears that my proposed text for 1D may have caused some confusion. Please see inline ... On 02/10/2015 19:11, Andy Bierman wrote: Hi, What about the data models that do not follow 1D? - templates: the intended data model and applied data model are disjoint This came up towards the end of the interim, and my understanding is that it acceptable for any templating solution to have to adhere to that constraint above. - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they will never have the same value The intention is: - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be determined by auto-negotiation) - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by auto-negotiation) - related derived-state duplex-state leaf = "full" or "half" or "unknown" (always represents the actual duplex setting of the interface) - 'use-dhcp' corner-case: intended config just enables specific derived state to be used; disjoint data models Similarly: - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP addresses) - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP addresses) - related derived-state IP address leaf = A.B.C.D (Primary IP address in use for the interface - if any). Somebody asked an important question at the interim: Is the intent of this group to limit all YANG data models such that they conform to 1D? (IMO that is a non-starter) It is not my intention that my proposed 1D text makes are constraint on the structure of YANG data models. IMO requirement 1D presume that the solution involves separate objects in the YANG data model for intended and applied states, and therefore it is an invalid requirement. That is not the intention of my phrasing, perhaps it needs further refinement? The intention is that a config node has two notional states in the data store, intended and applied. The aim is to tightly relate those two notional states as to when they are allowed to be the same or different. Only the 2 protocol-based solutions address this issue by using the same object identifier no matter which state is being queried. I don't think that this requirement excludes any of the three solutions that have been proposed (or the use of attribute to return intended vs applied state metadata). Thanks, Rob Andy On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <<mailto:jason.ste...@alcatel-lucent.com>jason.ste...@alcatel-lucent.com<mailto:jason.ste...@alcatel-lucent.com>> wrote: I agree with "e.g." rather than "i.e.". I'm sure there are lots of other examples of situations where intended config and applied config don't match when we consider the variety of systems out there that may use NETCONF/YANG. We should include some of these examples in the draft (in some informational section and have a reference/pointer to them just after the definition). Note that this updated definition for 1.D does not preclude the applied config object from matching the intended *before* it has been applied. Do we need to clarify that with some "conversely" clause or is that clear enough when considering the other requirements ? We should also cleanly define "applied" (and provide illustrative examples of when something is and is not applied). Should that be a separate email thread ? Jason -----Original Message----- From: netmod [mailto:netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>] On Behalf Of Robert Wilton Sent: Friday, October 02, 2015 5:24 To: Randy Presuhn; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" Hi Randy, On 01/10/2015 23:27, Randy Presuhn wrote: > Hi - > >> From: Robert Wilton >> <<mailto:rwil...@cisco.com>rwil...@cisco.com<mailto:rwil...@cisco.com>> >> Sent: Oct 1, 2015 10:01 AM >> To: "netmod@ietf.org<mailto:netmod@ietf.org>" >> <netmod@ietf.org<mailto:netmod@ietf.org>> >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully >> synchronized" in "Requirement 1.D" >> >> To clarify what I failed to eloquently express in the interim meeting. >> >> I propose changing the text for requirement 1.D. This also removes >> the need to define what fully synchronized means. >> >> >> Old text for 1.D >> D. For asynchronous systems, when fully synchronized, the data >> in the applied configuration is the same as the data in the >> intended configuration. >> >> >> Proposed text for 1.D: >> D. When the configuration change for any intended >> configuration leaf has been successfully applied to the >> system (i.e. not failed, nor deferred due to absent hardware) >> then the existence and value of the corresponding applied >> configuration leaf must match the intended configuration >> leaf. > Are "not failed" and "deferred due to absent hardware" the > *only* possibilities? If not, then the "i.e." needs to be replaced > with an "e.g." I'm not sure if it is the only possibility. Two other possible reason might be: - Configuration that cannot be applied because some dependent configuration hasn't been applied. (E.g. if you have configuration where an interface-ref couldn't be fulfilled because the referenced interface configuration hadn't been applied because either it had failed or been deferred due to absent hardware). But perhaps this would be classified as being one of the two cases above? - There is also the case the configuration is currently in the process of being applied. If it is agreed that github issue #2 (i.e. "Is there a requirement to indicate why intended config != applied cfg?") is a valid requirement, and I think that there might have been some support for this in the interim meeting yesterday, then I would hope that the final solution would enumerate the reasons why the applied configuration may not match the intended configuration. As such, changing from i.e. to e.g. seems like a good choice. So also taking into account Martin's suggestion the updated proposed text for 1.D would be: D. When the configuration change for any intended configuration node has been successfully applied to the system (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. Thanks, Rob > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > . > _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
