Re: [ippm] RFC 8321 and 8889

xiao.min2@zte.com.cn Fri, 13 August 2021 03:26 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 16D5A3A1AB1 for <ippm@ietfa.amsl.com>; Thu, 12 Aug 2021 20:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GnqWIpiENQ6p for <ippm@ietfa.amsl.com>; Thu, 12 Aug 2021 20:26:20 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 1208A3A1AB0 for <ippm@ietf.org>; Thu, 12 Aug 2021 20:26:19 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id EA72DBA6108ACD29CF3F; Fri, 13 Aug 2021 11:26:14 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 44009694D9239F834137; Fri, 13 Aug 2021 11:26:13 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl2.zte.com.cn with SMTP id 17D3Q3wP063063; Fri, 13 Aug 2021 11:26:03 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Fri, 13 Aug 2021 11:26:03 +0800 (CST)
Date: Fri, 13 Aug 2021 11:26:03 +0800
X-Zmail-TransId: 2afc6115e64b84c11cfa
X-Mailer: Zmail v1.0
Message-ID: <202108131126032940748@zte.com.cn>
In-Reply-To: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
References: CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: martin.h.duke@gmail.com
Cc: ippm@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 17D3Q3wP063063
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/2EfihrEQEVnDeTjfK9TpvgM1gDw>
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 03:26:25 -0000

Hi Martin,

AFAIK, RFC 8321 has been implemented (by at least three vendors) and deployed (by at least one operator) in MPLS mobile backhaul networks.
Although not all measuring options described in RFC 8321 are implemented, e.g. only fixed-timer block and double-marking methodology are used, I believe it's still reasonable to elevate it to PS.
As to RFC 8889, I have no idea on its maturity level, so I'll let others to comment.
With that said, I tend to support that we take action 1) and elevate RFC 8321 to PS.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人:MartinDuke
收件人:IETF IPPM WG;
日 期 :2021年08月13日 02:27
主 题 :[ippm] RFC 8321 and 8889
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

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 and 8889 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