Subject: Re: [i2rs] ephemeral RPC?

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 07:17:58 -0400

Joel: 

I am simply stating that 

I2RS RIB data model is an ephemeral-only data model, and uses an rpc to do
rib add/delete, route add/delete, nexthop add/delete.   The rpc function
must handle ephemeral datastore information.   The authors utilized the
input capabilities of the rpc.  For a ephemeral-only model, it does not
matter if the rpc is "ephemeral" or "non-ephemeral".   However, in a mixed
model (see my example of the bgp-global-config changes), this constraints
the functionality.      

The  <get-config> and <edit-config> is a separate function from rpc.  The
protocol-strawman indicates these need to be changed to handle ephemeral
datastore. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, May 31, 2016 4:27 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] ephemeral RPC?

This may well be just me leaping to assumptions about function structuring.
My apologies for raising a red herring if so.

I think this may be following the paradigm in Juergen's draft, where
accessing data <get...> and <set...> in different data stores uses different
RPCs?  Is that your intent?

Until I read Juergen's draft, it had never occurred to me that one would do
it that way.  I had expected that one would perform an operation, and target
it at a data store.

But if indeed we use different RPCs for the different data stores, then I
guess we do need versions of <get...> and <set...> that point at ephemeral.

Yours,
Joel

On 5/31/16 4:23 PM, Susan Hares wrote:
> Joel:
>
> I2RS data model is a ephemeral-only data model, and uses an rpc to do 
> rib add/delete, route add/delete, nexthop add/delete.  Therefore, we 
> need ephemeral rpc support.
>
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, May 31, 2016 12:34 PM
> To: [email-masked]
> Subject: [i2rs] ephemeral RPC?
>
> We have agreed that non-ephemeral data must not reference ephemeral data.
>
> However, we have, up till now, not had the notion of ephemeral RPCs.  
> I see that the recent ephemeral requirements draft, as a side-effect 
> of improving clarity, creates the notion of an ephemeral RPC.
>
> What is an ephemeral RPC, and why do we have it?
> We have been, up till now, assuming that we could use normal NetConf 
> RPCs to set and get the ephemeral information.
>
> Thank you,
> Joel
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 07:41:20 -0400

Jeff: 

I believe I have answered this elsewhere.  I2RS RIB Data Model provides an
rpc to:

.         add/delete RIBs, 

.         Add/delete Routes, 

.         Add/delete nexthops. 

The rpc could be augmented to simply provide a datastore. 

Sue  

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2016 5:58 PM
To: Susan Hares
Cc: 'Joel M. Halpern'; [email-masked]
Subject: Re: [i2rs] ephemeral RPC?

Sue,

Rather than saying "ephemeral RPC", I suspect you mean an RPC that has
impact on ephemeral configuration or operational state.

Arguably, if the RPC in question only manifests as operational state for
that case the idea of ephemeral configuration in yang may become moot.

-- Jeff

> From: i2rs [ <mailto:[email-masked]> mailto:[email-masked]]
On Behalf Of Joel M. Halpern

> To:  <mailto:[email-masked]> [email-masked]

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/i2rs>

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/i2rs>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jun 2016 09:35:54 -0400

I think this is an aspect of how we describe our requirements.

Our requirement is that we need RPC operations that manipulate (fetch, 
deposit, ...) ephemeral configuration information.

Whether those are new RPCs (ephemeral RPCs) or extensions to existing 
RPCs to indicate that the target is ephemeral information (data store), 
or some other mechanism, does not really matter to I2RS.
Juergen has indicated that some RPCs take data store as an argument. 
For any of those that are relevant to us, that RPC would seem to work 
unmodified with an ephemeral data store.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 1 Jun 2016 09:41:02 -0400

The deprecation of <get> and the addition of <get-state> lead me to 
conclude that you were moving to a paradigm of different RPCs for 
different data stores, rather than a paradigm of a datastore parameter 
for the RPC.

I may well have over-generalized from what I read.
Yours,
Joel

On 6/1/16 2:34 AM, Juergen Schoenwaelder wrote:
> On Tue, May 31, 2016 at 04:27:17PM -0400, Joel Halpern Direct wrote:
>>
> Joel,
> which part of my I-D made you believe this is the case? Several core
> NETCONF RPCs do take a datastore as an argument and this is just fine.
>
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 17:01:06 +0200

Oh, I see. The story line, however, is that <get> assumes it is
possible to merge operational state with <running> configuration
datastore content and this ultimately lead to the /foo and /foo-state
data model design pattern, which a number of people find cumbersome.
So the idea is to deprecate operations like <get> that assume
datastores can be merged because the models have been design to use
different branches. We then need a new operation that can be used to
retrieve state data and likely (perhaps as a feature) operations that
can retrieve data from multiple datastores (without assuming the
underlying data models avoid overlapping branches). Perhaps calling
the former <get-state> is misleading people, I can see that.

/js

On Wed, Jun 01, 2016 at 09:41:02AM -0400, Joel M. Halpern wrote:
> The deprecation of <get> and the addition of <get-state> lead me to conclude
> that you were moving to a paradigm of different RPCs for different data
> stores, rather than a paradigm of a datastore parameter for the RPC.
> 

-- 
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: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Jun 2016 11:54:46 -0400

Juergen,

An older rev of the ephemeral state requirements covered part of this point.
The suggestion in there was that <get> may require some ability to do
filtering operations based on where the information was from:

https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-00
See "filter-ephemeral".

I don't believe the I2RS working group has any particular opinion on what
the mechanism looks like, but we are in agreement that some solution will be
needed for this problem.

-- Jeff