Subject: [netmod] Opstate draft comments

From: Balazs Lengyel <[email-masked]>
Date: Thu, 22 Oct 2015 18:01:26 +0200

Hello,
- We define the derived state but we do not define "non-derived state" 
although it is referred to in the requirements. I would need a 
definition even if it is just a definition by examples. Better then nothing.
- We should mention long running operations like backup. Are they 
considered synchronous or async. It should be mentioned.
- There are systems out there where you write the intended config 
synchronously, but you get no feedback if and when pushing the data to 
the line cards succeeds. It is just assumed that pushing it to the real 
data users will be done fast and without errors. This works fine for 
many systems. How do we classify these?
- Some data really have two values e.g. one on the line card and one in 
the config datastore, but a lot of data (IMHO 70%) only exists in the 
config datastore. So as I see it the intended config only really exists 
for 30% of the data.
- Often it is defined in the data model whether a specific operation, 
action, rpc is synchronous or async. Include it in the draft.
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Gert Grammel <[email-masked]>
Date: Thu, 22 Oct 2015 17:51:35 +0000

Balazs,

Let me try to respond to a few of your questions. See below ...

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Balazs Lengyel <[email-masked]<mailto:[email-masked]>>
Date: Thursday 22 October 2015 18:01
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] Opstate draft comments

Hello,

Good question. Is it related to Opstate in particular or more in general i.e. Covering also intended/applied config?

IMO They shall be asynchronous:

  1.  The actual actual state/config is no backup and the intended state is no backup
  2.  Client provides a new intended state: Backup
  3.  Server responds after checking the new intended state and confirms Backup to be executed
  4.  Server runs the backup
  5.  client get informed that the backup is completed or an error had occurred.

This is a "cheating synchronous" behavior. For a true synchronous behaviour the server has to notify the client that the intended config is successfully applied. If the server responds prior to applying the config, it is asynchronous. IMO the fact that the server masquerades itself to be synchronous is an undesired behaviour.

Intended config exists 100% in the datastore when it is sent by the client. After it is successfully applied it sits 70% in the datastore and 30% i the line cards.

Given that a lot of so called 'synchronous' operations are asynchronous while cheating-synchronous, I wonder if the distinction makes a lot of sense.

Best

Gert

regards Balazs

--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Oct 2015 11:19:13 +0100

Hi Balazs,

> definition even if it is just a definition by examples. Better then 

Yes, if it is used, then I agree that we should also define non-derived 
state.

> considered synchronous or async. It should be mentioned.

Personally, I would like to restrict the scope of the requirements and 
solutions to only config operations.  Neither the NETCONF or YANG drafts 
make any mention of backup operations, so I would prefer that we don't 
introduce them here.

> the line cards succeeds. It is just assumed that pushing it to the 
> real data users will be done fast and without errors. This works fine 
> for many systems. How do we classify these?

Yes, I think that we could add a clarification to the draft that 
existing NETCONF/RESTCONF server config operations are not necessarily 
either synchronous or asynchronous, but could be reply at any time 
between an equivalent synchronous or asynchronous config operation.

To be more explicit, with this draft, I think that there are 3 valid 
ways that a NETCONF/RESTCONF server could reply to a config operation:
(1) As an explicit synchronous config operation,
(2) As an explicit asynchronous config operation,
(3) As an existing NETCONF/RESTCONF config operation.

All existing NETCONF/RESTCONF servers remain compliant via 3 with no 
changes required, but for vendors that need to implement the opstate 
extensions they may be asked to add support for explicit synchronous or 
asynchronous config operations.

As Gert has pointed out, clients can mostly handle existing 
NETCONF/RESTCONF config operations as being asynchronous but with two 
provisos: (i) There isn't any explicit notification of when the 
configuration apply phase has completed, and (ii) there may be quite a 
long delay (e.g. 10+ minutes) before the server replies to the 
configuration operation request.

>
> - Some data really have two values e.g. one on the line card and one 
> in the config datastore, but a lot of data (IMHO 70%) only exists in 
> the config datastore. So as I see it the intended config only really 
> exists for 30% of the data.
To clarify, do you mean "the applied" config only really exists for 30% 
of the data?

One way of thinking of the difference between the intended and applied 
leaves is that they are really just two separate views onto the same 
configuration node.  The intended view represents what the operator 
wants, and the applied view represents what the system is doing.  
Logically, these two views always exist for all configuration nodes 
regardless of where or how the configuration is actually programmed in 
the system.

> action, rpc is synchronous or async. Include it in the draft.

Again, I would prefer it if any non configuration operations are 
regarded as being outside the scope of the requirements draft which is 
really only concerned with the handling of configuration updates.

Thanks,
Rob