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".
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)?
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.
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.
> 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."
