Re: [ippm] RFC 8321 and 8889

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 13 August 2021 09:31 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 BC1A43A0DF3 for <ippm@ietfa.amsl.com>; Fri, 13 Aug 2021 02:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E27sr4WdBU3H for <ippm@ietfa.amsl.com>; Fri, 13 Aug 2021 02:31:15 -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 E87093A0DFB for <ippm@ietf.org>; Fri, 13 Aug 2021 02:31:13 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GmJFJ4qtNz6GBQr; Fri, 13 Aug 2021 17:30:28 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 13 Aug 2021 11:31:09 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.008; Fri, 13 Aug 2021 11:31:09 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Martin Duke <martin.h.duke@gmail.com>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] RFC 8321 and 8889
Thread-Index: AQHXj6gWPejcFtn9s0ywj57o9VM7G6txKo9A
Date: Fri, 13 Aug 2021 09:31:09 +0000
Message-ID: <6ae14cd1c93a400990abe1c95876fe93@huawei.com>
References: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
In-Reply-To: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.95.194]
Content-Type: multipart/alternative; boundary="_000_6ae14cd1c93a400990abe1c95876fe93huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/G8GmWCPPfRA1yo6T6FFtbdwFkdY>
Subject: Re: [ippm] RFC 8321 and 8889
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Aug 2021 09:31:21 -0000

Hi Martin,
I can surely provide detailed information about two implementations: one from Huawei and the other from Telecom Italia.
For this reason, I would suggest to consider to elevate the Alternate Marking Framework to Proposed Standard.

Regards,

Giuseppe


From: ippm <ippm-bounces@ietf.org> On Behalf Of Martin Duke
Sent: Thursday, August 12, 2021 8:26 PM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] RFC 8321 and 8889

Hello IPPM,

(with AD hat on)

The IESG is currently considering
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08
which is the implementation of RFC 8321<https://www.rfc-editor.org/rfc/rfc8321.html> and 8889<https://www.rfc-editor.org/rfc/rfc8889.html> techniques in an IPv6 framework. IIUC, this is very much how things are "supposed to work" -- measurement definitions and methodology are done by IPPM, and the protocol-specific instantiations are in the respective working groups.

However, there are complications in that 8321 and 8889 are Experimental RFCs, and the ipv6-alt-mark draft is a Proposed Standard. This has resulted in text from 8321/8889 going into ipv6-alt-mark so that it can be elevated to PS. I'm told that, if the status quo holds, other drafts will reference ipv6-alt-mark to avoid a downref. This seems suboptimal.

I would prefer that we take one of the two following actions:
1) If the WG has consensus that we are comfortable that there is enough experience with 8321 and/or 8889 to elevate them to PS, I can initiate a document action to change their status.

2) If there is no such consensus, ipv6-alt-mark should be Experimental.

In either case, the draft can probably lose some of the duplicate text.

Logically, there is a third option -- that the bits of the RFCs copied in the draft are mature enough to be a standard, but that the others aren't. Though I'm not an expert, I doubt this is the case. But if people believe it to be true, we'll have to come up with new options.

I would be grateful for the working group's thoughts about these documents and the ideas therein. Is it reasonable for people to read and reflect on this by 26 August (2 weeks from today?)

Thanks,
Martin