cyrill-k
commented
4 years ago I made a commit a6d104d with some small textual changes and I added the following to the path selection use case:
Path selection based on measurements might not just be useless but could also be harmful for the stability.
renghardt
Based on the comments we got at IETF 106 and on Med's review, I refactored the use cases. I removed Performance Monitoring and Enhancement because monitoring was mostly talking about how to get path properties (which is out of scope for our draft) and then enhancement can take different forms: Path selection, protocol selection/configuration, service invocation, or perhaps others. Here I'm just wondering whether to include a reference to LOOPS somewhere, e.g., a path element adding some FEC on some encapsulated traffic based on path properties. But we don't really have an adopted draft for that yet, while other examples such as TCP converters and performance routing are already adopted IETF documents.
I reshuffled the Path Selection section a bit because I think the part of when you can do path selection should come earlier, and also the warning to be aware of their limitations, before going into examples.
Finally I split Protocol Selection and Service Invocation (named based on a suggestion by Med), because I think these are really separate things to do to your traffic and/or path.
Please let me know what you think. :)
BTW, I'd like to get a new revision out soon-ish (within the next few weeks), i.e., before my planned relocation. If you want to do a PR for any of the remaining issues yourself before then, feel free to self-assign an issue.