On Fri, Oct 2, 2015 at 12:37 PM, Sterne, Jason (Jason) < [email protected]> wrote:
> Good point that the wording does imply separate objects in the YANG data > model. We should try to adjust the wording so that it could apply to other > solutions (e.g. attributes, different datastore, etc). Perhaps the > following ? > > > > 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 applied equivalent of > the node (whether that be a corresponding node in the data model, an > attribute associated with the intended config node, the configuration node > read from a different datastore or context, etc) must match the intended > configuration node. > > > > Templates: Perhaps templates (not instances of the template, but the > template itself) are always considered as “applied” as soon as they are > configured ? > > > > Auto-duplex: The configured duplex setting and the negotiated resulting > operational value are two separate and independent leaves IMO. The > configured duplex setting will have both an intended view and an applied > view (which are separate an independent from the negotiated duplex). E.g. > AdminDuplex (intended & applied) and OperDuplex (pure ‘derived’ state). > > > > I’m not familiar with the use-dhcp example. But maybe as soon as the > system is actually “using DHCP” down on the linecards then the applied > value would reflect that ? > > > This is really a derivative of the template case. The data models are different for config=true and config=false. The config=true knob does not match the operational state at all. E.g., set a boolean leaf to select DHCP instead of the config=true IP addresses. Then use a different data model to read the DHCP Lease info and get the assigned IP address. This is similar to the admin-state/oper-state use-case. Only the description-stmt in the admin-state object says "go look at oper-state for the real value". Andy Re all data models conforming to 1D: If the solution ends up being in the > protocols (instead of the models) then there are no requirements for > models. If the solution ends up being in the models then I don’t think we > can mandate that **all** models follow these requirements. > Controllers/clients will have to be able to manage systems that have a mix > of “opstate compliant” modules and non compliant modules. Operators who > are keen on these requirements will encourage them to be adopted by as many > IETF modules as possible. > > > > Implementation feasibility & impacts is something that we’ll need to > consider but for now I’m trying to ignore that and purely clarify what is > being requested. > > > > Jason > > > > *From:* Andy Bierman [mailto:[email protected]] > *Sent:* Friday, October 02, 2015 14:11 > *To:* Sterne, Jason (Jason) > *Cc:* Robert Wilton; Randy Presuhn; [email protected] > *Subject:* Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > > > Hi, > > > > What about the data models that do not follow 1D? > > > > - templates: the intended data model and applied data model are disjoint > > - 'auto-duplex' corner-case: the intended and applied leaf are the same, > but they > > will never have the same value > > - 'use-dhcp' corner-case: intended config just enables specific derived > state > > to be used; disjoint data models > > > > 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) > > > > 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. > > > > Only the 2 protocol-based solutions address this issue by using > > the same object identifier no matter which state is being queried. > > > > > > > > Andy > > > > On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) < > [email protected]> 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:[email protected]] On Behalf Of Robert Wilton > Sent: Friday, October 02, 2015 5:24 > To: Randy Presuhn; [email protected] > 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 <[email protected]> > >> Sent: Oct 1, 2015 10:01 AM > >> To: "[email protected]" <[email protected]> > >> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
