Hi Martin, Add the WG, so that we can hear others' comments as well. Please see below for a small addition.
On Fri, Dec 3, 2021 at 1:46 PM Y. Richard Yang <[email protected]> wrote: > Martin, > > Thanks a lot for the update! A quick reply on performance metrics. > > On Fri, Dec 3, 2021 at 1:22 PM Martin Duke <[email protected]> > wrote: > >> >> 2) We will have to do something about performance-metrics. In the >> telechat, we agreed that metrics collection is out of scope. >> > > Not sure I understand what metrics collection refers to. Could you please > add a bit of detail? > > >> However, more precise definitions of these metrics are in scope. I would >> suggest finding RFCs in the ippm WG stream that contain useful definitions >> and using those. >> > > Going down the path ippm can lead to potential issues. The current metrics > definitions are more based on deriving path metrics from link metrics > reported in the routing system (e.g., BGP-LS). This is how current > deployment (e.g., Flow Director, Lui's team) works and hence is proven to > be feasible. I do not see that the routing systems will start to ask > routing devices to measure link properties using ippm measurements, and > then report using routing protocols. Then conforming to ippm measurement > metrics can lead to higher deployment barriers. We sure can take a look but > want to point out the potential problem first. > > Almost all metrics are derived from BGL-LS metrics (RFC8571). Hence, it is not clear what more precise definitions mean. Does it mean that those definitions in RFC8571 (which are defined in IGP existing IGP protocols) are not precise, and hence should not be used (and hence switch to ippm type of metrics, which specify many more parameters such as traffic patterns)? Or it means that the performance metric document should just make a single reference, and the IGP metrics as already defined by IETF are acceptably "precise". Or maybe it is only about the tput metric, and if so, we can discuss it carefully. Thanks a lot, Richard > Thanks. > > Richard >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
