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

[Kent Watsen <[e-mail]>]

[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?

Thanks,
Kent



> 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]> <mailto:[e-mail]>
>> Date: Friday, 13 December 2024 at 16:41
>> To: [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>> Cc: [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[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] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]