Subject: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 17:07:21 +0200

Hi,

just to make sure everybody here has seen this.

/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/>

Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Mon, 29 Jun 2015 07:58:22 -0700
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>

The IESG has received a request from an individual submitter to consider
the following document:
- 'Time Capability in NETCONF'
  <draft-mm-netconf-time-capability-05.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-07-29. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a capability-based extension to the Network
   Configuration Protocol (NETCONF) that allows time-triggered
   configuration and management operations. This extension allows
   NETCONF clients to invoke configuration updates according to
   scheduled times, and allows NETCONF servers to attach timestamps to
   the data they send to NETCONF clients.

The Network Configuration Protocol (NETCONF) Capability URNs registry 
requires a standards action in order to populate the registry. This document 
was taken out of the ISE stream and brought forward as an AD sponsored 
individual-submission to address this consideration.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 10:27:03 -0700

Hi,

Is this an AD-sponsored draft?

This draft was "interesting" but not enough to be prioritized ahead
of other work being done in the NETCONF WG.

The draft mixes server measurement of RPC execution time
with a "cron" function.  The rationale for this grab-bag of
time-related functionality is not entirely clear.

This work does not have any consensus within the NETCONF WG.
It does seem a little surprising that it is being published without
even asking the NETCONF WG for comments.

I don't have any problem with Experimental RFCs as long as it
is clear this is not a product of the NETCONF WG.

Andy

On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> ---------- Forwarded message ----------
> Cc:
> Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time
> Capability in NETCONF) to Experimental RFC
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 19:54:38 +0200

Technically, I believe the solution is not really desirable. Figure 4
says you send an RPC and then wait potentially days or weeks for a
matching RPC reply and in between you get notifications (which travel
over a very different communication channel). But yeah, let people
experiment with this if they want to.

What I do not get is why this idea requires to get an entry in the
capabilities registry and thus is AD sponsored. I do not think that
NETCONF requires that experimental capabilities need to be registered
with IANA.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 29 Jun 2015 18:08:23 +0000

I believe that you should make your (Juergen's, Andy's) concerns known to the IETF mail list. This being an AD-sponsored I-D that seems to be the place to comment. 

Regards,

Dan

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Monday, June 29, 2015 8:55 PM
> To: Andy Bierman
> Cc: Netconf
> Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-
> capability-05.txt> (Time Capability in NETCONF) to Experimental RFC
> 
> Technically, I believe the solution is not really desirable. Figure 4 says you
> send an RPC and then wait potentially days or weeks for a matching RPC
> reply and in between you get notifications (which travel over a very different
> communication channel). But yeah, let people experiment with this if they
> want to.
> 
> What I do not get is why this idea requires to get an entry in the capabilities
> registry and thus is AD sponsored. I do not think that NETCONF requires that
> experimental capabilities need to be registered with IANA.
> 
> /js
> 
> > This draft was "interesting" but not enough to be prioritized ahead of
> > other work being done in the NETCONF WG.
> >
> > The draft mixes server measurement of RPC execution time with a "cron"
> > function.  The rationale for this grab-bag of time-related
> > functionality is not entirely clear.
> >
> > I don't have any problem with Experimental RFCs as long as it is clear
> > this is not a product of the NETCONF WG.
> >
> >
> >
> > Andy
> >
> >
> >
> > > Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo-
> EKyD24gL4IKoQu5XOXa5aeKohufY&s=YOeonUh8hkmY4VdCwSpkZk593aUNn
> haxHAeGUDKyUV0&e= >
> > >
> > >
> > > The IESG has received a request from an individual submitter to
> > > consider the following document:
> > > The IESG plans to make a decision in the next few weeks, and
> > > solicits final comments on this action. Please send substantive
> > > comments to the [email-masked] mailing lists by 2015-07-29.
> > > Exceptionally, comments may be sent to [email-masked] instead. In
> > > either case, please retain the beginning of the Subject line to allow
> automated sorting.
> > >
> > > Abstract
> > >
> > >
> > > The Network Configuration Protocol (NETCONF) Capability URNs
> > > registry requires a standards action in order to populate the
> > > registry. This document was taken out of the ISE stream and brought
> > > forward as an AD sponsored individual-submission to address this
> > > consideration.
> > >
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > > f.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
> 2Dcapability_&d=AwICAg&c=BFpWQ
> > >
> w8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&
> m=Q8
> > > 7IdLt8nKswJo-
> EKyD24gL4IKoQu5XOXa5aeKohufY&s=xXpTwBGoKzQwCICBcvA-IOLm
> > > fEd8emgt7EGVyAmzJ2s&e=
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > > f.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
> 2Dcapability_ballot_&d=AwICAg&
> > >
> c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrp
> hpBs
> > > FA&m=Q87IdLt8nKswJo-
> EKyD24gL4IKoQu5XOXa5aeKohufY&s=5XcQnG3n5R4D-qUiv
> > > 2DD-r67mQdOk39an9qW5Eb86Z8&e=
> > >
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_ma
> > >
> ilman_listinfo_netconf&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGx
> R31
> > > OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo-
> EKyD24gL4IKoQu5X
> > > OXa5aeKohufY&s=1RLb-
> m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e=
> > >
> > >
> 
> --
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87IdLt8nKswJo-
> EKyD24gL4IKoQu5XOXa5aeKohufY&s=YOeonUh8hkmY4VdCwSpkZk593aUNn
> haxHAeGUDKyUV0&e= >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netconf&d=AwICAg&c=BFpWQw8bsu
> Kpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Q87I
> dLt8nKswJo-EKyD24gL4IKoQu5XOXa5aeKohufY&s=1RLb-
> m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e=

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 29 Jun 2015 18:24:36 +0000

Hi Jürgen,

Thanks for the feedback.

> Figure 4 says you send an RPC and then wait potentially days or weeks for a matching RPC reply and in between you get notifications

For this reason (and others), the draft specifies that the time capability is intended for *near future* scheduling (see Section 3.6). Note that the default of the sched-max-future parameter is 15 seconds.

Cheers,
Tal.

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, June 29, 2015 8:55 PM
To: Andy Bierman
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Technically, I believe the solution is not really desirable. Figure 4 says you send an RPC and then wait potentially days or weeks for a matching RPC reply and in between you get notifications (which travel over a very different communication channel). But yeah, let people experiment with this if they want to.

What I do not get is why this idea requires to get an entry in the capabilities registry and thus is AD sponsored. I do not think that NETCONF requires that experimental capabilities need to be registered with IANA.

/js

On Mon, Jun 29, 2015 at 10:27:03AM -0700, Andy Bierman wrote:
> > either case, please retain the beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 29 Jun 2015 18:53:03 +0000

Hi Andy,

Thanks for the comments.

>time-related functionality is not entirely clear.

One of the most notable use cases is a network-wide commit. The time capability (using scheduled commits and cancel-schedule) allows a client to perform a network-wide commit in N servers, where either all perform the commit, or none of them does. Such behavior is not currently possible with confirmed commits (RFC6241); when using confirmed commits, if something goes wrong, then all the servers roll back to the previous configuration, which means that there is a (potentially long) transient state where some servers have changed their configuration and others have not.
The time capability allows the client to cancel the commit in advance: if one of the servers indicates it cannot perform the commit (using an error message), then the client sends a cancellation message to all the servers before the commit has occurred. All the servers consistently use the same datastore throughout the procedure.

The execution-time parameter allows the client to receive feedback about the actual execution time of the RPC. Based on this feedback the client: (1) knows how accurately the server scheduled the RPC, and (2) has a (rough) picture of whether the server’s clock is synchronized to its own (see Section 3.3 for further discussion).

We presented a few use-cases at the IETF meeting in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf), and the Dallas presentation (https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf), which was not presented due to lack of time, included the network-wide commit use case.

Cheers,
Tal.

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Monday, June 29, 2015 8:27 PM
To: Juergen Schoenwaelder; Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Hi,

Andy

On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

/js

---------- Forwarded message ----------
From: The IESG <[email-masked]<mailto:[email-masked]>>
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Mon, 29 Jun 2015 07:58:22 -0700
Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2015-07-29. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Jun 2015 21:03:32 +0200

> The time capability allows the client to cancel the commit in advance: if one of the servers indicates it cannot perform the commit (using an error message), then the client sends a cancellation me…

I am not sure I fully see the difference / advantage. With plain NC,
you can push changes into the candidate datastore and you can validate
that all the changes are valid regarding the data model(s). Then you
start the commit itself. Servers roll back the commit if the commit
fails. They also roll back in case the management system does not send
the confirming commit. (This includes that case where the commit locks
out the management system.)

You seem to schedule the commits to happen all at the same time
(assuming some reasonable time synchronization). Good. But if one out
of the several commits now fails, how do you recover from that? And
how is the recovery better than NC with confirmed-commit?

You seem to be talking about the idea that manager wants to abort the
scheduled commit. This does not exist in NC with confirmed-commit,
except that the manager can simply stop invoking commits if it changes
its mind spontaneously.

Perhaps both approaches simply try to optimize for different kinds of
commit failures.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 12:05:03 -0700

On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi <[email-masked]> wrote:

> One of the most notable use cases is a network-wide commit. The time
> capability (using scheduled commits and cancel-schedule) allows a client to
> perform a network-wide commit in N servers, where either all perform the
> commit, or none of them does. Such behavior is not currently possible with
> confirmed commits (RFC6241); when using confirmed commits, if something
> goes wrong, then all the servers roll back to the previous configuration,
> which means that there is a (potentially long) transient state where some
> servers have changed their configuration and others have not.
>
> The time capability allows the client to cancel the commit in advance: if
> one of the servers indicates it cannot perform the commit (using an error
> message), then the client sends a cancellation message to all the servers
> before the commit has occurred. All the servers consistently use the same
> datastore throughout the procedure.
>
>
>

Actually, RFC 6241 confirmed-commit has a <cancel-commit> operation
so it can operate the same way (client send cancel to N-1 servers when
1 server returns a commit-failed error)

>  The execution-time parameter allows the client to receive feedback about
> the actual execution time of the RPC. Based on this feedback the client:
> (1) knows how accurately the server scheduled the RPC, and (2) has a
> (rough) picture of whether the server’s clock is synchronized to its own
> (see Section 3.3 for further discussion).
>
>
>

This assumes that the load on the system at the time of the RPC
execution is somewhat known and stable. I am talking about
the elapsed time measurement.

The cleint can check the server's time-of-day just by
reading the current-date-time object.  It does not need
executed-at timestamps to check that the clocks are in synch.

>  We presented a few use-cases at the IETF meeting in Berlin (
> http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf), and
> the Dallas presentation (
> https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf),
> which was not presented due to lack of time, included the network-wide
> commit use case.
>
>
>
> Cheers,
>
> Tal.
>
>
>

Andy

>  *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Monday, June 29, 2015 8:27 PM
> *To:* Juergen Schoenwaelder; Netconf
> *Subject:* Re: [Netconf] [FOWARDING] Last Call:
> <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to
> Experimental RFC
>
>
>
> Hi,
>
>
>
>
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 29 Jun 2015 20:19:28 +0000

Andy, Jürgen,

Thanks for the prompt responses.

>1 server returns a commit-failed error)

Indeed, but the <cancel-commit> is applied only after the commit was already performed, meaning that now the server has to roll back.
The <cancel-schedule> operation lets you cancel the commit before it has occurred, allowing all servers to remain with the current configuration. See the example below.

Quoting Jürgen:

>But if one out of the several commits now fails, how do you recover from that? And how is the recovery better than NC with confirmed-commit?

Here is an example:
1. Client sends scheduled commit to N servers, to be performed at a future time T.
2. One of the servers replies with an rpc-error (meaning it will not be able to commit).
3. Client sends <cancel-schedule> to the other N-1 servers, before time T. None of the servers has committed yet, and they all cancel the scheduled commit.

The advantage is that there is no need to roll back. From a network-wide perspective, the configuration remains continuously consistent in the three steps above.

>the elapsed time measurement.

It is not assumed that the time of the RPC execution is known or stable. The scheduled-time specifies the *start* time of the RPC, and the execution-time specifies the *completion* time. That means that by knowing the scheduled-time and execution-time, the client knows that the difference between these two values is the elapsed time of execution + the scheduling inaccuracy.
Thus, the <execution-time> parameter allows the client to detect and monitor fluctuations in the RPC execution time.

Quoting Jürgen:

>You seem to be talking about the idea that manager wants to abort the scheduled commit.
>This does not exist in NC with confirmed-commit, except that the manager can simply stop invoking commits if it changes its mind spontaneously.

As Andy noted, NC supports the <cancel-commit> operation. The main difference is that the <cancel-commit> is performed *after* the commit was applied, as opposed to the <cancel-schedule>, performed *before* the commit is applied.

Cheers,
Tal.

From: Andy Bierman [mailto:[email-masked]]
Sent: Monday, June 29, 2015 10:05 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks for the comments.

Cheers,
Tal.

Andy

From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Monday, June 29, 2015 8:27 PM
To: Juergen Schoenwaelder; Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Hi,

Andy

/js

---------- Forwarded message ----------
From: The IESG <[email-masked]<mailto:[email-masked]>>
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Mon, 29 Jun 2015 07:58:22 -0700
Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Abstract

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Jun 2015 13:39:18 -0700

On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi <[email-masked]> wrote:

> Indeed, but the <cancel-commit> is applied only after the commit was
> already performed, meaning that now the server has to roll back.
>
> The <cancel-schedule> operation lets you cancel the commit before it has
> occurred, allowing all servers to remain with the current configuration.
> See the example below.
>
>
>

But the normal server doesn't send RPCs until they are needed
so it doesn't need to cancel anything before the commit.

>  Quoting Jürgen:
>
>
>
> >But if one out of the several commits now fails, how do you recover from
> that? And how is the recovery better than NC with confirmed-commit?
>
>
>
> Here is an example:
>

This is a big problem.
The server cannot validate the config at schedule time
and say it will be OK at RPC execution time.  What if it changes?
Even if everything stays locked for a long time (definitely NOT how
NETCONF locks are intended to be used) what if the operator
changes the hardware in some way (e.g. pull a line-card out)
or some hardware fails.

All the server can say for ANY <rpc> is "ok - I scheduled this operation
for the desired invocation time"

>  3. Client sends <cancel-schedule> to the other N-1 servers, before time
> T. None of the servers has committed yet, and they all cancel the scheduled
> commit.
>
>
>
> The advantage is that there is no need to roll back. From a network-wide
> perspective, the configuration remains continuously consistent in the three
> steps above.
>
>
>
> Quoting Andy:
>
>
>
> It is not assumed that the time of the RPC execution is known or stable.
> The scheduled-time specifies the **start** time of the RPC, and the
> execution-time specifies the **completion** time. That means that by
> knowing the scheduled-time and execution-time, the client knows that the
> difference between these two values is the elapsed time of execution + the
> scheduling inaccuracy.
>
> Thus, the <execution-time> parameter allows the client to detect and
> monitor fluctuations in the RPC execution time.
>
>
>
> Quoting Jürgen:
>
>
>
> scheduled commit.
> >This does not exist in NC with confirmed-commit, except that the manager
> can simply stop invoking commits if it changes its mind spontaneously.
>
>
>
> As Andy noted, NC supports the <cancel-commit> operation. The main
> difference is that the <cancel-commit> is performed **after** the commit
> was applied, as opposed to the <cancel-schedule>, performed **before**
> the commit is applied.
>

But <cancel-schedule> is a generic operation that has nothing to do
with <commit>.  The :time capability does not offer any features
related to commit.

I could see something like this used in CoMI where the network is slow there
may be lots of servers, so a unicast storm of requests and responses
all at commit time would be a problem.  But constrained devices need
simple APIs so none of the extras (like measuring execution time)
would be appropriate.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Monday, June 29, 2015 10:05 PM
> *To:* Tal Mizrahi
> *Cc:* Netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jun 2015 07:58:20 +0200

> The advantage is that there is no need to roll back. From a network-wide perspective, the configuration remains continuously consistent in the three steps above.

So what are the reasons you envision that causes one server fails with
an rpc-error? If you validated the config and nothing has changed in
the meantime, the commit failures should be rare. Is there any
evidence that this is a real-world problem? Do you have data how often
this problem occurs (after applying validation etc.) in operational
networks?

/js

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 30 Jun 2015 06:16:06 +0000

>for the desired invocation time"

However, if the server is down, and does not send back an “ok – I scheduled this operation”, the client can send a cancel-schedule to the other servers.
Going back to the confirmed commit, if one of the servers is down and the client sends a commit to all the servers, the client can send a <cancel-commit> upon detecting the failure, but this, again will result in a temporary state where different servers use different configuration versions. Using the :time capability, on the other hand, prevents this temporary inconsistency.

Thanks,
Tal.

From: Andy Bierman [mailto:[email-masked]]
Sent: Monday, June 29, 2015 11:39 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Andy, Jürgen,

Here is an example:

This is a big problem.

Cheers,
Tal.

Andy

From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 29, 2015 10:05 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Thanks for the comments.

Cheers,
Tal.

Andy

Hi,

Andy

/js

---------- Forwarded message ----------
From: The IESG <[email-masked]<mailto:[email-masked]>>
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Mon, 29 Jun 2015 07:58:22 -0700
Subject: Last Call: <draft-mm-netconf-time-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC

Abstract

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jun 2015 00:44:02 -0700

On Mon, Jun 29, 2015 at 11:16 PM, Tal Mizrahi <[email-masked]> wrote:

> However, if the server is down, and does not send back an “ok – I
> scheduled this operation”, the client can send a cancel-schedule to the
> other servers.
>
> Going back to the confirmed commit, if one of the servers is down and the
> client sends a commit to all the servers, the client can send a
> <cancel-commit> upon detecting the failure, but this, again will result in
> a temporary state where different servers use different configuration
> versions. Using the :time capability, on the other hand, prevents this
> temporary inconsistency.
>
>
>

Seems like if a server goes down the NMS will find out about it
through its normal FCAPS management.  If the NMS maintains
sessions then the dropped TCP connection will tell the NMS the server is
down.
This seems like a non-problem.

It is just as likely that the server will be up, return <ok> to
the schedule, and then go down.  This causes the <commit>
not to run, which causes the <cancel-commit> anyway.

Andy

> *Sent:* Monday, June 29, 2015 11:39 PM
> *To:* Tal Mizrahi
> *Cc:* Netconf