Vadim,
] 2) Don't Do Any Dynamic Routing Where Only One Path Exists.
Certainly I would not agree with this rule.
If I have a tail router that is down, I do not want to send
traffic to him, when he is not there to receive it. Rather, I
would want my intermediate router to reject it right off.
Furthermore, I do not want to extend nondynamic notification in my
network.
------------------------ = ------------------------
Network:
rtra --------+-------+
> >
rtrb --------+ rtrd +--------- rtre ------- rtrf
> >
rtrc --------+-------+
------------------------ = ------------------------
If rtra is down, I do not want rtre to send packets to rtrd to get
to rtra, do I? Wouldn't I prefer them to be stopped ASAP?
Certainly this is a debatable point.
* Another situation is what happens when you renumber networks?
What hapens when you've large number of downstream networks? Do
you really want static routes in rtrf for all networks attached to
rtrs a,b,c,d,e?
What I find, is that in running a "large" network, filtered
dynamic routing is far preferrable to either static leaf nodes, or
unfiltered dynamic routing.
I want my dynamic routing to be binary: what I should get, or
nothing.
-alan
If rtra is down, I do not want rtre to send packets to rtrd to get
to rtra, do I? Wouldn't I prefer them to be stopped ASAP?
This makes no difference. For most intents and purposes, one-way
traffic doesn't exist. The only thing going down that line will
be the odd packet intended to open a conversation -- the volume of
this will be minimal compared to normal traffic volumes. And even
if you had one-way traffic in volume, it wouldn't exceed normal
traffic levels, for which you will already have the capacity.
Whenever you do dynamic routing when it isn't necessary, you -will-
be emitting unnecessary updates, which nobody is interested in. We
have several ASs behind unstable lines behind us, from which we do
not propagate routing changes; we set origin AS and announce
nailed-up static routes in their AS. Neat, stable, works -- no flap
and no global propagation delay when the connection comes back up.
* Another situation is what happens when you renumber networks?
Your router configuration will be changed ... ? 
What hapens when you've large number of downstream networks? Do
you really want static routes in rtrf for all networks attached to
rtrs a,b,c,d,e?
Where you cut dynamic updates off doesn't really matter. The key
issue is not to propapgate unnecessary updates. I mean, is it really
interesting that a tail circuit in Cargolia went down? Does this
event -have- to be announced to the Net?
A different issue is that there are many networks with broken
configuration. If these people would "do the right thing", and not
announce their instability to the Net, we'd be rid of, what?, 90% of
all route flap.
From reading this discussion, I think that there are two separate issues
being discussed or argued here - specifically internal versus external
routing methodologies.
Generally, you should never announce internal instability/reachability
problems to the real world. There are some exceptions of course - most
notably issues regarding full "SPLITS" of internal networking (you end up
with two distinct networks which don't have connectivity to them) -
but in most of these cases you're screwed in any case as you've probably got
aggreated CIDR blocks split up.
As far as your internal routing goes, there's arguments both ways. In my
network I have some "customer edge" border routers which are quite
frankly incapable of "null0" routing. When they get a packet which is
bound for a link which is down they forward it back to their default,
which, under static routing, would forward it back to them, and on and on
until the TTL is expired.
I personsonally use dynamic routing between the braindead router and the
more clueful one (cisco) to enable discarding of packets. When the route
flaps down, the cisco now uses the null0 path. When it flaps back up,
the cisco then starts forwarding packets again.
However, the world never needs to see this - it's an internal routing
issue and when the internal route flaps it shouldn't affect the external
routes.
So in summary:
1) Never flap your routes in public. What you do in your own home is
your own business.
-forrestc@imach.com