1.1. Limitations of the protocol

1.1. Limitations of the protocol

This protocol does not solve every possible routing problem. As
mentioned above, it is primary intended for use as an IGP, in
reasonably homogeneous networks of moderate size. In addition, the
following specific limitations should be mentioned:

The protocol is limited to networks whose longest path
involves 15 hops. The designers believe that the basic
protocol design is inappropriate for larger networks. Note
that this statement of the limit assumes that a cost of 1
is used for each network. This is the way RIP is normally
configured. If the system administrator chooses to use
larger costs, the upper bound of 15 can easily become a
problem.

The protocol depends upon "counting to infinity" to resolve
certain unusual situations. (This will be explained in the
next section.) If the system of networks has several
hundred networks, and a routing loop was formed involving
all of them, the resolution of the loop would require
either much time (if the frequency of routing updates were
limited) or bandwidth (if updates were sent whenever
changes were detected). Such a loop would consume a large
amount of network bandwidth before the loop was corrected.
We believe that in realistic cases, this will not be a
problem except on slow lines. Even then, the problem will
be fairly unusual, since various precautions are taken that
should prevent these problems in most cases.

This protocol uses fixed "metrics" to compare alternative
routes. It is not appropriate for situations where routes
need to be chosen based on real-time parameters such a
measured delay, reliability, or load. The obvious
extensions to allow metrics of this type are likely to
introduce instabilities of a sort that the protocol is not
designed to handle.