.fe...@hp.com
Subject: Re: [i2rs] Point about writable running
> Then we really have to write up use cases, settle on requirements and
> decide on the protocol.
The original use case documents covered this specific situation. We decided
to expand the use cases for future use, I think, which then
> Then we really have to write up use cases, settle on requirements and
> decide on the protocol.
The original use case documents covered this specific situation. We decided
to expand the use cases for future use, I think, which then led to trying to
solve all the problems listed there in the fir
Then we really have to write up use cases, settle on requirements and decide on
the protocol.
Dean
On Dec 8, 2014, at 11:48 AM, Russ White wrote:
>
>> What state do we want to change via I2RS?
>
> The original intent was specifically state in the routing table, not --
>
>> As far I know,
> What state do we want to change via I2RS?
The original intent was specifically state in the routing table, not --
> As far I know, we wanted to allow i2rs agent to change any supported state
> on the device. If that is still the case, then we need to go through the
Or rather, the only suppor
I would go back and ask basic question
What state do we want to change via I2RS?
static route
dynamic routing protocol
stateless firewall filters
xVPN (E/L2/L3)
etc
based on that we can then decide if going through configuration or directly
accessing responsible daemon is better way.
As far I
> [Don] I agree. We need to define semantics for the datastore and
> predictable results for the writable running state or active
> configuration. It seems to me if there is priorities and overlap
> with various datastores there should be blocking or overriding of
> ephemeral data too.
If we st
ern.com; i2rs@ietf.org; jcla...@cisco.com; Fedyk, Don
> >> Subject: Re: [i2rs] Point about writable running
> >>
> >
> >> Just to be clear; the semantics you are talking about are not inherent
> >> to the
> >> *protocol*, they are tied to the
Maybe I am missing something, but in terms of intended effect, I thought
it was pretty clear, with one degree of freedom that folks were arguing
about, how the interaction was understood by I2RS.
Given a device with an existing configuration, and a set of models
accessible by I2RS, what I2RS c
On Mon, Dec 01, 2014 at 05:15:08PM +, Fedyk, Don wrote:
> > From: Martin Bjorklund [mailto:m...@tail-f.com]
> > Another way of stating this is that NETCONF commit semantics don't matter if
> > I2RS defines a new ephemeral datastore. (Modulo interactions with the
> > config
> > datastore).
> >
>> Cc: j...@joelhalpern.com; i2rs@ietf.org; jcla...@cisco.com; Fedyk, Don
>>> Subject: Re: [i2rs] Point about writable running
>>>
>>
>>> Just to be clear; the semantics you are talking about are not inherent to
>>> the
>>> *protocol*, the
dyk, Don
>> Subject: Re: [i2rs] Point about writable running
>>
>
>> Just to be clear; the semantics you are talking about are not inherent to the
>> *protocol*, they are tied to the *datastore*. This means that NETCONF and
>> RESTCONF will show similar behavior (somewha
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Sunday, November 30, 2014 4:26 AM
> To: jh...@pfrc.org
> Cc: j...@joelhalpern.com; i2rs@ietf.org; jcla...@cisco.com; Fedyk, Don
> Subject: Re: [i2rs] Point about writable running
>
&g
Jeffrey Haas wrote:
> Joel,
>
> On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
> > I don't recall seeing that form of commit in any protocol that has
> > been proposed. I think it would be rather hard to do.
>
> One of the prior complicating details had been I2RS saying we'd u
Andy Bierman writes:
> On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern wrote:
>> I can not tell from your description Andy who has control and who has
>> predictability. If the device folds the I2RS changes into the permanent
>> state, and saves them, it will make a mess with the way the WG ha
Thank you. That sounds like a useful path to go down.
Yours,
Joel
On 11/29/14, 10:54 PM, Andy Bierman wrote:
On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern wrote:
I can not tell from your description Andy who has control and who has
predictability. If the device folds the I2RS changes into
On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern wrote:
> I can not tell from your description Andy who has control and who has
> predictability. If the device folds the I2RS changes into the permanent
> state, and saves them, it will make a mess with the way the WG has assumed
> things to work.
I can not tell from your description Andy who has control and who has
predictability. If the device folds the I2RS changes into the permanent
state, and saves them, it will make a mess with the way the WG has
assumed things to work.
Yours,
Joel
On 11/29/14, 9:38 PM, Andy Bierman wrote:
On S
On Sat, Nov 29, 2014 at 3:41 AM, Juergen Schoenwaelder
wrote:
> On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote:
>> Joel,
>>
>> On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
>> > I don't recall seeing that form of commit in any protocol that has
>> > been proposed.
On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote:
> Joel,
>
> On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
> > I don't recall seeing that form of commit in any protocol that has
> > been proposed. I think it would be rather hard to do.
>
> One of the prior complic
Joel,
On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
> I don't recall seeing that form of commit in any protocol that has
> been proposed. I think it would be rather hard to do.
One of the prior complicating details had been I2RS saying we'd use "netconf
and restconf" when we s
Hi,
just to clarify:
If you write to the running configuration datastore (e.g., via
RESTCONF) and the running configuration datastore is locked, then
the write is rejected.
If there were a separate ephemeral datastore, then this ephemeral
datastore may not have locks and there may be some
2rs@ietf.org
Subject: Re: [i2rs] Point about writable running
I agree Joe. The challenge with using any of the existing stores is
that if
someone says "commit" they need to get the NetConf / RestConf normal
changes to that, but not the I2RS changes.
Yours,
Joel
On 11/13/14, 9:57 PM, Jo
A user may be allowed to override the config items that are ephemeral.
>>> The override may be priority based where user A with higher priority
>>> can override user B but not the reverse.
>>>
>>> So if the user A is i2rs agent and the user B is an operator where the
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, November 13, 2014 11:28 PM
To: Fedyk, Don; Joe Clarke; i2rs@ietf.org
Subject: Re: [i2rs] Point about writable running
I don't recall seeing that form of commit in any protocol that has
. It works both ways.
Cheers,
Don
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Thursday, November 13, 2014 11:28 PM
> To: Fedyk, Don; Joe Clarke; i2rs@ietf.org
> Subject: Re: [i2rs] Point about writable running
>
running store". No?
Don
-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Thursday, November 13, 2014 11:17 PM
To: Fedyk, Don; Joe Clarke; i2rs@ietf.org
Subject: Re: [i2rs] Point about writable running
The case that causes complications for treating only
, Don; Joe Clarke; i2rs@ietf.org
> Subject: Re: [i2rs] Point about writable running
>
> The case that causes complications for treating only one store is:
> 1) You have a running box, with a CLI client A and an I2RS client. The I2RS
> client understands and expects that its changes
s for what is needed?
Cheers,
Don
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, November 13, 2014 10:06 PM
To: Joe Clarke; i2rs@ietf.org
Subject: Re: [i2rs] Point about writable running
I agree Joe. The challenge with using
ow priority per item, doesn't this cover the bases for what is
needed?
Cheers,
Don
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, November 13, 2014 10:06 PM
To: Joe Clarke; i2rs@ietf.org
Subject: Re: [i2rs] Point about writa
heers,
Don
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Thursday, November 13, 2014 10:06 PM
> To: Joe Clarke; i2rs@ietf.org
> Subject: Re: [i2rs] Point about writable running
>
> I agree Joe. The challenge with usin
On Thu, Nov 13, 2014 at 6:57 PM, Joe Clarke wrote:
> During today's meeting Dean made a comment that we could use writable
> running as a way to do ephemeral state. I have a concern about this. I
> know it may seem like an implementation detail, but I feel that most vendors
> (and operators) ass
I agree Joe. The challenge with using any of the existing stores is
that if someone says "commit" they need to get the NetConf / RestConf
normal changes to that, but not the I2RS changes.
Yours,
Joel
On 11/13/14, 9:57 PM, Joe Clarke wrote:
During today's meeting Dean made a comment that we c
During today's meeting Dean made a comment that we could use writable
running as a way to do ephemeral state. I have a concern about this. I
know it may seem like an implementation detail, but I feel that most
vendors (and operators) assume that things in the running datastore
_could_ become
33 matches
Mail list logo
