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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf