Hmm, I know there are a lot of overburdened BR's out there, but
since this is set on a per-neighbor basis, there should at least
be room for some selective optimization. It seems a bit crazy
to think that each time there's a BR maintenance/reboot at an IXP,
peers will continue to send to the bit bucket in the sky for 180+
seconds.
I think the argument is one of stability. BGP is supposed to be stable for
days/weeks on end normally. Making your internal network too sensitive to
external changes destabilizes your network and those who connect to you.
If a BGP session with one peer resets once every three days, and you peer
with them at a few places, at most you are talking about a service
degradation for about 5-10 minutes as say 1/3 of your packets are resent
or dropped (assuming you peer in three places, etc). 180 seconds is
nothing for a router with many peering sessions and a reasonable traffic
load.
Its not exciting, but the other peer's customers are just as screwed. If
the whole fabric went goes down, a good dampening policy at your
internal-> BR routers will keep the instability from influencing your
core.
The bigger concern is IF a peer is dropping a session that often, *what*
is wrong with their router? I am very afraid of routers that *randomly*
timeout and re-peer with no good reason.
Most networks insert new routes at internal/CR/other routers that are
automatically distributed to their borders, this way internal route
changes do not require resetting of external peers to take effect.
So, maybe I am misunderstanding your concern, why micromanage BGP timers
on your routers when a reasonably sized network may have more than 1000
external peering sessions; and each router on both sides has different
loading characteristics that are not stable?
inbound prefix limits are my personal interest in a lot of these per
neighbor configs and even, then a big customer signed on or leaving a peer
causes the prefix limits to get hit or be meaningless; I only recommend
them for use with peers that have fat finger engineers working at 4am. 
Deepak Jain
AiNET
I think the argument is one of stability. BGP is supposed to be stable for
days/weeks on end normally. Making your internal network too sensitive to
external changes destabilizes your network and those who connect to you.If a BGP session with one peer resets once every three days, and you peer
with them at a few places, at most you are talking about a service
degradation for about 5-10 minutes as say 1/3 of your packets are resent
or dropped (assuming you peer in three places, etc). 180 seconds is
nothing for a router with many peering sessions and a reasonable traffic
load.
With regard to your earlier comments about busy routers "pausing"
BGP, perhaps this is something that can be investigated at a vendor
software level. I would think keepalives (of any variety) should rank
fairly high on the food chain in terms of CPU precedence. If this isn't
the case already, why not? I don't know how true it is anymore, but I
recall a few years back having to deal with some routers which got
bogged down with OSPF updates to the point that they kept resetting
perfectly stable links (or the other end did) due to keepalives not
being processed in a timely manner. In the interest of stability, I
would certainly want keepalives to be processed ahead of routing
updates. After all, it's not as though they even represent a significant
percentage of the total workload on the CPU, even when you reach a
reasonably high number of links. And if your links keep resetting due
to route churn, you've got a self-perpetuating problem.
The bigger concern is IF a peer is dropping a session that often, *what*
is wrong with their router? I am very afraid of routers that *randomly*
timeout and re-peer with no good reason.
In this case, I would expect a NOC with proper monitoring of peering
sessions to take notice and initiate an investigation into the problem.
-c
With regard to your earlier comments about busy routers "pausing"
BGP, perhaps this is something that can be investigated at a vendor
software level.
[snip]
In the interest of stability, I
would certainly want keepalives to be processed ahead of routing
updates.
BGP is TCP-based, so there is no (easy) way of ensuring that the
keepalives go to the top of the queue without possibly corrupting
the routing data itself.
But perhaps TCP connection handling (for existing connections anyway,
so as not to make the router more susceptible to a SYN flood) could
be bumped up, at which point you could hand off routing updates into
one queue and keepalives into another.
I know it's much easier for me to say than it would be to code, but
it certainly seems doable and it sure could be a lifesaver during
routing storms.
-c