Re: The Cidr Report

["Stephen J. Wilcox" <steve () telecomplete co uk>]

On Sun, 13 Feb 2005, Michael Smith wrote:

> > From: "Warren Kumari, Ph.D, CCIE# 9190" <warren () kumari net>
> > Date: Mon, 14 Feb 2005 10:14:38 -0500
> > To: <nanog () merit edu>
> > Subject: Re: The Cidr Report
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote:
> >
> > > On Sat, 12 Feb 2005, Alexander Koch wrote:
> > >
> > > > On Sat, 12 February 2005 14:58:42 +0000, Stephen J. Wilcox wrote:
> > > > > From: "Stephen J. Wilcox" <steve () telecomplete co uk>
> > > > > [...]   - would you agree that most of the poor deaggregating is not
> > > > > intentional
> > > > > ie that they're announcing their '16 class Cs' or historically had 2
> > > > > /21s and
> > > >
> > > > Think about someone putting in a Null0 route and re-
> > > > exporting stuff unconditionally, now after he originates
> > > > his /19 he is then adding a /24 here, and a /25 there.
> > > > Lack of experience, when you suggest to them they should
> > > > remove these announcements they are afraid to change it,
> > > > not understanding the implications, etc.
> > > >
> > > > Not to mention ppl using cisco and prefix lists, it is
> > > > way too easy with cisco to say '/19 le 24', and then they
> > > > use outbound prefix lists to their transit supplier
> > > > (different, but related as I see it). Some transit ISPs
> > > > use that a lot, and encourage the table growth.
> > >
> > > There are some business reasons to de-aggregate. Look at some outages
> > > caused by 'routing problems' (someone leaked my /24's to their peers,
> > > peers, peer and my traffic got blackholed, because the public net only
> > > knows me as a /20)
> > >
> > > There are multiple reasons for deaggregation aside from 'dumb
> > > operator',
> > > some are even 'valid' if you look at them from the protection
> > > standpoint.
> > >
> > > -Chris
> >
> > That and the "I have 1 circuit to $good_provider and 1 circuit to
> > $bad_provider and the only way I can make them balance is to split my
> > space in half and announce more specifics out through each provider"
> > argument. I have also often seen people do this without announcing the
> > aggregate because   <some undefined bad thing> will happen, usually
> > justified with much hand-waving.  The people who do this can usually
> > not be reasoned with....
> >
> > It happens all the time...
> >
> > Warren.
>
> So, say  I'm a provider that has received a /22 from UUNet (just for example
> Chris :-) ) and I now get another transit provider and announce the /22
> there.  So, I call UUNet and ask them to announce the /22 as a more specific
> because I don't want a de-facto asymmetric configuration.  I *want* to get a
> /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22
> for some time.

Hi Mike,
 this isnt the scenario being discussed. The scenario of issue is where you get 
your /22 from UUNET and announce 4x /24 ie based on what ips you have you choose 
to announce more than the minimum to make them routable

> By the long string of anecdotal attacks in the string to date, listing most or
> all such providers as "bad" or "uninformed" how do you separate out those
> providers who are legitimately interested in routing redundancy and not clue
> impaired?  Do we just say "too bad, routing table bloat is more important than
> your need for redundancy small guy!"?

As I say this isnt the issue here, altho what you suggest would be an example
of further aggregation that i personally think is extreme. Multihoming must be 
possible and a hierarchical structure to the internet is not appropriate.

> I find it interesting that the general theme is one of "we're smarter than
> they are because we aggregate more routes" as if clue were directly correlated
> to aggregated routing announcements.

Well, there does seem to be some loose correlation it cant be denied... (counter 
examples not required, we know they exist)

Steve