Aggregation & path information [was: 200K prefixes - Weekly Routing Table Report]

Patrick W. Gilmore patrick at
Fri Oct 13 19:30:37 UTC 2006

On Oct 13, 2006, at 3:26 PM, Jared Mauch wrote:
> On Fri, Oct 13, 2006 at 03:14:38PM -0400, Patrick W. Gilmore wrote:

>> Obviously the table contains kruft.  But I know we could not shrink
>> it to 109K prefixes without losing something from where I sit.  Are
>> you sure there's no additional path info?
>> If there were a way to guarantee certain prefixes are completely
>> superfluous, we could make a hit list of just those providers, then
>> ridicule or filter or cause them pain in some way to make them stop
>> causing us pain.  I haven't seen that type of report posted publicly,
>> just "this CIDR can fit in that one" without actual guarantees that
>> _paths_ are equivalent.  (Usually the origin AS is matched as well as
>> the prefixes, but that's not the same as guaranteeing the path is
>> equivalent.)
>> Of course, this is non-trivial.  But then neither is aggregating the
>> global table. :)
> 	how much of this could be mitigated if people properly announced
> aggregates and used a provider-local no-export to balance their links
> with them?  it does make those policies more complicated than the
> simple cut+paste examples that they've likely used in the past, but
> could possibly allow the "traffic-eng" with their upstream without
> the global pollution.

Sorry if I wasn't clear before, but I consider path info _just for  
your first hop upstream_ superfluous for the rest of the Internet.   
Does anyone think this is an unreasonable restriction?

More important question: How many people are doing TE or something  
and not applying no-export when they could?  If you need help fixing  
that, or even figuring out if you need to fix it, I guarantee you  
several people on this list would help you, many for free.

This is one of the reasons things become "non-trivial".  How do you  
prove that a disgregate prefix is useless to anyone except that one  

I do not think it is impossible.  But it certain ain't easy.


More information about the NANOG mailing list