Subject: issue 8

From: Yakov Rekhter <[email-masked]>
Date: Wed, 02 Oct 2002 08:49:34 -0700

Folks,

I'd like to propose the following text for "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 value for the ConnectRetry timer is 120 seconds.

   The suggested value for the Hold Time is 90 seconds.

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

   The suggested value for the MinASOriginationInterval is 15
   seconds.

   The suggested 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 shall apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter will not be applied on a "per
   peer" basis.

Any objections ?

Yakov.

   The amount of jitter to be introduced 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.

---

From: Justin Fletcher <[email-masked]>
Date: 02 Oct 2002 08:56:17 -0700

>    factor which is uniformly distributed in the range from 0.75 to

I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
to ensure the average is the configured interval.

Justin Fletcher

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Oct 2002 11:59:15 -0400

> I'd like to propose the following text for "BGP Timers" section:

This seems like a very good idea.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 02 Oct 2002 09:02:19 -0700

Justin,

> to ensure the average is the configured interval.

that would be fine too.

yakov.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 13:12:57 -0400

In message <[email-masked]>, Yakov Rekhter writes
>    are being sent; that is, jitter will not be applied on a "per

minor improvement (not really an objection) --
   s/suggested value/suggested default value/g

Also

  s/shall apply the same jitter/may apply the same jitter/
   (to each of these quantities regardless of ...).

  s/jitter will not be applied/jitter need not be configured/
    (on a "per peer" basis).

We allow both timers and jitter to be configured with fine granularity
(per peer for BGP, down to per LSP for MPLS, with a reasonable
inheritance heirarchy to allow a change in system defaults or at the
peer group level, etc).  I think others do as well but maybe not with
quite the same flexibility.  This seems to be forbidding configurable
jitter using lower case normative (whatever difference that makes).

>    factor which is uniformly distributed in the range from 0.75 to

I'd like to change that last paragraph:

   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.

We *do* allow all timers to be configured and allow absolute values or
relative values (a percentage of the base value).  We also add the
jitter to most timers (at least the MPLS ones) rather than make them
smaller but that is a minor difference.

[and you *can* really make a mess of things by configuring timers
badly - but this is consistent with the "more rope please" customer
requirement that we are all familiar with. :) ]

Curtis

ps - I hope this does not reopen the debate on timer verbs over what
it means to "set" a timer.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 13:23:51 -0400

> to ensure the average is the configured interval.

This is just a suggested default value and an implementor is free to
use another such as .75 to 1.25 (and it would be a good idea to
document it clearly).  Some conformance freak might take this as
gospel and also check the uniformness of the random distribution but
that too is a recommended default and selection from some other
distribution (tail truncated) would still be compliant.  Someone might
pick .75 to 1.25 if preserving the mean value seemed more appealing
and someone else might use another distribution if it saved a few CPU
cycles and both would be OK.

Briefly - it doesn't matter.

Curtis

---

From: Justin Fletcher <[email-masked]>
Date: 02 Oct 2002 10:59:42 -0700

> Briefly - it doesn't matter.

That is rather the question, isn't it?  If we're looking at this from
a new implementor's point of view, how do you know that this doesn't
matter from reading text that reads "shall be determined"?

If most implementations use other values and it doesn't matter,
I'd suggest the first line of the text to read

"A recommended amount of jitter to be introduced may be determined by"

In retrospect, I'd be happy with either the original text or any of the
proposed changes; it's not a strong opinion :-) and I wouldn't have
raised the issue in the first place if I'd done my homework & checked
the RFC.

Justin

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 16:57:26 -0400

> matter from reading text that reads "shall be determined"?

The wording changes I made stated this as a recommendation.  I'm sorry
for the inaccuracy in my comment.  It should be a recommendation.

> raised the issue in the first place if I'd done my homework & checked

Please consider the substitute text I suggested.  Relaxing the jitter
statement to a recommended default is one of the changes I suggested.

You are correct in that as it is now stated, the jitter is not
configurable and must be implemented as specified.  This should be
fixed.

Curtis