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

["[e-mail]" <[e-mail]>]

Hi, Thomas,

I still disagree with the assertions in this document - that TCP is too heavyweight for a line card or high bandwidth transfers, or even moderately harder than DTLS, which is already recommended.

That said, there’s also the issue of the port number on which this service runs - is it the same as netconf? That should be discussed. 

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 24, 2024, at 1:06 AM, [e-mail] wrote:
> 
> Dear Joe,
>  
> A small reminder. On behalf of the authors. Your review would be greatly appreciated.
>  
> Best wishes
> Thomas
>  
> From: Alex Huang Feng <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, October 21, 2024 2:33 PM
> To: [e-mail] <mailto:[e-mail]>
> Cc: Graf Thomas, INI-NET-VNC-HCS <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Tsv-art] UDP default port
>  
> Be aware: This is an external email.
>  
> Dear Joe, 
>  
> Thanks for the feedback, very appreciated. We have revised the text of the draft to address these different points.
> Please find the changes in the -16 iteration: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-16
>  
> Here the diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-udp-notif-15&url2=draft-ietf-netconf-udp-notif-16&difftype=--html
>  
> Also, thanks for the confirmation about the default port.
>  
> Regards,
>  
> Alex, on behalf of the authors
> 
> 
> On 18 Oct 2024, at 16:44, [e-mail] <mailto:[e-mail]> wrote:
>  
> Hi, all, 
>  
> A few key points I’ll add:
>  
> 1. Please change the document’s incorrect use of the term velocity. That is a very well-defined term that is not related to the situation here, as noted below.
>  
> 2. Please address the document’s rationale for needing a UDP variant. The vendor rationale below does not align with the text in the document.
>  
> 3. If use of MACSEC is key to security, please discuss this in the security considerations of this document. The term does not currently appear in the document.
>  
> 4. Based on sections 5 and 6, the very specific limitations on deployment under strict control are further evidence an assigned port number is not appropriate.
>  
> Joe
>  
>  
> On Oct 17, 2024, at 11:45 PM, [e-mail] <mailto:[e-mail]> wrote:
>  
> Dear Joe,
>  
> Thanks a lot for the promptly feedback and the clarification on the RFC 7605 requirements.
>  
> Regarding the velocity, the reasoning of the protocol, you are raising. We are in contact with several major vendors who either considering, working or having implementations already (https://datatracker.ietf.org/meeting/120/materials/slides-120-hackathon-sessd-validate-configured-subscription-yang-push-publisher-implementations) The reasons why in these implementations a connectionless transport protocol is being chosen is that the network processor is not able to retransmit the segments resp. not having for monitoring purposes enough time and resources to track the state, the acknowledgment of the segments. The main function of the network processor is forwarding packets. The monitoring aspect needs to be lightweight. Loss is not an issue since the focus is the export on accounting metrics. Similar discussions have been taken place at IETF in the past for the IPFIX protocol where both udp and sctp transport are available as choice and mostly udp is currently being implemented. For YANG-Push configured subscription, two documents draft-ietf-netconf-udp-notif and draft-ietf-netconf-https-notif are available for this purpose. The capability to export directly from network processor is key to enable scalability in distributed routing systems.
>  
> On the security, encryption aspect. Same as with IPFIX, we made sure that DTLS 1.3 support has been defined and major vendors have interest and intend to implement. However, there are network operators who intend to secure their networks otherwise by leveraging MACSEC ethernet encryption instead. Therefore, we leave the choice to the network operator wherever he wants to address encryption on L2 or on L4.
>  
> Both points have been addressed in Section 5 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-5 and 6https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-6 with references to RFC 8085. Do you think the following paragraph on the reasoning should be adjusted?
>  
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-1
> While powerful in their features and general in their architecture, the currently available transport mechanisms need to be complemented to support data publications at high velocity from network nodes that feature a distributed architecture. The currently available transports are based on TCP and lack the efficiency needed to continuously send notifications at high velocity.
>  
> Best wishes
> Thomas
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Friday, October 18, 2024 6:47 AM
> To: Alex Huang Feng <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Pierre Francois <[e-mail] <mailto:[e-mail]>>; Graf Thomas, INI-NET-VNC-HCS <[e-mail] <mailto:[e-mail]>>; Netconf <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Tsv-art] UDP default port
>  
> Be aware: This is an external email.
>  
> Before getting to the question of whether a port assignment is warranted, can someone please explain why this protocol should be allowed in the first place?
>  
> The document gives a confusing argument for this new service in addition to the current variety of Netconf protocols and its use of UDP - “high velocity”. 
>  
> - IP packets travel at the same *velocity* in a network, because velocity is defined (in physics) as a vector that combines speed and direction.
>  
> - If “velocity” is intended to imply latency, again, UDP does not reduce message latency compared to TCP. Packets not lost travel with the same latency; UDP packets that are lost  are never delivered, so the fact that TCP increases latency for retransmissions is not relevant.
>  
> -If “velocity” is intended to mean rate, UDP outperforms TCP only for extremely high rates (near Gbps and higher), far in excess of those permitted for UDP streams that lack congestion feedback, per RFC8085.
>  
> The document makes vague assertions about the need to use UDP due to TCP state, but this would affect only the collection node, not the individual reporting nodes. Additionally, avoiding TCP state doesn’t seem to significantly impact endpoint association state if DTLS is used - as in “unsecured networks”, which are basically nearly every network anyway.
>  
> The document makes vague assertion about hardware, but even very simple hardware is capable of implementing TCP, and certainly any hardware capable of implementing DTLS would probably be more than capable of supporting TCP as well.
>  
> So I don’t yet see the need for this variant - and even if there were, the very motivation (high performance flows in excess of TCP) is the reason why it cannot be safely deployed (per RFC8085).
>  
> It isn’t until all this is fixed that it would be useful to discuss whether a port is needed, but to cut that debate short, note hat the reporting happens AFTER subscriptions indicate an IP address and port number. As per RFC7605, this means that an assigned port is not needed, as the collector can run on a dynamic port selected at runtime and reported during the subscription step..
>  
> Joe
> — 
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> 
> On Oct 17, 2024, at 9:46 AM, Alex Huang Feng <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Dear Transport Area, 
>  
> The NETCONF WG suggested to contact designated experts for the default UDP port assignment.
>  
> The question is whether UDP-notif (https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-notif/) need to define a default port or not.
> The draft had an early review: https://datatracker.ietf.org/doc/review-ietf-netconf-udp-notif-11-tsvart-early-tuexen-2023-11-15/ where the default port was not raised.
>  
> The current understanding is that:
> -  Reading https://datatracker.ietf.org/doc/html/rfc7605#section-7.1 UDP-notif can be configured in both endpoints, and anyway the configuration of the IP address is needed before sending messages.
> - Reading https://datatracker.ietf.org/doc/html/rfc6335#section-7.2, given that port allocations are limited ressources, these assignments should be avoided when possible.
> - From discussions on the ML (https://mailarchive.ietf.org/arch/msg/netconf/9x_w3aI70Cw1oNJP4JH8h181cbI/) so far, current network telemetry protocols do not require a default port.
>  
> So, from these references UDP-notif does not have the requirements for a default port. Is this correct?
>  
> Regards,
> Alex
> _______________________________________________
> Tsv-art mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>  
> _______________________________________________
> Tsv-art mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>