Re: [ippm] RFC 8321 and 8889

"Ran Pang(联通集团中国联通研究院- 本部)" <> Fri, 20 August 2021 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5371C3A1DBF for <>; Fri, 20 Aug 2021 03:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IhcNIIaGy36h for <>; Fri, 20 Aug 2021 03:00:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B114C3A1DBC for <>; Fri, 20 Aug 2021 03:00:05 -0700 (PDT)
X-AuditID: 0a000f35-7a1ff70000008152-80-611f7d1fd629
Received: from M10-HQ-MLCEN05.cnc.intra (Unknown_Domain []) by (Symantec Messaging Gateway) with SMTP id 7B.9C.33106.F1D7F116; Fri, 20 Aug 2021 17:59:59 +0800 (HKT)
Received: from M10-HQ-ML12.hq.cnc.intra ( by M10-HQ-MLCEN05.cnc.intra ( with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 20 Aug 2021 17:59:59 +0800
Received: from M10-HQ-ML02.hq.cnc.intra ( by M10-HQ-ML12.hq.cnc.intra ( with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 20 Aug 2021 17:59:52 +0800
Received: from M10-HQ-ML02.hq.cnc.intra ([fe80::143:a5ed:cbd6:7b9f]) by M10-HQ-ML02.hq.cnc.intra ([fe80::143:a5ed:cbd6:7b9f%19]) with mapi id 15.00.1497.023; Fri, 20 Aug 2021 17:59:52 +0800
From: =?utf-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?utf-8?B?5pys6YOoKQ==?= <>
To: Martin Duke <>, IETF IPPM WG <>
Thread-Topic: [ippm] RFC 8321 and 8889
Thread-Index: AQHXlZ/Tes5VZ8CeJE6kqszh1JF3dw==
Date: Fri, 20 Aug 2021 09:59:52 +0000
Message-ID: <d392b3339899499590e0d1c9e7a761a0@M10-HQ-ML02.hq.cnc.intra>
References: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d392b3339899499590e0d1c9e7a761a0M10HQML02hqcncintra_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsXC9fOKsq58rXyiwZkrlhY9D94xW0x//ILN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp42xpV8CyoYuOx80wNjAcCuhg5OSQETCR+ dV9m7GLk4hASOM8o0d86hwXC2ckosfvhXGaQKjBn085qiMRBRokpc44wgThsAk2MEie+rwdy ODhEBNwlfi0TBmkQFlCVmPF1K1RYTWLPAocuRnYgU0/iswpIAQtQwePlmxlBbF6gvofLFzFB bAqQWHNjM5jNKCArMe3RfTCbWUBcYu60WawQNwtILNlznhnCFpV4+fgfVNxAYuvSfSwQtoLE 8p57jBC92RJ/p7YxQ+wSlDg58wkLxC5liebj01knMIrNQrJiFpKWWUhaZgH9wiygKbF+lz5E iaLElO6H7BC2hkTrnLnsyOILGNlXMUoG+7pbGFsY6Pob6yVnZOYlluZlJufn6iXnbWIERSID v+kOxo+3PugdYmTiYDzEKMHBrCTCq8onnyjEm5JYWZValB9fVJqTWnyIUZqDRUmc94SuR4KQ QHpiSWp2ampBahFMlomDU6qBafajHVN23uB4x7/baHfTzZvTP/lmsAVt+lGxSfbM9ar/avqr BAMeG7/s/znh1eZzCceu7r1r67/gd4XYH/E32+89XNHxQogtN4dDxyZe8pmTmPJri4cOHD+E bptPKf6W88A8qr6p+v9+z/NTjePt4zYW59yXulUvs+K6j+nj3u6qAv9VE3a6iL1bXs2xr/rH rTlXX88+O7unUva682y5tAcPS8PKvtTazbut6yhiPbu0L8l9XfBy/RMtz7LOPYuPnP/defpO tWLm9/FbS0vLnVRyV1pHF0y+9I9p0Y7MD983xLdGsCbF7V8y/WTguh6n7f45nVNWf4zt0/B4 Y77FXuFV9PRNUgGM+4qP+0deX6fEUpyRaKjFXFScCADQHBaJMwMAAA==
Archived-At: <>
Subject: Re: [ippm] RFC 8321 and 8889
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Aug 2021 10:00:17 -0000

Hi Martin and WG,

The alt-mk described in RFC8321/8889 has been deployed in some of our networks.
It works well.
So I would like the WG consider elevate them to proposed standard.

Best regards,
Pang Ran.

From: Martin Duke<>
Date: 2021-08-13 02:26
Subject: [ippm] RFC 8321 and 8889
Hello IPPM,

(with AD hat on)

The IESG is currently considering
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?)

如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.