Re: Experiment I-D: write DVMRP

Achmad Husni Thamrin <[email protected]> Wed, 30 Jul 2003 15:42:47 +0900
Newsgroups gmane.ietf.udlr
Message-ID <[email protected]>
Okay, here it is.

I think three paragraphs are enough to summarize the DVMRP experiment,
unless many of you think that I should elaborate some details.


4.4.1 DVMRP

DVMRP [RFC1075] exchanges routing information between neighbors and 
creates a separate MRIB based on the exchanged routing information.
With this feature, DVMRP works without any special configuration on 
UDLRs in terms of enabling multicast routing on the link. UDLRs can
carry multicast traffic even though the unicast routing is asymmetric
because the RPF procedure looks at the separate MRIB provided by
DVMRP.

DVMRP, on the other hand, has a well understood drawback: scalability.
On a UDLR, DVMRP does not scale to the number of DVMRP routers on
the network due to two factors:
1. DVMRP routers advertise poisoned routes;
2. DVMRP routers advertise neighbor lists.
These factors give a considerable control overhead and the way to
reduce this overhead is to set larger timers for these advertisements.
Setting larger timers come at the cost of wasting network bandwidth
for unnecessary multicast traffic.

Setting larger timers, however, does not solve the scalability problem.
Consider the case when a DVMRP router on the UDLR just went active. 
The router will send many messages during the first seconds after went
active to advertise the newly learnt neighbors and routing information.
This activity creates a storm on the UDLR with a large number of DVMRP
routers. The situation gets worse if more than a router go active
within a short timespan.

On Wed, 30 Jul 2003 15:37:48 +0900
Hidetaka IZUMIYAMA <[email protected]> wrote:

> Husni,
> 
> Thanks a lot.
> 
> Could you send the text of DVMRP section to this ML ?
> Because most of people cannot access the document until
> revised I-D will submit.
> 
> -- izu --
> 
-- 
Achmad Husni Thamrin <[email protected]>