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: Ejay Hire
  • Date: Wed Feb 15 15:57:17 2006 
I like this idea, and your argument about simplifying the
forwarding plane makes sense.  
Should every edge node speak the EGP, or is be static from
the NSP?  My assumption is that they'll generally be static
from the NSP, unless multihomed to keep from exchanging
routing information about 2^32 prefixes.

-ejay

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
On 
> Behalf Of Andre Oppermann
> Sent: Wednesday, February 15, 2006 2:42 PM
> To: Edward B. DREGER
> Cc: [email protected]
> Subject: Re: a radical proposal (Re: protocols that don't 
> meet the need...)
> 
> 
> Edward B. DREGER wrote:
> > CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
> > CA> From: Chris Adams
> > 
> > CA> There's a difference: computers (routers) handle the

> O(N^2) routing
> > CA> problem, while people would have to handle the
O(N^2) 
> cooperative AS
> > CA> problem.
> > 
> > 0.1 ^ 2 < 5000
> > 
> > One must also consider the scalar coefficient.
> 
> Err, the problem is not the number of AS numbers (other
than having to
> move to 32bit ones).  The 'problem' is the number of
prefixes in the
> routing system.  The control plane scales rather well and
directly
> benefits from Moore's law.  With todays CPU's there is no
problem
> handling 2 million routes and AS numbers.  Absolutely not.
> 
> Things get a bit more hairy with the forwarding plane
though.  The
> faster the link speed the less time it has per lookup and
the larger
> the routing table the more routes it has to search in that

> ever shrinking
> amount of time.
> 
> You see, saving on AS numbers is not really going to help 
> much where it
> matters.
> 
> IMHO, and I have stated this before, the best way to
handle the route
> issue is to hand out IPv6 /32 for multihoming and make it
the 
> routeable
> entity.  Perfect matches in hardware are pretty easy to do
for large
> numbers of them compared to longest match.  On the plus
side perfect
> match scales much better too and can be done in parallel
or 
> distributed
> within a routing chip.  Doing the same for longest-match 
> requires a lot
> more effort.  With perfect-match having 2 million routes
is 
> not much of
> a problem too.
> 
> -- 
> Andre
>