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

From: Randy Presuhn <[email-masked]>
Date: Fri, 14 Nov 2014 19:38:26 -0800 (GMT-08:00)

Hi -

>From: Kent Watsen <[email-masked]>
>Sent: Nov 14, 2014 7:17 PM
...
>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)
...
>4) request for an action that takes a long time to perform (network link
>performance validation)

I think the analysis neglects an important dimension of (1) and (4).
Particularly for management applications, there may be multiple
consumers of the (intermediate and final) results of these operations.
An RPC-centric approach scales poorly for these.  If I have three
management systems in different control centers interested in the
latency of a particular link, they shouldn't need to be running
three separate ongoing tests concurrently.

Randy

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Nov 2014 10:20:04 -0800

> three separate ongoing tests concurrently.

Are you suggesting an alternate solution path?
Multiple consumers sounds like a pub/sub model, and perhaps
some multicast transport. IMO, we need that more than
"CLI-over-NETCONF".

Another problem that seems to be ignored here (except by Martin)
is the resources required in the server to buffer unlimited events
while the client is blocked (at TCP level).  The server is expected
to concurrently invoke the periodic commands and independently
buffer the output for each client to accept at their leisure.

The NETCONF replay buffer is not unbounded.
Long running commands like "ping" need to account for
limited resources on the server.

> Randy

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 15 Nov 2014 16:55:42 -0800

[Still with the chair hat off]

Andy,

> buffer the output for each client to accept at their leisure.

This problem is no different from a ZWP attack as described in Section 3 of RFC 6428. As described in the RFC, the server is not prevented from closing connections that are either slow to respond or not reading the data.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 15 Nov 2014 16:57:14 -0800

Sorry. That was RFC 6429 not 6428.

Mahesh Jethanandani
[email-masked]