[quagga-dev 10840] Re: Quagga RIP supports RFC#2091
jch at pps.jussieu.fr
Thu Oct 24 14:52:24 BST 2013
Everything James has said is correct (and wise), but I'd still like to
present the opposite point of view.
> In my opinion, RIP users are better served by good summarization
> behavior and reasonable network design
One does not prevent the other, fortunately.
> The whole point of RIP (at least these days) is that listeners can
> obtain high-quality routing information for free, unlike other
> protocols that require per-peer state data. It scales nicely in
> that way. Triggered RIP breaks that design by forcing
> implementations to have per-peer retransmission tracking.
Right. Good argument for making triggered updates optional.
There's another important application of RIP, however, which is to
serve as a lowest common denominator between incompatible router
implementations. If you ask your friendly upstream to serve you your
local routing table (default route plus the few local prefixes you
actually care about) using OSPF, EIGRP, Babel, whatever, he might not
have the right software, and even if he does, he might need to do some
work. If you ask for the local table over RIP(ng), he's probably
already set up to do that, and he most certainly has the software,
whether he's using Cisco, Juniper, Quagga, or something else.
> And if you really have so many diverse routes that you need to resort to
> sending deltas instead on a very slow link, you're probably better off
> using a more established protocol such as OSPF, IS-IS, or BGP rather
> than something exotic like triggered RIP.
> I think it's hard to imagine what the use-case for RFC 2091
> triggered RIP might be as the year 2013 is ending.
Well, there's one realistic use case where triggered RIP really
helps -- and it happens to be the one that I've described above. If
your upstream is serving you the local table using RIP, for redundancy
and load balancing you might want to set up three edge routers that
speak RIP to him. When the upstream drops, the three routers start
counting to infinity. 8 minutes using plain RIP, less than a minute
using triggered RIP.
> Sorry to rain on your parade -- I get the sense that you're looking
> around for a good project -- but I don't think adding features just for
> feature's sake is the best answer. The best additions are the ones that
> are driven by real *need* not mere *opportunity*.
I've used the above setup until last year with my IPv6 provider.
(They've now dropped IPv6 support, so I'm using a tunnel to a router
I manage myself -- grr, -- and RIPng is no longer used.) I claim it's
a realistic scenario where the combination of split horizon and
triggered updates actually helps.
More information about the Quagga-dev