I do not know about such tools. Even if something close to what you are searching for exists, I don't expect any accuracy in the information or any scalable way to to tell this information to your routers (no question about forcing it to other people's routers for your incoming traffic). For example, the number of AS's in the path to a destination could be less via ISP B, but the geographical distance could be more, which normally translates to more delay. How can you teach your routers (and other people's routers) geography when the IP addressing scheme is so irrelevant to geography?
From my experience, if the two ISP's are "close" (e.g. both in Europe), then you won't have many problems and it is not worth the effort to do a lot of things. In this case, the number of AS's in the path to destination is an ok way for you to choose your outgoing path. If the two ISP's are "not close" (e.g. you are in Europe and you have one direct connection to Europe and one to US), then you do have a problem, mostly with networks that have the same number of AS's in the path to destination via both ISPs (e.g. 2 AS's via both ways). This kind of issue could be "solved" by directing outgoing traffic first to the router that has the direct connection in the same continent where your traffic is sourced (e.g. in the example above where you are in Europe, you believe that when 2 paths are equal, European connection will be better). Some traffic may sometimes do an extra hop inside your network, but I have seen this working fine. It might not be satisfying in you case, but I mention it just in case you are interested. (The logic behind this hack is based on the BGP best path selection algorithm. Router will prefer its own direct connection when AS path lengths are equal via both ways, all other things being equal.)
For your incoming traffic things are harder. You cannot really control how others will send traffic back to you. Even load balancing can be hard (with prepends and condidional advertisements), so no question about optimal incoming traffic distribution.
The Cisco Performance Routing Q&A does not mention ISPs as the target audience for this solution (perhaps because not many ISPs would listen to it, unless customer base is limited enough for their network to be considered equivalent to some kind of enterprise network). Have you seen this before being used in an ISP environment?
You're correct it isn't targeted toward ISPs, most likely due to scaling issues. However, in this particular instance, trying to obtain additional stats on just two paths, and without any need to control traffic, it might be of use.
No, haven't seen it in use in ISPs. Not only for possible scaling issues, but also platform support, which might also be a problem in this instance too.
OER/PfR has the ability to control routes in an attempt to improve end-to-end performance and/or load balance across multiple paths. There's a setting to only monitor, i.e. not control, the traffic. Since you're interested in collection of performance stats, that setting would be the one you would likely use (if you used this technology).
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...