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

[[e-mail]]

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.



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.

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.

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.

Best wishes
Thomas

From: zhangli (CE) <[e-mail]>
Sent: Tuesday, March 19, 2024 3:33 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>; [e-mail]
Cc: Tianran Zhou <[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