[trimmed individuals from cc list]
los pobres paquetos: that's just the beauty and purpose of routing
protocols to propagate the info so that los pobres paquetos don't clog
the pipe with the goal of being dropped.
Routing protocols propagate the info at some granularity. You inevitably
have to choose a granularity smaller than which you don't care to propagate
trivial little facts about reachability, though. Traditionally, the grain
of routing was the classful net, and no one propagated information about
subnets or host routes in their external routing. For example, if I turned
off my workstation, a telnet attempt would send packets all the way from
you to my border before you got an unreachable.
So dynamic routing has never provided full disclosure of the exact
topology. It provides a useful approximation. Part of what you have to
decide is the tradeoff between routing load and how much information it is
really useful to propagate.
Pipe clog is not likely to be a big issue for TCP connections at any rate
(as I think someone else observed) since they back off pretty fast.
Also, note that with CIDR the same kind of behavior is already built in to
the architecture: If you are advertising foo/16 and your customer foo/24
drops off the face of the earth, are you going to send a withdraw? I think
not. Packets for foo/24 get hauled to your border before you send an
unreachable. This has not yet caused the death of the net as we know it.
To hold routes eternally down is not good: what if the customer
disconnects that network? I don't want to be notified by all leaf
networks when they will hickup or disconnect for good.
I don't understand this point: You don't want to have to have to change
your router configuration even if you lose a customer? I have a hard time
believing that this is what you mean.
Many people have made good arguments for why you need to do dynamic routing
with multi-homed customers, but I have never yet seen a convincing reason
not to hold down stubs.