Subject: Re: [i2rs] Point about writable running

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 1 Dec 2014 17:15:08 +0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Sunday, November 30, 2014 4:26 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Fedyk, Don
> Subject: Re: [i2rs] Point about writable running
> 
<Snip> 
> 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 (somewhat dependant on which
> capabilities NETCONF advertises; as has been pointed out the client has more
> control over the NETCONF datastores, leading to more predictable behavior).
> 
> So the reasoning should not be: "NETCONF commit has unwanted semantics
> and/or performace, therefore we should use RESTCONF".  Rather it should be
> "Writes to the configuration datastore has unwanted semantics and/or
> performace, therefore we need to carefully define the semantics for the new
> ephemeral datastore" - and once that is done it is trivial to define the necessary
> protocol extensions for both NETCONF and RESTCONF.
> 
> 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).
> 
> 
> /martin
[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.  

Cheers,
Don

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Dec 2014 09:59:16 -0800

> [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…

NETCONF has global and partial locks. It also has a <copy-config>
operation to/from any datastore. Also a shared candidate datastore
and confirmed-commit that do not work well unless clients use locking.

NETCONF uses sessions and edit operations can require multiple steps.
RESTCONF does not use sessions and operations are stateless.
IMO 1 should be mandatory for an I2RS agent to support, but not both.

The ephemeral datastore could have new rules, such as no locking
and copy-config optional.  NETCONF text could be written
explaining how the new datastore interacts will all possible NETCONF
operations.  It would be less work to define the interactions in RESTCONF
simply because there are relatively so few bells and whistles.

> Don

Andy

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

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 1 Dec 2014 19:42:13 +0000

> IMO 1 should be mandatory for an I2RS agent to support, but not both.

I agree that only one should be mandatory and not both. And I would put RESTCONF forward as sole candidate for i2rs (for reasons Andy described earlier in this thread).
> operations.

and that would create a very complex scenarios, which I would prefer to avoid

>  It would be less work to define the interactions in RESTCONF

and that is exactly the reason why RESTCONF is right to do the job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 2 Dec 2014 13:41:23 -0500

> [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…

Interactions with things outside of the ephemeral config has been the
difficult thing for this discussion all along.  While I'm happy that people
seem to be thinking harder about the protocol details, I'm not sure I've
heard anything convincing that we know what that means yet.

(Although I do find the edata comment from Andy for Restconf to be
promising...)

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Dec 2014 14:12:18 -0500

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 clients do is applied to the underlying 
device, and is accessible at least by asking the I2RS agent what its 
state is.

The ambiguity is what happens if someone comes in with CLI later.
Can they see the effect of I2RS?  The group wanted it to be visible. 
But it must not be confused with the actual config.  Which may make it 
hard to do.
If a CLI change affects something that has been modified by I2RS, what 
happens?  The easy part is that the config gets changed.  The question 
is what effect this has on the box.  There are three chocies.
1) The CLI change takes effect, and the I2RS agent handles this with its 
clients just the way it would if a higher priority client had overridden 
the effect.
2) The CLI change simply does not take effect, and the operator is given 
whatever warnings or notifications the system wants.
3) There is a priority for CLI, and it is compared with the I2RS 
priority to choose between 1 and 2.
Choice 3 is what the I2RS group said it wanted.  If that can be shown to 
be non-meaningful, or too complicated, the group can revisit the question.

Yours,
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Dec 2014 14:47:27 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> >> *protocol*, they are tied to the *datastore*.  This means that NETCONF
> >> *and
> > [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.
> >
> 

Correct, but irrelevant to this question.

> RESTCONF does not use sessions and operations are stateless.

Yes; the session handling is the biggest difference IMO.

Note that for edits, if the RESTCONF server doesn't implement
yang-patch, edits in RESTCONF often require many more steps than in
NETCONF.

> IMO 1 should be mandatory for an I2RS agent to support, but not both.

Agreed.

> simply because there are relatively so few bells and whistles.

Maybe, or maybe not.

My point was that the original reasoning (i2rs needs to use restconf
b/c of problems with the commit model in netconf) is not correct.

This doesn't mean that there cannot be other reasons for using
RESTCONF in i2rs.

/martin

---

From: "Russ White" <[email-masked]>
Date: Wed, 3 Dec 2014 13:30:52 -0500

> 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 stuck to routing table state, rather than configuration state, then we
probably wouldn't have such overlaps in the first place... Or rather the
overlaps would be resolved through an 'administrative distance' sort of
mechanism, and each individual write would be wholly atomic, meaning there
would be no interlocking state changes. 

That we are talking about having interlocking state changes within a single
device implies, to me, that we're far afield of the original intent of I2RS
(?).

:-)

Russ

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 8 Dec 2014 16:39:33 +0000

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 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 configuration. If want to limit change of the state to certain primitives, then we can investigate what other options are available for i2rs

Dean

---

From: "Russ White" <[email-masked]>
Date: Mon, 8 Dec 2014 11:48:52 -0500

> 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 supported state was routing table state. The original
intent was, essentially, to allow an off box process to interact with the
local routing table just as an on box routing process might -- same speed,
same atomicity, etc. In other words, the router could run BGP locally or
remotely without the router, locally, knowing the difference. The major
conflict in this realm is whether this should include such things as
modifying a community string on a specific BGP route within the BGP process
itself. I don't know that we ever resolved this specific question.

If we've decided to change routing protocol configuration, packet filters,
and all the rest, then I would suggest we should break the work up into two
pieces -- one that covers the original (minimal) intent, and another that
covers the routing protocol configuration pieces. The configuration pieces
are more "full YANG" in nature, while the original intent work could use
YANG models, but would clearly not need (nor want) locks, multipart commits,
etc.

:-)

Russ

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 8 Dec 2014 16:57:31 +0000

Then we really have to write up use cases, settle on requirements and decide on the protocol. 

Dean

---

From: "Russ White" <[email-masked]>
Date: Mon, 8 Dec 2014 12:09:29 -0500

> Then we really have to write up use cases, settle on requirements and

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 first swack, and as one problem
set. Part of this was merging all the different use cases into a single set
of use case drafts that make the problem set appear (maybe) more unified
than it really is. 

It's perhaps more logical to look at the use cases we have and break them
back down into "now," and "later," and along clear lines of requirement
sets. I don't think we've actually done that work yet.

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 11 Dec 2014 09:26:24 -0500

Russ:

[i2rs-co-chair hat on]
Ed Crabbe broke things up into In-charter and out-of charter (see the use
case drafts).  Our AD (Alia) has us focusing on the Protocol independent use
cases (first), and the topology use cases which are in-charter.  
[i2rs-co-chair-hat off]

If this helps you to come up with a protocol specification for the Protocol
Independent, and a later protocols specification - please do.   For 12/16
interim, it is appropriate to bring a draft and a set of sides to discuss
these protocols.   Can you help with that protocol specification? 

The BGP I2RS Info-model and Yang draft - has the informational model for the
BGP portion of the specification.   We do suggest changing policy and
community strings.  This work is progressing in IDR, but needs the protocol
specification for the larger issues.  I'm happy to feedback those needs to
you. 

Does this help?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Monday, December 08, 2014 12:09 PM
To: 'Dean Bogdanovic'
Cc: [email-masked]; 'Martin Bjorklund'; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Point about writable running

:-)

Russ