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 protected]>, 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 protected]> wrote: > 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]> > wrote: > > Hi Greg, > > > > Thank you for your questions. Please see inline response. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky <[email protected]> > *Sent:* Wednesday, January 26, 2022 3: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 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]> > 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] > 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
