Heads up: Long AS-sets announced in the next few days

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