On Thu, 3 Mar 2005, Lorenzo Colitti wrote:
Ok, I realize I might have given the wrong impression here. Sorry.
So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity.
Since this is a new technique, it's not clear if it is actually effective, and to measure this we need to test it in the real world. If the experiments show that the technique performs as we hope, we intend to publish the results and provide the details for public use.
We will post appropriate references to this list as soon as we have some hard data and have put it into a presentable form. But first we need to do the experiments...
Hi Lorenzo, Its a basic design function to keep the net loop free, of BGP to not accept a route with the routers own ASn in the path from an external peer. You appear to be trying to take advantage of a side effect of this behaviour, in order to see what other ASn transitive adjacancies are available that would not normally be used, by inserting the ASns of transit AS's that would normally be used, into the as path you are announcing. I'm sure this was never an intended use for BGP as paths (or as sets, but that could be confused with the as-set object in the ripe database, which is something different, so i'll say as-paths). More to the point, you are breaking a very fundemenatal convention and expectation that if you see a given ASn in an as path, that route will have transited that given ASn. As such, inserting others ASns into an as path is about as helpful to debugging as policy routing all your ICMP traffic to a box running fakeroute! There are various 'better than regular bgp bestpath' platforms out there, such as those internap implements, routescience, sockeye, netvmg.. Are you certain that these products do not take into account the amount of churn of a given ASn? By inserting operators ASns into announcements for your research, you are artifically increasing the amount of churn seen for their ASn. I note from your initial email "The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654." I'd like to point you at https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html and note that the smallest allocation from 84/8 is a /21, so by doing your announcements with /24s, you are probably going to hit some operators prefix length filters, thus tainting your results. You might be better off with some swamp space, which will be accepted globally as /24s. Sorry to be a wet blanket, but I think inserting other operators ASns without their permission is lunacy. I'm also concerned that this might lead to a convention where inserting other operators ASns into a path becomes more seen as 'acceptable', whereas it is currently regarded as a big 'no no'. And I suspect that prefix length filtering on your /24s from /21 space is going to taint the results anyway. Regards James