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

[Gert Grammel]

Rob,

I think we are describing the same problem from a little different perspective:

Sent from my Apple ][

> On 16 Oct 2015, at 20:50, Robert Wilton  wrote:
> 
> Hi Gert,
> 
>> On 16/10/2015 18:14, Gert Grammel wrote:
>> Rob,
>> 
>> Current implementations are incomplete asynchronous, because they didn't 
>> verify the config as operational and applied.
>> 
>> What is frequently done is to perform additional checks on the intended 
>> config that go beyond a syntax check. That is fine, but I have a hard time 
>> to consider this to be "hybrid" which suggests something in between 
>> asynchronous and synchronous.
> I'm talking about netconf servers that effectively apply most of their 
> configuration before they reply.  E.g. they might take 10 minutes to reply.
> 
Exactly, that's why those servers are running asynchronously. The trouble is 
that in contrast to the synchronous operation there is no "done" information. 
Current implementations often try to work around that point by applying more 
than just a syntax check in the first phase. This way they are still quick in 
replying are more reliably responding, but still fail from time to time

> Perhaps this isn't a valid Netconf implementation, and all Netconf server 
> implementations are expected to be asynchronous w.r.t to when they apply 
> their configuration - but I can't see where this is stated in the NETCONF RFC 
> (but possibly I'm not looking in the right place).
> 
> 
>> 
>> >From a client perspective an asynchronous server and a hybrid server look 
>> >the same. The difference is that the asynchronous one should convey a 
>> >"finished" information to the client, while the hybrid would remain in a 
>> >"trust me babe" mode forever.
> Yes, but this isn't the only difference:
> - a client could expect that an asynchronous config operation response should 
> be reasonably expedient.
Agree, but this is true for hybrid and asynchronous and the term "reasonable" 
is not well defined.

>  E.g. if a client was to update 10 devices each with a reasonable size 
> configuration (that takes minutes to apply) in an asynchronous way then it 
> might reasonably consider sequencing the async config requests to each server 
> on one thread.  If each server acknowledged the requests in a couple of 
> seconds then all the servers would broadly end up applying the configuration 
> concurrently.
Yes, that's why we need asynchronous mode in the first place.
> - however, if the servers were hybrid, and their replies were sent much 
> closer to when the configuration was actually applied then initiating the 
> requests sequentially would effectively mean that the devices end up applying 
> the configuration serially which would end up taking much longer.  I.e. it 
> seems reasonable that a client may want to differentiate between the 
> behaviour of these two servers even if how it handles the resultant config 
> changes is the same.

It seems your definition of hybrid is something like "asynchronous but with a 
longer than reasonable response time".

This is similar to a bloated synchronous operation which takes too much time to 
respond.  Both cases are undesired and in both cases the solution is to make 
them truly asynchronous. So that we can have a reasonable response time. 

>> 
>> 
>> Another way to look at hybrids is to consider them "cheating synchronous". 
>> Given that the new config may not have been applied at the time of the 
>> response to the client. This is worse than the situation before where a 
>> missing verify lets the client know that something may still go on. Clients 
>> can't tell if servers are cheating :-)
> Yes, but clients also need to be able to determine if the server is likely to 
> be slow to response, because then the client would probably be designed to 
> interact with the server in a different fashion (e.g. use a pool of threads 
> to initiate the updates concurrently).

How would you do this in practice? Even servers don't know if they're likely to 
slow a response when they get a request. That's why a quick first response is 
required that assures the client the requests will be processed, followed by a 
potentially slow feedback that it is successfully executed (=verified) or 
failed.
> 
> Thanks,
> Rob
> 
> 
>> 
>> Gert
>> 
>> 
>> 
>> Sent from my Apple ][
>> 
>>> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
>>> 
>>> 
>>> 
 On 16/10/2015 14:59, Kent Watsen wrote:
 
>>> 3.  Support for both synchronous and asynchronous configuration
>>> operations
>>> 
>>> A. A server may choose to support only synchronous
>>> configuration
>>>operations, or only asynchronous configuration operations,
>>> or
>>>both synchronous and asynchronous configuration operations
>>> in
>>>a client specified per-operation basis.
>> I think the most common mode *today* is a mix of sync/async, on a
>> 

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

[Robert Wilton]

On 19/10/2015 13:18, Martin Bjorklund wrote:

Robert Wilton  wrote:

Hi Martin,

On 19/10/2015 12:06, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 16/10/2015 22:32, Kent Watsen wrote:

Will there ever be a server that operates in synchronous mode, given
that applied will not match intended if hardware is missing?

Will a client ever use "block" mode if it means that it might hang
forever (or at least until some hw is plugged in)?

I think the key is in the phrase "The server MUST fully *attempt* to
apply..."

+1.

So today we have this situation:


 intended operational
  config values
X--X
(time ->)


When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated.  Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.

The NMS/operator writes to intended config, ang verifies by checking
the operational state.


With applied config we have this situation:


 intended   applied   operational
  config config  values
X--X---X


In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.


With async/sync systems we now have:

attempted
 intendedapplied applied   operational
  config  config config  values
X---X--X---X
^
 this is when "block"
 would return
   To me it seems we're exposing another internal state to
   the
NMS/operator.  But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.

I see it slightly differently.

I think that "attempted applied config" is effectively the same time
point as "applied config" above.

But if I pre-configure an interface for which the hw is not present,
it has been said that this config will exist in intended but not in
applied.  And you said that you didn't want "block" to wait for the hw
to be present.  So the server will return before this data shows up in
applied.

My thinking is:

For a synchronous operation (with continue-on-error option):
 - the hw dependent config is updated to intended, probably an 
error/warning is returned for those leaves to indicate that it can't be 
applied because the hardware isn't present.
 - at some given point in the future, i.e. as a completely separate 
event, the hardware may be inserted and the intended config is applied 
at that time.


For a synchronous operation (with rollback-on-error option):
 - the configuration would fail because the hw isn't present (same 
errors/warnings returned as above) and hence the entire config operation 
is completely undone due to the rollback-on-error semantics.


Thanks,
Rob





As in the server has attempted to
apply all the configuration and for every it has either succeed,
failed, or can't be applied because the hardware isn't present.

Yes.


So using your time line above:
1. If you have an async config operation then the server returns at
time "intended config".
2. If you have a sync (blocking) config operation then the server
returns at time "applied config".
3. If you have an existing netconf config operation that is neither
explicitly sync nor async then the server may return at any time
between "intended config" and "applied config".

Sure.  My time line shows how the new value trickels down from
intended to oper.


/martin
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Martin,

Attempting to apply a config appears to me as a process, not a state. So in my 
mind the little drawing should look like this then:


receive   updated   Attempting to
intended  intended  apply intendedapplied   operational
configconfig configconfig  values
X--X-X---X
 ^
 this is when "block"
   would return



Gert

From: netmod > on 
behalf of Martin Bjorklund >
Date: Monday 19 October 2015 13:06
To: "rwil...@cisco.com" 
>
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous 
systems to provide a blocking config update?

Robert Wilton > wrote:
On 16/10/2015 22:32, Kent Watsen wrote:
>> Will there ever be a server that operates in synchronous mode, given
>> that applied will not match intended if hardware is missing?
>>
>> Will a client ever use "block" mode if it means that it might hang
>> forever (or at least until some hw is plugged in)?
> I think the key is in the phrase "The server MUST fully *attempt* to
> apply..."
+1.

So today we have this situation:

   intended operational
config values
  X--X
  (time ->)


When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated.  Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.

The NMS/operator writes to intended config, ang verifies by checking
the operational state.


With applied config we have this situation:


   intended   applied   operational
config config  values
  X--X---X


In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.


With async/sync systems we now have:

  attempted
   intendedapplied applied   operational
config  config config  values
  X---X--X---X
  ^
   this is when "block"
   would return



To me it seems we're exposing another internal state to the
NMS/operator.  But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

Hi Gert,

On 19/10/2015 09:06, Gert Grammel wrote:

Rob,

I think we are describing the same problem from a little different perspective:

Perhaps, but I'm not sure that we are on the same page yet.



Sent from my Apple ][


On 16 Oct 2015, at 20:50, Robert Wilton  wrote:

Hi Gert,


On 16/10/2015 18:14, Gert Grammel wrote:
Rob,

Current implementations are incomplete asynchronous, because they didn't verify 
the config as operational and applied.

What is frequently done is to perform additional checks on the intended config that go 
beyond a syntax check. That is fine, but I have a hard time to consider this to be 
"hybrid" which suggests something in between asynchronous and synchronous.

I'm talking about netconf servers that effectively apply most of their 
configuration before they reply.  E.g. they might take 10 minutes to reply.


Exactly, that's why those servers are running asynchronously. The trouble is that in 
contrast to the synchronous operation there is no "done" information. Current 
implementations often try to work around that point by applying more than just a syntax 
check in the first phase. This way they are still quick in replying are more reliably 
responding, but still fail from time to time
I don't follow why you think that these servers are running 
asynchronously.  They are much closer to handling all config operations 
as synchronous blocking calls.  This is a just a small amount of 
programming that is being performed asynchronously.






Perhaps this isn't a valid Netconf implementation, and all Netconf server 
implementations are expected to be asynchronous w.r.t to when they apply their 
configuration - but I can't see where this is stated in the NETCONF RFC (but 
possibly I'm not looking in the right place).



>From a client perspective an asynchronous server and a hybrid server look the same. The difference 
is that the asynchronous one should convey a "finished" information to the client, while the 
hybrid would remain in a "trust me babe" mode forever.

Yes, but this isn't the only difference:
- a client could expect that an asynchronous config operation response should 
be reasonably expedient.

Agree, but this is true for hybrid and asynchronous and the term "reasonable" 
is not well defined.
This is true for asynchronous but not hybrid, since a hybrid operation 
might return just before a proper synchronous operation would.





  E.g. if a client was to update 10 devices each with a reasonable size 
configuration (that takes minutes to apply) in an asynchronous way then it 
might reasonably consider sequencing the async config requests to each server 
on one thread.  If each server acknowledged the requests in a couple of seconds 
then all the servers would broadly end up applying the configuration 
concurrently.

Yes, that's why we need asynchronous mode in the first place.

- however, if the servers were hybrid, and their replies were sent much closer 
to when the configuration was actually applied then initiating the requests 
sequentially would effectively mean that the devices end up applying the 
configuration serially which would end up taking much longer.  I.e. it seems 
reasonable that a client may want to differentiate between the behaviour of 
these two servers even if how it handles the resultant config changes is the 
same.

It seems your definition of hybrid is something like "asynchronous but with a longer 
than reasonable response time".
My definition of hybrid (i.e. the default existing netconf config 
operations) is along the lines of "asynchronous in behaviour, but may 
reply any time between when the intended configuration has been updated 
and the applied configuration has been completely updated ".




This is similar to a bloated synchronous operation which takes too much time to 
respond.  Both cases are undesired and in both cases the solution is to make 
them truly asynchronous. So that we can have a reasonable response time.
I agree with the goal, but it may be difficult to change some existing 
NETCONF operational handling to be either strictly sync or async.


  



Another way to look at hybrids is to consider them "cheating synchronous". 
Given that the new config may not have been applied at the time of the response to the 
client. This is worse than the situation before where a missing verify lets the client 
know that something may still go on. Clients can't tell if servers are cheating :-)

Yes, but clients also need to be able to determine if the server is likely to 
be slow to response, because then the client would probably be designed to 
interact with the server in a different fashion (e.g. use a pool of threads to 
initiate the updates concurrently).

How would you do this in practice?

Roughly, I would suggest:

Assuming that this is going to be a new optional to implement extension:
 - There would be a capability to indicate whether a server supports an 
explicit sync config operation.
 - There 

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Oct 15, 2015 at 09:52:00AM +0200, Ladislav Lhotka wrote:
>
> [...]
>  
>> The "schema" part addresses syntactic changes in protocol messages,
>> which are inevitable, and the second part is about risky
>> annotations. I agree evil annotations should be banned but I am not
>> sure we can find a satisfactory formulation. Do you have any
>> suggestion?
>
> Perhaps the simples solution is to remove the first sentence in order
> to avoid having 'schema' understood in different ways. (I personally
> believe an annotation MUST NOT change data model semantics but lets
> try to find a compromise.) So my proposal is to replace the entire
> paragraph with:
>
>Due care has to be exercised when introducing annotations in network
>management systems in order to avoid interoperability problems and
>software failures.  The following aspects should be taken into
>account:

I am fine with this. In a parallel thread I proposed to extend YANG spec
with a general permission for instance data and protocol messages to
include annotations (in any encoding). This would help to make sure that
compliant parsers won't choke on XML attributes or JSON objects whose
names start with "@".

Would this be acceptable?

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: Re: Order of evaluation for when?

[Ladislav Lhotka]

Xiang Li  writes:

> On 10/18/2015 8:31 AM, Ladislav Lhotka wrote:
>> Xiang Li  writes:
>>
>>> On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
> On 16 Oct 2015, at 12:27, Balazs Lengyel  
> wrote:
>
> IMHO YANG should define the behavoir, and I would want it to be the same 
> on Netconf/Restconf/CLI etc.
> I agree that " 1) you get an error back" would be the best: because it is 
> the easiest to understand for the operator, with the fewest corner cases.
> Also we must define if in the same transaction we set b=42 and a=2. which 
> of the 3 options are taken?
>
>
> We should not leave such complex cases undefined, or alternatively state 
> that they are implementation dependant.
 I might be difficult to say what is a complex case, unless we abandon 
 XPath in "when" statements and use something else - and considerably 
 simpler.

 Here is another interesting corner case - does it qualify as being complex?

 leaf-list bar {
  type uint8;
  when "count(../*) > 1";
 }
 leaf foo {
  type uint8;
 }
>>> Interesting example...
>>>
 Assuming no instances exist, is this edit allowed? (This was essentially 
 your question.)

 1
 2
>>> I think this should succeed
>>>
 But what about this?

 1
 2

>>> I think this should succeed too because the when is satisfied in the
>>> data store after the edit-config.
>>>
>> According to the third bullet in sec. 7.21.5 of 6020bis, a validating
>> algorithm has to remove the existing "bar" instances, add a dummy
>> instance and then evaluate the XPath expression. If the result is true,
>> the existing "bar" instances will be put back, otherwise a validation
>> error will be reported - so in our case we will have only one "bar" node,
>> which is invalid.
>
>
> Thanks  you are right. I missed that...
>
>>
>> The result of this change is that we (hopefully) made the processing of
>> "when" well-defined and unambiguous, but the cost in increased comlexity
>> is quite high - both for module readers and implementors of a validating
>> algorithm.
> yes the clarification in  sec. 7.21.5 of 6020bis   does make this clearer.
>
>> In fact, when we discussed issue Y18, my understanding was that dummy
>> node manipulations will be used only if the context node is missing.

> This is something that actually still confuses me!  If a context node
> exists why we still need to replace it with a dummy node, especially
> if an edit-config is performing a "merge" operation?

This is indeed rather confusing. I think the idea was to use this
procedure instead of stating that a "when" expression must not refer to
any children of its context node - the procedure removes them so the
result of evaluating the XPath expression is always the same no matter
what's the subtree of the context node actually contains.

However, the result can be that what's then in the data tree apparently
violates the "when" expression. 

Lada

>
> -Xiang Li
>
>
>
>> Lada
>>
>>>
>>> -Xiang Li
>>>
>>>
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

Hi Randy,

Thanks for the comments.

On 17/10/2015 04:29, Randy Presuhn wrote:

Hi -


From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous 
systems to provide a blocking config update?

...

Here is my attempt at word smithing section 3:

...

 A. A server may choose to support only synchronous configuration
operations, or only asynchronous configuration operations, or
both synchronous and asynchronous configuration operations in
a client specified per-operation basis.

Editorial comments:
   - is the "may" intended as a RFC 2119 MAY?  If so, this seems
 a semantically inappropriate use of the keyword.

No, I don't think that is intended as an RFC 2119 MAY.


   - please avoid unnecessary anthropomorphisms; the server doesn't
 "choose" anything here.
   - s/ in/ on/
   - s/client specified/client-specified/

All three fixed.

Proposed updated text for 3.A:

   A. A server may support only synchronous configuration
  operations, or only asynchronous configuration operations, or
  both synchronous and asynchronous configuration operations on
  a client-specified per-operation basis.



...

  failed.  A configuration protocol, or server, SHOULD provide
  support for rollback-on-error behavior and MAY choose to
  provide support for best effort semantics as well.

Editorial comments:

   - The implications of the RFC 2119 SHOULD and MAY are quite different
 depending on which of the two subjects ("protocol" or "server") one
 chooses to think about.  The server's observable behaviour is presumably
 circumscribed by the protocol, so I suggest removing ", or server,".

   - Please suppress anthropomorphisms.

   - s/best effort/best-effort/
I had reworded 3.D based on Gert's comments.  Folding in your comments 
above to that text produces:


   D. The configuration protocol MUST specify how configuration
  errors are handled.  Errors could be handled by "stop-on-error",
  "continue-on-error" or "rollback-on-error" semantics (see
  terms).  Support for "rollback-on-error" SHOULD be provided.


 Extra term to add the definitions (based on the definitions for 
NETCONF RFC):


  stop-on-error:  The configuration operation is aborted on the 
first

error.

 continue-on-error:  Continue to process configuration data on
error; error is recorded, and negative response is generated
if any errors occur.

 rollback-on-error:  If an error condition occurs such that part
of applying the configuration fails, the server will stop
processing the configuration operation and restore the
specified configuration to its complete state at the start
of this configuration operation.

Thanks,
Rob



Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

Hi Kent, Gert,

For clarity, the text that I had reached for 3 (folding in the comments 
so far) is this:


   3.  Support for both synchronous and asynchronous configuration
   operations (see terms)

   A. A server may support only synchronous configuration
  operations, or only asynchronous configuration operations, or
  both synchronous and asynchronous configuration operations on
  a client-specified per-operation basis.

   B. Servers that support asynchronous configuration operations MAY
  also provide a verify operation that a client can request from
  the server to return information regarding the difference
  between the intended and applied configurations.

   C. The configuration protocol MUST specify how configuration
  errors are handled.  Errors may be handled by "stop on error",
  "continue on error" or "rollback on error" semantics (see
  terms).  Support for "rollback on error" SHOULD be provided.


 Extra terms to add the definitions section (based on the definitions 
for NETCONF RFC):


  stop-on-error:  The configuration operation is aborted on the 
first

error.

 continue-on-error:  Continue to process configuration data on
error; error is recorded, and negative response is generated
if any errors occur.

 rollback-on-error:  If an error condition occurs such that part
of applying the configuration fails, the server will stop
processing the configuration operation and restore the
specified configuration to its complete state at the start
of this configuration operation.


Gert has provided some definitions that are closer to Kent's original 
text, how do we resolve?


Thanks,
Rob


On 19/10/2015 14:22, Kent Watsen wrote:

I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:


Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent


On 10/16/15, 11:29 PM, "Randy Presuhn" 
wrote:


Hi -


From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
asynchronous systems to provide a blocking config update?

...

Here is my attempt at word smithing section 3:

...

 A. A server may choose to support only synchronous
configuration
operations, or only asynchronous configuration
operations, or
both synchronous and asynchronous configuration
operations in
a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
"choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...

  failed.  A configuration protocol, or server, SHOULD provide
  support for rollback-on-error behavior and MAY choose to
  provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
depending on which of the two subjects ("protocol" or "server") one
chooses to think about.  The server's observable behaviour is
presumably
circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Hi Rob,

From: Robert Wilton >
Date: Monday 19 October 2015 14:25
To: Gert Grammel >
Cc: Kent Watsen >, Martin 
Bjorklund >, 
"netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous 
systems to provide a blocking config update?

Hi Gert,

On 19/10/2015 09:06, Gert Grammel wrote:
Rob,

I think we are describing the same problem from a little different perspective:
Perhaps, but I'm not sure that we are on the same page yet.
Didn’t claim that we’d be on the same page, but at least we appear to look at 
the same problem.

Sent from my Apple ][

On 16 Oct 2015, at 20:50, Robert Wilton 
> wrote:

Hi Gert,

On 16/10/2015 18:14, Gert Grammel wrote:
Rob,

Current implementations are incomplete asynchronous, because they didn't verify 
the config as operational and applied.

What is frequently done is to perform additional checks on the intended config 
that go beyond a syntax check. That is fine, but I have a hard time to consider 
this to be "hybrid" which suggests something in between asynchronous and 
synchronous.
I'm talking about netconf servers that effectively apply most of their 
configuration before they reply.  E.g. they might take 10 minutes to reply.

Exactly, that's why those servers are running asynchronously. The trouble is 
that in contrast to the synchronous operation there is no "done" information. 
Current implementations often try to work around that point by applying more 
than just a syntax check in the first phase. This way they are still quick in 
replying are more reliably responding, but still fail from time to time
I don't follow why you think that these servers are running
asynchronously.  They are much closer to handling all config operations
as synchronous blocking calls.  This is a just a small amount of
programming that is being performed asynchronously.

If a configuration would only take some second or so, everyone would probably 
be happy to apply synchronous config. Asynchronous config come in, when the 
server would need a long time to apply the config or if the time is 
unpredictable. So when we talk about a config that needs 10 min to be applied, 
I would consider a synchronous configuration the wrong design choice to start 
with. A server should reply shortly after receiving the intended config to 
indicate that they are accepting the config and after e.g. 9:59 minutes come 
back with an information that the config has successfully been applied. If you 
mix both information into one you either create a black hole in the beginning 
of the process (request an intended config and getting feedback 10min after) or 
you end up with a grey hole in the end where you know the server is working on 
it but have no idea when it has finished, so that you can reasonably expect an 
operational state in line with your config.


Perhaps this isn't a valid Netconf implementation, and all Netconf server 
implementations are expected to be asynchronous w.r.t to when they apply their 
configuration - but I can't see where this is stated in the NETCONF RFC (but 
possibly I'm not looking in the right place).


>From a client perspective an asynchronous server and a hybrid server look the 
>same. The difference is that the asynchronous one should convey a "finished" 
>information to the client, while the hybrid would remain in a "trust me babe" 
>mode forever.
Yes, but this isn't the only difference:
- a client could expect that an asynchronous config operation response should 
be reasonably expedient.
Agree, but this is true for hybrid and asynchronous and the term "reasonable" 
is not well defined.
This is true for asynchronous but not hybrid, since a hybrid operation
might return just before a proper synchronous operation would.

What is the level of information the client has before and after this ‘return’? 
Before the return, it doesn’t know if the config is being processed, and after 
the return it doesn’t know if it has been applied. Just like asynchronous.



   E.g. if a client was to update 10 devices each with a reasonable size 
configuration (that takes minutes to apply) in an asynchronous way then it 
might reasonably consider sequencing the async config requests to each server 
on one thread.  If each server acknowledged the requests in a couple of seconds 
then all the servers would broadly end up applying the configuration 
concurrently.
Yes, that's why we need asynchronous mode in the first place.
- however, if the servers were hybrid, and their replies were sent much closer 
to when the configuration was actually applied then initiating the requests 
sequentially would effectively mean that the devices end up applying the 
configuration serially which 

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

[Kent Watsen]

I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:

>Hi Rob,
>
>I know there is an on-going discussion about the time-line of things, but
>the draft needs to be posted today...  Can you help finalize the text?
>
>Randy offers some good editorial suggestions below, and I believe you and
>Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>
>Thanks,
>Kent
>
>
>On 10/16/15, 11:29 PM, "Randy Presuhn" 
>wrote:
>
>>Hi -
>>
>>> From: Robert Wilton
>>> Sent: Oct 16, 2015 5:12 AM
>>> To: Kent Watsen , Nadeau Thomas
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>asynchronous systems to provide a blocking config update?
>>...
>>>Here is my attempt at word smithing section 3:
>>...
>>> A. A server may choose to support only synchronous
>>>configuration
>>>operations, or only asynchronous configuration
>>>operations, or
>>>both synchronous and asynchronous configuration
>>>operations in
>>>a client specified per-operation basis.
>>
>>Editorial comments:
>>  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>a semantically inappropriate use of the keyword.
>>  - please avoid unnecessary anthropomorphisms; the server doesn't
>>"choose" anything here.
>>  - s/ in/ on/
>>  - s/client specified/client-specified/
>>
>>...
>>>  failed.  A configuration protocol, or server, SHOULD provide
>>>  support for rollback-on-error behavior and MAY choose to
>>>  provide support for best effort semantics as well.
>>
>>Editorial comments:
>>
>>  - The implications of the RFC 2119 SHOULD and MAY are quite different
>>depending on which of the two subjects ("protocol" or "server") one
>>chooses to think about.  The server's observable behaviour is
>>presumably
>>circumscribed by the protocol, so I suggest removing ", or server,".
>>
>>  - Please suppress anthropomorphisms.
>>
>>  - s/best effort/best-effort/
>>
>>Randy
>>
>>___
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Hi Kent,

Here my proposals

   3.  Support for both synchronous and asynchronous configuration
   operations (see terms)

   A. A server may only support synchronous configuration
  operations, or may only support asynchronous configuration
  operations, or may support synchronicity to be client
  specified on a per-operation basis.

NEW   A. The way a server executes an operation (synchronous or asynchronous) 
is implementation specific and may change on a per-operation basis.

   C. Support for synchronous configuration operations
  requires the server to block sending a response to
  the client until it is able to able to determine whether
  there are any errors in the request or errors from
  applying the configuration change.

NEW (changed OR into AND)
   C. Support for synchronous configuration operations
  requires the server to block sending a response to
  the client until it is able to able to determine whether
  there are any errors in the request and errors from
  applying the configuration change.

OK
   D. Support for asynchronous configuration operations
  requires the server to send a response to the client
  immediately indicated that the request was accepted
  and send a notification to the client when the intended
  config is fully effective or there are any errors from
  applying the configuration change.
OK
   E. Support for asynchronous configuration operations MAY
  also provide a verify operation which a client can request
  from the server to obtain information regarding the
  difference between the intended and applied configurations.










From: netmod > on 
behalf of Kent Watsen >
Date: Monday 19 October 2015 15:22
To: Kent Watsen >, Robert 
Wilton >
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous 
systems to provide a blocking config update?


I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent


On 10/19/15, 9:14 AM, "Kent Watsen" 
> wrote:

Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent


On 10/16/15, 11:29 PM, "Randy Presuhn" 
>
wrote:

Hi -

From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
asynchronous systems to provide a blocking config update?
...
Here is my attempt at word smithing section 3:
...
 A. A server may choose to support only synchronous
configuration
operations, or only asynchronous configuration
operations, or
both synchronous and asynchronous configuration
operations in
a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
"choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
  failed.  A configuration protocol, or server, SHOULD provide
  support for rollback-on-error behavior and MAY choose to
  provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
depending on which of the two subjects ("protocol" or "server") one
chooses to think about.  The server's observable behaviour is
presumably
circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org

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

[Kent Watsen]

OK, it looks like we converged.  Thank you all.
I will use the text below for the draft.

Kent   // with editor hat on  ;)



On 10/19/15, 9:52 AM, "Robert Wilton"  wrote:

>Hi Kent, Gert,
>
>For clarity, the text that I had reached for 3 (folding in the comments
>so far) is this:
>
>3.  Support for both synchronous and asynchronous configuration
>operations (see terms)
>
>A. A server may support only synchronous configuration
>   operations, or only asynchronous configuration operations, or
>   both synchronous and asynchronous configuration operations on
>   a client-specified per-operation basis.
>
>B. Servers that support asynchronous configuration operations MAY
>   also provide a verify operation that a client can request from
>   the server to return information regarding the difference
>   between the intended and applied configurations.
>
>C. The configuration protocol MUST specify how configuration
>   errors are handled.  Errors may be handled by "stop on error",
>   "continue on error" or "rollback on error" semantics (see
>   terms).  Support for "rollback on error" SHOULD be provided.
>
>
>  Extra terms to add the definitions section (based on the definitions
>for NETCONF RFC):
>
>   stop-on-error:  The configuration operation is aborted on the
>first
> error.
>
>  continue-on-error:  Continue to process configuration data on
> error; error is recorded, and negative response is generated
> if any errors occur.
>
>  rollback-on-error:  If an error condition occurs such that part
> of applying the configuration fails, the server will stop
> processing the configuration operation and restore the
> specified configuration to its complete state at the start
> of this configuration operation.
>
>
>Gert has provided some definitions that are closer to Kent's original
>text, how do we resolve?
>
>Thanks,
>Rob
>
>
>On 19/10/2015 14:22, Kent Watsen wrote:
>> I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
>> change the 1.D text to..."
>>
>> Sorry for the confusion.
>>
>> Kent
>>
>>
>> On 10/19/15, 9:14 AM, "Kent Watsen"  wrote:
>>
>>> Hi Rob,
>>>
>>> I know there is an on-going discussion about the time-line of things,
>>>but
>>> the draft needs to be posted today...  Can you help finalize the text?
>>>
>>> Randy offers some good editorial suggestions below, and I believe you
>>>and
>>> Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>> On 10/16/15, 11:29 PM, "Randy Presuhn" 
>>> wrote:
>>>
 Hi -

> From: Robert Wilton
> Sent: Oct 16, 2015 5:12 AM
> To: Kent Watsen , Nadeau Thomas
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
> asynchronous systems to provide a blocking config update?
 ...
> Here is my attempt at word smithing section 3:
 ...
>  A. A server may choose to support only synchronous
> configuration
> operations, or only asynchronous configuration
> operations, or
> both synchronous and asynchronous configuration
> operations in
> a client specified per-operation basis.
 Editorial comments:
   - is the "may" intended as a RFC 2119 MAY?  If so, this seems
 a semantically inappropriate use of the keyword.
   - please avoid unnecessary anthropomorphisms; the server doesn't
 "choose" anything here.
   - s/ in/ on/
   - s/client specified/client-specified/

 ...
>   failed.  A configuration protocol, or server, SHOULD
>provide
>   support for rollback-on-error behavior and MAY choose to
>   provide support for best effort semantics as well.
 Editorial comments:

   - The implications of the RFC 2119 SHOULD and MAY are quite
different
 depending on which of the two subjects ("protocol" or "server")
one
 chooses to think about.  The server's observable behaviour is
 presumably
 circumscribed by the protocol, so I suggest removing ", or
server,".

   - Please suppress anthropomorphisms.

   - s/best effort/best-effort/

 Randy

 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-acl-model-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group 
of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Dean Bogdanovic
  Kiran Agrahara Sreenivasa
  Lisa Huang
  Dana Blair
Filename: draft-ietf-netmod-acl-model-04.txt
Pages   : 28
Date: 2015-10-17

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

[Gert Grammel]

+1
Gert 

Sent from my Apple ][

> On 19 Oct 2015, at 18:10, Kent Watsen  wrote:
> 
> 
> All,
> 
> This issue somewhat dropped from our radar - we didn't discuss it during
> the interim or since.  Nonetheless, my interpretation of the below thread
> is that Robert's proposal was accepted.  So I'm going to replace 1.D with
> the text below (albeit s/system/server/) and move this issue to the REVIEW
> state.
> 
> Thanks,
> Kent
> 
> 
> 
>> On 10/14/15, 2:08 PM, "Kent Watsen"  wrote:
>> 
>> 
>> The new 1-D works for me.  It is similar in spirit to the proposal I just
>> sent in the issue #4 thread.
>> 
>> Thanks,
>> Kent
>> 
>> 
>>> On 10/13/15, 9:14 AM, "Robert Wilton"  wrote:
>>> 
>>> In an attempt to try and close on some of the proposed requirement text
>>> before Thursday's interim meeting.
>>> 
>>> Does anyone have any outstanding objections on using this proposed text
>>> for Requirement 1.D, or is it sufficiently clear to update the draft,
>>> and resolve issue 1?
>>> 
>>> OLD text for Requirement 1:
>>> 
>>>   1.  Ability to interact with both intended and applied configuration
>>> 
>>>   A.  The ability to ask the operational components of a system
>>>   (e.g., line cards) for the configuration that they are
>>>   currently using.  This is the "applied configuration".
>>> 
>>>   B.  Applied configuration is read-only
>>> 
>>>   C.  The data model for the applied configuration is the same as
>>>   the data model for the intended configuration (same leaves)
>>> 
>>>   D.  For asynchronous systems, when fully synchronized, the data
>>>   in the applied configuration is the same as the data in the
>>>   intended configuration.
>>> 
>>> 
>>> NEW text (as above, changing 1.D only):
>>> 
>>>   1.  Ability to interact with both intended and applied configuration
>>> 
>>>   A.  The ability to ask the operational components of a system
>>>   (e.g., line cards) for the configuration that they are
>>>   currently using.  This is the "applied configuration".
>>> 
>>>   B.  Applied configuration is read-only
>>> 
>>>   C.  The data model for the applied configuration is the same as
>>>   the data model for the intended configuration (same leaves)
>>> 
>>>   D.  When the configuration change for any intended configuration
>>>   node has been successfully applied to the system (e.g. not
>>>   failed, nor deferred due to absent hardware) then the
>>>   existence and value of the corresponding applied
>>>   configuration node must match the intended configuration
>>>   node.
>>> 
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
 On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
>>> Hi Kent,
>>> 
 On 06/10/2015 01:40, Kent Watsen wrote:
 This issue appears to have become more like issue #5 ­ should we
 mark
 this one a duplicate of the other?
>>> I suggest that we can just finalize on the text being discussed to
>>> replace 1.D and then resolve issue #1.
>>> 
>>> Jason had proposed this text:
>>> 
>>> When the configuration change for any intended configuration node
>>> has
>>> been successfully applied to the system (e.g. not failed, nor
>>> deferred
>>> due to absent hardware) then the existence and value of the applied
>>> equivalent of the node (whether that be a corresponding node in the
>>> data
>>> model, an attribute associated with the intended config node, the
>>> configuration node read from a different datastore or context, etc)
>>> must
>>> match the intended configuration node.
>> I have no clue what "an attribute associated with the intended config
>> node" or "the configuration node read from a different datastore or
>> context" or "etc". means. What exactly is an "applied equivalent of
>> the node"?
>> 
>>> Or perhaps this slightly briefer alternative is better?:
>>> 
>>> D.  When the configuration change for any intended
>>> configuration node has been successfully applied to the
>>> system (e.g. not failed, nor deferred due to absent
>>> hardware)
>>> then the existence and value of the corresponding,
>>> possibly
>>> notional, applied configuration node must match the
>>> intended
>>> configuration node.
>> What is the purpose of the phrase "possibly notional"?
> There was a concern that my previous text, i.e. as above but without
> "possibly notional", implied that applied configuration had to be
> actually represented as real data nodes in a YANG 

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-00.txt

[Kent Watsen]

This draft has been posted as a WG draft (i.e. s/chairs/ietf/).

Thank you everyone for the time it's taken to bring it to this state.

Moving forwards, please don't wait to post comments.   That is, it's okay
to continue the discussion before the meeting in Yokohama.  We will open
new issues on the GitHub issue tracker as needed.

Thanks again,
Kent


On 10/19/15, 1:07 PM, "internet-dra...@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the NETCONF Data Modeling Language Working
>Group of the IETF.
>
>Title   : NETMOD Operational State Requirements
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-00.txt
>   Pages   : 8
>   Date: 2015-10-19
>
>Abstract:
>   This document defines requirements for servers enabling better
>   visibility and control over the server's operational state.  To
>   achieve this end, this document also defines terminology describing a
>   conceptual model enabling the requirements to be expressed.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod