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

From: Randy Presuhn <[email-masked]>
Date: Sat, 15 Nov 2014 18:06:13 -0800 (GMT-08:00)

Hi -

>From: Mahesh Jethanandani <[email-masked]>
>Sent: Nov 15, 2014 4:55 PM
>To: Andy Bierman <[email-masked]>
>Cc: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] how YANG and NETCONF support the long running command (e.g ping)
>
>[Still with the chair hat off]
>
>Andy,
>
>On Nov 15, 2014, at 10:20 AM, Andy Bierman <[email-masked]> wrote:
>
>> 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.
>
>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.

No, the problems are different.  ZWP closes the window.  The
concern here is that the client may read events at a slower rate
than the server generates them.   The client's window would
more-or-less alternately open and close, but the server queue
would grow without bound.

Even if the problems were equivalent, the proposed mitigation
strategy (closing connections that are not reading data as
rapidly as the server generates it) could be disastrous in
fire-fighting situations, such as using a dial-in link to
manually fix a hosed network.  Or should one just use SNMP
to handle emergency configuration changes in such situations? :-)

Randy

---

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

>would grow without bound.

Without bound?  The local send-buffer should become full and then
pending/subsequent write requests would either 1) block until all the data
is sent (for a blocking socket) or 2) return EAGAIN or EWOULDBLOCK (for a
non-blocking socket)

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Nov 2014 17:33:13 -0800

> is sent (for a blocking socket) or 2) return EAGAIN or EWOULDBLOCK (for a

I think Randy is suggesting (or I am) that a solution that models the results
in a ring buffer (like the notification replay buffer or usrHistoryTable)
will lose results in a predictable way. Gaps in sequence IDs can identify
what was lost.

IMO we should not expect the server to execute operations and
collect results forever.  We should not specify implementation
details either, like the select loop that must be used.

> Kent

Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod