Subject: [i2rs] inteirm 10/7/20

From: "Susan Hares" <[email-masked]>
Date: Fri, 9 Oct 2015 16:13:03 -0400

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.

3)      The ephemeral datastore is never locked.

4)      I2RS is using a 2 panes of glass mechanisms

Pane 1: normal configuration 

Pane 2:  ephemeral state 

                The I2RS agent and configuration software on 

              the node  must handle this complexity.

5)      The key word "ephemeral" can be used to identify 

Identities which are ephemeral in data models.

Does anyone have any concerns with adding this to 

Yang? 

6)       Each client has a priority.  

a.       Multiple clients may share a priority, 

b.      AAA or other external mechanisms 

provides the client ID and priority 

c.       An authorized I2RS client must have both

A client Id and a priority, 

d.      System administrators set up the number 

of client IDs and priorities within a system. 

7)      I2RS has defined 3 ways of handling errors  in order

To be efficient in the processing. 

a.       "all-or-nothing", 

b.      "stop-on-error", 

c.       "continue on error"

.         If these three are supported, it is the agent which must support
the complexity to support all three.

.         The WG must consider whether for the initial release we limit the
agent by doing "all or nothing". 

.         One issues with this is grouping changes into a related group. 

.         The failure in one part of a related  group could cause errors in
the related 

.         "continue on error" were only meant for variables which are
orthogonal or independent. 

8)      There is no caching in the I2RS agents. 

.         Andy - noted a concern that without caching some of updates may
have too much latency. 

Please review the whole minutes for all the details. 

Sue Hares

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 11 Oct 2015 18:11:08 +0200

> configuration that is intended to not survive a reboot.

Configuration as YANG config true or a subset thereof?

>               the node  must handle this complexity.

So is there one ephemeral datastore or are there multiple?  Some
slides say one per client, others seem to indicate one for all
clients.

> Does anyone have any concerns with adding this to 

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?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 11 Oct 2015 09:55:31 -0700

> Configuration as YANG config true or a subset thereof?

config=true nodes only.
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.

> slides say one per client, others seem to indicate one for all

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

> 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.

NETCONF has no edit ordering or ability to return a partial
error. IMO only RESTCONF is needed.  Proposals to
improve NETCONF editing to support YANG Patch have
already been made, and the WG had higher priorities.
I don't see why 2 protocols are needed instead of 1.

> /js

Andy

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 11 Oct 2015 19:51:23 +0200

> > Configuration as YANG config true or a subset thereof?

good

> 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 pane that overrides the running datastore

good

> that are refined in the uses-stmt to set the ephemeral flag.

I fail to understand the groupings argument.
 
> I don't see why 2 protocols are needed instead of 1.

Perhaps the WG should discuss and decide. If all the WG wants is
RESTCONF, then we can simplify the discussion.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 11 Oct 2015 11:10:16 -0700

> I fail to understand the groupings argument.

The refine-stmt is defined to work on YANG statements, not external
statements.

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.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 11 Oct 2015 21:58:18 +0200

> The refine-stmt is defined to work on YANG statements, not external

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.
 
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2015 16:11:11 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 11 Oct 2015 22:24:10 +0200

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2015 16:28:50 -0400

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 12 Oct 2015 02:55:12 -0400

Juergen: 

>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?

Yes - I should have said schema nodes. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sunday, October 11, 2015 12:11 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] inteirm 10/7/20

>               the node  must handle this complexity.

So is there one ephemeral datastore or are there multiple?  Some slides say
one per client, others seem to indicate one for all clients.

> Does anyone have any concerns with adding this to Yang?

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?

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 12 Oct 2015 03:18:10 -0400

Juergen: 

You make an excellent point on whether the WG should just select RESTCONF
instead of both RESTCONF and NETCONF.   I will start a discussion thread
later today on this point. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Sunday, October 11, 2015 1:51 PM
To: Andy Bierman
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [i2rs] inteirm 10/7/20

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.
> 

good

> > 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?
> >
> 
> Otherwise YANG groupings cannot be utilized w/ statements that are 
> refined in the uses-stmt to set the ephemeral flag.

> NETCONF has no edit ordering or ability to return a partial error. IMO 
> only RESTCONF is needed.  Proposals to improve NETCONF editing to 
> support YANG Patch have already been made, and the WG had higher 
> priorities.

Perhaps the WG should discuss and decide. If all the WG wants is RESTCONF,
then we can simplify the discussion.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 12 Oct 2015 03:45:10 -0400

Juergen: 

The data models will be different for I2RS. 

I2RS has protocol independent Data models which are different that the
general data models (I2RS RIB, I2RS topology models, and I2RS FB-RIB).  The
I2RS protocol modules discuss for BGP are different than BGP general yang
modules. 

Sue 

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

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:
> to support ephemeral behavior for all parts of all models, we need 
> some way to clearly indicate what is expected.
> 
> >>>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.
> >>>>
> >>>>>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?
> >>>>>
> >>>>
> >>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.
> >

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 12 Oct 2015 03:46:16 -0400

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:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, October 11, 2015 4:29 PM
To: Andy Bierman; Susan Hares; [email-masked]; [email-masked]
Subject: Re: [i2rs] inteirm 10/7/20

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:
>> 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.
>>
>> Marking elements in the model as ephemeral seems the clearest and 
>> most efficient mechanism, but I am sure there are other alternatives.
>>
>> Yours,
>> Joel
>>
>>>>>> module, unless every persistent config leaf is expected to also 
>>>>>> be supported as ephemeral data.
>>>>>>
case.
>>>>>> Otherwise YANG groupings cannot be utilized w/ statements that 
>>>>>> are refined in the uses-stmt to set the ephemeral flag.
>>>>>
>>> be worth thinking about adding a conformance mechanism that 
>>> decouples conformance requirements from the data model definition.
>>>
>>> /js
>>>
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Oct 2015 09:49:12 +0200

> I2RS protocol modules discuss for BGP are different than BGP general yang

My parser throws an except here...

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 12 Oct 2015 04:42:50 -0400

Juergen: 

My apologies.  Reparsing. 

By experience, the data models seem to be different.  The I2RS has protocol
independent data modules which are different that the routing data modules
(I2RS RIB, I2RS topology models, and I2RS FB-RIB).  

As I've worked on I2RS BGP modules, these BGP modules also appear to require
different data than the general BGP yang modules even though the I2RS BGP
modules want to use groupings from standard BGP yang modules.  These i2RS
BGP modules need to be reviewed by Yang experts. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, October 12, 2015 3:49 AM
To: Susan Hares
Cc: [email-masked]; 'Joel M. Halpern'; [email-masked]; 'Andy Bierman'
Subject: Re: [i2rs] inteirm 10/7/20

On Mon, Oct 12, 2015 at 03:45:10AM -0400, Susan Hares wrote:
> general data models (I2RS RIB, I2RS topology models, and I2RS FB-RIB).  
> The I2RS protocol modules discuss for BGP are different than BGP 
> general yang modules.
>

/js