Subject: [ippm] RFC 8321 and 8889

From: Martin Duke <[email-masked]>
Date: Thu, 12 Aug 2021 11:26:19 -0700

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

---

From: Jai Kumar <[email-masked]>
Date: Thu, 12 Aug 2021 19:04:19 +0000

Quick feedback on 8321.
8321 is deployed in 5G and SP deployment and has support from Broadcom as silicon vendor.

Let me know if any supporting document (non-confidential) with deployment details are needed to elevate the draft status to PS.

Note: I am not on the author list of the draft.

-Jai

From: ippm <[email-masked]> on behalf of Martin Duke <[email-masked]>
Date: Thursday, August 12, 2021 at 11:26 AM
To: IETF IPPM WG <[email-masked]>
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.

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

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

---

From: <[email-masked]>
Date: Fri, 13 Aug 2021 11:26:03 +0800 (CST)

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
[email-masked]
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.

Thanks,
Martin

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 13 Aug 2021 09:31:09 +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 <[email-masked]> On Behalf Of Martin Duke
Sent: Thursday, August 12, 2021 8:26 PM
To: IETF IPPM WG <[email-masked]>
Subject: [ippm] RFC 8321 and 8889

Hello IPPM,

(with AD hat on)

Thanks,
Martin

---

From: Cociglio Mauro <[email-masked]>
Date: Sat, 14 Aug 2021 13:24:01 +0000

Hi Martin.
Telecom Italia is using Alternate Marking defined n RFC8321 and RFC8889 to monitor LTE backhauling as also described in
https://ieeexplore.ieee.org/abstract/document/8782889
So I am in favor to elevate these RFCs to PS.
Thanks.
Mauro

-------- Messaggio originale --------
Da: Martin Duke <[email-masked]>
Data: 12/08/21 20:27 (GMT+01:00)
A: IETF IPPM WG <[email-masked]>
Oggetto: [EXT] [ippm] RFC 8321 and 8889

Hello IPPM,

(with AD hat on)

Thanks,
Martin

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 19 Aug 2021 12:16:27 +0800

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:[email-masked]] 代表 Martin Duke
发送时间: 2021年8月13日 02:26
收件人: IETF IPPM WG
主题: [ippm] RFC 8321 and 8889

Hello IPPM,

(with AD hat on)

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.

Thanks,

Martin

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 19 Aug 2021 08:23:09 -0400

Hi WG,
The alternate marking method has also been by
draft-gandhi-ippm-simple-direct-loss
as well as draft-gandhi-mpls-ioam. I support elevating to PS.

Thanks,
Rakesh

---

From: <[email-masked]>
Date: Fri, 20 Aug 2021 07:15:06 +0800 (CST)

Hi, Martin et al.,

I, too, support progressing RFC 8321 (as a co-author) and RFC 8889. The Alternate Marking method has been proven in several independent implementations that are deployed and provide valuable operational information. Also, progressing to the Standards track will help our work apply the Alternate Marking in non-IP environments, e.g., BIER and SFC NSH.

I'll be glad to help any way I can.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: RakeshGandhi
To: Martin Duke;
CC: IETF IPPM WG;
Date: 2021/08/19 05:23
Subject: Re: [ippm] RFC 8321 and 8889

Hi WG,
The alternate marking method has also been by draft-gandhi-ippm-simple-direct-loss as well as draft-gandhi-mpls-ioam. I support elevating to PS.

Thanks,
Rakesh

Hello IPPM,

(with AD hat on)

Thanks,
Martin

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 20 Aug 2021 01:30:17 +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:[email-masked]] On Behalf Of Martin Duke
Sent: Friday, August 13, 2021 2:26 AM
To: IETF IPPM WG <[email-masked]>
Subject: [ippm] RFC 8321 and 8889

Hello IPPM,

(with AD hat on)

Thanks,
Martin

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 20 Aug 2021 09:59:52 +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<mailto:[email-masked]>
Date: 2021-08-13 02:26
To: IETF IPPM WG<mailto:[email-masked]>
Subject: [ippm] RFC 8321 and 8889
Hello IPPM,

(with AD hat on)

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

---

From: Martin Duke <[email-masked]>
Date: Fri, 20 Aug 2021 09:31:04 -0700

Thanks all,

I'm hearing strong consensus that 8321 should be a PS and somewhat weaker
support for 8889, but no dissents.

If anyone has serious concerns, this would be a good time to say so.

On Fri, Aug 20, 2021 at 3:02 AM Ran Pang(联通集团中国联通研究院-本部) <
[email-masked]> wrote:

> *From:* Martin Duke <[email-masked]>
> *Date:* 2021-08-13 02:26
> *To:* IETF IPPM WG <[email-masked]>
> *Subject:* [ippm] RFC 8321 and 8889
> Hello IPPM,
>
> (with AD hat on)
>
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
> If you have received this email in error please notify us immediately by
> e-mail. Please reply to [email-masked] ,you can unsubscribe from
> this mail. We will immediately remove your information from send catalogue
> of our.
>

---

From: "MORTON JR., AL" <[email-masked]>
Date: Fri, 20 Aug 2021 16:41:08 +0000

Hi Martin,

While I don’t have a serious concern, I’d prefer to elevate the parts of 8321 that *were implemented* to PS.  I think I read that some parts were not implemented and I look to those who reported on their implementations to say what they did.

This thinning-out of non-implemented capabilities was a feature of Standards Track Advancement processes in the past, so it makes sense to apply it here as well.  I realize this means a new draft, but the processing could be accelerated to match the need.

If the entire RFC 8321 was implemented, then this point is a non-issue.

hope this helps,
Al

From: ippm <[email-masked]> On Behalf Of Martin Duke
Sent: Friday, August 20, 2021 12:31 PM
To: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Cc: IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] RFC 8321 and 8889

Thanks all,

I'm hearing strong consensus that 8321 should be a PS and somewhat weaker support for 8889, but no dissents.

On Fri, Aug 20, 2021 at 3:02 AM Ran Pang(联通集团中国联通研究院-本部) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin and WG,

Best regards,
Pang Ran.

(with AD hat on)

The IESG is currently considering
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCBYQM6IB$>
which is the implementation of RFC 8321<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8321.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCEt7L0EO$> and 8889<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8889.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCD5jrkAO$> 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.

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

---

From: Martin Duke <[email-masked]>
Date: Mon, 23 Aug 2021 12:34:06 -0700

Hi Al, this is my impression as well. In a perfect world I would ask the WG
to do a bis draft to inventory what is mature and to deprecate the bits
that haven't seen real deployment. If it turns out that it's all deployed,
then we could do a simpler document action.

Is this work that anyone is interested in taking on?

On Fri, Aug 20, 2021 at 9:41 AM MORTON JR., AL <[email-masked]> wrote:

> Hi Martin,
>
>
>
> While I don’t have a serious concern, I’d prefer to elevate the parts of
> 8321 that **were implemented** to PS.  I think I read that some parts
> were not implemented and I look to those who reported on their
> implementations to say what they did.
>
>
>
> This thinning-out of non-implemented capabilities was a feature of
> Standards Track Advancement processes in the past, so it makes sense to
> apply it here as well.  I realize this means a new draft, but the
> processing could be accelerated to match the need.
>
>
>
> *From:* ippm <[email-masked]> *On Behalf Of *Martin Duke
> *Sent:* Friday, August 20, 2021 12:31 PM
> *To:* Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
> *Cc:* IETF IPPM WG <[email-masked]>
> *Subject:* Re: [ippm] RFC 8321 and 8889
>
>
>
> Thanks all,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-08__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCBYQM6IB$>
>
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8321.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCEt7L0EO$>
> and 8889
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8889.html__;!!BhdT!04s1Z7EtCnJrifRI3dUP1d0hps2MsV_B1gLCAqMQ1jJwmHnx-jiXCD5jrkAO$>
> 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.
>
>
>
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退
> 订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error
> please notify us immediately by e-mail. Please reply to
> [email-masked] ,you can unsubscribe from this mail. We will
> immediately remove your information from send catalogue of our.
>
>

---

From: <[email-masked]>
Date: Tue, 24 Aug 2021 08:41:41 +0800 (CST)

Hi Martin,

I'd like to work on this, as an author or a contributor.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：MartinDuke
收件人：MORTON JR., AL;
抄送人：Ran Pang(联通集团中国联通研究院-本部);IETF IPPM WG;
日 期 ：2021年08月24日 03:35
主 题 ：Re: [ippm] RFC 8321 and 8889
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Hi Al, this is my impression as well. In a perfect world I would ask the WG to do a bis draft to inventory what is mature and to deprecate the bits that haven't seen real deployment. If it turns out that it's all deployed, then we could do a simpler document action.

Thanks all,

On Fri, Aug 20, 2021 at 3:02 AM Ran Pang(联通集团中国联通研究院-本部)  <[email-masked]> wrote:
Hi Martin and WG,
From: Martin  Duke
To: IETF  IPPM WG

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 24 Aug 2021 02:40:09 +0000

Hi Martin,

IMO, the entire RFC8321 is mature enough to be proposed standard.
There are two options for coloring, say fixed number of packets, or fixed timer.
Different projects will choose the right way to use, just based on the requirement and scenario.
Min report a fixed timer based implementation, and Rakesh’s report (IMO) is based on fixed number of packets.
All these options are well discussed and analyzed.

My preference is to do a simple action to elevate RFC8321 to ps.

Best,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: Tuesday, August 24, 2021 3:34 AM
To: MORTON JR., AL <[email-masked]>
Cc: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] RFC 8321 and 8889

On Fri, Aug 20, 2021 at 9:41 AM MORTON JR., AL <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

hope this helps,
Al

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Duke
Sent: Friday, August 20, 2021 12:31 PM
To: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] RFC 8321 and 8889

Thanks all,

Best regards,
Pang Ran.

(with AD hat on)

Thanks,
Martin

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 24 Aug 2021 08:36:07 +0000

Hi Martin,
In RFC 8321 there are only two alternatives in relation to the number of bits: single marking and double marking. And both are implemented.
As author of RFC 8321, I think that it can be simply elevated as is to PS by slightly revising or by omitting some text that refers to the experiment already done (e.g. section 5).

Regards,

Giuseppe

Sent: Monday, August 23, 2021 9:34 PM

hope this helps,
Al

Thanks all,

Best regards,
Pang Ran.

(with AD hat on)

Thanks,
Martin

---

From: Martin Duke <[email-masked]>
Date: Fri, 27 Aug 2021 13:37:08 -0700

Hi all,

Thanks for all the feedback.

I have launched an IETF last call for the status change:
https://datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/

As this call continues, it would be worthwhile for someone to inventory
8321 (and especially 8889) to see if there are any pieces that ought not to
progress. We already have a volunteer to shepherd a bis document for either
document, if need be.

Martin

On Tue, Aug 24, 2021 at 1:36 AM Giuseppe Fioccola <
[email-masked]> wrote:

> Hi Martin,
>
> In RFC 8321 there are only two alternatives in relation to the number of
> bits: single marking and double marking. And both are implemented.
>
> As author of RFC 8321, I think that it can be simply elevated as is to PS
> by slightly revising or by omitting some text that refers to the experiment
> already done (e.g. section 5).
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> *From:* ippm <[email-masked]> *On Behalf Of * Martin Duke
> *Sent:* Monday, August 23, 2021 9:34 PM
> *To:* MORTON JR., AL <[email-masked]>
> *Cc:* Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>; IETF IPPM WG <
> [email-masked]>
> Hi Al, this is my impression as well. In a perfect world I would ask the
> WG to do a bis draft to inventory what is mature and to deprecate the bits

---

From: Giuseppe Fioccola <[email-masked]>
Date: Sat, 28 Aug 2021 07:18:30 +0000

Hi Martin,
Thanks a lot for launching the IETF Last Call for the status change of RFC8321 and RFC8889.
Please note that I’m available to inventory and work on a possible new draft on RFC8321bis and RFC8889bis, depending on the outcome from the Last Call.

Regards,

Giuseppe

From: Martin Duke <[email-masked]>
Sent: Friday, August 27, 2021 10:37 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: MORTON JR., AL <[email-masked]>; Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>; IETF IPPM WG <[email-masked]>; Erik Kline <[email-masked]>
Subject: Re: [ippm] RFC 8321 and 8889

Hi all,

As this call continues, it would be worthwhile for someone to inventory 8321 (and especially 8889) to see if there are any pieces that ought not to progress. We already have a volunteer to shepherd a bis document for either document, if need be.

Martin

On Tue, Aug 24, 2021 at 1:36 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,
In RFC 8321 there are only two alternatives in relation to the number of bits: single marking and double marking. And both are implemented.
As author of RFC 8321, I think that it can be simply elevated as is to PS by slightly revising or by omitting some text that refers to the experiment already done (e.g. section 5).

Regards,

Giuseppe

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Duke
Sent: Monday, August 23, 2021 9:34 PM
To: MORTON JR., AL <[email-masked]<mailto:[email-masked]>>
Cc: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] RFC 8321 and 8889

hope this helps,
Al

Thanks all,

Best regards,
Pang Ran.

(with AD hat on)

Thanks,
Martin

---

From: "MORTON JR., AL" <[email-masked]>
Date: Sat, 28 Aug 2021 20:11:48 +0000

Hi Giuseppe,

I read in the [0] that
... it is possible to use the two least-significant bits of
   the DSCP field (bit 0 and bit 1) to implement the method without
   affecting QoS policies.
but this was a single domain solution for the experiment described.

Of the four alternate marking method applications (for bit locations) listed in section 5, which ones have been implemented?

thanks,
Al

[0] https://datatracker.ietf.org/doc/html/rfc8321#section-5

From: Giuseppe Fioccola <[email-masked]>
Sent: Saturday, August 28, 2021 3:19 AM
To: Martin Duke <[email-masked]>
Cc: MORTON JR., AL <[email-masked]>; Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>; IETF IPPM WG <[email-masked]>; Erik Kline <[email-masked]>
Subject: RE: [ippm] RFC 8321 and 8889

Hi Martin,

Regards,

Giuseppe

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 27, 2021 10:37 PM
To: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Cc: MORTON JR., AL <[email-masked]<mailto:[email-masked]>>; Ran Pang(联通集团中国联通研究院-本部) <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; Erik Kline <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] RFC 8321 and 8889

Hi all,

I have launched an IETF last call for the status change:
https://datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/__;!!BhdT!337sv1u42kl9wmAzWIEjgBRRkvACHnb4mqVGIZgNmvHrDo_wKq9HrNco9TS_$>

Martin

Regards,

Giuseppe

hope this helps,
Al

Thanks all,

Best regards,
Pang Ran.

(with AD hat on)

Thanks,
Martin

---

From: Giuseppe Fioccola <[email-masked]>
Date: Sun, 29 Aug 2021 10:59:46 +0000

Hi Al,
Yes, the use of the DSCP field as marking field was mentioned in RFC 8321 just to explain the initial experiment done in Telecom Italia in 2010 by leveraging the available router functions. But this is now outdated by the current implementations.

Regarding the applications listed in Section 5 (IPFPM, OAM Performance Measurement for BIER, SFC, MPLS, Active Performance Measurement) are all implemented at different stages by vendors (e.g. Huawei, Cisco, ZTE, Broadcom..) and deployed by operators (Telecom Italia, China Mobile, China Unicom..) as also confirmed by the answers to the poll launched by Martin Duke two weeks ago.
Since the number of the applications is expected to change over time, this section should be updated by adding the latest implementations (SR-MPLS, IPv6, SRv6) and, maybe, omitted in a Proposed Standard document.

Regards,

Giuseppe

From: MORTON JR., AL <[email-masked]>
Sent: Saturday, August 28, 2021 10:12 PM
To: Giuseppe Fioccola <[email-masked]>; Martin Duke <[email-masked]>
Cc: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>; IETF IPPM WG <[email-masked]>; Erik Kline <[email-masked]>
Subject: RE: [ippm] RFC 8321 and 8889

Hi Giuseppe,

I read in the [0] that

thanks,
Al

From: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 28, 2021 3:19 AM
To: Martin Duke <[email-masked]<mailto:[email-masked]>>
Cc: MORTON JR., AL <[email-masked]<mailto:[email-masked]>>; Ran Pang(联通集团中国联通研究院-本部) <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; Erik Kline <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] RFC 8321 and 8889

Hi Martin,

Regards,

Giuseppe

Hi all,

Martin

Regards,

Giuseppe

hope this helps,
Al

Thanks all,

Best regards,
Pang Ran.

(with AD hat on)

Thanks,
Martin