[netconf] Re: [Tsv-art] UDP default port

[Andy Bierman <[e-mail]>]

On Thu, Dec 19, 2024 at 9:05 AM Kent Watsen <[e-mail]> wrote:

> [Removing Joe and TSVART]
>
>
> As I understand it, udp-notif is intended to be used only for
> notifications that do not require reliable delivery.  That is, there would
> be one configured subscription using udp-notif for nodes that don’t require
> reliable delivery, and another configured subscription using, e.g.,
> https-notif, for nodes that do require reliable delivery.  Is this
> correct?
>
> Two things confuse me:
>
> 1) the YANG Push protocol itself defines some notifications
> (subscription-changed) that are intended to be reliable.
>
> 2) Slides 11 of IETF YANG-Push Implementations and Next Steps
> <https://datatracker.ietf.org/meeting/121/materials/slides-121-nmop-ietf-yang-push-implementations-and-next-steps-01> suggests
> that some notifications occur once (e.g., On-change sync), and hence
> suggest a need to be delivered reliably.
>
>
> How are these issues resolved?   Wouldn’t QUIC resolve them better?
>
>
The architecture has a Controller and a Collector.
The Controller needs to use NETCONF or RESTCONF to configure, monitor,
resync, etc.

I don't know why the UDP-notif draft says to use HTTP-Notif for reliable
notification delivery.
What about the long-deployed dynamic subscription over SSH or TLS?
The most notification deployment is still RFC 5277.
I think the reliable delivery option is already handled.

There should be no assumption that the system will work without a
traditional client session,
in addition to the UDP-notif receivers.


Thanks,
> Kent
>
>
Andy


>
>
> On Dec 17, 2024, at 11:37 AM, Benoit Claise <benoit.claise=
> [e-mail]> wrote:
>
> Hi,
>
>
> On 12/17/2024 3:44 PM, Rob Wilton (rwilton) wrote:
>
> Hi Kent, all.
>
>
>
> Not an author (but I am involved with the implementation of the UDP Notif
> draft), one comment inline …
>
>
>
>
>
> *From: *Kent Watsen <[e-mail]> <[e-mail]>
> *Date: *Friday, 13 December 2024 at 16:41
> *To: *[e-mail] <[e-mail]> <[e-mail]>,
> [e-mail]
> <[e-mail]>
> <[e-mail]>
> *Cc: *[e-mail] <[e-mail]> <[e-mail]>,
> [e-mail] <[e-mail]> <[e-mail]>
> *Subject: *[netconf] Re: [Tsv-art] UDP default port
>
>
>
> Hi Joe and UDP-Notif Authors,
>
>
>
> It seems that this thread has stalled.  What can we do to move it forward?
>
>
>
>
> Kent and Per // NETCONF chairs
>
>
>
>
>
> A couple thought-provoking questions:
>
>
>
> 1.      What does "udp-notif" bring that isn’t supported by the
> "https-notif" draft, assuming the https-notif draft supports the QUIC
> transport?
>
> 2.      If the https-notif draft with QUIC transport is deemed
> unacceptable, would a "quic-notif” draft work?
>
>
>
>
>
> PROs:
>
>
>
> ·         QUIC is well-defined (RFC 9000) and tooling should prominent.
>
> ·         HTTP/3 is well-defined (RFC 9114) and tooling should prominent.
>
> ·         QUIC supports reliability on a per frame-type basis, thus
> muxing both types is possible (see RFC 9221)
>
> ·         Stateful firewalls supporting QUIC will allow the return
> packets, thus enabling an “encoding-discovery” mechanism.
>
> ·         QUIC is still UDP, and so (I think) continues to support the
> properties desired by the “distributed-notify” draft.
>
> ·         Anything else?
>
>
>
> CONs:
>
>
>
> ·         No ability to disable encryption (for “private” networks)
>
> o    I don’t know how big of a problem this is.
>
> o    Assuming long-lived connections, the overhead of the asymmetric key
> handshake is negligible.
>
> o    The overhead for symmetric-key encryption (e.g., AES) is also pretty
> negligible
>
> o    The “overhead” is mostly a concern on the receiver-side, as logging
> is a many-to-one activity, but it’s easy to scale receivers.
>
> o    Encryption negates the ability to copy frames directly to persistent
> storage.  This is unlikely a good idea anymore, but ~20 years ago I
> designed the binary logging protocol such that the packets could be mmap-ed
> directly to disk, in their final storage format (note: a post-sweep would
> build indices).
>
>
>
> ·         Anything else?
>
> Yes, it is not what the clients/servers are implementing. ;-)  I.e., the
> UDP notif draft ticks the running code box, but AFAIK nobody is yet
> implementing a QUIC based transport, although I understand that there is
> potentially interest in future.
>
> Another key benefit of the UDP stack is that it is lightweight.  We
> implemented the core of it in a few weeks.  A QUIC implementation will take
> significantly more time and effort, or most likely we will try and find a
> suitable third-party library to leverage.
>
> But ultimately, If the operators are saying that UDP fits their
> requirements, and the vendors are implementing then what is the stumbling
> block to publishing this?
>
> What Rob said.
> IPFIX has been proving that UDP works and scales in production now.
>
> Regards, Benoit
>
> Regards,
> Rob
>
>
>
>
>
> Kent / contributor
>
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>