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 protected]> Sent: Thursday, January 27, 2022 4:22 PM To: Haoyu Song <[email protected]>; Greg Mirsky <[email protected]> Cc: [email protected]; IETF IPPM WG <[email protected]> Subject: RE: [ippm] [spring] Active OAM in SRv6 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 protected]] Sent: Friday, January 28, 2022 2:50 AM To: Tianran Zhou <[email protected]<mailto:[email protected]>>; Greg Mirsky <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; IETF IPPM WG <[email protected]<mailto:[email protected]>> Subject: RE: [ippm] [spring] Active OAM in SRv6 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 protected]<mailto:[email protected]>> Sent: Wednesday, January 26, 2022 7:19 PM To: Greg Mirsky <[email protected]<mailto:[email protected]>>; Haoyu Song <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; IETF IPPM WG <[email protected]<mailto:[email protected]>> 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%7C9584ccacf3be4468376c08d9e1f448a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789261575001900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HpxtO%2BRjmZaR10fvALm0w6M2YVhHOAtXwI6Ue6m%2Fv3U%3D&reserved=0> Best, Tianran From: ippm [mailto:[email protected]] On Behalf Of Greg Mirsky Sent: Thursday, January 27, 2022 7:01 AM To: Haoyu Song <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; IETF IPPM WG <[email protected]<mailto:[email protected]>> 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%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 On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <[email protected]<mailto:[email protected]>> 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%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. 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%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 protected]<mailto:[email protected]> 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>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
