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

Thomas.Graf@swisscom.com Mon, 07 August 2023 08:50 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 7CA61C14F75F for <netconf@ietfa.amsl.com>; Mon, 7 Aug 2023 01:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 kRxH7fIhXhoi for <netconf@ietfa.amsl.com>; Mon, 7 Aug 2023 01:50:54 -0700 (PDT)
Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0F1C151554 for <netconf@ietf.org>; Mon, 7 Aug 2023 01:50:53 -0700 (PDT)
Received: by mail.swisscom.com; Mon, 7 Aug 2023 10:50:42 +0200
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_1312756_588160350.1691398242412"
From: Thomas.Graf@swisscom.com
To: benoit.claise=40huawei.com@dmarc.ietf.org, zhoutianran@huawei.com, netconf@ietf.org, jschoenwaelder@constructor.university
Thread-Topic: [netconf] draft-ietf-netconf-udp-notif-10
Thread-Index: AdnIDrztCMSFTgSeQHeUupzExnFQ3AAGCR4AADBluAAAALjsgAAAwR+AAAZpDWA=
Date: Mon, 07 Aug 2023 08:50:38 +0000
Message-ID: <6f0be853231c4fa4b24de758590770f2@swisscom.com>
References: <e2e898680f2b40a78b7d8854ca5fee4f@huawei.com> <wd6kzin4foik2dimypz67ziqya7lhbs3rzk7t4gp6jic77kxb3@6pvkir2sivsn> <04cb53fc90f84bf4b23acd598eefaf1c@huawei.com> <anhguehaskcbb2ayryota6fixkijydn2tjp2iggkrxqfottfxh@c5zwzaewitu6> <80d76006-a780-ddf0-74e9-7edc6b2063ce@huawei.com>
In-Reply-To: <80d76006-a780-ddf0-74e9-7edc6b2063ce@huawei.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_Enabled=true; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2023-08-07T08:50:37Z; 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_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=5b32d0da-5fe2-4f4f-883e-83b607b1a441; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0
x-originating-ip: [10.45.71.66]
X-CFilter-Loop: Reflected
X-Mailer: Totemo_TrustMail_(Notification)
X-Trustmail: processed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-E2PiRC0HqVSRDOFiSqkBJd3KCs>
Subject: Re: [netconf] draft-ietf-netconf-udp-notif-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2023 08:50:55 -0000

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 <netconf-bounces@ietf.org> On Behalf Of Benoit Claise
Sent: Monday, August 7, 2023 9:17 AM
To: Tianran Zhou <zhoutianran@huawei.com>; netconf <netconf@ietf.org>
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 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
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf