[quagga-dev 10841] Re: Quagga RIP supports RFC#2091

James Carlson carlsonj at workingcode.com
Thu Oct 24 15:30:38 BST 2013


On 10/24/13 09:52, Juliusz Chroboczek wrote:
> 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.

I agree up to this point.  But if he's able to supply only the "lingua
franca" of RIP-2, and nothing snazzier, then why would we expect that
he'd be able to do something exotic, optional, and obscure like
triggered RIP?

I don't doubt that there are providers out there who'll give you table
updates via RIP and nothing else.  It's a handy mechanism, because you
don't really have to trust your peer at all.  In fact, you can
completely ignore your peer (dropping all inbound port 520 packets) and
transmit into the blind.  That makes it pretty darned bullet-proof for
providers concerned about security.  You can't do that with OSPF or BGP.

I'm not personally opposed to RFC 2091 triggered RIP, I'm just skeptical
of its utility.  If there's a provider out there who'll actually
configure such a thing for you, I've yet to locate it.  That makes it
pretty low bang-for-buck to me.

>> 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.

That's not triggered RIP.

It sounds to me like you're talking about triggered updates in RIP --
that is, RIP Response packets sent due to a change in interface status
or computed routes.  That's completely unrelated to RFC 2091 "Triggered
Extensions to RIP to Support Demand Circuits."

"Triggered RIP" as described in RFC 2091 is an odd beast.  It involves
explicit delta updates *and* acknowledgement messages, so that the
30-second updates are essentially eliminated.  It behaves more like
OSPF's LSUpdate/LSAck.  The only real reason I can see to do this is
that you have thousands of distinct (non-summarizable) routes to keep
fresh in your peer, and thus your end up sending relatively large
numbers of Response messages just to stay inside the 180 second "stale"
timer.  Even then, I'd wonder a bit about the network designer's intent.

In contrast, absolutely all implementations of RIP ought to support
updates based on state change in addition to the normal 30-second timer
mechanism.  There's no need to appeal to any use case; it's just good
design.  Anything that doesn't support "triggered updates" as described
in RFC 2453 sounds just plain old broken to me.

>> 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.

Triggered updates != Triggered RIP.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>




More information about the Quagga-dev mailing list