Subject: Re: [ippm] [spring] Active OAM in SRv6

From: Greg Mirsky <[email-masked]>
Date: Wed, 26 Jan 2022 15:01:19 -0800

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the
concept of Active IOAM is introduced in the IPPM WG draft
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags> it seems
to me like adding the IPPM WG community to the discussion is the right
thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <[email-masked]> wrote:

> Hi SPRING WG,
>
>
>
> Real time monitor on every node and every link on a network is necessary
> to detect  gray failures, which are the key culprit for poor QoS but hard
> to catch. SR provides an ideal mechanism, when working with some efficient
> planning algorithm, to achieve that with low cost.   Our proposal SRv6
> In-situ Active Measurement (SIAM) suggests a simple  active measurement
> approach which can support different
>
GIM>> I wonder what gaps you find in the existing active measurement
protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an
acronym). It appears to me that, for example, STAMP and its extensions,
including the SRPM draft
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm>,
comprehensively address the PM OAM requirements for SRv6.

> options of IOAM and other OAM methods in SRv6, without needing to worry
> about the extension header issue.
>
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

>
>
> Your comments, questions, and suggestions are very welcome. I’d like to
> know your opinion if you think this work is in scope and should be adopted
> by the working group.  If you are interested in contributing to this work,
> please also let me know.
> https://datatracker.ietf.org/doc/draft-song-spring-siam/
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 03:19:05 +0000

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm>, comprehensively address the PM OAM requirements for SRv6.
options of IOAM and other OAM methods in SRv6, without needing to worry about the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

Your comments, questions, and suggestions are very welcome. I’d like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 27 Jan 2022 00:03:13 -0500

Hi Haoyu

I think it would be good to identify the problem statement and gap with
existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be
utilized or fall short in what you are trying to achieve with Active OAM in
SRv6.

In-situ IOAM data packets is already possible with SRv6 as mentioned as
this draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

This draft as well mentioned as normative reference draft below provides
OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list
tracing capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-12>3

This draft as well also mentioned as normative reference draft below
provides in-situ IOAM for OAM and PM information can be piggybacked in data
packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational
and telemetry info in the data packets.

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05

Thanks

Gyan

On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zhoutianran=
[email-masked]> wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, January 27, 2022 7:01 AM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* [email-masked]; IETF IPPM WG <[email-masked]>
> *Subject:* Re: [ippm] [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu,
>
> <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags> it
> seems to me like adding the IPPM WG community to the discussion is the
> right thing to do.
>
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Haoyu Song <[email-masked]>
Date: Thu, 27 Jan 2022 18:42:13 +0000

Hi Gyan,

Thank you for your comments! Please see inline for response marked with [HS]

Best,
Haoyu

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, January 26, 2022 9:03 PM
To: Tianran Zhou <zhoutianran=[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Haoyu Song <[email-masked]>; IETF IPPM WG <[email-masked]>; [email-masked]
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

I think it would be good to identify the problem statement and gap with existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized or fall short in what you are trying to achieve with Active OAM in SRv6.

[HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, here we want to collect data from every node and every link on any path, without needing to set up any sessions. So the scope and coverage are different.

In-situ IOAM data packets is already possible with SRv6 as mentioned as this draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-data-16&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b6abSWTm77Z4Td%2B0X5hjmZBrFHTe%2FpPdZuWyXNEY3vU%3D&reserved=0>

[HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our proposal aims to provide such a solution, and (1) the solution avoids the issues on encapsulating the IOAM trace in EHs and (2) it's extensible to include OAM methods beyond IOAM.

This draft as well mentioned as normative reference draft below provides OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tracing capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-spring-srv6-oam-12&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EnHxos0Nc%2BF3d%2FehCZuIoSswxZ7udPLASp22oW5UES4%3D&reserved=0>3

[HS] This is for in-band OAM for SRv6 user traffic and it only works for triggering postcard exports (i.e., don't allow the packet to carry data). Our proposal support all the IOAM options and more important, it's an active method which means one can generate and inject probing packets to cover arbitrary paths by crafting an SRH.

This draft as well also mentioned as normative reference draft below provides in-situ IOAM for OAM and PM information can be piggybacked in data packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and telemetry info in the data packets.

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ali-spring-ioam-srv6-05&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9zM0yFTsl2jKvDDd8uDv0rtGcOsoaKY%2FEaqUXZmsJ5U%3D&reserved=0>

[HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhead concern (IOAM trace could be large) and other issues related to EH, I don't support such a solution.

[HS] The three drafts you mentioned are all be reference in our draft and discussed. We think our use cases are different and our approach is more general and extensible to our use cases.

Thanks

Gyan

On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>> wrote:
Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zqVhnbQoOc33My8fwqES5arm9vT0NCeUs3kIIkGPlug%3D&reserved=0>

Best,
Tianran

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5rsC694oCufl11dAM4pfiB%2FIKazRSNV3KWAmY%2B7hReA%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nbxsguDj1bZHDKu2RkvdBkOUxvrXeY%2F5Vlc5jBj2qgE%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aV3fE%2BZWpaILCWRLJQEo98%2FZ65gN5U%2FIR%2BJdyFHQjyU%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6l%2F90vtnx7lbNsKu5RwYBBqjS5M4D%2BD6KhaiHSZpjVs%3D&reserved=0>
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OntVxXeEzhGZ8G%2B00zHbhdCc9b1%2ByhJp9inqWabEVo0%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UZoeWsVHOHCoe8ZCPdcr7yf930qNAFZMli9E3H02WY0%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Haoyu Song <[email-masked]>
Date: Thu, 27 Jan 2022 18:50:11 +0000

Hi Tianran,

We didn't invent any new protocol but to simply use UDP for the probing packets in SRv6.
What we want to avoid is SRH TLV in EH which can significantly increase the EH overhead because the data needed to be carried may be too large.
Also, since IOAM options have been well defined, it's unnecessary to augment the other existing protocols to provide similar functionality. We just need a way to encapsulate them.

Best,
Haoyu

From: Tianran Zhou <[email-masked]>
Sent: Wednesday, January 26, 2022 7:19 PM
To: Greg Mirsky <[email-masked]>; Haoyu Song <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf92f8db9e83446aa16f308d9e143cb41%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788503585330916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aatvet2BClP0UZgi%2Fu0YghheqocztyGsfKx4%2BnK8zf0%3D&reserved=0>

Best,
Tianran

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf92f8db9e83446aa16f308d9e143cb41%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788503585330916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LMeQUNry3UpwUshJ0sz6geLmHNvGixm9IOs4Ohub%2BPw%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf92f8db9e83446aa16f308d9e143cb41%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788503585330916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mz2HpxSUsqEECW137oPdH%2F0hieavc7vxATnIlzmiKT4%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf92f8db9e83446aa16f308d9e143cb41%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788503585330916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vnwAq6H0DGkZxN2fsMnRVv5ACOoM43R4HpASv4HLUls%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf92f8db9e83446aa16f308d9e143cb41%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637788503585330916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6MgfNu8%2BnvQhhGNNcYSkciMNUQBMrNc922kh2E5PAW0%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Thu, 27 Jan 2022 19:00:21 +0000

Hi Greg,

Thank you for your questions. Please see inline response.

Best,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, January 26, 2022 3:01 PM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ICDx4pdmgXJBs68SATcvkTpZSOTZ6LD7JyCCKYM6IJg%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Czxg8dYGfDXViyRtY2Z2vuIKit%2B9Pw0atzLonOVTdfE%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

HS>> Let's give a few features of our proposal: (1) it's session-less and we don't need assign any roles (e.g.,  reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based which can support any existing IOAM modes and potentially other OAM methods.

HS>> In this particular case, IOAM is used for active measurement because it's not included in a user packet.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EgovYo3tJgmCUR8eu0I%2BkF%2Ff9fcfKFGi6gaOycyFM6g%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=x0ROnWuMAW%2BJhiEROH%2Fg4%2BruahabOaHctwN6eVeX9jw%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 27 Jan 2022 14:00:49 -0800

Hi Haoyu,
thank you for your detailed reply. Please find my follow-up notes in-lined
below under the GIM2>> tag.

Regards,
Greg

On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <[email-masked]>
wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Wednesday, January 26, 2022 3:01 PM
> *Subject:* Re: [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu,
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ICDx4pdmgXJBs68SATcvkTpZSOTZ6LD7JyCCKYM6IJg%3D&reserved=0> it
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Czxg8dYGfDXViyRtY2Z2vuIKit%2B9Pw0atzLonOVTdfE%3D&reserved=0>,
> HS>> Let’s give a few features of our proposal: (1) it’s session-less and
> we don’t need assign any roles (e.g.,  reflector); (2) no needs for a
> return path. The measurement can start and end at any node (solely
> determined by the SRH); (3) udp-based which can support any existing IOAM
> modes and potentially other OAM methods.
>
GIM2>> I don't think adding a protocol that can generate a test probe from
an arbitrary node to arbitrary targets (SRv6 supports multicast) is as
simple as you present. If an operator needs to monitor the performance of
the SR policy used by data packets, IOAM can be applied to data packets. If
the operator wants to explore a policy that is not used for data traffic, I
imagine IOAM can be added to a test packet of the existing OAM protocol,
e.g., ICMP. Am I missing some of the requirements?

> HS>> In this particular case, IOAM is used for active measurement because
> it’s not included in a user packet.
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EgovYo3tJgmCUR8eu0I%2BkF%2Ff9fcfKFGi6gaOycyFM6g%3D&reserved=0>
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=x0ROnWuMAW%2BJhiEROH%2Fg4%2BruahabOaHctwN6eVeX9jw%3D&reserved=0>
>
>

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 23:53:27 +0000

Hi Haoyu,

I agree with Greg. I think IOAM with existing OAM protocol can address your case.
Again, I can show you some more details on your motivation.
(1) it’s session-less and we don’t need assign any roles (e.g.,  reflector);
ZTR> I am not sure if I understand what the “session-less” mean.
But I think in your application, the sender should keep the session state, right?
Reflector is not always required. OWAMP is one way, so no reflector. STAMP, IMHO, could also be one way.
In RFC8762, STAMP “enables the measurement of both one-way and round-trip performance metrics”.

(2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH);
ZTR> This is achieved by SRH, you did not create anything on OAM after UDP. So this applies for any one way OAM protocol.
On the other hand, many measurement need two ways (e.g., delay). Even data collections need two ways, because the forward and backward are totally different two paths.
Of cause, you can use one way protocol to travel both way.
Two way need a reflector, but will also reduce a lot of resources. For example the length of the SID list.

(3) udp-based which can support any existing IOAM modes and potentially other OAM methods.
ZTR> STAMP is UDP based.

Sent: Friday, January 28, 2022 6:01 AM

Hi Haoyu,
thank you for your detailed reply. Please find my follow-up notes in-lined below under the GIM2>> tag.

Regards,
Greg

On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Haoyu

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Hi Haoyu,

Regards,
Greg

HS>> Let’s give a few features of our proposal: (1) it’s session-less and we don’t need assign any roles (e.g.,  reflector); (2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH); (3) udp-based which can support any existing IOAM modes and potentially other OAM methods.
GIM2>> I don't think adding a protocol that can generate a test probe from an arbitrary node to arbitrary targets (SRv6 supports multicast) is as simple as you present. If an operator needs to monitor the performance of the SR policy used by data packets, IOAM can be applied to data packets. If the operator wants to explore a policy that is not used for data traffic, I imagine IOAM can be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I missing some of the requirements?
options of IOAM and other OAM methods in SRv6, without needing to worry about the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

HS>> In this particular case, IOAM is used for active measurement because it’s not included in a user packet.

Your comments, questions, and suggestions are very welcome. I’d like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc347a296576a4bcc02dc08d9e11fcba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788348960663433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EgovYo3tJgmCUR8eu0I%2BkF%2Ff9fcfKFGi6gaOycyFM6g%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 28 Jan 2022 00:22:21 +0000

Hi Haoyu,

I do not understand why the UDP encapsulation is better than SRH TLV.
IMO, IOAM is already too complex, some more work on TLV parsing is not critical.
If you care about the data length "because the data needed to be carried may be too large", what's the limit on SRH TLV?
What's your use case, and your requirement? Let's evaluate it with numbers.

Best,
Tianran

From: Haoyu Song [mailto:[email-masked]]
Sent: Friday, January 28, 2022 2:50 AM
To: Tianran Zhou <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Tianran,

Best,
Haoyu

From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 26, 2022 7:19 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

Best,
Tianran

Hi Haoyu,

Regards,
Greg

Thank you very much!

Best regards,
Haoyu

---

From: Haoyu Song <[email-masked]>
Date: Fri, 28 Jan 2022 01:44:54 +0000

Hi Greg, please see Inline

Sent: Thursday, January 27, 2022 2:01 PM

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AYvvbUcYcrpMRtKt7zbCFXe8RNLAI9e4p7tk2X8CTXc%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RERE4ZeUQY0azpscgyRFenxuGVL5wCGUwAfADYrAV8%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

HS2>> For the first point: I don't think a protocol is needed here. If one wants to test the path a->b->c->d->e, he doesn't need to find a user packet on that path to carry IOAM (there could be no such packet at all). Instead, he can generate a probe packet with an SRH for the path and use the probe packet to carry IOAM. At the path end, it simply extracts and exports the IOAM data using the mechanism defined for IOAM and drops the probe packet.
For the second point: I don't think ICMP can achieve what IOAM can do. IOAM is much more powerful in terms of the data it can collect. Moreover, the proposal can be easily extended to support other kinds of OAM methods. One just carry it in UDP payload using different port. No need to worry about the size if such info has to be carried in EH TLV.
options of IOAM and other OAM methods in SRv6, without needing to worry about the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n91iqOTxknBNtpFXrgcpOzdU60SfzDiFbfliOAGmkgk%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BCOpBP26FIqhHTRNKBdG6ykLAUD8kn2S%2BDv2baEKOL4%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 28 Jan 2022 01:57:28 +0000

Hi Tianran,

The use case I target  is to generate probing packets to collect node/link data on arbitrary path. We have algorithms to generate such packets on a few path to cover the entire network (reference is given in the draft). If we periodically do such measurements, we can gain the visibility of the whole network and detect the gray failures, which can have countless  useful applications.

Why using UDP rather than EH TLV? here's some of my thoughts. First, I don't need to do it in user packets, so essentially the payload is free to use.
Second, there are a lot of discussions and debates on the size/location of the IPv6 EHs, and there are so many proposals want to use the EHs. I don't want to add more complexity to it.
Third, the proposal can be extended to support other OAM schemes using the same method. Of course, you can also keep introducing new TLV options to EH. But again, that's the path I don't want to go.

Best,
Haoyu

From: Tianran Zhou <[email-masked]>
Sent: Thursday, January 27, 2022 4:22 PM
To: Haoyu Song <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

Best,
Tianran

To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Hi Tianran,

Best,
Haoyu

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575001900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HpxtO%2BRjmZaR10fvALm0w6M2YVhHOAtXwI6Ue6m%2Fv3U%3D&reserved=0>

Best,
Tianran

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575158134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SLkdO9JibbfFTU%2BN%2Fv%2F1db6DabwLmvpRliIRI6u4ljk%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575158134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vcs%2F%2F5QjmRLTzlhJjrsp96Iiftkkg%2BuUebB3ICuk%2Fs8%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575158134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pcwop4I5OpsZe4HuzTT6xS466uSa3YbFLT9z38wCK40%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575158134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PvWeHAEIPpvveTP2wZy3uCcXXr4WPOHn9boBh80pFAg%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 27 Jan 2022 18:17:19 -0800

Hi Haoyu,
now, without in-lining my notes.
It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/>.
Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is
IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM
would not understand your probe packet without an SW upgrade. In my book,
that's a new protocol.
In closing, I'll reference two works by Ruediger Geib
<https://datatracker.ietf.org/person/[email-masked]>, where
combining the defined techniques of steering test probes with standard IOAM
might reveal a lot of useful information about a network:

   - RFC 8403 <https://datatracker.ietf.org/doc/rfc8403/>
   - draft-ietf-ippm-connectivity-monitoring
   <https://datatracker.ietf.org/doc/draft-ietf-ippm-connectivity-monitoring/>

Regards,
Greg

On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <[email-masked]> wrote:

> *Sent:* Thursday, January 27, 2022 2:01 PM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AYvvbUcYcrpMRtKt7zbCFXe8RNLAI9e4p7tk2X8CTXc%3D&reserved=0> it
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RERE4ZeUQY0azpscgyRFenxuGVL5wCGUwAfADYrAV8%3D&reserved=0>,
> HS2>> For the first point: I don’t think a protocol is needed here. If one
> wants to test the path a->b->c->d->e, he doesn’t need to find a user packet
> on that path to carry IOAM (there could be no such packet at all). Instead,
> he can generate a probe packet with an SRH for the path and use the probe
> packet to carry IOAM. At the path end, it simply extracts and exports the
> IOAM data using the mechanism defined for IOAM and drops the probe packet.
>
> For the second point: I don’t think ICMP can achieve what IOAM can do.
> IOAM is much more powerful in terms of the data it can collect. Moreover,
> the proposal can be easily extended to support other kinds of OAM methods.
> One just carry it in UDP payload using different port. No need to worry
> about the size if such info has to be carried in EH TLV.
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n91iqOTxknBNtpFXrgcpOzdU60SfzDiFbfliOAGmkgk%3D&reserved=0>
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BCOpBP26FIqhHTRNKBdG6ykLAUD8kn2S%2BDv2baEKOL4%3D&reserved=0>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 28 Jan 2022 19:10:18 +0000

Hi Greg,

Thanks for the info. I'd like to clarify this work means to use the standardized IOAM options to support active measurement, so it's fair to say we use IOAM in SRv6 for active measurement. Another point I'd like to mention is that draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%3D&reserved=0> is for IPv6 in general but not for SRv6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, and it means to support in-band measurement for user traffic.

In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail, it's natural to use the traffic steering feature for probing and measurements as well. If we have a unified method to cover as many techniques as possible, we can imagine new techniques can also be introduced easily. Without needing to set up any sessions and maintain any states, the controller can inject probing packets from any node, steer them on any path, terminate them at any node, and collect any data we like. Such in-network measurement doesn't need to involve end hosts like PING. It can be used for traffic engineering (e.g., evaluating different paths at background) and for gray failure detection and prevention.

I hope the WG can see the simplicity, extensibility, and great application potential of the proposed scheme, and provide constructive suggestions to improve it.

Thanks!
Haoyu

Sent: Thursday, January 27, 2022 6:17 PM

Hi Haoyu,
now, without in-lining my notes.
It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%3D&reserved=0>. Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM would not understand your probe packet without an SW upgrade. In my book, that's a new protocol.
In closing, I'll reference two works by Ruediger Geib<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fperson%2FRuediger.Geib%40telekom.de&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n22sC0FjPtfa%2FoAOV%2BtLzYh3Dc9%2FT7CLW4tjYDvMfHc%3D&reserved=0>, where combining the defined techniques of steering test probes with standard IOAM might reveal a lot of useful information about a network:

  *   RFC 8403<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8403%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a180XC%2F8M9u0C%2B3g7VFit8cx3MlfrpIkOw5%2BhoxR3JQ%3D&reserved=0>
  *   draft-ietf-ippm-connectivity-monitoring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-connectivity-monitoring%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bfBsZ1NYSkiQA1SinEmTw4U0KO4A47vPys%2BGYYfNL8c%3D&reserved=0>

Regards,
Greg

On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg, please see Inline

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9ODsMyWuYOPjnmvAHcmyZ8a00QmIOVR7BbXiXgZQhU%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=STWFmE1srlwuuMXZoF6oEgjWz%2B6aFkhzY%2B9p3zR9W8g%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jZeeAirU35C9MGAIvbDX79%2FA7CZEr7gmspx0%2BHsMMIQ%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hB%2FZ0HwhEmS0kkskCcPcxe%2FtzYctaBBoJ0jAI%2Fu6Uyw%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 28 Jan 2022 19:22:55 +0000

See inline

-Haoyu

Sent: Thursday, January 27, 2022 3:53 PM

Hi Haoyu,

I agree with Greg. I think IOAM with existing OAM protocol can address your case.
Again, I can show you some more details on your motivation.
(1) it's session-less and we don't need assign any roles (e.g.,  reflector);
ZTR> I am not sure if I understand what the "session-less" mean.
But I think in your application, the sender should keep the session state, right?
Reflector is not always required. OWAMP is one way, so no reflector. STAMP, IMHO, could also be one way.
In RFC8762, STAMP "enables the measurement of both one-way and round-trip performance metrics".

HS> It means "stateless". The state could be some identifier kept by the network device. Augmenting some existing protocols to cover new function require the same amount of work and in many cases, due to the limitations of the original protocol, the extensibility is seriously limited. The protocols you mentioned were designed for e2e measurement. Each new patch adding to them will raise the concern for the standard updates and eventually make the protocol itself unwieldy because the new things are beyond the original design scope. In other words, having the existing protocol doesn't help here but exert unnecessary limitations.

HS> Two way can easily be supported by SRH itself (just add the round trip path in segment list). There's no need to introduce any other mechanism.

HS> If so, it can also be supported by our framework. But there's no need to force IOAM functions as a part of STAMP. That's like reinventing the wheel.

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SbBIhJvEvjS2bbTTDx%2Fa3XrQZSl5NqxgzcrtofpGwU8%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h7sgdenzeF%2Bxb9doJDXLGlP20OG7WBSu29ZelD%2Fcqa8%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6D6f642sXltag67xRVA5tuF9s%2Ft6CEjF3W2lCzDiRRs%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4e2TDzuHKQb7dyLOw%2BtOxWIRzSDY4QyNOSTHkOvou4U%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Jan 2022 12:02:53 -0800

Hi Haoyu,
I'm surprised that you suggest an alternative to the IPv6 way of collecting
IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare
cases, SRv6-specific extensions to IPv6 OAMAs for the limited amount of
information that can be collected using IPv6 extension headers, IOAM Direct
Export
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>, or
the Hybrid Two-step
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>
provide the solution. Both solve this problem by separating the generation
of the IOAM data set from the collection and transport. You are
well-familiar with both drafts.

Regards,
Greg

On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> Thanks for the info. I’d like to clarify this work means to use the
> standardized IOAM options to support active measurement, so it’s fair to
> say we use IOAM in SRv6 for active measurement. Another point I’d like to
> mention is that draft-ietf-ippm-ioam-ipv6-options
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%3D&reserved=0>
> is for IPv6 in general but not for SRv6 specifically. Moreover, it also use
> EH TLVs and we propose to use UDP, and it means to support in-band
> measurement for user traffic.
>
>
>
> In my view, SRv6 is the way to steer traffic. If SRv6 networks prevail,
> it’s natural to use the traffic steering feature for probing and
> measurements as well. If we have a unified method to cover as many
> techniques as possible, we can imagine new techniques can also be
> introduced easily. Without needing to set up any sessions and maintain any
> states, the controller can inject probing packets from any node, steer them
> on any path, terminate them at any node, and collect any data we like. Such
> in-network measurement doesn’t need to involve end hosts like PING. It can
> be used for traffic engineering (e.g., evaluating different paths at
> background) and for gray failure detection and prevention.
>
>
>
> I hope the WG can see the simplicity, extensibility, and great application
> potential of the proposed scheme, and provide constructive suggestions to
> improve it.
>
>
>
> Thanks!
>
> Haoyu
>
>
>
> *Sent:* Thursday, January 27, 2022 6:17 PM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%3D&reserved=0>.
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fperson%2FRuediger.Geib%40telekom.de&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n22sC0FjPtfa%2FoAOV%2BtLzYh3Dc9%2FT7CLW4tjYDvMfHc%3D&reserved=0>,
> where combining the defined techniques of steering test probes with
> standard IOAM might reveal a lot of useful information about a network:
>
>    - RFC 8403
>    <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8403%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a180XC%2F8M9u0C%2B3g7VFit8cx3MlfrpIkOw5%2BhoxR3JQ%3D&reserved=0>
>    <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-connectivity-monitoring%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bfBsZ1NYSkiQA1SinEmTw4U0KO4A47vPys%2BGYYfNL8c%3D&reserved=0>
>
>
>
> Regards,
>
> Greg
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9ODsMyWuYOPjnmvAHcmyZ8a00QmIOVR7BbXiXgZQhU%3D&reserved=0> it
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=STWFmE1srlwuuMXZoF6oEgjWz%2B6aFkhzY%2B9p3zR9W8g%3D&reserved=0>,
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jZeeAirU35C9MGAIvbDX79%2FA7CZEr7gmspx0%2BHsMMIQ%3D&reserved=0>
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hB%2FZ0HwhEmS0kkskCcPcxe%2FtzYctaBBoJ0jAI%2Fu6Uyw%3D&reserved=0>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 28 Jan 2022 20:10:26 +0000

Hi Greg,

Sure, SRv6 is IPv6 but SRv6 doesn't equal to IPv6. If you define IOAM in IPv6, then what's its behavior in SRv6? Shall it be applied on every node or every SR node? But the more fundamental issue is that I don't think putting all of such things in EH TLVs is a good idea. All of the discussions around this which you are also very familiar make me think we should avoid it if we can.

Best,
Haoyu
Sent: Friday, January 28, 2022 12:03 PM

Hi Haoyu,
I'm surprised that you suggest an alternative to the IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gw58jVbuNtvV11Bko%2FiDOHo5izQ4uPCz81B0fdbFNrg%3D&reserved=0>, or the Hybrid Two-step<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-ippm-hybrid-two-step%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2oKqJPhLdZVUxdzJ41Y5nPa2pJYv%2FYkDu6ViqJga4xA%3D&reserved=0> provide the solution. Both solve this problem by separating the generation of the IOAM data set from the collection and transport. You are well-familiar with both drafts.

Regards,
Greg

On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks for the info. I'd like to clarify this work means to use the standardized IOAM options to support active measurement, so it's fair to say we use IOAM in SRv6 for active measurement. Another point I'd like to mention is that draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0BZvQjhxlRQvI8dSvfTThQwc3mVU01dpj0UjHCAu1CI%3D&reserved=0> is for IPv6 in general but not for SRv6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, and it means to support in-band measurement for user traffic.

Thanks!
Haoyu

Hi Haoyu,
now, without in-lining my notes.
It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0BZvQjhxlRQvI8dSvfTThQwc3mVU01dpj0UjHCAu1CI%3D&reserved=0>. Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM would not understand your probe packet without an SW upgrade. In my book, that's a new protocol.
In closing, I'll reference two works by Ruediger Geib<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fperson%2FRuediger.Geib%40telekom.de&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=L8pN4A6sKha7LCQbTPnK44gG8WnzS2ySisE377AIhnI%3D&reserved=0>, where combining the defined techniques of steering test probes with standard IOAM might reveal a lot of useful information about a network:

  *   RFC 8403<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8403%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YAi4ps4uW9kWkp2%2FZMO2sFUcq2eeAxJ%2B5lytt4%2BJIrM%3D&reserved=0>
  *   draft-ietf-ippm-connectivity-monitoring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-connectivity-monitoring%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UwFgdb3tUQwouDm7O80LTjQ%2BijtFTvKEv%2FAUqCgwkAY%3D&reserved=0>

Regards,
Greg

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=J1qeMCtu5CMakfMnis%2FCNWc1RDXCW4ToXTbiKufgwk4%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CIXT637fO6QOBaXIzIycSwVNVUy7KZ0e22sMt2i0HwM%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SD0Se%2FAuRFK%2B%2FB4miPJ%2FQVH0YOf6LP6R7X3SmKRSnLE%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7C68756b8238854f369c4f08d9e2993304%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789969905226641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9qk2ueicYlgitBrSQYBp0KLcbSqsnrvK7X0PuMRneXc%3D&reserved=0>

---

From: Tianran Zhou <[email-masked]>
Date: Sat, 29 Jan 2022 03:44:24 +0000

Hi Haoyu and Greg,

I think we are getting clear, the discussion falls into two points:
1. new protocol vs reuse existing protocol
2. IPv6 EH vs UDP

Best,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Haoyu Song
Sent: Saturday, January 29, 2022 4:10 AM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Greg,

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Thanks!
Haoyu

Hi Haoyu,

Regards,
Greg

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,

Regards,
Greg

Thank you very much!

Best regards,
Haoyu

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 30 Jan 2022 12:40:31 -0500

Hi Haoyu

On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song <[email-masked]> wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, January 26, 2022 9:03 PM
> *To:* Tianran Zhou <zhoutianran=[email-masked]>
> *Cc:* Greg Mirsky <[email-masked]>; Haoyu Song <
> [email-masked]>; IETF IPPM WG <[email-masked]>; [email-masked]
> [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements,
> here we want to collect data from every node and every link on any path,
> without needing to set up any sessions. So the scope and coverage are
> different.
>
>  Gyan> Understood.  STAMP/TWAMP can be used as well to collect from every
> node as well.
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-data-16&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b6abSWTm77Z4Td%2B0X5hjmZBrFHTe%2FpPdZuWyXNEY3vU%3D&reserved=0>
>
>
>
> [HS] There’s no accepted solution on how to support IOAM in SRv6 yet. Our
> proposal aims to provide such a solution, and (1) the solution avoids the
> issues on encapsulating the IOAM trace in EHs and (2) it’s extensible to
> include OAM methods beyond IOAM.
>
>  Gyan> IPPM WG can speak to this document which has been adopted and been
> developed since 2016 and provides in-situ OAM as you desire and supports
> Segment Routing SRv6 as well as other encapsulations.
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-spring-srv6-oam-12&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EnHxos0Nc%2BF3d%2FehCZuIoSswxZ7udPLASp22oW5UES4%3D&reserved=0>
> 3
>
>
>
> [HS] This is for in-band OAM for SRv6 user traffic and it only works for
> triggering postcard exports (i.e., don’t allow the packet to carry data).
> Our proposal support all the IOAM options and more important, it’s an
> active method which means one can generate and inject probing packets to
> cover arbitrary paths by crafting an SRH.
>
>  Gyan> Understood
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ali-spring-ioam-srv6-05&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9zM0yFTsl2jKvDDd8uDv0rtGcOsoaKY%2FEaqUXZmsJ5U%3D&reserved=0>
>
>
>
> [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the
> overhead concern (IOAM trace could be large) and other issues related to
> EH, I don’t support such a solution.
>
>  Gyan> Understood.  Work is being done in 6MAN WG to address EH headers
> issues below as well as other drafts to make EH viable and reduce overhead.
>

https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt

[HS] The three drafts you mentioned are all be reference in our draft and
> discussed. We think our use cases are different and our approach is more
> general and extensible to our use cases.
>
> Gyan> Understood.  I think if you can add some additional verbiage as to
> problem statement and why existing solutions drafts mentioned are not
> sufficient for your requirements.  Maybe listing out your requirements
> would help couple to your proposed solution.
>
> Thanks
>
>
>
> Gyan
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136005568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zqVhnbQoOc33My8fwqES5arm9vT0NCeUs3kIIkGPlug%3D&reserved=0>
>
>
>
> Best,
>
> Tianran
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5rsC694oCufl11dAM4pfiB%2FIKazRSNV3KWAmY%2B7hReA%3D&reserved=0> it
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nbxsguDj1bZHDKu2RkvdBkOUxvrXeY%2F5Vlc5jBj2qgE%3D&reserved=0>,
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aV3fE%2BZWpaILCWRLJQEo98%2FZ65gN5U%2FIR%2BJdyFHQjyU%3D&reserved=0>
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6l%2F90vtnx7lbNsKu5RwYBBqjS5M4D%2BD6KhaiHSZpjVs%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OntVxXeEzhGZ8G%2B00zHbhdCc9b1%2ByhJp9inqWabEVo0%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd997fc19042a43dad96e08d9e152596a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788566136161714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UZoeWsVHOHCoe8ZCPdcr7yf930qNAFZMli9E3H02WY0%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 17:19:18 +0000

Tianran,

Your summary is basically correct.
But for the first point, I don't think using UDP is a new protocol. And extending an existing protocol beyond its original scope in many cases is like designing a new protocol.  The pros and cons all need to be carefully considered.

Best,
Haoyu

From: Tianran Zhou <[email-masked]>
Sent: Friday, January 28, 2022 7:44 PM
To: Haoyu Song <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: RE: [spring] Active OAM in SRv6

Hi Haoyu and Greg,

Best,
Tianran

To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Hi Greg,

Best,
Haoyu

Hi Haoyu,
I'm surprised that you suggest an alternative to the IPv6 way of collecting IOAM data. SRv6 must use all of IPv6 OAM. Would you agree? In some rare cases, SRv6-specific extensions to IPv6 OAMAs for the limited amount of information that can be collected using IPv6 extension headers, IOAM Direct Export<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lUJ1ZHpASqP6mnL8dKIPKpYol2B7VOd%2FZx38oX1yT%2BM%3D&reserved=0>, or the Hybrid Two-step<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-ippm-hybrid-two-step%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1NmymTdXooQ71DwD6GpFFt4qn8Y9%2BNuhLnAVXKgDZwk%3D&reserved=0> provide the solution. Both solve this problem by separating the generation of the IOAM data set from the collection and transport. You are well-familiar with both drafts.

Regards,
Greg

Thanks for the info. I'd like to clarify this work means to use the standardized IOAM options to support active measurement, so it's fair to say we use IOAM in SRv6 for active measurement. Another point I'd like to mention is that draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lciwJ8QmGpZY2xRXAwgyMSVlIUlrBYu1RUqYA8FpB08%3D&reserved=0> is for IPv6 in general but not for SRv6 specifically. Moreover, it also use EH TLVs and we propose to use UDP, and it means to support in-band measurement for user traffic.

Thanks!
Haoyu

Hi Haoyu,
now, without in-lining my notes.
It appears that you propose not to use draft-ietf-ippm-ioam-ipv6-options<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-ipv6-options%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lciwJ8QmGpZY2xRXAwgyMSVlIUlrBYu1RUqYA8FpB08%3D&reserved=0>. Thus, your proposal cannot be referred to as IOAM in SRv6. At best, it is IOAM-inspired, IOAMish. As a result, a node supporting standardized IOAM would not understand your probe packet without an SW upgrade. In my book, that's a new protocol.
In closing, I'll reference two works by Ruediger Geib<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fperson%2FRuediger.Geib%40telekom.de&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4wAEoWKmLTwlPM15adX%2FyHrwq%2BSdOVbiKrKeKiAqoKE%3D&reserved=0>, where combining the defined techniques of steering test probes with standard IOAM might reveal a lot of useful information about a network:

  *   RFC 8403<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8403%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=reSbtMXQ9EkAwiLW9s4vI5D3BLHDkaw7zbmwr3m%2Fx%2Bw%3D&reserved=0>
  *   draft-ietf-ippm-connectivity-monitoring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-connectivity-monitoring%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g9%2B1H9Q3zaAR3mtBTkJz9sTYEEtjjKqVSzVOx8pnuu8%3D&reserved=0>

Regards,
Greg

Hi Haoyu,

Regards,
Greg

Best,
Haoyu

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uYYsOuqLix3X2ls0%2BUTBUMwXtA6PmmkSqIU4ElMiquQ%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

Real time monitor on every node and every link on a network is necessary to detect  gray failures, which are the key culprit for poor QoS but hard to catch. SR provides an ideal mechanism, when working with some efficient planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ Active Measurement (SIAM) suggests a simple  active measurement approach which can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BkRbtHvDld4W%2BWCkZGAFjArownn9JunpDkrf4CpxBgU%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uIiLPXZq5D2GMK0dqeWn07qPYsEKMoTTGJU4nX4PupM%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Jd%2ByLHVQXYHZO2%2B8wUmabsZxx%2BxreBls%2BLuq5TSRNSM%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 17:29:37 +0000

Thanks Gyan!
In the next revision, I'll add more information on the requirements and comparisons with the other approaches.

Best,
Haoyu

From: Gyan Mishra <[email-masked]>
Sent: Sunday, January 30, 2022 9:41 AM
To: Haoyu Song <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; IETF IPPM WG <[email-masked]>; Tianran Zhou <zhoutianran=[email-masked]>; [email-masked]
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Best,
Haoyu

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 26, 2022 9:03 PM
To: Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Haoyu Song <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

[HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, here we want to collect data from every node and every link on any path, without needing to set up any sessions. So the scope and coverage are different.
 Gyan> Understood.  STAMP/TWAMP can be used as well to collect from every node as well.
In-situ IOAM data packets is already possible with SRv6 as mentioned as this draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-data-16&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b87You4N5cgK7mQX7vz%2B3KQ%2FFwbnBg3oAEIm9SDDFH0%3D&reserved=0>

[HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our proposal aims to provide such a solution, and (1) the solution avoids the issues on encapsulating the IOAM trace in EHs and (2) it's extensible to include OAM methods beyond IOAM.
 Gyan> IPPM WG can speak to this document which has been adopted and been developed since 2016 and provides in-situ OAM as you desire and supports Segment Routing SRv6 as well as other encapsulations.
This draft as well mentioned as normative reference draft below provides OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tracing capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-spring-srv6-oam-12&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BOfmDM0Q7AmZU9xB7phQ11MEI8Elh4u8WkjR9LW%2FO4s%3D&reserved=0>3

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ali-spring-ioam-srv6-05&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n%2Fo10SkitX8ixSt8mFn32QAYuFYxsZ23OnM3Sl%2FSRh8%3D&reserved=0>

[HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhead concern (IOAM trace could be large) and other issues related to EH, I don't support such a solution.
 Gyan> Understood.  Work is being done in 6MAN WG to address EH headers issues below as well as other drafts to make EH viable and reduce overhead.

https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-herbert-6man-eh-limits-00.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i6CpxDS%2F0wI%2FmM1iaU8kk8arfdkqFPwOoUWJ72%2BvIFc%3D&reserved=0>

[HS] The three drafts you mentioned are all be reference in our draft and discussed. We think our use cases are different and our approach is more general and extensible to our use cases.
Gyan> Understood.  I think if you can add some additional verbiage as to problem statement and why existing solutions drafts mentioned are not sufficient for your requirements.  Maybe listing out your requirements would help couple to your proposed solution.
Thanks

Gyan

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-ippm-stamp-hbh-extensions-03.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i0Tt5TXvEepSx6%2FFsy1KjKdbwM9ecAFRrO6pTwQGTlE%3D&reserved=0>

Best,
Tianran

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the concept of Active IOAM is introduced in the IPPM WG draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-ioam-flags&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aZhGQatM6N5iFenRL9pz%2B%2BYB81ALg6MBbZxNRpeksXA%3D&reserved=0> it seems to me like adding the IPPM WG community to the discussion is the right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

GIM>> I wonder what gaps you find in the existing active measurement protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It appears to me that, for example, STAMP and its extensions, including the SRPM draft<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bWbnm7%2BWnd%2B0qKezxl7j657xf5NEJzegoW9CHXaP%2Fss%3D&reserved=0>, comprehensively address the PM OAM requirements for SRv6.

Your comments, questions, and suggestions are very welcome. I'd like to know your opinion if you think this work is in scope and should be adopted by the working group.  If you are interested in contributing to this work, please also let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-spring-siam%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S8wtLHz71arJAu89usFrGflaSGWmpeY0kPhX8o99ER0%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PhGNGIoZ%2F%2BkxvD1pa%2FcF2AwQ5QDZ4YFFBRQ5sAwItU8%3D&reserved=0>
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H4Fk06zxnAYUv9Acz8Sgpx%2BYsW5SejzzSPtbuoAy1%2BY%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ntlmkfouhbjnEIP8AP1vedsNQTxkYc2s0CI21kBCTyU%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ntlmkfouhbjnEIP8AP1vedsNQTxkYc2s0CI21kBCTyU%3D&reserved=0>

Gyan Mishra

M 301 502-1347