Subject: Optional Parameters

From: Alvaro Retana <[email-masked]>
Date: Fri, 29 Mar 2002 09:44:32 -0500 (EST)

This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):

(1) Only one parameter is defined...

(2) If we want to reflect current implementations/deployment, shouldn't we
at least make reference to the other parameters??  Even if all the text is
not included, just a reference should be made...

----

      BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer.

But draft-ietf-idr-bgp-identifier-00.txt, which proposes an alternate
definition, is a WG document.  IMHO, we should incorporate the text from
draft-ietf-idr-bgp-identifier-00.txt in the spec.  In fact,
draft-ietf-idr-bgp-identifier-00.txt reads:

   Therefore it is concluded that the revisions proposed in this
   document do not introduce any backward compatibility issue with the
   current usage of the BGP Identifier.

----

      Hold Time:

         This 2-octet unsigned integer indicates the number of seconds
         that the sender proposes for the value of the Hold Timer. Upon
         receipt of an OPEN message, a BGP speaker MUST calculate the
         value of the Hold Timer by using the smaller of its configured
         Hold Time and the Hold Time received in the OPEN message. The
         Hold Time MUST be either zero or at least three seconds.  An
         implementation may reject connections on the basis of the Hold
         Time.  The calculated value indicates the maximum number of
         seconds that may elapse between the receipt of successive
         KEEPALIVE, and/or UPDATE messages by the sender.

"The Hold Time MUST be either zero or at least three seconds."  The text
doesn't explain (here, it does elsewhere) what happens if the Hold Time is
zero.  It is not straight forward beacuse the definition is "maximum
number of seconds that may elapse between the receipt of successive
KEEPALIVE, and/or UPDATE messages by the sender".

We should add at the end: "If the negotiated Hold time value is zero, then
the session never expires.

----

Appendix 1. Comparison with RFC1771

   There are numerous editorial changes (too many to list here).

   The following list the technical changes:

      Changes to reflect the usages of such features as TCP MD5 [10],
      BGP Route Reflectors [11], BGP Confederations [13], and BGP Route
      Refresh [12].

...but when the message types are defined, Route Refresh is left out:

      Type:

         This 1-octet unsigned integer indicates the type code of the
         message. The following type codes are defined:

                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

For completeness...and to reflect the current state, shouldn't type 5 be
included??  Route refresh is mentioned a couple of times.

----

      Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict. If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used. The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

I would rewrite it to say:

This 16-octet field contains a value that the receiver of the message can
predict.  If the Type of the message is OPEN, or if no authentication
mechanism (which is specified as part of the Authentication Information
Optional Parameter in the OPEN message) is used, then the Marker must be
all ones.  Otherwise, the value of the marker can be predicted by a
computation specified as part of the authentication mechanism in use.
The Marker can be used to detect loss of synchronization between a pair of
BGP peers, and to authenticate incoming BGP messages.

The part thats kindda confusing is which messages should carry all
ones...and then the part that reads:  "...predicted by some a
computation...".

----

4.3

The UPDATE message always includes the fixed-size BGP header, and also
includes the other fields as shown below (note, some of the shown
fields may not be present in every UPDATE message):

I assume that the fixed length fields must always be included, or
there is not way to parse the update format. In light of this, it
might be better to change this to state: "....(note, some of the shown
variable length fields may not be present....)"

----

7.

version number each supports. If an open attempt fails with an Error
Code OPEN Message Error, and an Error Subcode Unsupported Version
Number, then the BGP speaker has available the version number it
tried, the version number its peer tried, the version number passed
by its peer in the NOTIFICATION message, and the version numbers that
it supports.

This sentence doesn't seem to make any sense. Maybe:

If an open attempt fails bceause of a version number mismatch, then
the local BGP speaker should receive an Error Code OPEN Message Error
with an Error Subcode Unsupported Version Number. On receiving this
notification, the local BGP speaker should have available the version
number it tried, the version number its peer tried, and the version
numbers it supports.

page 32

----

9.2.1.1

   Two UPDATE messages sent from a single BGP speaker that advertise
   feasible routes to some common set of destinations received from
   external peers must be separated by at least
   MinRouteAdvertisementInterval. Clearly, this can only be achieved
   precisely by keeping a separate timer for each common set of
   destinations. This would be unwarranted overhead. Any technique which
   ensures that the interval between two UPDATE messages sent from a
   single BGP speaker that advertise feasible routes to some common set
   of destinations received from external peers will be at least
   MinRouteAdvertisementInterval, and will also ensure a constant upper
   bound on the interval is acceptable.

Didn't we determine (on list) that this was true of unfeasible
destinations as well?

----

9.2.1.3 Jitter

   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, and
   MinRouteAdvertisementInterval.

Hmmm.... Maybe:

"To minimize the likelihood that the distribution of BGP messages by a
given BGP speaker will cluster around a particular time, causing a
short term spike in traffic which could overwhelm the network or the
peer, ...."