Hi Haoyu, thanks for your remarks. Let me pick up your numbering
1. IOAM information could be added by a passed router, if there's interest. The draft doesn't exclude that. But that's not in focus either. I didn't make up my mind, whether and which IOAM information may add value to such measurements. But that doesn't preclude this discussion. I'd prefer any related information in a separate document (and happily add a reference, should there be one). 2. The path set up chosen carries a design and it is optimized by the goal one monitored path/interface, one measurement path. It allows active monitoring of connectivity, congestion location (queue depth) and delay at forwarding layer. The draft assumes a single outage only. I didn't try to seize the same information with less measurements (I'm happy I found the solution shown in the draft). I agree that automated set up of large scale network monitoring measurements is an important and related topic. I prefer to look at it as another building block. I think, other optimized measurement path set ups may be used to reach other monitoring goals (e.g., just connectivity, just congestion location or just delays). I don't want to overload this draft, even if contents are related. I'd be glad if it is a useful part of a bigger picture "highly automated network monitoring". Regards, Ruediger Von: Haoyu Song <haoyu.s...@futurewei.com> Gesendet: Donnerstag, 27. Februar 2020 20:44 An: Geib, Rüdiger <ruediger.g...@telekom.de>; ippm-cha...@ietf.org Cc: spring@ietf.org; i...@ietf.org Betreff: RE: Monitoring metric to detect and locate congestion Hi Ruediger, I like the general idea that using pre-determined paths in SR to collect performance metrics. I think this approach provides some unique benefits compared with the other approaches. It is also coincident with some of related research work I'm doing. Here are some thoughts I have. 1. I think IOAM could be used as the standard approach for such probing packets. It can collect the performance metrics mentioned in the draft and does more. 2. An interesting problem raised by the draft but not fully addressed is the method to plan the optimal paths. There is a work called INT-PATH (https://ieeexplore.ieee.org/document/8737529) which applies Eulerian Path algorithm to find the minimum set of paths with network-wide coverage. However, the problem here seems different: you need path coverage redundancy. My question is: do we really need the redundancy to achieve the measurement goal? If so, what's the best planning algorithm should be? In a real and large scale network, we have constraint on where the probing device(s) can be placed, and we usually want to monitoring the entire network, so an efficient algorithm is necessary. Best regards, Haoyu From: ippm <ippm-boun...@ietf.org<mailto:ippm-boun...@ietf.org>> On Behalf Of ruediger.g...@telekom.de<mailto:ruediger.g...@telekom.de> Sent: Tuesday, February 25, 2020 11:55 PM To: ippm-cha...@ietf.org<mailto:ippm-cha...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf..org> Subject: [ippm] Monitoring metric to detect and locate congestion Dear IPPM (and SPRING) participants, I'm solliciting interest in a new network monitoring metric which allows to detect and locate congested interfaces. Important properties are * Same scalability as ICMP ping in the sense one measurement relation required per monitored connection * Adds detection and location of congested interfaces as compared to ICMP ping (otherwise measured metrics are compatible with ICMP ping) * Requires Segment Routing (which means, measurement on forwarding layer, no other interaction with passed routers - in opposite to ICMP ping) * Active measurement (may be deployed using a single sender&receiver or separate sender and receiver, Segment Routing allows for both options) I'd be happy to present the draft in Vancouver.. If there's community interest. Please read and comment. You'll find slides at https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F105%2Fmaterials%2Fslides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7C4f7ef087db7046424e2508d7ba915817%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183005756536633&sdata=98D7jZDubbhdB3ext94tjEElItEBVyDUld6cQtND6O4%3D&reserved=0> Draft url: https://datatracker.ietf.org/doc/draft-geib-ippm-connectivity-monitoring/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-geib-ippm-connectivity-monitoring%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C4f7ef087db7046424e2508d7ba915817%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183005756546590&sdata=sRAxvsAvs2nHOFme1%2FVZV%2FcFgvZ5AIFtFe5jInmfy7Q%3D&reserved=0> Regards, Ruediger
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
