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

[[e-mail]]

Dear Hannes,

Thanks a lot. We are perfectly in line and I do appreciate your feedback. 

To my understanding, your described concerns should be already addressed in the applicability section

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-5

In case you feel that there is something missing or should be correct, I would appreciate a suggestion.

The "Message ID" enables segmentation 

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-4.1

and helps to detect loss at the YANG push receiver and therefore is preferable over fragmentation.

And yes, not to maintain states is only applicable when DTLS is not been used.

Best wishes
Thomas

-----Original Message-----
From: Hannes Tschofenig <[e-mail]> 
Sent: Monday, August 7, 2023 5:30 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>; benoit.claise=[e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: AW: [netconf] draft-ietf-netconf-udp-notif-10

Hi Thomas,

I have no problem with your choice of two transports. I was reading the draft trying to understand what was written.

When packet loss is neglectable and payload sizes are small then everything is fine -- even with UDP.
If this is not the case then there is a problem. The document needs to say that.

If you expect to send large volumes of data without flow and congestion control I fear you will see a lot of incomplete messages arriving at the receiver. You will be unhappy.

Once you use fragmentation you will have to maintain state since otherwise you cannot put the sent message together. 
Once you use security you will also have to maintain state. 

Thanks for the pointers to the implementations. Will try them. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: netconf <[e-mail]> Im Auftrag von 
> [e-mail]
> Gesendet: Montag, 7. August 2023 10:51
> An: benoit.claise=[e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Betreff: Re: [netconf] draft-ietf-netconf-udp-notif-10
> 
> Dear Jürgen,
> 
> Following up on Tianran's and Benoit's comments.
> 
> The reason why I am co-authoring and supporting 
> draft-ietf-netconf-udp-notif and draft-ietf-netconf-distributed-notif 
> because it is important that a network operator has the choice between 
> two transport protocols for YANG push. One, 
> draft-ietf-netconf-https-notif, which maintains states between YANG 
> push publisher and receiver, and draft-ietf-netconf-udp-notif which 
> doesn't require to maintain states. It should be the operators choice 
> to chose which of the transport protocols make most sense for which 
> type of metrics. Speaking for Swisscom, accounting metrics should be 
> sent without states, directly from network processors on line cards, 
> where re-transmitting packets are not feasible and at YANG push 
> receiver. Where state changes, should be sent through a transport 
> protocol which maintains states and re-transmission is supported and 
> can be sent from the route processor. It is desirable to have minimal 
> interaction between Network Telemetry data collection and the network node exporting the metrics, in particular when load is distributed among multiple YANG push receiver daemons in a redundant fashion.
> 
> I believe in running code. draft-ietf-netconf-udp-notif and 
> draft-ietf-netconf- distributed-notif describe both an implementation 
> status section where open- source code is linked. For https-notif we 
> published a YANG push publisher 
> https://github.com/network-analytics/https-notif-c-publisher and YANG push receiver https://github.com/network-analytics/https-notif-c-collector as well.
> Udp-notif has been integrated into the pmacct Network Telemetry 
> open-source project.
> 
> I confirm that CBOR will be a further important step to make YANG push 
> equally scalable and efficient than the other Network Telemetry 
> protocols in use. I am looking forward to contribute to the netconf working group.
> 
> Best wishes
> Thomas
> 
> -----Original Message-----
> From: netconf <[e-mail]> On Behalf Of Benoit Claise
> Sent: Monday, August 7, 2023 9:17 AM
> To: Tianran Zhou <[e-mail]>; netconf <[e-mail]>
> Subject: Re: [netconf] draft-ietf-netconf-udp-notif-10
> 
> Dear all,
> 
> On 8/7/2023 8:55 AM, Jürgen Schönwälder wrote:
> > On Mon, Aug 07, 2023 at 06:34:36AM +0000, Tianran Zhou wrote:
> >>> The abstract says:
> >>>
> >>>     The objective is to provide a lightweight approach to enable higher
> >>>     frequency and less performance impact on publisher and receiver
> >>>     processes compared to already established notification mechanisms.
> >>>
> >>> It is not clear what 'performance impact' means here. Anyway, is 
> >>> there a
> proof that this design accomplishes the objective and how much is the 
> gain over a transport that does segmentation properly, e.g., TCP?
> >> ZTR> There is no such proof from my side. I am not sure if there is 
> >> ZTR> any from
> coauthors.
> >>
> > It would help to demonstrate that the design achieves the stated 
> > goals... This will likely make you think more clearly what you mean 
> > with 'less performance impact on publisher and receiver processes' 
> > and how much the gain is over 'established notification mechanisms'.
> >
> There is a reason why NetFlow was exported over UDP and why IPFIX is 
> still exported over UDP (independently of what the IPFIX RFC mandates).
> 
> Regards, Benoit
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf