Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20

["Susan Hares" <[e-mail]>]

Joel: 

The I2RS models for BGP utilize the BGP yang module definitions, but these
models are not the same.  I would agree with you that the I2RS models are
unique. 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Joel M. Halpern
Sent: Sunday, October 11, 2015 4:29 PM
To: Andy Bierman; Susan Hares; [e-mail]; [e-mail]
Subject: Re: [i2rs] inteirm 10/7/20

While there will be new information that needs new models, some of the
things to be manipulated in an ephemeral fashion by I2RS are already in
existing models.

I have heard proposals to use some version of overlapping or related models,
and I do not know what can be made to work.

Yours,
Joel

On 10/11/15 4:24 PM, Juergen Schoenwaelder wrote:
> Joel,
>
> do you expect that special models will be written for I2RS or do you 
> expect that generic routing configuration models will do the job?
>
> /js
>
> On Sun, Oct 11, 2015 at 04:11:11PM -0400, Joel M. Halpern wrote:
>> I would phrase the marking need slightly differently.
>> Given that it would seem onerous to expect all I2RS-supporting 
>> devices to support ephemeral behavior for all parts of all models, we 
>> need some way to clearly indicate what is expected.
>>
>> Trying to do it as separate models seems difficult.
>>
>> Marking elements in the model as ephemeral seems the clearest and 
>> most efficient mechanism, but I am sure there are other alternatives.
>>
>> Yours,
>> Joel
>>
>> On 10/11/15 3:58 PM, Juergen Schoenwaelder wrote:
>>> On Sun, Oct 11, 2015 at 11:10:16AM -0700, Andy Bierman wrote:
>>>> On Sun, Oct 11, 2015 at 10:51 AM, Juergen Schoenwaelder < 
>>>> [e-mail]> wrote:
>>>>
>>>>> On Sun, Oct 11, 2015 at 09:55:31AM -0700, Andy Bierman wrote:
>>>>>> On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder < 
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote:
>>>>>>>> The 10/7/2015 interim discussed the ephemeral portion of the 
>>>>>>>> protocol
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 1)      Ephemeral state is not unique to zI2RS
>>>>>>>>
>>>>>>>> 2)      The ephemeral datastore is a datastore holds
>>>>>>>>
>>>>>>>> configuration that is intended to not survive a reboot.
>>>>>>>>
>>>>>>>
>>>>>>> Configuration as YANG config true or a subset thereof?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> config=true nodes only.
>>>>>
>>>>> good
>>>>>
>>>>>> Some way is needed to specify I2RS conformance for a given YANG 
>>>>>> module, unless every persistent config leaf is expected to also 
>>>>>> be supported as ephemeral data.
>>>>>>
>>>>>> If not, a YANG "ephemeral-stmt" is probably needed, since 
>>>>>> config=true is insufficient to support I2RS conformance.
>>>>>
>>>>> One question is whether this needs to be inline in the data model 
>>>>> or not. If conformance is the goal, then you know what having 
>>>>> things defined inline has limits. If we would address conformance 
>>>>> in more general terms, perhaps I2RS conformance falls out as a special
case.
>>>>>
>>>>>> One ephemeral datastore.
>>>>>> No client panes.  That was to support caching, but the 
>>>>>> architecture forbids caching, so that was taken out.
>>>>>>
>>>>>> One ephemeral pane that overrides the running datastore
>>>>>
>>>>> good
>>>>>
>>>>>>> Identities? I assume you mean schema nodes, do you?  Adding by 
>>>>>>> defining an YANG extension such as i2rs:ephemeral true? How does 
>>>>>>> such an i2rs:ephemeral true interplay with config true/false? 
>>>>>>> What about contexts for must/when expressions? Or is the idea to 
>>>>>>> settle on RESTCONF and to work with YANG patch?
>>>>>>>
>>>>>>
>>>>>> I think a real keyword is needed not an extension.
>>>>>> Otherwise YANG groupings cannot be utilized w/ statements that 
>>>>>> are refined in the uses-stmt to set the ephemeral flag.
>>>>>
>>>>> I fail to understand the groupings argument.
>>>>>
>>>>
>>>>
>>>> The refine-stmt is defined to work on YANG statements, not external 
>>>> statements.
>>>
>>> RFC 6020bis says in section 7.13.2.:
>>>
>>>     o  Any node can get refined extensions, if the extension allows
>>>        refinement.  See Section 7.19 for details.
>>>
>>>> A YANG extension is (by definition) something external to the YANG 
>>>> language.
>>>> The WG needs to decide if the ephemeral property should be specific 
>>>> to an I2RS YANG module or should be basic property of the YANG data 
>>>> modeling language.  YANG keywords must be supported and they do not 
>>>> need to be imported from a YANG module to be used.
>>>
>>> Or it is a common extension (that is the extension is not I2RS 
>>> specific but instead for everything that wants to use ephemeral 
>>> datastores).
>>>
>>> Anyway, if the main purpose is to define a conformance level, it may 
>>> be worth thinking about adding a conformance mechanism that 
>>> decouples conformance requirements from the data model definition.
>>>
>>> /js
>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs