Subject: Question on PIM-SM

From: Chirayu Shah <[email-masked]>
Date: Wed, 01 Mar 2000 16:03:45 -0500

Hi,
	I had a question on periodic join/prunes sent to the RP in
the following configuration:

			h1
			|
		--------r1------
		|		|
		r2		r3
		|		|
		|		|
		|		r4
		|		|
		|		|
		|		r5 (RP)
		|		|
		-------------------
			|
			r6
			|
			h2

r5 is the RP for 235.1.1.1. 
h1 is the source, h2 is the receiver.
The shortest path from r6 to h1 is through r2. The following sequence 
of events occur:
a. h2 joins a group (235.1.1.1)
b. h1 sends to 235.1.1.1
c. After sometime, r6 realizes that the data rate has exceeded 
and switches to SPT (h2->r6->r2->r1->h1).

So finally, r6 has a (*,g) entry and a (s,g)SPT entry.

My question is: what does r6 put in the j/p message that it sends
to r5? My guess is:

	join list: (*,235.1.1.1)
	prune list: (h1,235.1.1.1) with RPT bit set and WC bit cleared
		    (an (S,G)RPT prune).

But I couldn't find the section which describes this scenario.
It would help if someone could point out which rule applies here.

Thanks.
Chirayu.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Wed, 1 Mar 2000 16:45:04 -0500

Hi Chirayu,
  In this scenario, there is no way for r6 to know if it has switched to 
  SPT, i.e. it cannot distinguish if its recving data from r2 or r5 (unless
you do MAC
  source address check). So r6 will not send an <S, G>RPT prune to r5.
  Instead, r2 and r5 will assert, as both will have interface connecting to
  r6 in their oifs, when data gets forwarded on that interface. And then r5 
  will lose assert (due to RPT bit set in pref), leaving r2 to forward the
data.

  - Ravi Shekhar.

---

From: Billy Ng <[email-masked]>
Date: Thu, 2 Mar 2000 09:41:40 -0500

The solution that we have on this is that after we create (S,G)
and sending the SPT join to the source as a result of threshold,
the next data packet will cause the assert to happen.  In this
case, we will check to see whether the upstream neighbors between the 
(S,G) and (*,G) is the same. If different, then we set the SPT bit
and generate a (S,G) prune toward the shared tree.

--Billy

-----Original Message-----
From: Mohit Talwar [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 8:00 PM
To: Isidor Kouvelas; Mohit Talwar
Cc: Chirayu Shah; [email-masked]
Subject: RE: Question on PIM-SM 

on the more general problem discussed in...
http://www.aciri.org/fenner/mcast/pim/sm/issues.html

PIM-SM issue #32: (*,G) joins undoing (S,G) Asserts

"After an (S,G) assert has happened, the DR or (*,G) assert winner has
(S,G)RPTbit state with a null oiflist.  A (*,G) join from a downstream
router can add the interface back on the (S,G)RPTbit oiflist, undo the
upstream pruning, and cause even more frequent periodic flooding than
just the basic assert mechanism does.

Downstream routers that have more general state need to create (S,G)RPT
state when receiving Asserts with the RPF neighbor set to the assert
winner. They can then include (S,G)RPT-bit prunes with their (*,G) joins
so that their periodic (*,G) joins don't undo the Asserts (in the case
of multiple upstreams). This will reduce the flooding period to the assert
expiration time."

---

the solution proposes setting up an (S,G) RPT entry in downstream routers
which would otherwise end up sending (*,G) joins and undoing the assert.  
i believe that we can get the same behaviour by creating an (S,G)SPT entry!
this entry would result in sending a (S,G) prune towards the RP and an
(S,G) join towards the assert winner.

This does not require monitoring the LAN for (S,G) prunes and seems 
(to me :) to fit better within the existing set of rules (which state that 
when the OutgoingInterfaceList of an (S,G)RPT entry is the same as that 
of the (*,G), the (S,G) RPT entry should be deleted.

thoughts, please?
mohit.

>-----Original Message-----
>From: Isidor Kouvelas [mailto:[email-masked]]
>Sent: Wednesday, March 01, 2000 2:33 PM
>To: Mohit Talwar
>Cc: Chirayu Shah; [email-masked]
>Subject: Re: Question on PIM-SM 
>
>
>
>This is addressed in issue 11 on the web page at:
http://www.aciri.org/fenner/mcast/pim/sm/issues.html
>thanks
>Isidor
>Mohit Talwar writes:
>>in this scenario, an assert election will take place 
>>on the LAN between r2 and r5.  r2 will win since it 
>>has an (S,G) entry while r5 has (*,G).  r5 will create
>>an (S,G)RPT bit entry.
>>(section 3.5.2, "Receiving Assert on OIF", 1)
>>
>>note that r6 will not set the SPT bit for its (s,g)
>>entry!!!  so its JoinPrune message to r5 has only
>>
>>> join list: (*,235.1.1.1)
>>
>>hope i haven't overlooked anything.
>>mohit.
>>
>>
>>>

---

From: Billy Ng <[email-masked]>
Date: Thu, 2 Mar 2000 13:50:10 -0500

Mohit,

> Sent: Thursday, March 02, 2000 12:12 PM
> To: Billy Ng; [email-masked]; [email-masked]
> Cc: [email-masked]
> hi billy, isidor,
> i am thinking of
>     S        RP
>     .        .
>     .        .
>     .        .
>     R1       R2
> ------------------
>     R3       R4
> Router      State   RPF-Neighbor
> R3          (S,G)   R1
> R4          (*,G)   R2
> R1          (S,G)   towards S
> R2          (*,G)   towards RP
> 
> an assert election would result in R2 creating an (S,G) RPT bit entry
> and sending (S,G) prunes upstream (if the OIL of S,G)RPT is 
> NULL).  but
> as per the existing set of rules the JoinPrune message from R4 to R2 
> would "...add the interface back on the (S,G)RPT OIL, undo 
> the upstream 
> pruning..."

which rule is this?  If R4 sends a (S,G)RPT prune to R2, R2 should remove
the OIF toward where the prune came in on.

more below:

> 
> the solution u propose in
> 
> proposes (if i understand correctly) setting up an (S,G)RPT 
> entry in R4, 

if R4 is the last hop and it switches, it should not have a (S,G)RPT
because there is a (S,G) and will have SPT bit set when data comes in.

--Billy

> monitoring (S,G)Join/Prune to R1 to refresh/timeout this entry.
> 
> and my question is, why can't we create an (S,G)SPT entry in 
> R4 instead.
> this would result in sending a (S,G) prune to R2 and (S,G) join to R1.
> this (S,G)SPT entry has the same incoming interface as the (*,G) entry
> but a different upstream neighbor, just as in the solution u 
> propose to 
> issue 11.  the entry is Refreshed/TimedOut depending on the 
> data rate, 
> as is the case with all (S,G)SPT entries.  
> 
> i am sorry isidor, but i don't understand your objection to this, 
> could u please elaborate?
> 
> thanx,
> mohit.
>  
>