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

[Haoyu Song <[e-mail]>]

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 <[e-mail]>
Sent: Sunday, January 30, 2022 9:41 AM
To: Haoyu Song <[e-mail]>
Cc: Greg Mirsky <[e-mail]>; IETF IPPM WG <[e-mail]>; Tianran Zhou <zhoutianran=[e-mail]>; [e-mail]
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

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

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

Best,
Haoyu

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, January 26, 2022 9:03 PM
To: Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>>
Cc: Greg Mirsky <[e-mail]<mailto:[e-mail]>>; Haoyu Song <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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.
 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

[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
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%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

On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>> 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%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i0Tt5TXvEepSx6%2FFsy1KjKdbwM9ecAFRrO6pTwQGTlE%3D&reserved=0>

Best,
Tianran

From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
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%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

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> 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://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.
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%7C3d37b8ae83514b99705c08d9e417a3fa%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637791612471240255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S8wtLHz71arJAu89usFrGflaSGWmpeY0kPhX8o99ER0%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

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

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347