Subject: Re: Typo in draft-ietf-idmr-dvmrp-v3-09.txt,.ps

From: Sundeep Singatwaria <[email-masked]>
Date: Sat, 02 Oct 1999 16:40:42 -0700

I guess my thought process was stuck at the parent router of the router
which went down. Consider following ex.

		R0
		 |
		 |
		R1
	     /   \
	    /     \
	   R2      R3
	  /  \      | \
	 /    \     |  \
	R4    R5   R6   R7

Let's say R3 goes down and is up again. The idea should be to restore R3 to
the state it was before without flodding the network with lot of broadcast
messages. So if R1 sends Graft messages for all the groups for which R3 is
the downstream router then R3 in turn can forward it along its downstream
path to find it anyone along its downstream path is interested in those
groups. This will allow R3 to restore back its tables much quicker.

Comments ?

sundeep

At 01:07 AM 10/2/99 -0700, Thomas Maufer wrote:
>At 19:48 -0700 1-Oct-1999, Sundeep Singatwaria wrote:
>
>>there is a typo in dvmrp draft on Pg. 11 first para
>>
>>If this prune state has caused the prune information to be sent upstream, a
>>graft will need to be sent upstream just as though.....
>>                           ^^^^^^^^
>>                               |
>>should be downstream.
>
>
>
>Sundeep--
>
>Actually, the draft is correct.  The graft process starts with
>a router that is, almost by definition, attached to a leaf of
>the tree that -- here's the key -- previously had no group
>members.  Once a group member announces its presence (via an
>IGMP Report message), the leaf router needs to send the graft
>upstream to erase the prune state.  The graft will travel as
>far as it needs to, stopping when it encounters a router that
>is on an active branch of the distribution tree.  That router
>will add the interface on which the graft was received to its
>forwarding state for that (s,g) pair, and then data will begin
>flowing downstream (of course, only if that source is actually
>sending to that group at that time).  If there are any routers
>between the on-tree router and the leaf that sent the original
>prune, they just need to erase their prune state...once a data
>packet arrives it will stimulate the creation of forwarding
>state for this (s,g) pair.
>
>Cheers,
>Tom
>-- 
>Thomas Maufer                    "Lots of things are simple when   |o|
>                                     you ignore the hard parts."   |o|
>PGP Key Fingerprint (DSS):                                         |o|
> 0E37 CE46 9D05 63C5 BD8C          - Mark Handley, 22-Sept.-1998   |o|
> 1242 5240 843D A36B FEB1            (quote used with permission)  |o|
>

---

From: Thomas Maufer <[email-masked]>
Date: Sat, 2 Oct 1999 18:39:25 -0700

Sundeep--

The following section of the DVMRP spec (I'm quoting from draft-
ietf-idmr-dvmrp-v3-09.txt, here), illustrates what happens in
situations like that which you described.

>3.2.2.  Generation ID
>
>
>   If a DVMRP router is restarted, it will not be aware of any previous
>   prunes that it had sent or received.  In order for the neighbor to
>   detect that the router has restarted, a non-decreasing number is
>   placed in the periodic probe message called the generation ID.  When
>   a change in the generation ID is detected, any prune information
>   received from the router is no longer valid and should be flushed.
>   If this prune state has caused prune information to be sent upstream,
>   a graft will need to be sent upstream just as though a new member has
>   joined below. Once data begins to be delivered downstream, if the
>   downstream router again decides to be pruned from the delivery tree,
>   a new prune can be sent upstream at that time.
>
>   In addition, the effects of a restart can be minimized if the router
>   can learn all of the routes known by its neighbors without having to
>   wait for an entire report interval to pass.  When a router detects a
>   change in the generation ID of a neighbor, it should send a unicast
>   copy of its entire routing table to the neighbor.
>
>   A time of day clock provides a good source for a non-decreasing 32
>   bit integer.

Cheers,
Tom
-- 
Thomas Maufer                 "It's better to have had your wish,  |o|
                                     than to have wished you had." |o|
PGP Key Fingerprint (DSS):                                         |o|
 0E37 CE46 9D05 63C5 BD8C  1242 5240 843D A36B FEB1                |o|
____________________________________________________________________ |