Subject: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Sep 2015 14:04:16 +0000

OK, how about another (hopefully) easy one.

Robert Wilton writes: "It wasn't clear to me where the requirement 3 (A)
came from. I'm not necessarily opposed to it, only that it doesn't appear
to be obviously specified in the openconfig-netmod-opstate draft."

For convenience, Requirement 3 is reproduced below in its entirety:

   3.  Support for both transactional, synchronous management systems as
       well as distributed, asynchronous management systems

       A.  For asynchronous systems, the ability to request a protocol
           operation to not return (i.e. block) until the intended
           configuration has been fully synchronized.

       B.  The protocol operation's response would indicate the result
           of the operation (success, failure, partial, etc.)

Regarding where requirement 3A came from, as the Appendix shows, the
entire requirement #3 is derived from draft-openconfig-netmod-opstate-01,
Section 4.2, which says:

   In a synchronous system, configuration changes are transactional and
   committed as an atomic unit.  This implies that the management system
   knows the success or failure of the configuration change based on the
   return value, and hence knows that the intended configuration matches
   what is on the system (i..e, what has been applied).

Given that we only have asynchronous systems today with NETCONF and
RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
synchronous with a blocking call.   This may have been a bad assumption on
my part, as Anees has since clarified that the solution may not even use
the NETCONF or RESTCONF protocols. Further, rather than assuming we need
to make an asynchronous system synchronous, it could be instead that we
merely just need to accept that synchronous systems may exist somewhere in
the world outside NETCONF/RESTCONF.  To that end, there may not be an
actionable requirement here and we should just remove Requirement #3
altogether.  Thoughts?

PS: please Reply-All to this thread, rather than post comments on the
GitHub issue tracker.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2015 16:22:54 +0200

> actionable requirement here and we should just remove Requirement #3

Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
Did you messes up the terms throughout this paragraph? If I swap all
of them, the text starts to make sense to me.

/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: Robert Wilton <[email-masked]>
Date: Tue, 22 Sep 2015 17:01:58 +0100

> of them, the text starts to make sense to me.
I can see that they are both:
(i) They are synchronous with respect to the config operation. I.e. they 
don't send a reply until the config operation has completed.
(ii) They are asynchronous with respect to the communication.  I.e. the 
client isn't blocked while the config operation is ongoing, and a client 
may send additional requests whilst waiting for a reply.

I believe that the text in draft-openconfig-netmod-opstate-01, Section 
4.2 is mainly concerned with (i) and not (ii), but I read it as 
describing both sync vs async management systems as well as sync vs 
async YANG servers.  From my reading of the text:

The first paragraph of section 4.2 is just describing existing NETCONF 
like protocols.  Hence, no new requirement here, and so I think that 3.A 
can be deleted.

The second paragraph of section 4.2 states that async servers may reply 
early, and applied cfg state is used to check the system state (which is 
effectively already covered as a separate requirement). However, does a 
client need to be able to know that a server will process a particular 
config request, or all config requests, in an asynchronous fashion?  I 
don't think that the opstate draft states this - presumably on the 
assumption is that they can always use intended vs applied config leaves 
for both sync and async servers and so don't need to differentiate.  Is 
this assumption valid for all client/server interactions?

The third paragraph only provides justification and doesn't introduce 
any new requirements.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Sep 2015 16:06:27 +0000

> of them, the text starts to make sense to me.

Nope, but I grant you there are terminology issues here.  What I mean, and have said before, is that NETCONF/RESTCONF make no assertions with regard to the applied configuration when the RPC-reply or HTTP response is provided.   In my experience, only the control plane is updated and sometime later the changes are propagated to dataplane. 

Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 09:20:18 -0700

On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen <[email-masked]> wrote:

> Nope, but I grant you there are terminology issues here.  What I mean, and
> have said before, is that NETCONF/RESTCONF make no assertions with regard
> to the applied configuration when the RPC-reply or HTTP response is
> provided.   In my experience, only the control plane is updated and
> sometime later the changes are propagated to dataplane.
>
>

NETCONF and RESTCONF are asynchronous, meaning the client and server
run in separate processes and communication between client and server can
occur at any time.

If the server returns <ok/> to an edit request, that means it is accepted in
the intended config.

Kent

Andy

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 Sep 2015 17:38:13 +0100

On 22/09/2015 17:20, Andy Bierman wrote:
>
>
> On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>
>     Nope, but I grant you there are terminology issues here. What I
>     mean, and have said before, is that NETCONF/RESTCONF make no
>     assertions with regard to the applied configuration when the
>     RPC-reply or HTTP response is provided.   In my experience, only
>     the control plane is updated and sometime later the changes are
>     propagated to dataplane.
>
>
>

I would expect that if a normal NETCONF server returned <ok/> from an 
edit request, then that means that it is accepted in both the intended 
and applied config. I.e. it is what you would get back if you made a 
get-config request.

A server behaving in an async fashion would reply immediately the 
intended config was updated, and the applied config would be updated later.

Thanks,
Rob

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2015 19:00:13 +0200

> run in separate processes and communication between client and server can

I thought the openconfig discussion was centered around the server
side...

> If the server returns <ok/> to an edit request, that means it is accepted in

I think we need to use precise terminology otherwise we keep talking
past each other. An <ok/> to an <edit-config> means the edit got
'accepted' (not sure what this term means) in the configuration
datastore being edited, such as <running/> or <candidate/>.

Perhaps <running/> === intended configuration datastore. But I think
it is important to not forget that there are multiple configuration
datastores in NETCONF.

My understanding is that the <edit-config/> operation is synchronous
with respect to the change of the configuration datastore. The
propagation of the data from the <running/> configuration datastore to
the internal pieces of hardware and software being configured may be
asynchronous and is usually considered an implementation detail. The
protocol itself allows asynchronous clients to be written that can
talk to multiple servers and in principle the protocol supports
pipelining of requests from a single client to a single server but all
requests are executed serially. I think the same applies to RESTCONF
but I am a bit less confident.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 11:04:35 -0700

> datastore being edited, such as <running/> or <candidate/>.

OK -- the edit is accepted as part of the <running> datastore.
That means is passes the YANG validation tests.
I guess our terminology is so poor that we cannot even describe that
means wrt/ the device or the network.

> but I am a bit less confident.

I agree with Carl that there is no problem to solve wrt/ "show running"
being delayed.  I think implementations just return the intended values.

/js

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Sep 2015 11:21:26 +0100

On 22/09/2015 19:04, Andy Bierman wrote:
>
>
> On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

This doesn't seem to be consistent with the rfc6241 section 5.1 that states:
"The running configuration datastore holds the complete configuration 
currently active on the network device."

Also, section 4.2 of openconfig-netmod-opstate states:

    "In a synchronous system, configuration changes are transactional and
    committed as an atomic unit.  This implies that the management system
    knows the success or failure of the configuration change based on the
    return value, and hence knows that the intended configuration matches
    what is on the system (i..e, what has been applied).  In particular,
    the value of any configuration variable should always reflect the
    (intended) configured value.  Synchronous operation is generally
    associated with a NETCONF-based system that provides transactional
    semantics for all changes."

Taken together, to me, this implies that the definition of "applied 
configuration" is such that after a successful regular (i.e. 
"synchronous") NETCONF edit-config request then the values that the 
running datastore holds is both the intended configuration and applied 
configuration.  I.e. they are the same.

Of course, I agree that this doesn't guarantee that a particular item of 
configuration has been fully programmed everywhere on the system, but 
that is what the derived state indirectly tells gives you.

It is only "asynchronous" servers that return early from an edit-config 
request for which the intended config can ever differ from the applied 
config.  Further, assuming that there are no errors when applying the 
configuration, then at the point in time that a server would have 
logically completed a normal "synchronous" config request, the value of 
the "applied configuration" leaves would be identical to the "intended 
configuration" leaves.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Sep 2015 15:03:57 +0000

> "The running configuration datastore holds the complete configuration currently active on the network device."

Good catch!  RFC 6241 appears to be inaccurate, unless we assume "currently active" means active from the control plane's perspective, but not necessarily operationally active.  Does this require errata?

Popping the stack on this issue, the issue remains as to what to do with requirement 3:

   3.  Support for both transactional, synchronous management systems
        as well as distributed, asynchronous management systems

Again, my position is that sub-requirements A and B are not actual requirements in the sense that we're being asked to add to NETCONF/RESTCONF (the only protocols supported currently) an ability to block protocol operations until the intended configuration is fully propagated to the operational components of a system.  So I think that 3A and 3B should be removed.

But the top-level statement in 3 remains valid, and yet it now seems like a duplicate to the requirement #1.  That is, a synchronous system presumably has no "applied" configuration whereas an asynchronous does.  So it seems that satisfying this requirements is one and the same as satisfying the desire for a system to advertise (or not) support for an "applied" configuration.  Agreed?

If this is agreed, then we can close this issue by replacing A and B with a note indicating that requirement #3 is a duplicate of #1.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Sep 2015 17:13:53 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Good catch!  RFC 6241 appears to be inaccurate, unless we assume
> "currently active" means active from the control plane's perspective,
> but not necessarily operationally active.  Does this require errata?

I think the term "active configuration" can be interpreted to mean
"intended configuration".  I don't think we should file an errata at
this point, and in any case we should wait until we have a (published)
definition of the term.

> Again, my position is that sub-requirements A and B are not actual
> requirements in the sense that we're being asked to add to
> NETCONF/RESTCONF (the only protocols supported currently) an ability
> to block protocol operations until the intended configuration is fully
> propagated to the operational components of a system.  So I think that
> 3A and 3B should be removed.

+1

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 23 Sep 2015 16:25:24 +0100

On 23/09/2015 16:03, Kent Watsen wrote:
> > "The running configuration datastore holds the complete 
> configuration currently active on the network device."
>
> but not necessarily operationally active.
That is what I would normally expect the running the configuration to mean.

>  Does this require errata?
>
>
> propagated to the operational components of a system.
I don't think that this is what it asking for, but I'm not sure that it 
matters.

>  So I think that 3A and 3B should be removed.
I agree.

>
> But the top-level statement in 3 remains valid, and yet it now seems 
> like a duplicate to the requirement #1.  That is, a synchronous system 
> presumably has no "applied" configuration whereas an asynchronous 
> does.  So it seems that satisfying this requirements is one and the 
> same as satisfying the desire for a system to advertise (or not) 
> support for an "applied" configuration.  Agreed?
Not quite.

E.g. I think that for compatibility a system could still advertise 
support for "applied" configuration even through its configuration 
processing is "synchronous" and hence applied config would always match 
intended config.

Hence I still question whether there is a need for the system to 
advertise that it performs "asynchronous" configuration processing, 
which is different from the requirement to support applied configuration 
above.  I.e. does the client need to know that config edit operations 
will return before the configuration is applied to running config.  It 
may be that we need to get to the bottom of the definition of "intended 
vs applied vs currently active" cfg before this can be sensibly answered.

Rob

>
> If this is agreed, then we can close this issue by replacing A and B 
> with a note indicating that requirement #3 is a duplicate of #1.
>
> Thanks,
> Kent
>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Sep 2015 16:12:56 +0000

> processing is "synchronous" and hence applied config would always
> match intended config.

OK, I can see this perspective.   For now I've updated #3 with a proposal to remove A & B, with a remaining open issue is top-level requirement #3 is still needed.

> which is different from the requirement to support applied
> configuration above.  I.e. does the client need to know that config
> edit operations will return before the configuration is applied to
> running config.  It may be that we need to get to the bottom of the
> definition of "intended vs applied vs currently active" cfg before this
> can be sensibly answered.

Yes, and this is exactly what issue #6 is about:

  #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Let me start a thread on that now.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Sep 2015 10:40:13 +0200

>         as well as distributed, asynchronous management systems

I fail to understand 'transactional' and 'distributed' here. And
frankly, I am not sure why the management _systems_ are classified to
be synchronous or asynchronous - I think we are talking about
protocols between a management system and a device. In NETCONF as well
as RESTCONF are, you can pipeline YANG operations but all operations
are processed sequentially in order.

There are apparently other proprietary protocols that do things
differently but so far we have not seen a specification of how this
works.

Anyway, I am not sure 3. is properly worded until someone defines
'transactional', 'distributed', 'synchronous management systems' and
'asynchronous management systems'.

/js