IETF Logo Mail Archive

Re: [ippm] RFC 8321 and 8889

Tianran Zhou <zhoutianran@huawei.com> Fri, 20 August 2021 01:30 UTC

Return-Path: <zhoutianran@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 B57643A16D8 for <ippm@ietfa.amsl.com>; Thu, 19 Aug 2021 18:30:29 -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, HTML_MESSAGE=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 nWJRJ3qfqnia for <ippm@ietfa.amsl.com>; Thu, 19 Aug 2021 18:30:24 -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 63FA93A16D5 for <ippm@ietf.org>; Thu, 19 Aug 2021 18:30:24 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GrPDy6wCFz6BHws; Fri, 20 Aug 2021 09:29:22 +0800 (CST)
Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 20 Aug 2021 03:30:19 +0200
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 20 Aug 2021 09:30:17 +0800
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2176.012; Fri, 20 Aug 2021 09:30:17 +0800
From: Tianran Zhou <zhoutianran@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: AQHXj6gXYFLOXr8EnUa/cGcJ/ISGV6t7pSdw
Date: Fri, 20 Aug 2021 01:30:17 +0000
Message-ID: <86e63d87eaf6425f860d0ae4c5011187@huawei.com>
References: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
In-Reply-To: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.128]
Content-Type: multipart/alternative; boundary="_000_86e63d87eaf6425f860d0ae4c5011187huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/e5f3WlXyUzhwLah7M5edfsFwosg>
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, 20 Aug 2021 01:30:30 -0000

Hi Martin and WG,

I am involved in several implementations and documents on alt-mk.
RFC8321 and 8889 are very useful in practice and are referenced in many other drafts.
It would be really helpful if they can be elevated to PS.

Cheers,
Tianran
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Friday, August 13, 2021 2:26 AM
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

v2.23.0 | Report a Bug | By Email