Re: [ippm] [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://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>, or
the Hybrid Two-step
<https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>
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.song@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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%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 <gregimirsky@gmail.com>
> *Sent:* Thursday, January 27, 2022 6:17 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,
>
> 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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tVevPlkRykwgaEbU9tAftdnjZn27Zc74Wgr8b6nsxgQ%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n22sC0FjPtfa%2FoAOV%2BtLzYh3Dc9%2FT7CLW4tjYDvMfHc%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a180XC%2F8M9u0C%2B3g7VFit8cx3MlfrpIkOw5%2BhoxR3JQ%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546317842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bfBsZ1NYSkiQA1SinEmTw4U0KO4A47vPys%2BGYYfNL8c%3D&reserved=0>
>
>
>
> 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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9ODsMyWuYOPjnmvAHcmyZ8a00QmIOVR7BbXiXgZQhU%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=STWFmE1srlwuuMXZoF6oEgjWz%2B6aFkhzY%2B9p3zR9W8g%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jZeeAirU35C9MGAIvbDX79%2FA7CZEr7gmspx0%2BHsMMIQ%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%7Cbb534802a33e486439bc08d9e2045725%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637789330546474520%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hB%2FZ0HwhEmS0kkskCcPcxe%2FtzYctaBBoJ0jAI%2Fu6Uyw%3D&reserved=0>
>
>