Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

From: Tianran Zhou <[email-masked]>
Date: Fri, 22 Oct 2021 06:27:29 +0000

Hi WG,

There are many interests in this working group working on the alternate marking, RFC8321 and RFC8889.
As you may have seen, we applied this method in IPv6, and the draft is in IESG review.
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/

Based on the above draft, and the comments/suggestions we received, we produced an Enhanced Alternate Marking Method.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/

This document extends the IPv6 Alternate Marking Option,  to provide the enhanced capabilities and allow advanced functionalities.

We hope you like this idea.
Any comments are welcome.

Thanks,
Tianran

---

From: Haoyu Song <[email-masked]>
Date: Fri, 22 Oct 2021 17:59:19 +0000

Hi Tianran,

I'm interested in this work but I think the draft needs to be expanded to clarify several points

  1.  The meaning and usage of the flag bits need to be further explained. For example, what's the true meaning of "flow direction"?
  2.  The use of meta info is not explained.
  3.  The capability description is too terse for me to catch the real impact of the enhancement. For example, what's the thicker loss measurement and more dense delay measurement? How does the new enhancement help to achieve the goal and how much can it help?

Thanks,
Haoyu

From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Thursday, October 21, 2021 11:27 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi WG,

There are many interests in this working group working on the alternate marking, RFC8321 and RFC8889.
As you may have seen, we applied this method in IPv6, and the draft is in IESG review.
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-ipv6-alt-mark%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4c8f62b3f93a4cda92d908d9952517cc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637704808830897476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sg4Lo2JNBtmnAHkjIyry5Y4uaPzOEsGGKWCbWZ9pYDQ%3D&reserved=0>

Based on the above draft, and the comments/suggestions we received, we produced an Enhanced Alternate Marking Method.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-ippm-enhanced-alternate-marking%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C4c8f62b3f93a4cda92d908d9952517cc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637704808830907402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EV9y8%2FfV1Oe8MgcSC15uF4CC7qnLKKRXFVhyQ7q10lw%3D&reserved=0>

Thanks,
Tianran

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 25 Oct 2021 01:53:54 +0000

Hi Haoyu,

Thanks very much for you interest and comments.
This version mainly shows the idea for extension. I will add more details in the next version.
And please see in line below for my initial thoughts.

Cheers,
Tianran

From: Haoyu Song [mailto:[email-masked]]
Sent: Saturday, October 23, 2021 1:59 AM
To: Tianran Zhou <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi Tianran,

1.       The meaning and usage of the flag bits need to be further explained. For example, what's the true meaning of "flow direction"?
ZTR> Yes, I will add more details in the next version. In brief, the "flow direction" is used to address the requirement on setup backward direction flow monitoring automatically. Alt-MK applied to one direction only before. This flag is use to indicate the need to set up.

2.       The use of meta info is not explained.
ZTR> The meta info is used to provide some more information to help the Alt-MK measurement. I just listed some idea in the draft, but not describe the detailed data format. This will be added in the next version.

3.       The capability description is too terse for me to catch the real impact of the enhancement. For example, what's the thicker loss measurement and more dense delay measurement? How does the new enhancement help to achieve the goal and how much can it help?
ZTR> Yes, I will add more info later. On you specific question on the delay enhancement, our idea is to add a timestamp taken from the head node, as the meta data. There are many ways to use it. For example, in this way, the intermediate node can always compare with this timestamp to check the delay.

Thanks,
Haoyu

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Thursday, October 21, 2021 11:27 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi WG,

Thanks,
Tianran

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 24 Oct 2021 19:25:13 -0700

Hi Tianran,
thank you for bringing up this work. I've read the draft and have several
comments, questions. Please kindly find those below:

   - Based on the comments during the IESG review of
   draft-ietf-6man-ipv6-alt-mark, I see a value in extending FlowMonID. That
   might reduce the probability of a collision.
   - What could be the use case for the Flow direction identification flag?
   As the AltMark is applied to the data traffic, wouldn't it always be in the
   forward direction?
   - I'm also not clear about the use of the Measurement mode flag. I
   thought that the mode, hbh or e2e, is determined by the choice of
   appropriate IPv6 EH - Hop-by-Hop Option Header or Destination Option
   Header, accordingly. Am I missing something here?
   - Reading the draft, it was not clear how the extended header helps to
   lower marking intervals increasing the density of measurements.

Regards,
Greg

On Thu, Oct 21, 2021 at 11:27 PM Tianran Zhou <[email-masked]>
wrote:

> Based on the above draft, and the comments/suggestions we received, we
> produced an Enhanced Alternate Marking Method.
>
>
> This document extends the IPv6 Alternate Marking Option,  to provide the
> enhanced capabilities and allow advanced functionalities.
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 25 Oct 2021 03:24:56 +0000

Hi Greg,

Thanks very much for your interest and review comments.
Please see in line with my thoughts.

Cheers,
Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, October 25, 2021 10:25 AM
To: Tianran Zhou <[email-masked]>
Cc: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi Tianran,
thank you for bringing up this work. I've read the draft and have several comments, questions. Please kindly find those below:
·  Based on the comments during the IESG review of draft-ietf-6man-ipv6-alt-mark, I see a value in extending FlowMonID. That might reduce the probability of a collision.
ZTR> Thanks. I appreciate you agree with the value on this.
·  What could be the use case for the Flow direction identification flag? As the AltMark is applied to the data traffic, wouldn't it always be in the forward direction?
ZTR> Copied from my reply to Haoyu,  I will add more details in the next version. In brief, the “flow direction” is used to address the requirement on setup backward direction flow monitoring automatically. Alt-MK applied to one direction only before. This flag is used to indicate the need to set up.
·  I'm also not clear about the use of the Measurement mode flag. I thought that the mode, hbh or e2e, is determined by the choice of appropriate IPv6 EH - Hop-by-Hop Option Header or Destination Option Header, accordingly. Am I missing something here?
ZTR> Your perspective is correct. This idea is based on our practice on existing network. There were discussions in 6MAN or so, about the EH processing capability.
·  Reading the draft, it was not clear how the extended header helps to lower marking intervals increasing the density of measurements.
ZTR> I will add more info later. Our idea is to add a timestamp taken from the head node, as the meta data. In this way, the intermediate node can always compare with this timestamp to check the delay. So not depend on the delay bit.
Regards,
Greg

On Thu, Oct 21, 2021 at 11:27 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

Thanks,
Tianran
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 25 Oct 2021 06:51:28 +0000

Hi Greg,

I am sorry. I was interrupted, and sent out an incomplete email.
Please see below.

Tianran

From: Tianran Zhou
Sent: Monday, October 25, 2021 11:25 AM
To: 'Greg Mirsky' <[email-masked]>
Cc: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi Greg,

Cheers,
Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, October 25, 2021 10:25 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] Enhanced Alternate Marking draft-zhou-ippm-enhanced-alternate-marking-07

Hi Tianran,
ZTR> Your perspective is correct. This idea is based on our practice on existing network. There were discussions in 6MAN or so, about the EH processing capability. The standard approach as you mentioned above requires implementation and support on several EHs, which could be complex. We consider in some cases, implementation of one EH is applied. For example, if we only implement HbH, then intermediate nodes could use the measurement mode flag in the extension part to decide whether to do further actions.

Thanks,
Tianran