IETF Logo Mail Archive

Re: [ippm] [OPSAWG] draft-spiegel-ippm-ioam-rawexport

Thomas.Graf@swisscom.com Wed, 20 March 2024 23:18 UTC

Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B4AC14F6FA; Wed, 20 Mar 2024 16:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.406
X-Spam-Level:
X-Spam-Status: No, score=-4.406 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_MSPIKE_H2=-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_BLOCKED=0.001, 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 ni1sZFVpZMCD; Wed, 20 Mar 2024 16:18:42 -0700 (PDT)
Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 E6E06C14F708; Wed, 20 Mar 2024 16:18:28 -0700 (PDT)
Received: by mail.swisscom.com; Thu, 21 Mar 2024 00:18:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1710976706; bh=h8anq3A1IHD6HW7E5XKloCOKkWdeN8j0tc/nF8xweA4=; h=From:To:Subject:Date:References:In-Reply-To; b=rOaiX4NEWaBcaZt/mYrxR1/Rnq9TXs7Ta4zfg1mtjHiiyuEplYGYuNDELlZgh4pAI mMdydJmhMtNvWHk26qqstIgb8WPoK0GI801JLxdtjejnSPgyESrPnnImXFUCrJhPqE KVOU2phB169goJ8xXAp2JrW3jEUy9S7dr+FkpSasr3nk3nErs+YLvbdwQ0tfsNkdH7 H0NHQJvEGHLWwdmo2n9HE1U7WnObS/rtujyzJCcxfCeKrn2BI7a083nym0SZ8cwM1S +bIgFNQfJCS/tiBoymGrnc6d+y25ZoHr6Di8w14oEyleoYA72lNxNc/pQF1kkOu5Wp NYFtOwNKy4FhQ==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_2239820_924310776.1710976705547"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: reshad@yahoo.com, ippm@ietf.org, opsawg@ietf.org, justin.iurman@uliege.be
Thread-Topic: [OPSAWG] draft-spiegel-ippm-ioam-rawexport
Thread-Index: Adp5k6jXQyeYOkNbS/SPBXtiq8UoSwAC4NqAAF8/0bA=
Date: Wed, 20 Mar 2024 23:18:22 +0000
Message-ID: <22a690f804874d37bca954e25a02913f@swisscom.com>
References: <7192bc432d5d47aa89e7ced33ff4cc84@swisscom.com> <1145921607.3427282.1710816351156@mail.yahoo.com>
In-Reply-To: <1145921607.3427282.1710816351156@mail.yahoo.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=6905d264-6311-4399-8861-239dd6cedae3; 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-03-20T23:13:08Z; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/GDdUz6QlktZDquZjPwqWVv4K0jw>
Subject: Re: [ippm] [OPSAWG] draft-spiegel-ippm-ioam-rawexport
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 23:18:47 -0000

Dear Reshad,

I am refering to the IOAM data fields described in https://datatracker.ietf.org/doc/html/rfc9197#section-4. So that those entities can be decomposed on the network node and not at the data collection. Depending on IPFIX configuration, some of the dimensions will be key fields, some of them not. Depending on keying, IPFIX will aggregate the data on the network node before exporting to the data collection. That increases scalability of the solution. See https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark as example.

Best wishes
Thomas

From: Reshad Rahman <reshad@yahoo.com>
Sent: Tuesday, March 19, 2024 12:46 PM
To: ippm@ietf.org; opsawg@ietf.org; justin.iurman@uliege.be; Graf Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>
Subject: Re: [OPSAWG] draft-spiegel-ippm-ioam-rawexport


Be aware: This is an external email.


Hi Thomas,

By "IOAM dimension fields", are you referring to fields such as ingress/egress intf id etc in IOAM data? And you are requesting for these fields to be included to facilitate aggregation by another entity (e.g the aggregating mediator in RFC7015)? i.e you are not requesting for the IOAM node in this document (i.e. the exporter) to export aggregated data?

If I understood correctly, then I agree.

Regards,
Reshad.

On Monday, March 18, 2024, 08:42:41 PM EDT, Thomas.Graf@swisscom.com<mailto:Thomas.Graf@swisscom.com> <thomas.graf@swisscom.com<mailto:thomas.graf@swisscom.com>> wrote:



Dear Justin, Dear OPSAWG and IPPM working groups



Thanks a lot for the presentation at IPPM. I believe that this work needs further refinement by defining also IPFIX entities for IOAM which allow a decomposition of each IOAM dimension fields, thus enabling IPFIX Flow Aggregation as described in RFC 7015 which is a requirement to scale out for IOAM DEX and Trace Option Type. I believe this should be performed after the working group adoption and me should move forward quickly since IOAM is now getting implemented by vendors and applied by operators.



While shepherding IPFIX at OPSAWG, I noticed that most discussions where around choosing the right data type and aligning with the IPFIX registry. Not so much about exposing the right dimensions from the data plane.



draft-ietf-opsawg-ipfix-on-path-telemetry is already adopted and well progressed at OPSAWG. I suggest that draft-spiegel-ippm-ioam-rawexport is being adopted together with draft-gfz-opsawg-ipfix-alt-mark. With that we are covering both Hybrid Type options developed at IPPM.



In order to pool the IPFIX entity definitions, I believe OPSAWG would be the best place to move with draft-spiegel-ippm-ioam-rawexport forward.



I would appreciate feedback from IPPM and OPSAWG wherever they share my opinion or not.



Best wishes

Thomas


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg

v2.23.0 | Report a Bug | By Email