On 2-dec-04, at 9:54, Simon Leinen wrote:
But all of this is only delaying the inevitable (not that that can't
be useful sometimes): at some point, we need to move away from the
premise that all default-free routers must know about all reachable
prefixes.
But isn't this the *definition* of a default-free router?
That's my point. We need to find some middle ground between using a
default and having every single prefix in the world in the table.
Maybe you mean we need to move away from the premise that you have to
run default-free ("full BGP table!") to be taken seriously.
Who cares about being taken seriously? :-)
No, that's not it. A default doesn't do any good because the only thing
it does is move the packets to a place where full routing information
is known. Obviously today some people run defaultless because they can
and not because they must, but there are also lots of routers that run
defaultless because there is no smarter router they can dump the
traffic on.
With this ball and chain removed we can start looking at new
interdomain routing paradigms, such as an idr link state protocol
that can function in a never fully converged state. (Which would
make for some nice PhD work...)
There's lots of exciting new work about loop prevention in link-state
internal routing protocols right here in the IETF - check out
http://rtg.ietf.org/wg/rtgwg/
I don't see anything except web design with broken assumptions...
But correct me if I'm wrong, current link state routing protocols
already know how to get rid of loops...?
Maybe some of this could be leveraged for a new external routing
protocol.
(Not that I think that it will be likely that we move from BGP to an
entirely new protocol without replacing all current IDR players... but
that doesn't mean you shouldn't try :-).
A new EGP needs to be able to work with BGP so there is no need for
everyone to upgrade at the same time. But even then it won't be easy as
network operators are a conservative bunch (much more so than they
think they are). Most of all, a new EGP needs to bring compelling
benefits to the table.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf