North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: The Cidr Report

  • From: Stephen J. Wilcox
  • Date: Sun Feb 13 18:23:56 2005

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