Subject: [Netconf] Updated draft-mm-netconf-time-capability-01

From: Tal Mizrahi <[email-masked]>
Date: Thu, 02 Jan 2014 17:56:30 +0200

Hi,

We have posted an updated draft:
http://tools.ietf.org/html/draft-mm-netconf-time-capability-01

Thanks to all the people who reviewed and sent comments about draft 00.
Here is a summary of the changes compared to draft 00:
-	We have added discussion about the scheduling tolerance: an upper  
bound on how far into the future/past an RPC can be scheduled.
-	The scheduled time now refers to the *start* time of the operation,  
rather than to its completion.
-	The time format has been changed to date-and-time.

There is a key issue that we would like to raise. There is a  
well-known distinction between *hard* real-time and *soft* real-time  
scheduling; hard-real time implies that if one of the servers does not  
perform the scheduled operations on time the system may fail, whereas  
soft real-time means that the system will perform better if all the  
servers invoke the operations on time, but nothing breaks even if they  
don’t.

We received quite a bit of comments and questions, that we believe are  
more relevant to the *hard* real-time case, for example: what happens  
if a server is unable to schedule the RPC to the scheduled time? is  
there a way to remove pending scheduled operations? What if the NACM  
rules change while the operation is pending? What if the server  
reboots while operations are pending?

We believe the current draft allows soft real-time scheduling, i.e.,  
it provides the tools to schedule an RPC without strict guarantees. An  
implicit assumption here is that RPCs are scheduled to near-future  
deadlines (e.g., on the order of seconds in the future), which allows  
a long enough time for the NETCONF message to be delivered to the  
server, but not enough time for (or a very low probability of)  
significant changes in the server, such as NACM rule changes, or  
server restart.

At this point, draft 01 is soft-real-time-oriented. We are interested  
to hear feedback about whether there is an interest in the working  
group to develop the hard real-time functionality as well.

Regards,
Tal Mizrahi.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 14 Jan 2014 13:03:03 -0500

> -    The time format has been changed to date-and-time.

I read through the draft, Tal, and I have a few comments.

Section 3.1:

I think there should be a way to query the server's current time to make
sure the client and server agree.  This should be part of the overall
dialogue between the two when scheduling will be done.  Even though the
client may be configured to use NTP, the server may not have had a
chance to sync to its clock source.  You talk about time sync, but I
think this extra level of checking will assure that the server doesn't
do something the client didn't expect.  At the very least, the client
may decide to abort the scheduled operation.

This goes outside of the time tolerance you define in Section 3.5.  I
could, for example, say I have a 10 second tolerance in either direction
of time 2015-10-21T04:29:00.235.  The server gets a chance to execute at
2015-10-21T04:38:00.235 and does, but the actual time on the client is
2015-10-21T05:29:00.235.

Section 3.4:

You introduce time-interval here without really saying how it will be
used.  You do this later, but it seemed a bit disjointed to me.  Maybe
swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4.

Section 4.5

You define the element <schedule> but you reference it as <scheduled>:

OLD TEXT:

...operation. Every <rpc> message MAY include the <scheduled>...

NEW TEXT:

...operation. Every <rpc> message MAY include the <schedule>...

NIT: I would swap the order of <get-time> and <execution-time> as the
former references the latter.

Section 4.5.1:

You have two leaf nodes with the name sched-max-past.  They have two
different descriptions.  I think the first should be sched-max-future.

> At this point, draft 01 is soft-real-time-oriented. We are interested to
> hear feedback about whether there is an interest in the working group to
> develop the hard real-time functionality as well.

I think soft time is fine.  However, the draft doesn't discuss how a
client can retrieve the results of a scheduled RPC.  How would I go
about ensuring that an RPC completed (or not) at the scheduled time?

Joe

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 19 Jan 2014 15:57:09 +0200

Hi Joe,

Thanks for the comments.

> However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC.  How would I go about ensuring that an RPC completed (or not) at the scheduled time?

If the client gets an rpc-reply with an <ok> element it knows the scheduled operation was performed successfully. 
If the client wants to know whether the RPC was performed *on time* it needs to include the <get-time> element in the RPC (in addition to including the <scheduled-time> element), causing the server to include the <execution-time> element in the rpc-reply. This allows the client to receive feedback about the actual execution time of the RPC. This behavior is described in section 3.1 of the draft.

> I think there should be a way to query the server's current time to make sure the client and server agree.

One way to do this is to use the <get-time> element; the client can send (any kind of) an RPC to the server which includes the <get-time> element. Consequently, the server includes the <execution-time> in its rpc-reply. It should be noted that this method allows a *very* rough indication about whether the client and server are synchronized.
However, I believe the correct way to inquire about whether the server is synchronized or not is at the clock synchronization protocol layer. For example, the NTP MIB (RFC 5907) includes a set of objects that allow you to check the current status of NTP, including the offset to the current reference time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes similar objects. 
[One may ask whether NTP and PTP have a YANG module for NETCONF, but that is a completely different story...:) ]

Thanks,
Tal Mizrahi.

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Joe Marcus Clarke
Sent: Tuesday, January 14, 2014 8:03 PM
To: Tal Mizrahi; [email-masked]
Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01

Section 3.1:

I think there should be a way to query the server's current time to make sure the client and server agree.  This should be part of the overall dialogue between the two when scheduling will be done.  Even though the client may be configured to use NTP, the server may not have had a chance to sync to its clock source.  You talk about time sync, but I think this extra level of checking will assure that the server doesn't do something the client didn't expect.  At the very least, the client may decide to abort the scheduled operation.

This goes outside of the time tolerance you define in Section 3.5.  I could, for example, say I have a 10 second tolerance in either direction of time 2015-10-21T04:29:00.235.  The server gets a chance to execute at
2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015-10-21T05:29:00.235.

Section 3.4:

You introduce time-interval here without really saying how it will be used.  You do this later, but it seemed a bit disjointed to me.  Maybe swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4.

Section 4.5

OLD TEXT:

NEW TEXT:

NIT: I would swap the order of <get-time> and <execution-time> as the former references the latter.

Section 4.5.1:

You have two leaf nodes with the name sched-max-past.  They have two different descriptions.  I think the first should be sched-max-future.

> group to develop the hard real-time functionality as well.

I think soft time is fine.  However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC.  How would I go about ensuring that an RPC completed (or not) at the scheduled time?

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

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 19 Jan 2014 18:44:34 -0500

> If the client wants to know whether the RPC was performed *on time* it needs to include the <get-time> element in the RPC (in addition to including the <scheduled-time> element), causing the server…

I don't get this.  If I schedule something to run in one hour, I have to 
wait an hour for the rpc-reply?  That doesn't seem right.

My understanding from the initial read was that I would get an rpc-reply 
right away to indicate the request was scheduled successfully.

> [One may ask whether NTP and PTP have a YANG module for NETCONF, but that is a completely different story...:) ]

In terms of this draft should there be some text that explain this as a 
potential concern with suggestions?

Joe

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 23 Jan 2014 08:56:07 +0200

Hi Joe,

Thanks again for the comments.

> I don't get this.  If I schedule something to run in one hour, I have to wait an hour for the rpc-reply?  That doesn't seem right.

Okay, so this goes back to our comment that the current draft focuses on soft-real time scheduling (http://www.ietf.org/mail-archive/web/netconf/current/msg08549.html), but I should probably explain it a bit further. In this context there is an implicit assumption that RPCs are scheduled to a *near future* time. Here is an example (the numbers are just an example, so they do not necessarily represent a real-life scenario).  Let's say we have a client and two servers, and let's say that every RPC the client sends (a normal RPC, not a scheduled one) is executed within 3 seconds with a probability .999, i.e., the client receives an rpc-reply within 3 seconds. The client can send a *scheduled* RPC to the two servers, with a <scheduled-time> that is 3 seconds into the future; consequently, each of the two servers performs the RPC exactly 3 seconds afterwards with a probability .999 (each). The client has to wait 3 seconds to get the rpc-reply, but that is not so bad, since in the non-scheduled RPC the client may need to wait 3 seconds anyway. And we should note that in this example each of the servers has a probability of .001 not to perform the RPC on time, which is why we are emphasizing that we have focused on addressing soft-real time scheduling.

Indeed, the rpc-reply is received only after the RPC was scheduled, but we are assuming that the scheduling time is not too far into the future (which is one of the reasons this draft includes the <sched-max-future>).

I think the current draft is less targeted at far-future scheduling (e.g., an hour in your example). Our thoughts were that approaches such as draft-kwatsen-conditional-enablement are a better fit for far-future scheduling. However, if we come to the conclusion that we *do* need to address far-future scheduling, it is possible to add the following functionality (this is a tweak to something Andy suggested a couple of months ago): (i) When a server receives a scheduled RPC, it can send a notification to the client, indicating that the scheduled RPC was received and added to the server's schedule. The rpc-reply itself is sent after the RPC was executed at the scheduled time. (ii) The client can send a cancellation message if it does not receive a notification, or if it receives an rpc-error from one of the servers. 

So an open question here is whether we should add the 2 features above (notification, cancellation) that would enable far-future scheduling as well.

Regards,
Tal.

-----Original Message-----
From: Joe Marcus Clarke [mailto:[email-masked]] 
Sent: Monday, January 20, 2014 1:45 AM
To: Tal Mizrahi; Tal Mizrahi; [email-masked]
Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01

> If the client wants to know whether the RPC was performed *on time* it needs to include the <get-time> element in the RPC (in addition to including the <scheduled-time> element), causing the server…

I don't get this.  If I schedule something to run in one hour, I have to wait an hour for the rpc-reply?  That doesn't seem right.

My understanding from the initial read was that I would get an rpc-reply right away to indicate the request was scheduled successfully.

> [One may ask whether NTP and PTP have a YANG module for NETCONF, but 
> that is a completely different story...:) ]

In terms of this draft should there be some text that explain this as a potential concern with suggestions?

Joe

> could, for example, say I have a 10 second tolerance in either 
> direction of time 2015-10-21T04:29:00.235.  The server gets a chance 
> to execute at