Subject: DVMRP pruning

From: Petri Helenius <[email-masked]>
Date: Sun, 12 May 1996 10:40:44 +0300 (EET DST)

-----BEGIN PGP SIGNED MESSAGE-----

  How often does mrouted try to prune towards the source again in case
it keeps receiving data from it's neighbor? (that is the prune message
is lost).

Pete

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Sun, 12 May 1996 19:24:26 -0700

On Sunday, May 12th 1996 at 10:40 +0300,
in message <[email-masked]>

>> it keeps receiving data from it's neighbor? (that is the prune message

I believe it is always possible that a router will continue to see multicast
traffic on an upstream interface for a group it was pruned, for example on
a shared LAN where there are other routers that have not sent a prune or
if there are local members.  since a router has no idea if its prune was
lost or whether it's the situation above, it should do nothing until
its current prune state expires, at which time it can refresh the prune
state if there's still traffic.  at a leaf node, I think the prune timer
will be set to the defualt cache lifetime, which is something like 300s
in mrouted.  at an interior node, the prune timeout is dependent on the
minimum timeout interval across all the downstream prunes that were received.

danny

---

From: Petri Helenius <[email-masked]>
Date: Mon, 13 May 1996 05:52:51 +0300 (EET DST)

> minimum timeout interval across all the downstream prunes that were received.
But the router does know whether the link is multiaccess or
point-to-point and if the link is point-to-point re-prune data-driven
but on multiaccess do exactly what you said. Of course this applies on
S,G and *,G basis depending on how the router in question wants to
handle the traffic.

Pete

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Sun, 12 May 1996 20:23:53 -0700

On Monday, May 13th 1996 at 05:52 +0300,
in message <[email-masked]>
Petri Helenius writes:

>> but on multiaccess do exactly what you said. 

[I haven't double checked the code/spec on any of this, so hopefully I'm 
not spewing too much misinformation...]

mrouted certainly knows what link type each interface is, but once
the forwarding cache entry is resolved and pushed into the kernel and
the prune is sent, then the kernel just tosses the packets and mrouted
receives no notification.

dvmrp only looks at the downstream prunes and group memberships before
deciding to propagate a prune.  it's possible there could be a group
member on the local mrouter host that is joined on the upstream interface.
therefore, even on a p2p link it may be correct that there is traffic
on the link even though a prune was sent.

danny

---

From: Petri Helenius <[email-masked]>
Date: Mon, 13 May 1996 08:03:11 +0300 (EET DST)

> receives no notification.

That's the unfortunate drawback on user/kernel space implementations
instead of just integrated routers.
 > deciding to propagate a prune.  it's possible there could be a
group

It looks at the oif-states. And prunes are not 'propagated' it just
initiates prune when the oif-list gets empty. I was fishing for
what is the interval it re-sends a data-driven prune when the oif-list
is null.

 > on the link even though a prune was sent.
In that case the oif-list would not be null and a prune would never be
initiated. If the member appeared later the link would have been
grafted.

Pete

---

From: Bill Fenner <[email-masked]>
Date: Wed, 15 May 1996 10:39:40 PDT

Petri,

  mrouted does not retransmit prunes; if a prune is lost it waits for the 
lifetime of the prune before sending another one.  This is a property of the 
implementation, not of the protocol.  "Rexmit prunes?" is one of the things 
written on my whiteboard.

Danny Mitzel gave a good example:
>In that case the oif-list would not be null

That's not true.  If the mrouter is joined to the group on the upstream 
interface, its list of outgoing interfaces may well be null -- the membership 
is on the upstream interface.

However, that's irrelevant.  It knows about the membership on the P<>P 
interface and can suppress retransmission of prunes on P<>P interfaces on 
which there are members.  Retransmission of prunes on multi-access networks is 
much more complex (and deployment is also problematic due to an error in the 
choice of severity for the duplicate prune warning message).

So, to summarize, it seems as though prune retransmission on P<>P links is 
fairly straightforward to implement if desired.

  Bill