North American Network Operators Group

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

Re: a radical proposal (Re: protocols that don't meet the need...)

  • From: Andre Oppermann
  • Date: Wed Feb 15 16:20:09 2006

Edward B. DREGER wrote:
AO> Date: Wed, 15 Feb 2006 21:41:53 +0100
AO> From: Andre Oppermann

AO> Err, the problem is not the number of AS numbers (other than having to
AO> move to 32bit ones). The 'problem' is the number of prefixes in the

It's both.

AO> routing system. The control plane scales rather well and directly
AO> benefits from Moore's law. With todays CPU's there is no problem
AO> handling 2 million routes and AS numbers. Absolutely not.

For some equipment. However, I encounter a number of 7200s still in service.
So what?  The newer 7200s have got NPE-G1's or soon NPE-G2's in them.
Comes with 1G RAM default.  It's not that your 7 year old NPE-150 can
still participate in todays DFZ, is it?  We're not going to explode
the table to 2 million routes by this evening.  It still takes its
time.  You always had to upgrade to keep up with [speed, pps, routes,
features] and it's not going to change.  Get over it.  I'm not saying
only a Cisco CRS-1 or Juniper M640 can handle it.

AO> Things get a bit more hairy with the forwarding plane though. The
AO> faster the link speed the less time it has per lookup and the larger
AO> the routing table the more routes it has to search in that ever shrinking
AO> amount of time.


AO> You see, saving on AS numbers is not really going to help much where it
AO> matters.

It's also saving on route count. In my example, Cox and SBC partner up and share an ASN and a netblock. That's _one_ global route for a ton of dual-homed leaves.
1) How does this deal with local loop failures and other routing trouble?
   Think very hard.  You see?

2) You are missing the renumbering issue. Multihomed customer doesn't want
   renumber when he changes any of the ISPs in the mix.  That's why everyone
   wants PI space.

AO> entity.  Perfect matches in hardware are pretty easy to do for large
AO> numbers of them compared to longest match.  On the plus side perfect
AO> match scales much better too and can be done in parallel or distributed
AO> within a routing chip.  Doing the same for longest-match requires a lot
AO> more effort.  With perfect-match having 2 million routes is not much of
AO> a problem too.

All true.  But can we wait for all the forklifts?
Well, the policy and some aspects of the implementation have to change anyway.
Why not do it in a way that at least scales before we hit the other brickwall?