[ippm] 答复: RFC 8321 and 8889

qinfengwei <qinfengwei@chinamobile.com> Thu, 19 August 2021 04:16 UTC

Return-Path: <qinfengwei@chinamobile.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 99F403A15A0 for <ippm@ietfa.amsl.com>; Wed, 18 Aug 2021 21:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 q0TMaaRXpfaY for <ippm@ietfa.amsl.com>; Wed, 18 Aug 2021 21:16:33 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 015E73A159C for <ippm@ietf.org>; Wed, 18 Aug 2021 21:16:32 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee2611ddb1e8cf-cade1; Thu, 19 Aug 2021 12:16:30 +0800 (CST)
X-RM-TRANSID: 2ee2611ddb1e8cf-cade1
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[223.69.29.81]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee9611ddb1c2ea-905b4; Thu, 19 Aug 2021 12:16:30 +0800 (CST)
X-RM-TRANSID: 2ee9611ddb1c2ea-905b4
From: qinfengwei <qinfengwei@chinamobile.com>
To: 'Martin Duke' <martin.h.duke@gmail.com>, 'IETF IPPM WG' <ippm@ietf.org>
References: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
In-Reply-To: <CAM4esxQHOV2uWJGeqhSyWAbgr36n71S8Ss1bc-1qFiFex9Wu3w@mail.gmail.com>
Date: Thu, 19 Aug 2021 12:16:27 +0800
Message-ID: <004d01d794b0$fce85b00$f6b91100$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01D794F4.0B0B9B00"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHXj6gXYFLOXr8EnUa/cGcJ/ISGV6t6QYUA
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/LTzv83k4Td3uegS9PbdyinnS1IE>
Subject: [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: Thu, 19 Aug 2021 04:16:40 -0000

Hi Martin and WG,

         We found RFC8321 is very useful and applied in our network including the transport network and data center.

         Our experience shows RFC8321 is mature.

         I would prefer the option 1, and elevate RFC 8321/8889 to PS.

 

 

 

Thanks,

Fengwei Qin

 

发件人: ippm [mailto:ippm-bounces@ietf.org] 代表 Martin Duke
发送时间: 2021年8月13日 02:26
收件人: IETF IPPM WG
主题: [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