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

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 29 April 2024 09:48 UTC

Return-Path: <giuseppe.fioccola@huawei.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 4E8F8C16940F; Mon, 29 Apr 2024 02:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 n6-Jmup6zH3y; Mon, 29 Apr 2024 02:48:13 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF00C14F6F3; Mon, 29 Apr 2024 02:48:13 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VSdjn4qrXz6K5s9; Mon, 29 Apr 2024 17:45:33 +0800 (CST)
Received: from frapeml100008.china.huawei.com (unknown [7.182.85.131]) by mail.maildlp.com (Postfix) with ESMTPS id B489F140C72; Mon, 29 Apr 2024 17:48:10 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml100008.china.huawei.com (7.182.85.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 29 Apr 2024 11:48:10 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.035; Mon, 29 Apr 2024 11:48:10 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>, "draft-gfz-opsawg-ipfix-alt-mark@ietf.org" <draft-gfz-opsawg-ipfix-alt-mark@ietf.org>
CC: opsawg <opsawg@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>, "draft-ietf-opsawg-ipfix-on-path-telemetry@ietf.org" <draft-ietf-opsawg-ipfix-on-path-telemetry@ietf.org>
Thread-Topic: [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark
Thread-Index: AQHalulfZwbveubKrEi7JZm71r8eI7F6hs8AgARTlSA=
Date: Mon, 29 Apr 2024 09:48:10 +0000
Message-ID: <9bae7cfc2f17431b90608536a8f53509@huawei.com>
References: <CA+RyBmWZY-p6XyYHZDHyvGou5De8iWQ20seTDjU8J6qiyvW1VQ@mail.gmail.com> <5E856D6B-5871-4917-A214-2A8F85F4963F@insa-lyon.fr>
In-Reply-To: <5E856D6B-5871-4917-A214-2A8F85F4963F@insa-lyon.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.201.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/gCr3yV3L5eHptmRBzQLJRr9Bv0Q>
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: Mon, 29 Apr 2024 09:48:19 -0000

Dear Alex, All,
Thanks a lot for your comments.
We will change the intended status to standards track in the next revision of the draft.
Your considerations about the IEs for the node delay between the ingress and the egress interface make sense, especially in the case of Alternate-Marking.
As you noted, an implementation, that can monitor both interfaces, may export only a single mean delay value. But the delay of the single node may also be of interest in some use cases.
Since draft-ietf-opsawg-ipfix-on-path-telemetry introduces the IEs for on-path delay in a general way, the IEs for the node delay could also be added in this draft. What is your opinion?

Regards,

Giuseppe


-----Original Message-----
From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr> 
Sent: Friday, April 26, 2024 5:05 PM
To: draft-gfz-opsawg-ipfix-alt-mark@ietf.org
Cc: opsawg <opsawg@ietf.org>; IETF IPPM WG <ippm@ietf.org>; Greg Mirsky <gregimirsky@gmail.com>
Subject: Re: [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark

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