Subject: RE: issue 8: final text

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 18 Oct 2002 09:38:32 -0400

Folks,

The IOS defaults are 5 seconds for MinRouteAdvertisementInterval for IBGP
and 30 seconds for
EBGP(not sure what these are for Juniper, my guess is 30 for both).  This
makes sense to me
since for IBGP you are more concerned with convergence, whereas for EBGP you
are more
concerned with stability.  But I'm not sure if this could effect
interoperability, but if it
is and the involved implementations' timers were not configurable then there
might be a
problem.

I propose we change:
"An implementation of BGP MUST allow the Hold Time timer to be configurable,
and MAY allow
the other timers to be configurable."
to:
"An implementation of BGP MUST allow the Hold Time timer to be configurable
on a per peer
basis, and SHOULD allow the other timers to be configurable on a per peer
basis.

(RFC1771 has "An implementation of BGP MUST allow these timers to be
configurable.")

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, October 17, 2002 9:23 AM
To: [email-masked]
Subject: issue 8: final text

Folks,

Here is the final text for the BGP Timers section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested default value for the ConnectRetry timer is 120
   seconds.

   The suggested default value for the Hold Time is 90 seconds.

   The suggested default value for the KeepAlive timer is 1/3 of
   the Hold Time.

   The suggested default value for the MinASOriginationInterval is
   15 seconds.

   The suggested default value for the MinRouteAdvertisementInterval
   is 30 seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker may apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter need not be configured on a "per
   peer" basis.

   The suggested default amount of jitter shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0. A new random value should be picked each time the timer
   is set. The range of the jitter random value MAY be configurable.

With this in mind, I would suggest we mark this issue as closed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 18 Oct 2002 09:53:54 -0700

Jonathan,

> basis, and SHOULD allow the other timers to be configurable on a per peer

How about the following:

  An implementation of BGP MUST allow the Hold Time timer to be configurable
  on a per peer basis, and MAY allow the other timers to be configurable.

Yakov.