IETF Logo Mail Archive

Re: [ippm] [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark

Alex Huang Feng <alex.huang-feng@insa-lyon.fr> Fri, 26 April 2024 15:05 UTC

Return-Path: <alex.huang-feng@insa-lyon.fr>
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 4AEECC14F681; Fri, 26 Apr 2024 08:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.727
X-Spam-Level:
X-Spam-Status: No, score=-4.727 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, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=insa-lyon.fr
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 3TylK_pkkl-i; Fri, 26 Apr 2024 08:05:25 -0700 (PDT)
Received: from smtpout02-ext4.partage.renater.fr (smtpout02-ext4.partage.renater.fr [194.254.241.31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB18C14F6AB; Fri, 26 Apr 2024 08:05:22 -0700 (PDT)
Received: from zmtaauth02.partage.renater.fr (zmtaauth02.partage.renater.fr [194.254.241.25]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id C10C4BFB40; Fri, 26 Apr 2024 17:05:15 +0200 (CEST)
Received: from zmtaauth02.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPS id B7225A0850; Fri, 26 Apr 2024 17:05:15 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTP id A5ECAA0843; Fri, 26 Apr 2024 17:05:15 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zmtaauth02.partage.renater.fr A5ECAA0843
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insa-lyon.fr; s=CB289C06-95B8-49FE-9C4B-D197C6D2E7CB; t=1714143915; bh=YwCmK7JeIM7hL+RJ521a/zZBRijMefKtVqieKdXMviE=; h=Mime-Version:From:Date:Message-Id:To; b=P0D6MGuXdtYmimCnLKbhDrSnbd0ifTDV/TNqnEgwuNnHjIqQ1O8LYpubXOr8/JCND pXwzRXJ+F/4AsZ/1dH8pQLkKNru/vltg4ihQXkQZU9cHWIsHlrCxyntZzVCQuwOJcD cNciwfC4OE1WOGJ7O/55npeJgzvBvio6z/L499Kv/ybhRJ3jFelhtUcr0X1ZTUOJ8h gReVmnvLsFMb062rh3qnU3AmbZv7GBf7PK4vgR5MhgX5nU2Lf2UqKgb+QLi/ZVxGmi kUslsGU5PQlsUjhHeBig572SsepzWbkqG3OI27ba4TMToWEtfhUNzKMvPdBwQS6FPF uzb8a1ziP9G3Q==
Received: from zmtaauth02.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth02.partage.renater.fr [127.0.0.1]) (amavis, port 10026) with ESMTP id vaUYsbM_0eh1; Fri, 26 Apr 2024 17:05:15 +0200 (CEST)
Received: from 38.150.99.10 (unknown [194.254.241.250]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPA id C9C6FA0874; Fri, 26 Apr 2024 17:05:10 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
In-Reply-To: <CA+RyBmWZY-p6XyYHZDHyvGou5De8iWQ20seTDjU8J6qiyvW1VQ@mail.gmail.com>
Date: Sat, 27 Apr 2024 00:04:48 +0900
Cc: opsawg <opsawg@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E856D6B-5871-4917-A214-2A8F85F4963F@insa-lyon.fr>
References: <CA+RyBmWZY-p6XyYHZDHyvGou5De8iWQ20seTDjU8J6qiyvW1VQ@mail.gmail.com>
To: draft-gfz-opsawg-ipfix-alt-mark@ietf.org
X-Mailer: Apple Mail (2.3731.700.6)
X-Virus-Scanned: clamav-milter 0.103.8 at clamav01
X-Virus-Status: Clean
X-Renater-Ptge-SpamState: clean
X-Renater-Ptge-SpamScore: -100
X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgedvledrudelledgkeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecutffgpfetvffgtfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhgvgicujfhurghnghcuhfgvnhhguceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqeenucggtffrrghtthgvrhhnpefhtefgudejgfejtdegffeiueejkeejiefgudejvdelheeijefgveeuhfdugeevleenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeduleegrddvheegrddvgedurddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelgedrvdehgedrvdeguddrvdehtddphhgvlhhopeefkedrudehtddrleelrddutddpmhgrihhlfhhrohhmpegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrhdpnhgspghrtghpthhtohepgedprhgtphhtthhopegurhgrfhhtqdhgfhiiqdhophhsrgifghdqihhpfhhigidqrghlthdqmhgrrhhksehivghtfhdrohhrghdprhgtphhtthhopehophhsrgifghesihgvthhfrdhorhhgpdhrtghpthhtohepihhpphhmsehivghtfhdrohhrghdprhgtphhtthhopehgrhgvghhimhhirhhskhihsehgmhgrihhlrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Zyj4Pz_6wq6yMGRgjaogC6V-V4E>
Subject: Re: [ippm] [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark
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: Fri, 26 Apr 2024 15:05:29 -0000

Dear authors,

I finally got some time to read the draft. 
I have the same comment as Greg, Standard track seems more appropriate.

Also, I have also read RFC9341 and Alt-Mark can also compute the delay between the ingress interface and the egress interface within a single node (node monitoring).
I have done a quick research on the IPFIX registry, AFAIK, the only delays defined in that registry are from the current work from draft-ietf-opsawg-ipfix-on-path-telemetry. Yet this delay is between the encapsulating node and the local node.
I wonder if it is worth defining an IE for the delay between the ingress and the egress interface within a single node.
I would imagine an implementation able to monitor both interfaces and just exporting the average delay directly from the node (or even the mean, max, min as draft-ietf-opsawg-ipfix-on-path-telemetry are doing).
Any thoughts about this?

Other than that, I think the draft is well written and it explains clearly why these IEs are necessary for IPFIX.

Regards,
Alex

> On 25 Apr 2024, at 17:19, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> Dear, Authors et al.,
> thank you for your continued work on the Alternate Marking method. In my opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making the use of IPFIX operationally viable option for the Alternate Marking method. While I've read the document, it seems that its current track, Informational, may not be consistent with the request for specific actions from IANA. Could it be that the Standard track is more appropriate for the draft?
> 
> Regards,
> Greg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

v2.27.6 | Report a Bug | By Email | System Status