Science vs. bullshit

["Patrick W. Gilmore" <patrick () ianai net>]

Lightning talk followup because I want to make sure there was not a  
miscommunication.  A two sentence comment at the mic while 400+ of  
your not-so-close friends are watching does not a rational discussion  
make.

The talk in question:

   <http://nanog.org/meetings/nanog47/presentations/Lightning/Cowie_Recession_lightning_N47.pdf 
>

The disagreement is whether Renesys can reliably find out how many  
transit providers an AS has.  Remember, we are discussing transit  
providers here, not peers.

My point is if an AS has _transit_, then it must be visible in the  
global table (assuming a reasonably large set of vantage points), or  
it would not be transit.  Of course, this is not perfect, but it is a  
pretty close approximation for fitting curves over 10s of 1000s of  
ASes.  So things like "I have two transit providers, and one buys  
transit from the other" is a small number and not relevant to fitting  
curves.  (It also means you are an idiot, or in a corner of the  
Internet where you should probably be considered as having only one  
provider.)

Majdi has pointed out other corner cases where transit is not viewable  
through systems like Rensys.  For instance, announcing prefixes to  
Provider 2 with a community to local-pref the announcement below peer  
routes.  That means only one transit is visible in BGP data.

There were several reasons some of us did not think edge cases like  
this were important.  For instance, Renesys keeps -every- update ever,  
so if Provider 1 ever flaps, Rensys will see Provider 2.  Also, when  
looking for the number of providers, a "backup path" may not be  
relevant since no packets take that path.

More importantly, I thought the point of the talk was to show that the  
table was growing during the recession and people were still getting  
more providers.  The result is a curve, not a hard-and-fast number.   
Corner cases like the one above are barely noise, so the curve it  
still valid.

It is true that finding peering edges with things like route-views is  
problematic at best, so finding ASes with one transit plus peering  
might be problematic.  But since I do not think that was the point of  
the talk, I do not consider that problem.


If anyone who still thinks the problems with finding transit edges  
somehow make the talk 'bullshit' could clarify their position, I would  
be grateful.

--
TTFN,
patrick