[130191] in North American Network Operators' Group
Re: RIP Justification
daemon@ATHENA.MIT.EDU (Christian Martin)
Wed Sep 29 16:44:07 2010
In-Reply-To: <AANLkTinW=V+RqCOf1DmBzuD06WzQk6upkZTNtU_cRCc6@mail.gmail.com>
From: Christian Martin <christian.martin@teliris.com>
Date: Mon, 18 Oct 2010 16:16:02 -0400
To: Jesse Loggins <jlogginsccie@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 29, 2010, at 4:20 PM, Jesse Loggins wrote:
> A group of engineers and I were having a design discussion about =
routing
> protocols including RIP and static routing and the justifications of =
use for
> each protocol. One very interesting discussion was surrounding RIP and =
its
> use versus a protocol like OSPF. It seems that many Network Engineers
> consider RIP an old antiquated protocol that should be thrown in back =
of a
> closet "never to be seen or heard from again". Some even preferred =
using a
> more complex protocol like OSPF instead of RIP. I am of the opinion =
that
> every protocol has its place, which seems to be contrary to some =
engineers
> way of thinking. This leads to my question. What are your views of =
when and
> where the RIP protocol is useful? Please excuse me if this is the =
incorrect
> forum for such questions.
>=20
I'd argue that in order to do anything useful (read: moderately sized) =
with RIP (aside from supporting legacy devices lacking anything else and =
as Patrick mentioned handling asymmetric links), you actually need to =
_add_ complexity in order to make it work =96=96 if you can at all. The =
lack of path vectoring limits network diameter due to counting to =
infinity, redundancy requires the use of hold down timers (which are =
proportionate to the diameter of the network), etc.
Antilock brakes are "complex" from an mechanical perspective. But the =
act of braking is the same. Turn on the protocol. Add the necessary =
interfaces. Subnet accordingly. Summarize where possible. Walk away.
"Let the machines do the work." -Vijay Gill (most recently as I recall)
C
> --=20
> Jesse Loggins
> CCIE#14661 (R&S, Service Provider)
