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

[Benoit Claise <[e-mail]>]

Kent,

I guess I fail to understand this willingness to come back to the use 
cases behind this draft, to try to find new solutions here (QUIC), and 
to postpone further the publication.
A 4 years old WG document, with 6 implementations (see Implementation 
Status 
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#name-implementation-status>). 
Isn't it time to ship it?

Regards, Benoit

On 12/20/2024 9:35 AM, [e-mail] wrote:
>
> Dear Kent,
>
> Speaking as an operator who maintains a large scale Network Telemetry 
> data collection. We at Swisscom have >2 years of experience operating 
> udp-notif data collection in production environment with periodical, 
> on-change and on-change sync-on-start subscriptions.
>
>   * 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.
>
> Correction. Slide 10 and 11 show the use cases. Slide 12 how they are 
> being addressed.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-5 
> <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-5>describes 
> main appliccability.
>
> The main use case of the proposed mechanism is the collection of 
> statistical metrics for accounting purposes, where potential loss is 
> not a concern, but should however be reported (such as IPFIX Flow 
> Records exported with UDP [RFC7011 
> <https://www.rfc-editor.org/info/rfc7011>]). Such metrics are 
> typically exported in a periodical subscription as described in 
> Section 3.1 of [RFC8641 <https://www.rfc-editor.org/info/rfc8641>].
>
> Today snmp traps, the YANG-Push on-change pendant, are sent via udp. 
> IPFIX has data-templates and options-templates, similar to YANG-Push 
> subscription state change notifications, are sent also via UDP but 
> periodically. Loss can occur not only in YANG-Push transport but also 
> somewhere throughout the data processing chain 
> (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-05#section-4) 
> Therefore it is important to be able to recognize loss 
> (https://datatracker.ietf.org/doc/html/draft-netana-netconf-notif-envelope-01#section-3.4.1) 
> throughout the data processing chain and not only retrieve at the 
> YANG-Push session establishment the initial state with on-change 
> sync-on-start 
> (https://datatracker.ietf.org/doc/html/rfc8641#section-3.1) when the 
> YANG-Push session was lost, but also periodically throughout the 
> YANG-Push subscription life cycle. Today this requires two 
> subscriptions but tomorrow, same as in gNMI, this could be an option 
> at the subscription.
>
> From vendor implementation interactions we understood that udp-notif 
> is implementable on distributed systems because session states doesn't 
> need to be maintained. Current implementations are ranging from 
> routers with line cards in the IP domain, OLT's in the broadband 
> access domain to even SmartSFP's. I am not aware of any vendors intend 
> to implement https-notif nor QUIC transport for YANG-Push. In the 
> future, with different hardware capabilities, this might change.
>
> Best wishes
>
> Thomas
>
> *From:*Kent Watsen <[e-mail]>
> *Sent:* Thursday, December 19, 2024 6:05 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [netconf] [Tsv-art] UDP default port
>
>
> 	
>
> *Be aware:*This is an external email.
>
> [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] <[e-mail]>
>         <mailto:[e-mail]>,
>         [e-mail]
>         <[e-mail]>
>         <mailto:[e-mail]>
>         *Cc: *[e-mail] <[e-mail]>
>         <mailto:[e-mail]>, [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:
>
>         1.QUIC is well-defined (RFC 9000) and tooling should prominent.
>
>         2.HTTP/3 is well-defined (RFC 9114) and tooling should prominent.
>
>         3.QUIC supports reliability on a per frame-type basis, thus
>         muxing both types is possible (see RFC 9221)
>
>         4.Stateful firewalls supporting QUIC will allow the return
>         packets, thus enabling an “encoding-discovery” mechanism.
>
>         5.QUIC is still UDP, and so (I think) continues to support the
>         properties desired by the “distributed-notify” draft.
>
>         6.Anything else?
>
>         CONs:
>
>         1.No ability to disable encryption (for “private” networks)
>
>         1.I don’t know how big of a problem this is.
>
>         2.Assuming long-lived connections, the overhead of the
>         asymmetric key handshake is negligible.
>
>         3.The overhead for symmetric-key encryption (e.g., AES) is
>         also pretty negligible
>
>         4.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.
>
>         5.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).
>
>         2.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 [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 [e-mail]