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

[[e-mail]]

Dear Kent,

We haven't observed loss on transport between YANG-Push publisher and receiver. on-change and subscription state change notifications are sent once, but can also be subscribed periodical in case a loss on transport occurs. We haven't done so but intend to do in the near future.

In comparison, we also have propriety YANG-Push implementations which are TCP based with a shim header (Cisco IOS XR). Compared to, we do not see any difference in terms of loss.

As described, with draft-wilton-netconf-yp-observability we see the possibility to add an option to sync-on-start to send the current state periodically, same as gNMI already has specified and implemented. That simplifies the subscription management.

Best wishes
Thomas

From: Kent Watsen <[e-mail]>
Sent: Friday, December 20, 2024 1:43 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [netconf] Re: [Tsv-art] UDP default port


Be aware: This is an external email.


Hi Thomas,

I perfectly well understand that some values (e.g., counters) are okay to be lossy.  But I’m wondering if only lossy are sent when:

1) some events on that slide seem singular (one-time-change), but maybe I’m reading the slide wrong?

2) the YP protocol definitely has messages that occur one time, the loss of which seems problematic (RFC violations?)

I understand that you are happy with the current solution, which is great, but I’m trying to understand how happy one can be when it seems some things that must not be dropped may be lost.

The perfect response for me here would be, for #1, explain that there aren’t any one-time messages and, for #2, either explain that aren’t any one-time messages or explain that this is why YP Lite is needed (i.e., to remove the reliability constraints).

Thanks,
Kent


On Dec 20, 2024, at 3:36 AM, [e-mail]<mailto:[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.


  1.  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 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]<mailto:[e-mail]>>
Sent: Thursday, December 19, 2024 6:05 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto: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:

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]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>