Subject: Re: [netmod] how YANG and NETCONF support the long running command (e.g ping)

From: Randy Presuhn <[email-masked]>
Date: Thu, 13 Nov 2014 19:12:52 -0800 (GMT-08:00)

Hi -

>From: Johnson Zhu <[email-masked]>
>Sent: Nov 13, 2014 4:30 PM
>To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: [netmod] how YANG and NETCONF support the long running command (e.g ping)
...
>So any recommendation how to proceed/define the long running command?
...

I'd suggest modeling it in a manner analogous to
RFC 4560's approach in the SNMP world.  That would
let you accomplish your objective without needing
to change the protocol or the modeling language.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Nov 2014 10:52:23 +0100 (CET)

> to change the protocol or the modeling language.

Another way of doing this (I don't remember if I suggested this on the
list or not) is to use multiple rpcs:  first the client starts the
operation, then it asks for the first result, and the next, and so
on.  Eventually he got all results, or he can cancel the operation.

  rpc start-ping-operation {
    input {
      leaf address { ... }
      ...
    }
    output {
      leaf ping-operation-handle {
        type uint32;
      }
    }
  }

  rpc get-next-ping-result {  // or get-results might be better
    input {
      leaf ping-operation-handle {
        type uint32;
      }
    }
    output {
      choice result {
        case data {
          leaf time { ... }
          ...
          }
        }
        leaf no-more-data {
          type empty;
        }
      }
    }
  }

  rpc cancel-ping-operation {
    input {
      leaf ping-operation-handle {
        type uint32;
      }
    }
  }

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Nov 2014 11:36:15 +0100

>       leaf ping-operation-handle {

Yes, you can do this. That said, this approach requires to define 2-3
RPCs each time and it causes the client to block for the next result
(or you make the get-next-ping-result) return an indication that
nothing is there yet, which then of course leads to even more polls.
For me, this looks like a work-around given the mechanisms we have in
place today but not like a proper generic solution.

/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: Kent Watsen <[email-masked]>
Date: Sat, 15 Nov 2014 03:17:47 +0000

Regarding the "persistent", "fragmentation" and "datastore-push" drafts,
and related ideas floating around, I believe that there are the following
use-cases:

1) request for an unbounded number of periodic responses sent relatively
frequently (ping)

2) request for a large YANG config=false list (retrieving interface
statistics)

3) request for a large blob (file transfer)

4) request for an action that takes a long time to perform (network link
performance validation)

5) subscription request on subtree to receive on-change data notifications
(config false also)

The solution to these may or may not overlap. For instance, consider the
following:

Options for #1:
A) use a never-ending rpc-reply; server pushes data as it becomes available
B) initial response returns handle with which client polls for incremental
results and cancels the request

Options for #2:
A) pagination, multiple rpcs to return subsets of list
B) break response into blocks returned independently

Options for #3:
A) use a file-transfer protocol like SCP, SFTP, or FTPS
B) use a never-ending rpc-reply; server stream data as it becomes available
C) break response into blocks returned independently

Options for #4:
A) initial response returns handle which the client uses to monitor
progress, receive the final result, and cancel the request

Options for #5:
A) use netconf notifications as is
B) use a modified version of netconf notifications for higher throughput
C) direct responses into a queue that the client can poll

Thoughts?  Any additions?

Thanks,
Kent

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 14 Nov 2014 19:27:26 -0800

[With chair hat off]

>      leaf ping-operation-handle {

This requires that client knows when or how often to poll for an expected reply, otherwise as Juergen suggests it leads to unnecessary polls.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 14 Nov 2014 19:46:28 -0800

[Again with chair hat off]

> results and cancels the request

This assumes that client also knows when to terminate the session (requires server to indicate it is done). I am distinguishing termination from canceling, with the former being a termination by the server while cancel is forced by the client.

> progress, receive the final result, and cancel the request

Again a minor variation to this use cases is, initial response returns handle which the client uses to monitor progress, receives the final result without requiring client to cancel the request. Case in point being traceroute command, where the server knows when to terminate the request. The idea being that the end of transaction can come from the client or the server.

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Tue, 18 Nov 2014 01:08:23 +0000

>This requires that client knows when or how often to poll for an expected
>reply, otherwise as Juergen suggests it leads to unnecessary polls.

True enough.  One option to resolve this is to use a hanging-reply in
that, like select(), the server blocks until the file descriptor has data
to read.  Extending this analogy further, it's ideal to use a single
select() for a number of file descriptors.  That is, we could have a
special hanging-reply that could be used by any number of long-running
commands to return their incremental responses, which scales better.

PS: this regards options 1B and 5C in my list
(http://www.ietf.org/mail-archive/web/netmod/current/msg11269.html).

Kent