RE: Scalability issues in the Internet routing system
Andre: Hence my earlier point on #2 - the prefixes in the routing hit one part of Moore's law. The FIB hits another. Using the compression ("cooking") per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a "minimum" set of routes can provide some leverage against the prefix growth. Tony point still stands. The "cookinjg" way to deal with prefix growth by using a compression algorithm for FIB insertion. Moore's law hits the security filters, the route filters, and lots more - that may or may-not be able to be "cooked". Sue Hares -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tony Li Sent: Tuesday, October 18, 2005 4:46 PM To: Andre Oppermann Cc: nanog@nanog.org Subject: Re: Scalability issues in the Internet routing system Andre,
capacity = prefix * path * churnfactor / second
capacity = prefixes * packets / second
I think it is safe, even with projected AS and IP uptake, to assume Moore's law can cope with this.
This one is much harder to cope with as the number of prefixes and the link speeds are rising. Thus the problem is multiplicative to quadratic.
You'll note that the number of prefixes is key to both of your equations. If the number of prefixes exceeds Moore's law, then it will be very difficult to get either of your equations to remain under Moore's law on the left hand side. That's the whole point of the discussion. Tony
Susasn,
Using the compression ("cooking") per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a "minimum" set of routes can provide some leverage against the prefix growth.
By cooking down the prefixes you unfortunately lose topology information which might be a bad thing, and at the same moment disrespect the site's wish to how it would like to be routed. Another bad thing, if you think of companies/sites paying for the entire network in the long run. Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes. I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions? Yours, Elmi. PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)? -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Elmar K. Bins wrote:
Susasn,
Using the compression ("cooking") per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a "minimum" set of routes can provide some leverage against the prefix growth.
By cooking down the prefixes you unfortunately lose topology information which might be a bad thing, and at the same moment disrespect the site's wish to how it would like to be routed. Another bad thing, if you think of companies/sites paying for the entire network in the long run.
Cooking prefixes was only meant to be done within the router between the control plane and the (hardware) FIB or forwarding engine. This ain't prefix aggregation within the BGP system.
Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes.
And this won't change in future.
I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions?
Yours, Elmi.
PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)?
With pretty high certainy one can say that it is an old idea with some minor twist or wording change. -- Andre
nanog-list@nrg4u.com (Andre Oppermann) wrote:
Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes.
And this won't change in future.
I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions?
Yours, Elmi.
PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)?
With pretty high certainy one can say that it is an old idea with some minor twist or wording change.
I was thinking of something different from Susan's approach, hence my question. Cooking up stuff to save memory and processing in the router isn't it, IMHO, but I have ideas in my head which I would like to share. But then, I wouldn't want to spoil everybody's time if it's old. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Wed, 2005-10-19 at 09:31 +0200, Elmar K. Bins wrote:
Susasn,
Using the compression ("cooking") per router can provide one level of abstraction [reduction of prefix space] at router. So cooking down your Large number of routes to a "minimum" set of routes can provide some leverage against the prefix growth.
By cooking down the prefixes you unfortunately lose topology information which might be a bad thing, and at the same moment disrespect the site's wish to how it would like to be routed. Another bad thing, if you think of companies/sites paying for the entire network in the long run.
Don't expect an interest in your topology to reach much beyond your peers. This isn't about prefix-aggregation, but about dropping information from a router's memory that isn likely to be used. With many peers you may have a large number of route entries for a given prefix from which your router chooses one to be used and possibly re-distributed to others. Ex: All that happens if you choose to only keep the 2 best alternatives out of 5 or more is loss of redundancy in case both the best routes are withdrawn. The algorithms used to select the best path(s) remain unchanged.
Apart from that, IMHO cooking down the prefixes only buys time, but does not solve the problem. More people will multihome, and with the current mechanisms and routing cloud, they have to do it by injecting prefixes.
I'm not sure whether this hasn't long become an architectural question and should be moved to the (new) IETF arch list. Opinions?
Agree ... unless ....
Yours, Elmi.
PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)?
I'm aware of the new architecture list, but maybe the IRTF Routing Research Group (http://psg.com/~avri/irtf/rrg-page.html) is an even more appropriate place. From their charter: The Routing Research Group (RRG) is a group chartered under the Internet Research Task Force to "explore routing problems that are important to the development of the Internet but are not yet mature enough for engineering work within the IETF." Of partial relevance to the recent discussion you'll find documents there like a recent compilation of requirements for future inter-domain-routing: http://www.watersprings.org/pub/id/draft-irtf-routing-reqs-03.txt //Per
PS: Btw, anyone can give me a hint on where to discuss new ideas for e.g. routing schemes (and finding out whether it's an old idea)?
You might start with the routing-discussion mailing list: http://www.rtg.ietf.org/ Please expect that your idea has been discussed before. We're an old bunch. ;-) Tony
tony.li@tony.li (Tony Li) wrote:
Please expect that your idea has been discussed before. We're an old bunch. ;-)
I've just answered on a mail from Owen, so maybe you get the feeling of "oh, we discarded that long ago" when you read it. Please tell me ;-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
participants (5)
-
Andre Oppermann -
Elmar K. Bins -
Per Heldal -
Susan Hares -
Tony Li