Re: [netconf] draft-ietf-netconf-udp-notif-10

[Andy Bierman <[e-mail]>]

On Wed, Aug 9, 2023 at 11:03 AM Jürgen Schönwälder
<[e-mail]> wrote:

> On Wed, Aug 09, 2023 at 10:21:32AM -0700, Andy Bierman wrote:
> >
> > > Perhaps you just wanted UDP and the rest just got added for political
> > > correctness in the IETF?
> >
> > The solution is partial at best and designed for use in enterprise
> networks.
> > The introduction describes lots of line cards blasting UDP packets at a
> > single receiver.
> >
> > Maybe it is unwise to have a standard that almost certainly generates
> > packet loss, yet has zero tolerance for packet loss.
> >
>
> A UDP "blasting service" can work if the network is provisioned
> accordingly and the sources take precautions to avoid excessive
> sending rates (e.g., by using some throttling mechanisms) and
> implementations ensure some good randomization of the sending events
> over time to avoid synchronization issues leading to excessive traffic
> spikes.
>
>
I don't think YANG Push has this sort of mechanism.
Consider lots of line cards with "on-change" subscriptions.
The report frequency may jump on all line cards at once.

There are no mandatory mechanisms or even complete optional mechanisms
to detect message loss, especially if the first segment is lost.
Since packet order is unreliable, a missing Message-Id is not so easy to
identify.
Unreliable packet ordering is not good for YANG Push.
There are many ways for a sequence of patches to produce different
results if the order is wrong.

Now not so sure I want to give up TCP for YANG Push...


Andy




One benefit mentioned before is to avoid connection state at the
> receiving side. I do not know whether this is a real concern; once you
> have thousands of notification senders, you likely also provision more
> than one receiver. But it would certainly be good to know what the
> performance requirements are and then some experiments can shed some
> light on things. Our intuition about performance bottlenecks is often
> not good and the document does not detail which performance problems
> exactly are being addressed by the solution.
>
> /js
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>
>