Re: [ippm] draft-zhang-ippm-ioam-mp

["zhangli (CE)" <[e-mail]>]

Dear Thomas,

Thanks for your kindly feedback, my feedback is shown in yellow color.

Thanks a lot for sharing operator network analytical use cases with me, and I am always available for the discussion.

Best regards
Li
发件人: [e-mail] <[e-mail]>
发送时间: 2024年3月19日 16:25
收件人: zhangli (CE) <[e-mail]>; [e-mail]
抄送: Tianran Zhou <[e-mail]>
主题: RE: draft-zhang-ippm-ioam-mp

Dear Li,


Thanks a lot for the feedback. I do understand that your objective is to apply this feature only for Hybrid Type II active probing as described in RFC 7799. However I do not concur with your security assessment described in section 5 (https://datatracker.ietf.org/doc/html/draft-zhang-ippm-ioam-mp-00#section-5). You did not describe what measurements should be taken to prevent that this option is being abused.



Li>correct, thanks for your comments, I will provide more detail description in section5.



To come back to my original statement. I quote


https://datatracker.ietf.org/doc/html/rfc9232#section-2.4
It is worth noting that a network telemetry system should not be intrusive to normal network operations by avoiding the pitfall of the "observer effect". That is, it should not change the network behavior and affect the forwarding performance.

Network Telemetry protocols are designed so that they are passive measuring networks with the least amount interference with the connectivity service. Hybrid Type I and II  however augment the packet with additional tracing information. Therefore we the IETF community need to pay close attention that such protocols are not going one step further and influencing the forwarding of the in-flight (customer) packets. There I see that your proposed crosses a red line and I object in the interest of Network Telemetry not being intrusive which is key for me as network operator since we receive push backs from colleagues in network operation or in software development on network vendor side when introducing Network Telemetry features in the forwarding and in the control plane of networks. Introducing such features would make it even harder to get adoption in the industry.

>ok, I understand, it is an interesting background.

As Greg and I described. With flow label in IPv6 or entropy label in MPLS we have mechanism in the data plane already which can be applied in probing application to steer the traffic in multipathing scenarios. However I do understand the challenges there.

>if I understand correctly, you mean change the IPv6 flow label or MPLS entropy label of probe packets dynamically to cover different paths. If right there are still some challenges because of the  hash algorithm, it is not guaranteed that the probe packets can discover all paths.

I am available this week at IETF and would like to take the opportunity to share with you some operator network analytical use cases and put your work in perspective and might be able to suggest some alternative options.

>Thank you very much, I will be glad to learn the use cases and discuss the alternative options.

Best wishes
Thomas

From: zhangli (CE) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 19, 2024 3:33 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Subject: RE: draft-zhang-ippm-ioam-mp


Be aware: This is an external email.


Hi Thomas,

Thanks for your kindly comments.
Yes, your understanding is correct, but this extended flag only takes effect when using IOAM to do active measurements, so from my point of view, this extension will not impact normal In-suit OAM. And yes, this extension can also be used with STAMP.
I have a look at RFC 643 roughly, from my understanding, the usage of flow label is to enable efficient IPv6 flow classification, and make the load balance performance better. Our object is to collect every path’s information, so there's not much correlation between them.

Best Regards
Li

发件人: ippm <[e-mail]<mailto:[e-mail]>> 代表 [e-mail]<mailto:[e-mail]>
发送时间: 2024年3月19日 9:05
收件人: [e-mail]<mailto:[e-mail]>
主题: [ippm] draft-zhang-ippm-ioam-mp

Dear Li,

Thanks a lot for your presentation at IPPM.

If I understood correctly, the document proposes to clone a packet based on an IOAM flag. As a network operator I like to raise my concern. Network Telemetry protocols shall not be intrusive in the packet forwarding. I believe the objective of this work should be part of the probing protocol like STAMP or data plane protocol like IPv6. In IPv6 the flow label is defined in RFC 6437 to influence multipathing.

Best wishes
Thomas