[netconf] Re: [Tsv-art] UDP default port
Thomas.Graf@swisscom.com Fri, 18 October 2024 06:45 UTC
Return-Path: <Thomas.Graf@swisscom.com>
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 E7B6BC1516E0; Thu, 17 Oct 2024 23:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Level:
X-Spam-Status: No, score=-4.405 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=swisscom.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 N0zV5iJtaHhj; Thu, 17 Oct 2024 23:45:38 -0700 (PDT)
Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8449C14F6BA; Thu, 17 Oct 2024 23:45:36 -0700 (PDT)
Received: by mail.swisscom.com; Fri, 18 Oct 2024 08:45:33 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1729233934; bh=UeMCrJJAbyQUWTVnaaOdJs1vk35wob6IMQYmVM/GOzU=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=TZZimyyBTmsSEa9Uti/JEm8709D38bae6HG55JjezaeYO5HMdqGai+b3vE2vrYXfr XEOTa/gm2GQI7CBdyj8drGZShwLMDRVFCTwqbjdoBUly9AZTfGwwpOEYl3LsIBUsC9 Nsr1c9rMt7PKiLUbAtTbN0VHzj1AJYcjVKwHa7uau+13z+PpzuOCJy7Kx96YTLX3c2 lfjd35L2AAASe02rzsBME08uQuI/LXpGAVGNgMbESyQbVQmVm0k8BYgntL8dim7nBe +GiwSRigwJ3hlGGhjJD9eecihmKUAuvCcf1eH/wBK0HPH+w48QiBqalTnWulXfBdKS SJbudihizsdaQ==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_488230_1558240817.1729233933533"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: touch@strayalpha.com, alex.huang-feng@insa-lyon.fr
Thread-Topic: [Tsv-art] UDP default port
Thread-Index: AQHbILQxgbFY+trzZU6KuGhXy5uhX7KLzqEAgAA5EJA=
Date: Fri, 18 Oct 2024 06:45:30 +0000
Message-ID: <249963514c32443fb46250e3d7492944@swisscom.com>
References: <2EBB4D35-4D0A-4123-AE45-0D0C6B549E48@insa-lyon.fr> <EAEFE72C-2E72-4847-B612-E76617A1C5CC@strayalpha.com>
In-Reply-To: <EAEFE72C-2E72-4847-B612-E76617A1C5CC@strayalpha.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=70f9058c-bc8c-4898-84c2-174b0f9c3d4d;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2024-10-18T06:11:20Z;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1;
x-originating-ip: [138.188.161.184]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Message-ID-Hash: VYL2M6BRO6R5FVIEC5RGCR7EKVRPGGDN
X-Message-ID-Hash: VYL2M6BRO6R5FVIEC5RGCR7EKVRPGGDN
X-MailFrom: Thomas.Graf@swisscom.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: [netconf] Re: [Tsv-art] UDP default port
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-7q5S-UtmzTz_iZtPdkQgxVycFU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>
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 6 https://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: 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. 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 <alex.huang-feng@insa-lyon.fr<mailto:alex.huang-feng@insa-lyon.fr>> 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 -- tsv-art@ietf.org<mailto:tsv-art@ietf.org> To unsubscribe send an email to tsv-art-leave@ietf.org<mailto:tsv-art-leave@ietf.org>
- [netconf] UDP default port Alex Huang Feng
- [netconf] Re: UDP default port Kent Watsen
- [netconf] Re: UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port touch@strayalpha.com
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port touch@strayalpha.com
- [netconf] Re: [Tsv-art] UDP default port Alex Huang Feng
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port touch@strayalpha.com
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Rob Wilton (rwilton)
- [netconf] Re: [Tsv-art] UDP default port Benoit Claise
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Andy Bierman
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port Benoit Claise
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port Carsten Bormann
- [netconf] Re: [Tsv-art] UDP default port Carsten Bormann
- [netconf] Re: [Tsv-art] UDP default port Benoit Claise
- [netconf] Re: [Tsv-art] UDP default port Kent Watsen
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port Thomas.Graf
- [netconf] Re: [Tsv-art] UDP default port touch@strayalpha.com