Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Joel Halpern Direct <[e-mail]>]

My question was not about whether I2RS operations and configuration can 
produce operational state.

Rther, the quesiton is whether this operational state is in any way 
different from all other operational state?
Operational state, by its nature, is never persisted in config.
Operational state, by its nature, comes and goes depending upon other 
aspects (you frequently can not get statistics on an interface that is 
not enabled.)

So I don't see anything special on the operational side that I2RS requires.

Yours,
Joel

On 6/1/16 7:09 AM, Susan Hares wrote:
> Joel:
>
> I am surprised you asked this question as you have followed the I2RS data
> modules.  Is this question rhetorical?
> Ephemeral operational state have three types:
>
> 1) results of rpc operations stored to respond to rpc actions
>
> I2RS-RIB-Data
> Rpcs:
>       +---x rib-add
>       |  +---w input
>       |  |  +---w rib-name        string
>       |  |  +---w rib-family      rib-family-def
>       |  |  +---w ip-rpf-check?   boolean
>       |  +--ro output
>       |     +--ro result uint32
>       |     +--ro reason? string
>
> 2) notification data stored
>
>
> I2RS-RIB-Data
>    notifications:
>       +---n nexthop-resolution-status-change
>       |  +--ro nexthop
> .....
>       +---n route-change
>          +--ro rib-name                 string
>          +--ro rib-family               rib-family-def
>          +--ro route-index              uint64
>
> 3) read-only status information
>
> See my presentation where the bgp-global-config - can be used by config or
> state.  It is ephemeral state augmenting these features.   Or see the L2
> topology module below.
>
> augment /nw:networks/nw:network/nw:node/nt:termination-point:
>    +--rw l2-termination-point-attributes
>       +--rw description?          string
>       +--rw maximum-frame-size?   uint32
>       +--rw (l2-termination-point-type)?
>       |  +--:(ethernet)
>       |  |  +--rw mac-address?          yang:mac-address
>       |  |  +--rw eth-encapsulation?    identityref
>       |  |  +--rw port-vlan-id?         vlan {VLAN}?
>       |  |  +--rw vlan-id-name* [vlan-id] {VLAN}?
>       |  |     +--rw vlan-id      vlan
>       |  |     +--rw vlan-name?   string
>       |  +--:(legacy)
>       |     +--rw encapsulation?        identityref
>       +--ro tp-state?             Enumeration
>
>
> Sue Hares
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2016 4:10 PM
> To: Susan Hares
> Cc: [e-mail]
> Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
> - Topic: Ephemeral State Requirements
>
> Can you clarify something for me?
> What is ephemeral operational state?
>
> The only thing I can think of is operational state like statistics related
> to ephemeral leaves or constructs?
> Is that what you mean by "ephemeral operational state"?
> The reason i ask is that such state does not seem to need any special
> handling or labeling.
>
> Yours,
> Joel
>
> On 5/31/16 3:29 PM, Susan Hares wrote:
>> Juergen:
>>
>>
>>> I understand YANG validation rules and I understand YANG's notion of
>> configuration datastores. I do not >think this matches your ephemeral
>> configuration validation.
>>
>> This does not provide a technical discussion of:
>> a) what you understand the ephemeral configuration validation rules to
>> be,
>> b) why you do not the model matches the configuration validation rules.
>>
>> 1 Data Model is a great idea for NETCONF/NETMOD.  However, it should
>> encompass
>>
>> Ephemeral data:== ephemeral state ::== Ephemeral configuration +
>> Ephemeral operational state
>>
>> Cheers,
>>
>> Sue
>