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 <zhoutian...@huawei.com> Sent: Friday, January 28, 2022 7:44 PM To: Haoyu Song <haoyu.s...@futurewei.com>; Greg Mirsky <gregimir...@gmail.com> Cc: spring@ietf.org; IETF IPPM WG <i...@ietf.org> Subject: RE: [spring] Active OAM in SRv6 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:ippm-boun...@ietf.org] On Behalf Of Haoyu Song Sent: Saturday, January 29, 2022 4:10 AM To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Cc: spring@ietf.org<mailto:spring@ietf.org>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>> Subject: Re: [ippm] [spring] Active OAM in SRv6 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 From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Friday, January 28, 2022 12:03 PM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: spring@ietf.org<mailto:spring@ietf.org>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>> Subject: Re: [spring] Active OAM in SRv6 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 On Fri, Jan 28, 2022 at 11:10 AM Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> 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%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. 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 From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Thursday, January 27, 2022 6:17 PM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: spring@ietf.org<mailto:spring@ietf.org>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>> Subject: Re: [spring] Active OAM in SRv6 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 On Thu, Jan 27, 2022 at 5:44 PM Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> wrote: Hi Greg, please see Inline From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Thursday, January 27, 2022 2:01 PM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: spring@ietf.org<mailto:spring@ietf.org>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>> 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 <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> wrote: Hi Greg, Thank you for your questions. Please see inline response. Best, Haoyu From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Wednesday, January 26, 2022 3:01 PM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: spring@ietf.org<mailto:spring@ietf.org>; IETF IPPM WG <i...@ietf.org<mailto:i...@ietf.org>> 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%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 On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> 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%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BkRbtHvDld4W%2BWCkZGAFjArownn9JunpDkrf4CpxBgU%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%7Cd6dc5bab1d3847e0465508d9e2d9a606%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790246703481353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uIiLPXZq5D2GMK0dqeWn07qPYsEKMoTTGJU4nX4PupM%3D&reserved=0> Thank you very much! Best regards, Haoyu _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> 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>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
