Re: [ippm] [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://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/Ruediger.Geib@telekom.de>, 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 <haoyu.song@futurewei.com> wrote:

> Hi Greg, please see Inline
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Thursday, January 27, 2022 2:01 PM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* spring@ietf.org; IETF IPPM WG <ippm@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.song@futurewei.com>
> wrote:
>
> Hi Greg,
>
>
>
> Thank you for your questions. Please see inline response.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Wednesday, January 26, 2022 3:01 PM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* spring@ietf.org; IETF IPPM WG <ippm@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%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 <haoyu.song@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%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
> 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%7Cb3f85572e3c04ab9476b08d9e1e082c7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789176666557150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BCOpBP26FIqhHTRNKBdG6ykLAUD8kn2S%2BDv2baEKOL4%3D&reserved=0>
>
>