Re: [ippm] [spring] Active OAM in SRv6

[Haoyu Song <[e-mail]>]

See inline

-Haoyu

From: Tianran Zhou <[e-mail]>
Sent: Thursday, January 27, 2022 3:53 PM
To: Greg Mirsky <[e-mail]>; Haoyu Song <[e-mail]>
Cc: [e-mail]; IETF IPPM WG <[e-mail]>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

I agree with Greg. I think IOAM with existing OAM protocol can address your case.
Again, I can show you some more details on your motivation.
(1) it's session-less and we don't need assign any roles (e.g.,  reflector);
ZTR> I am not sure if I understand what the "session-less" mean.
But I think in your application, the sender should keep the session state, right?
Reflector is not always required. OWAMP is one way, so no reflector. STAMP, IMHO, could also be one way.
In RFC8762, STAMP "enables the measurement of both one-way and round-trip performance metrics".

HS> It means "stateless". The state could be some identifier kept by the network device. Augmenting some existing protocols to cover new function require the same amount of work and in many cases, due to the limitations of the original protocol, the extensibility is seriously limited. The protocols you mentioned were designed for e2e measurement. Each new patch adding to them will raise the concern for the standard updates and eventually make the protocol itself unwieldy because the new things are beyond the original design scope. In other words, having the existing protocol doesn't help here but exert unnecessary limitations.

(2) no needs for a return path. The measurement can start and end at any node (solely determined by the SRH);
ZTR> This is achieved by SRH, you did not create anything on OAM after UDP. So this applies for any one way OAM protocol.
On the other hand, many measurement need two ways (e.g., delay). Even data collections need two ways, because the forward and backward are totally different two paths.
Of cause, you can use one way protocol to travel both way.
Two way need a reflector, but will also reduce a lot of resources. For example the length of the SID list.

HS> Two way can easily be supported by SRH itself (just add the round trip path in segment list). There's no need to introduce any other mechanism.

(3) udp-based which can support any existing IOAM modes and potentially other OAM methods.
ZTR> STAMP is UDP based.

HS> If so, it can also be supported by our framework. But there's no need to force IOAM functions as a part of STAMP. That's like reinventing the wheel.

From: ippm [mailto:[e-mail]] On Behalf Of Greg Mirsky
Sent: Friday, January 28, 2022 6:01 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] [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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thank you for your questions. Please see inline response.

Best,
Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, January 26, 2022 3:01 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
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%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SbBIhJvEvjS2bbTTDx%2Fa3XrQZSl5NqxgzcrtofpGwU8%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 <[e-mail]<mailto:[e-mail]>> 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%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h7sgdenzeF%2Bxb9doJDXLGlP20OG7WBSu29ZelD%2Fcqa8%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?
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%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6D6f642sXltag67xRVA5tuF9s%2Ft6CEjF3W2lCzDiRRs%3D&reserved=0>

Thank you very much!

Best regards,
Haoyu
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
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%7Cd32306a08eca4103020f08d9e1f038db%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637789244141327200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4e2TDzuHKQb7dyLOw%2BtOxWIRzSDY4QyNOSTHkOvou4U%3D&reserved=0>