AT&T
doesn't seem to be even willing to change BGP timers. If anyone have
been able to talk AT&T or Qwest in doing so, it would really help to
Hold timers are negotiated in the OPEN message, I seem to remember, so
surely you *have* to hard reset the connection to get the lower
holdtime?
M
I just tested this and, yes, with Cisco to Cisco, changing the setting
won't reset the connection but you have to reset the connection to
have the value take effect. I need to look up what happens when two
sides are set to different values and which one takes precedent.
The holdtime isn't technically negotiated, both sides convey their
value in the open message and the lower of the two is used by both
BGP speakers. IIRC, neither J or C reset the session with the timer
change, but the new holdtimer expiry value doesn't take effect until
then.
One other thing to note is that by default, keepalive intervals in
those implementations are {holdtime/3}. Normally, if you're setting
holdtime to something really lower (e.g., 10 seconds) you might want
to increase the frequency of keepalives such that the probability of
getting one through in times of instability rise. In particular,
congestion incurred outside of BGP, as update messages themselves
will serve as implicit keepalives, and with the amount of churn in BGP,
empty updates (keepalives) are rare for most speakers with a global BGP
view.
-danny
Rest assured J will always reset the session if given given half a
chance, and changing your holdtime is more than half. 
One thing I find interesting is that most other protocols will err on
the side of caution and use the higher of two values like this when
negotiating between two parties, but BGP does the opposite. I still run
into bad bgp implementations which can't keep up with my 30 sec hold
timers all the time *coughghettoequinixrouteservercough*.