Hi Greg, please see Inline From: Greg Mirsky <[email protected]> Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song <[email protected]> Cc: [email protected]; IETF IPPM WG <[email protected]> Subject: Re: [spring] Active OAM in SRv6
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 protected]<mailto:[email protected]>> wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; IETF IPPM WG <[email protected]<mailto:[email protected]>> 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%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 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%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RERE4ZeUQY0azpscgyRFenxuGVL5wCGUwAfADYrAV8%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. 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? 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? 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%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 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%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BCOpBP26FIqhHTRNKBdG6ykLAUD8kn2S%2BDv2baEKOL4%3D&reserved=0>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
