Hi,
You are not describing the procedure very precisely, even for Junos,
let alone a standard. You are vaguely describing different
datastores, except the I2RS datastore does not support multiple
layers. If client A data gets deleted because of higher priority
client B, then that client A data does not come back automatically
if client B data is deleted. (So there cannot be multiple ephemeral
instances in the I2RS standard).
If the 1 'admin-temp' config=true leaf is
used for both configuration and ephemeral,
and the only difference is what operation is used to edit the data,
then the server has to keep track of each. The retrieval operations
have to keep each type of data separate. Whether that
is a tag or a datastore, the implementation is basically the same.
The difference is that YANG has specific validation rules about
what is in the running datastore. This cannot change in NETCONF.
Unless YANG validation is ignored by I2RS, new text will be needed
to say how this is handled. Is there any concept of datastore validation
in I2RS?
Any YANG validation procedures specified at all?
Unless I2RS can explain why the NETCONF architecture and its
use of datastores is inappropriate, I see no reason to change it.
Andy
On Tue, Jun 23, 2015 at 3:17 PM, Dean Bogdanovic <de...@juniper.net> wrote:
>
> On Jun 23, 2015, at 5:57 PM, Andy Bierman <a...@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 23, 2015 at 2:15 PM, Dean Bogdanovic <de...@juniper.net>
> wrote:
>
>>
>> On Jun 23, 2015, at 1:50 PM, Andy Bierman <a...@yumaworks.com> wrote:
>>
>>
>>
>>
>>>
>>> Yup, and reality can change when you swap FRUs.
>>>
>>> >> actual state + counters => operational state
>>> >This should be:
>>> > actual state + statistics => operational state
>>> >Statistics is largely dominated by counters but not only counters.
>>>
>>> Sound good.
>>>
>>> Precise language is so important, so I think well-defined terms
>>> matter. Then again, one can be completely precise while being
>>> completely useless, like my current favorite word, sphygmomanometer.
>>>
>>>
>> IMO getting the concepts right needs to be done first.
>> Picking the right terms helps if the concepts are right in the first
>> place.
>>
>> The thermometer example I have given many times needs to be understood.
>>
>> Let's say the same leaf "temperature" is used in all datastores.
>> The "running" temperature is the configured desired value.
>> The "operational" temperature is the current value read from a sensor.
>>
>> So where does "ephemeral" temperature fit in? Does this setting
>> override
>> the desired temperature and have no affect on the operational sensor
>> value?
>> Or does it over-write the sensor value to the device is now lying
>> when it reports the operational temperature?
>>
>>
>> Andy,
>>
>> ephemeral "temperature" would overwrite which ever data store was read
>> to set "running" temperature. If the "temperature" was read from "startup"
>> config, then ephemeral would mask the "temperature" leaf in the startup and
>> running would read from ephemeral data store.
>> One of the issues I personally ran into while at Juniper was people
>> perception that configuration is persistent. Ephemeral config was very
>> confusing to Juniper customers, as I was trying to explain them, that if
>> they change the ephemeral and device reboots, the configuration is gone.
>> For many of them, it was running config, but it is not. Another issue was
>> no rollback. Actually, there is only rollback 0, which is done
>> automatically by the system, if the config commit is not successful.
>>
>>
>>
>> IMO it is quite obvious that ephemeral data is configuration, not state.
>>
>>
>> I would not say that ephemeral data is config. It is temporary state
>> developers want to change the device state too.
>>
>>
>
> Here is a simple example.
> I hope it is not too abstract.
>
> No, it is not
>
> leaf admin-temp {
> type uint32;
> units "degrees Celsius";
> description "The configured temperature.";
> }
>
>
> From YANG perspective, it would be exactly the same, in persistent
> config and ephemeral data store
>
> the only difference is in NETCONF RPC
>
> for persistent config
> <edit-configuration>
>
> and for ephemeral
> <edit-ephemeral-instance>
>
> As there can be multiple ephemeral instances.
>
>
> leaf oper-temp {
> type uint32;
> units "degrees Celsius";
> config false;
> description "The measured temperature.";
> }
>
>
> Would your I2RS solution be able to over-ride the admin-temp
> with a temporary ephemeral value?
>
>
> When commit is executed in ephemeral instance, merge between persistent
> and ephemeral is being executed, with priority for values coming from
> ephemeral data store.
>
> Makes sense?
>
>
> Describe the solution
> in detail. Provide all YANG and all protocol operations that would be
> used
>
>
>
>
>> Thx
>>
>> Dean
>>
>>
> Andy
>
>
>
>> Operational state is always read-only.
>>
>>
>>
>> Thanks,
>>> Phil
>>>
>>
>>
>> Andy
>>
>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
