Subject: PIM-SM receiving (S,G) Prune question

From: Vera Volfson <[email-masked]>
Date: Thu, 10 Dec 1998 11:34:41 -0500

Hi,

In the section 3.2.2 Receiving Join/Prune messages in
the part about processing prune list 

For each group address G, in the Join/Prune message, the associated
prune list is processed as follows. We refer to each address in the
prune list as Sp; Sp refers to the RP if the RPT-bit and WC-bit are
both set. For each Sp in the prune list of the Join/Prune message:

[(S,G) prune]
1. For each address, Sp, in the prune list whose RPT-bit and WC-bit are cleared:

   1.If there is an existing (Sp,G) route entry, the router lowers the entry's
     Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream 
     routers on a multi-access LAN to override the prune.
     However, on point-to-point links, the oif-timer is expired immediately.

...

[(S,G)RPT prune]
2. For each address, Sp, in the prune list whose RPT-bit is set and whose
 WC-bit cleared:

   2.If there is an existing (Sp,G) route entry, the router lowers the entry's
     Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream 
     routers on a multi-access LAN to override the prune.
     However, on point-to-point links, the oif-timer is expired immediately.

...

and the paragraph 4 states for both cases:

    4.If there exists a (Sp,G) entry, with or without the RPT-bit set, 
      the oif-timer for I is expired, and the Entry-timer is restarted.

My interpretation is that when the router receives the first prune
oif-timer is lowered to oif-deletion-delay.
When the next prune is received the oif is deleted and e-timer restarted.

Is that correct interpretation?

Is it OK to let oif timeout without deleting it right away?

Thanks,
Vera
-

---

From: Shahzad Ali <[email-masked]>
Date: Thu, 10 Dec 1998 12:30:36 -0500 (EST)

Hi,

> Is that correct interpretation?

I dont think so.  3.2.2 prune-list #2 (d) is not needed IMHO.  This is
covered separately by 3.2.2 prune-list #1 (a) and 3.2.2 prune-list #2 (a) 
as you pointed out. I think rusty also points this out in an errata to the
spec that he maintains.  I hope that it will be incorporated in the new
spec if it really is the case (question for the authors maybe??). This and
other errata are at: 

http://www.isi.edu/~eddy/pim/pim-specv2-notes.html

Cheers,

-Shahzad Ali
ECE Grad University of Delaware.
Software Enginner, Torrent Networking Tech.

---

From: [email-masked]
Date: Thu, 10 Dec 1998 11:17:23 -0800 (PST)

> Software Enginner, Torrent Networking Tech.

Shahzad,

Thanks for pointing this out!  the last time i brought this doc up on
the list,  there was some confusion as to wich draft was submitted for
rfc.  i figured i'd wait until after this ietf rush and bring it up
again, in about january.  i hope to go through the spec and mail list
one more time to update it before contacting the list.

thanks,

- rusty

---

From: [email-masked]
Date: Thu, 10 Dec 1998 12:06:29 -0800 (PST)

> oif-timer is lowered to oif-deletion-delay.

yes.

> When the next prune is received the oif is deleted and e-timer restarted.
the oif is deleted when the oif timer expires.  all prunes recieved
after the first have no effect, since a prune will only reduce the
oif-timer to [oif-deletion-delay], all subsequent prunes will
encounter an oif-timer of [oif-del-delay] or less.

re-setting the oif-timer to the del-delay stops a single nbr from
pruning a lan when there are others present.

> Vera

i think the official anwer is no, when an interface timesout it should 
be removed.  however, i think the only harm is wasted bw/processing,
etc. that goes along with unwanted packets.  (after all a the
del-delay implicitly requires unwanted packets, the rest could be
considered timer slop :)

- rusty