RIP Justification

Thu Sep 30 03:37:37 UTC 2010

hi, I summarize the discussion in my way. Please add or fix it.

* RIP works okay in topologies without topological loops.

   I would like to elaborate the term "small networks" in "RIP works
   well in small networks".
   Specifically the term "small network" would mean: 
     1) the diameter of the network is less than 15 hops,
     2) the network does not include topological loop, and
     3) the #routes exchanged in it is small.
   One does not need to care about 1) unless he or she wants to use
   the path with more than 15 hops. 2) is important to care because
   it leads to counting-to-infinity. For 3), if the #routes is large,
   the routing message may seem to be really redundant or painfull
   (refer poisonous reverse discussion).

   I am wondering whether someone saying "working well in small networks"
   checks if the counting-to-infinity occurs on their networks.
   I guess Counting-to-infinity is really hard to catch.

   I think RIP works "okay" in a whatever-large network, if above 3 points
   are fine with us. But I would not like to call the case "works well".

* Routing control message seems more redundant in RIP.

   Every 30 seconds may seem redundant.

   You may need to advertise the prefix that doesn't exist in some cases
   (poisonous reverse).

* RIP have rooms to fix, tweak, or hack the routes.

   The algorithm works okay with rejecting and modifying the 
   routes (filters) at an arbitrary point in the network. Link State
   routing protocols including OSPF and IS-IS basically do not support this.
   This is the pros in RIP.

* RIP algorithm is simple, but debugging is really hard.

   You would never want to debug what is happening in RIP, when a problem
   occurs such as Counting-to-infinity. The state of the routes
   changes too quickly to catch, and you must track the logs of all the
   routers on the way. This is almost impossible.

* OSPF algorithm (i.e. DB exchange) is complex, but debugging is
  simple.

   OSPF is easy to debug because one can point out the bad part easily
   by comparing DBs. If DBs are sync'ed, they are okay. If DBs are
   not sync'ed, the source of the problem lies in either (or both) of
   the routers. If the DB is sync'ed but routes are strange, then the
   problem lies in the Dijkstra code in the router. Most operators
   prefers this characteristic (feature). In all of the above case,
   you can simply replace the router to fix the problem.

   (Check if the router-id conflicts first, when DB changes so quickly.)

   Most people hates DB exchange in OSPF since it is hard to understand.
   So, some prefers IS-IS more, because the DB exchange algorithm is simpler.
   Complex algorithm in DB exchange may produce bugs, but may prevent
   (or at least alert) some problems that is hard to debug.

* Complexities in configuring them are not much different.

   As someone stated, tasks necessary to configure, e.g., turn on protocol,
   include network I/F, ..., walk away, are equivalent for both.

I support "everything has its place".

In summary, if you can avoid topological loop in your network,
I think RIP works okay even in a large network.

regards,
yasu