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

[Andy Bierman <[e-mail]>]

On Thu, Aug 10, 2023 at 7:06 AM Kent Watsen <[e-mail]> 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.
>>
>
> I have seen the need for distributed data-plane (not control-plane) log
> collection, whereby some collectors are physically in the same rack as
> the producers.  Unencrypted UDP  is usedto minimize the performance
> impact to the revenue-generating line cards.
>
> The collector can be assembled using off-the-shelf components.  The
> collector aggregates/deduplicates/compresses the logs before forwarding
> them to a centralized collector, using an encrypted TCP-based transport.
>
> I support this work, but only for this use case.
>
>
The scope is for Configured Subscriptions.

I appreciate the need for a distributed system, where lightweight
collectors can
simply listen for notifications, without all the heavyweight protocols used
to
configure the system.

What if I just ran this protocol over TCP instead of UDP?
What if I don't want to reimplement all the features of TCP in the
application layer,
because that's a horrible idea?

IMO this option is actually much better for configured subscriptions than
UDP.
Many on-change subscriptions and all event stream subscriptions will work
much better
with a reliable transport. Duplicates, misordering, and lost packets can
cause many problems
for a YANG Push collector.

Only the simplest periodic datastore subscriptions are safe for UDP.
Yet on-change is a must-have since periodic updates can use up lots of
bandwidth for duplicate reports.
On-change updates may omit data nodes that did not change, so if lost,
there may not
be another update that has the lost information.





> Kent
>

Andy