Subject: [netmod] separate state and config

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Nov 2014 08:50:56 -1000

Hi,

I think $subj needs more discussion because there still seem to be disagreements whether separate config and state trees are necessary or not.

Maybe the answer can be different for NETCONF and RESTCONF. In NETCONF, in something changes in the system (e.g. an interface card is installed), state data is the only safe place where the system can record the change. Writing it to running is problematic because (1) running may be locked, or (2) running and candidate may get out of sync and the client then might not be able to commit.

In contrast, neither (1) nor (2) is an issue for RESTCONF’s unified datastore, and so system-generated writes are probably safe.

That would however mean that data models written primarily for RESTCONF might have problems if used with NETCONF, which is IMO not good.

Lada
 
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Nov 2014 20:02:24 +0100 (CET)

Lada,

The intention is not that RESTCONF has a *separate* datastore than
NETCONF - it just provides unified access to
startup/running/candidate.  If you write something through RESTCONF,
it immediately shows up in get-config(running) in NETCONF.

/martin

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> I think $subj needs more discussion because there still seem to be
> disagreements whether separate config and state trees are necessary or not.
> 
> Maybe the answer can be different for NETCONF and RESTCONF. In NETCONF, in
> something changes in the system (e.g. an interface card is installed), state
> data is the only safe place where the system can record the change. Writing it
> to running is problematic because (1) running may be locked, or (2) running and
> candidate may get out of sync and the client then might not be able to commit.
> 
> In contrast, neither (1) nor (2) is an issue for RESTCONF’s unified datastore,
> and so system-generated writes are probably safe.
> 
> That would however mean that data models written primarily for RESTCONF might
> have problems if used with NETCONF, which is IMO not good.
> 
> Lada
>  
> --
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 20:20:03 +0100

On Thu, Nov 13, 2014 at 08:02:24PM +0100, Martin Bjorklund wrote:

> If you write something through RESTCONF, it immediately shows up in
> get-config(running) in NETCONF.

Out of curiosity: What happens if running is locked? I get a 409
Conflict HTTP error response?

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Nov 2014 20:24:44 +0100 (CET)

> Conflict HTTP error response?

Yes, see section 6 in the draft, and the example in 6.1.

/martin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 13 Nov 2014 09:51:50 -1000

That is probably up to the "application" making the call.  It can just retry of course.

	--Tom

> On Nov 13, 2014:9:20 AM, at 9:20 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Nov 2014 12:09:27 -0800

> That would however mean that data models written primarily for RESTCONF might have problems if used with NETCONF, which is IMO not good.

We made locking mandatory-to-implement but optional-to-use.
We decided to live with the consequences of that decision.
Editing without locking is prone to failures. So what?
Use locking if you care about that.

If other protocols interact with the config to produce operational
state, then the data model
should account for that.  Whether or not the non-config nodes are child nodes of
config nodes or standalone data structures makes no difference here.

If an instance of foo-state can exist even if the corresponding
foo-config instance
does not exist, then separate trees are needed. Otherwise they are not.

> Lada

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 21:44:54 +0100

> 	That is probably up to the "application" making the call.  It can just retry of course.

Tom, I was asking about the server behaviour and that better is
clearly defined (and it seems it is).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Nov 2014 13:16:44 -1000

> it immediately shows up in get-config(running) in NETCONF.

But that's your choice, right? If I don't need a parallel access via
NETCONF, is there anything that prevents me from implementing just the
unified datastore, pretty much 1:1 to what's presented to the RESTCONF
client?

Lada

---

From: Kent Watsen <[email-masked]>
Date: Fri, 14 Nov 2014 00:59:30 +0000

>unified datastore, pretty much 1:1 to what's presented to the RESTCONF

No, but if just implementing RESTCONF, then the implementation doesn't
really have a "unified" datastore, as unification relates to NETCONF's
datastores, for which it would have none.  For all intents and purposes,
the RESTCONF-only server would just have a writable-running datastore.

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Nov 2014 16:16:18 -1000

> the RESTCONF-only server would just have a writable-running datastore.

OK, we can call it that way, but since it cannot be locked, even system-controlled entries could be safely put in the same lists with user-controlled ones, which would make the whole thing a lot easier to model and operate. So I am back at my point: config and state trees needn’t be distinct in this case.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Nov 2014 05:38:40 +0100

> Yes, see section 6 in the draft, and the example in 6.1.

This text may be a bit confusing:

   The following example shows an error returned for an "lock-denied"
   error on a datastore resource.

Perhaps it should be something like this:

   The following example shows an error returned if an attempt to
   modify a resource fails because the resource is locked (e.g.,
   by a lock created by NETCONF).

But then the POST is actually:

      POST /restconf/operations/example-ops:lock-datastore HTTP/1.1
      Host: example.com

This is not covering the case where a normal resource updates fails
because of locks that exist but are not managed by RESTCONF. Could
also be that I am missing something but searching for 'lock' in the
I-D, the pieces of text I find do not really make things clear.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Nov 2014 05:47:02 +0100 (CET)

Hi,

>    by a lock created by NETCONF).

Good suggestion.

> I-D, the pieces of text I find do not really make things clear.

Ok, yes I think the text needs clarification.

/martin