Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544D9C15171B; Tue, 26 Nov 2024 19:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5qtFx5ssjNH; Tue, 26 Nov 2024 19:22:29 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A867C151520; Tue, 26 Nov 2024 19:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QwtZOri5JZ3CDCUIvquinqsqP7oG5tm7ijLpEkQWUrU=; b=XY/YRAja8cXTBjHqKtuZH7eEEN 693ueWXj1sddMv9VKnzeLA8IbrsNPC6rHplb8o6AqMNiJrBaF+0kGI4StpgadXYtnPP8WQqUkaLv7 bQtCUFkShpCZQVJZBdtdwcFDqFx57//ywLBJwB21hI/kr/++Wi7BAFBqVcctG+ugp0fancKn9N6DO s4uOEHTDszPTi9Wm8pJFRIwZU5PHCRIetqrVTSj0qiPCZ6NAkZRioX6MTrBNOYeARXfWqvJhvqzui r9oJJEy6/scjRojulbm2TBMVxejM/XohkbEq1+HKem9gGqjPmORbuGqNOsCjDNiSNJqSZOzPdAqiw BqPmnT2g==; Received: from [172.58.211.230] (port=4508 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1tG8dG-00C1VG-1x; Tue, 26 Nov 2024 22:22:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_92906AEB-8DC8-43D2-95C4-B1E5AF512CEF" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) From: "touch@strayalpha.com" In-Reply-To: <9056d35ba7e24548b36c31bf75a4a6b6@swisscom.com> Date: Tue, 26 Nov 2024 19:22:14 -0800 Message-Id: <98762A51-2207-4193-BB67-8F13CAD9A2C4@strayalpha.com> References: <2EBB4D35-4D0A-4123-AE45-0D0C6B549E48@insa-lyon.fr> <249963514c32443fb46250e3d7492944@swisscom.com> <1FD4AA1D-0509-45F3-96D4-A2FEE0390B60@strayalpha.com> <9056d35ba7e24548b36c31bf75a4a6b6@swisscom.com> To: Thomas.Graf@swisscom.com X-Mailer: Apple Mail (2.3826.200.121) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Message-ID-Hash: CPFCHM2SEEDGT3YWH7VLFLAGKFLEA7T7 X-Message-ID-Hash: CPFCHM2SEEDGT3YWH7VLFLAGKFLEA7T7 X-MailFrom: touch@strayalpha.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tsv-art@ietf.org, pierre.francois@insa-lyon.fr, netconf@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bnetconf=5D_Re=3A_=5BTsv-art=5D_UDP_default_port?= List-Id: NETCONF WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_92906AEB-8DC8-43D2-95C4-B1E5AF512CEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99s also the issue of the port number on which = this service runs - is it the same as netconf? That should be discussed.=20= Joe =E2=80=94 Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Nov 24, 2024, at 1:06=E2=80=AFAM, Thomas.Graf@swisscom.com wrote: >=20 > Dear Joe, > =20 > A small reminder. On behalf of the authors. Your review would be = greatly appreciated. > =20 > Best wishes > Thomas > =20 > From: Alex Huang Feng > > Sent: Monday, October 21, 2024 2:33 PM > To: touch@strayalpha.com > Cc: Graf Thomas, INI-NET-VNC-HCS >; tsv-art@ietf.org = ; pierre.francois@insa-lyon.fr = ; netconf@ietf.org = > Subject: Re: [Tsv-art] UDP default port > =20 > Be aware: This is an external email. > =20 > Dear Joe,=20 > =20 > 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 > =20 > Here the diff: = https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-netconf-udp-notif-1= 5&url2=3Ddraft-ietf-netconf-udp-notif-16&difftype=3D--html > =20 > Also, thanks for the confirmation about the default port. > =20 > Regards, > =20 > Alex, on behalf of the authors >=20 >=20 > On 18 Oct 2024, at 16:44, touch@strayalpha.com = wrote: > =20 > Hi, all,=20 > =20 > A few key points I=E2=80=99ll add: > =20 > 1. Please change the document=E2=80=99s incorrect use of the term = velocity. That is a very well-defined term that is not related to the = situation here, as noted below. > =20 > 2. Please address the document=E2=80=99s rationale for needing a UDP = variant. The vendor rationale below does not align with the text in the = document. > =20 > 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. > =20 > 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. > =20 > Joe > =20 > =20 > On Oct 17, 2024, at 11:45=E2=80=AFPM, Thomas.Graf@swisscom.com = wrote: > =20 > Dear Joe, > =20 > Thanks a lot for the promptly feedback and the clarification on the = RFC 7605 requirements. > =20 > 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-s= essd-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. > =20 > 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. > =20 > 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#sectio= n-6 with references to RFC 8085. Do you think the following paragraph on = the reasoning should be adjusted? > =20 > = 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. > =20 > Best wishes > Thomas > =20 > From: touch@strayalpha.com = > > Sent: Friday, October 18, 2024 6:47 AM > To: Alex Huang Feng > > Cc: tsv-art@ietf.org ; Pierre Francois = >; = Graf Thomas, INI-NET-VNC-HCS >; Netconf > > Subject: Re: [Tsv-art] UDP default port > =20 > Be aware: This is an external email. > =20 > 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? > =20 > The document gives a confusing argument for this new service in = addition to the current variety of Netconf protocols and its use of UDP = - =E2=80=9Chigh velocity=E2=80=9D.=20 > =20 > - IP packets travel at the same *velocity* in a network, because = velocity is defined (in physics) as a vector that combines speed and = direction. > =20 > - If =E2=80=9Cvelocity=E2=80=9D 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. > =20 > -If =E2=80=9Cvelocity=E2=80=9D 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. > =20 > 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=E2=80=99= t seem to significantly impact endpoint association state if DTLS is = used - as in =E2=80=9Cunsecured networks=E2=80=9D, which are basically = nearly every network anyway. > =20 > 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. > =20 > So I don=E2=80=99t 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). > =20 > It isn=E2=80=99t 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.. > =20 > Joe > =E2=80=94=20 > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com >=20 >=20 >=20 > On Oct 17, 2024, at 9:46=E2=80=AFAM, Alex Huang Feng = > = wrote: > =20 > Dear Transport Area,=20 > =20 > The NETCONF WG suggested to contact designated experts for the default = UDP port assignment. > =20 > 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-e= arly-tuexen-2023-11-15/ where the default port was not raised. > =20 > 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. > - =46rom 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. > =20 > So, from these references UDP-notif does not have the requirements for = a default port. Is this correct? > =20 > Regards, > Alex > _______________________________________________ > Tsv-art mailing list -- tsv-art@ietf.org > To unsubscribe send an email to tsv-art-leave@ietf.org = > =20 > _______________________________________________ > Tsv-art mailing list -- tsv-art@ietf.org > To unsubscribe send an email to tsv-art-leave@ietf.org = --Apple-Mail=_92906AEB-8DC8-43D2-95C4-B1E5AF512CEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s also = the issue of the port number on which this service runs - is it the same = as netconf? That should be = discussed. 

Joe
=E2=80=94
Dr. Joe Touch, temporal = epistemologist
www.strayalpha.com

On Nov 24, 2024, at 1:06=E2=80=AFA= M, Thomas.Graf@swisscom.com wrote:

Dear Joe,
 
A small = reminder. On behalf of the authors. Your review would be greatly = appreciated.
 
Best = wishes
Thomas
 
From: Alex = Huang Feng <alex.huang-feng@insa-lyon.fr>
Sent: Monday, October 21, 2024 = 2:33 PM
To: touch@strayalpha.com
Cc: Graf Thomas, = INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>; tsv-art@ietf.org; pierre.francois@insa-lyon.fr; netconf@ietf.org
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.
 
 
Also, thanks = for the confirmation about the default = port.
 
Regards,
 
Alex, on behalf = of the authors


On 18 Oct 2024, at 16:44, touch@strayalpha.com wrote:
=
 
Hi, all, 
 
A few key = points I=E2=80=99ll add:
 
1. Please = change the document=E2=80=99s 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=E2=80=99s 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=E2=80=AFPM, Thomas.Graf@swisscom.com 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-imple=
mentations). 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-n= otif#section-5 and = 6https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-n= otif#section-6 with = references to RFC 8085. Do you think the following paragraph on the = reasoning should be adjusted?
 
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: touch@strayalpha.com <touch@strayalpha.com>
Sent: Friday, October 18, 2024 = 6:47 AM
To: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Cc: tsv-art@ietf.org; Pierre Francois <pierre.francois@insa-lyon.fr>; Graf = Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>; Netconf <netconf@ietf.org>
Subject: Re: [Tsv-art] UDP default = port
 
Be aware: This is an external = email.
<= div style=3D"margin: 0in; font-size: 11pt; font-family: Calibri, = sans-serif;"> 
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 - =E2=80=9Chigh = velocity=E2=80=9D. 
 
- 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 =E2=80=9Cvelocity=E2=80=9D 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 =E2=80=9Cvelocity=E2=80=9D 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=E2=80=99t seem to significantly impact endpoint association state = if DTLS is used - as in =E2=80=9Cunsecured networks=E2=80=9D, 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=E2=80=99t 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=E2=80=99t 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
=E2=80=94 
<= div>
Dr. Joe Touch, temporal = epistemologist



On Oct 17, 2024, at 9:46=E2=80=AFAM, Alex Huang Feng <alex.huang-feng@insa-lyon.fr> = wrote:
 
Dear Transport Area, 
<= div>
 
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&= nbsp;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.
- =46rom = discussions on the ML (https://mailarchive.ietf.org/arch/msg/netconf/9x_w3aI70Cw1oNJP= 4JH8h181cbI/), 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 -- tsv-art@ietf.org
To unsubscribe send an email to tsv-art-leave@ietf.org
 
_______________________________________________
Tsv-art = mailing list -- tsv-art@ietf.org
To unsubscribe send an = email to tsv-art-leave@ietf.org

= --Apple-Mail=_92906AEB-8DC8-43D2-95C4-B1E5AF512CEF--