Subject: Re: PIM-SM: Parallel downstream routers.

From: [email-masked] (Billy Ng)
Date: Thu, 11 Mar 1999 00:31:03 -0500

> From [email-masked] Wed Mar 10 22:59:18 1999
> 

What a timing!  I am also entrenched in this part :)

Here is what I think how it works:

> I have some questions on triggered Join/Prune messages in case of 
> a parallel downstream router pruning your active entry (section 
> 3.2.1.2 item 5).
> 
> Consider the following scenario:
> 
>                RT-UP 
>                  |   
>    -------------------------------
>      |           |            |
>     RT1         RT2          RT3 
>    (*,G)       (*,G)        (*,G)
>    (S1,G)RPT   (S1,G)RPT
>    (S2,G)RPT   (S3,G)RPT
> 
> Assume (*,G)s have oif<>NULL and (S,G)RPTs have oif==NULL.
> 
> Consider the following events:
> 
>    - RT1 sends Join for (*,G) and Prunes for (S1,G)RPT and (S2,G)RPT.
> 
>    - what should RT2 do in this case?
>      According to spec, RT2 will only trigger a Join for (*,G).
>      However, since RT2 and the message from RT1 agrees on the
>      prune of (S1,G)RPT, shouldn't it also send Prune for (S1,G)RPT 
>      along with the Join for (*,G)?

No.  Well, depends, if you implement join/prune suppression, one of them
needs to be suppressed according to the spec.

> 
>    - how should RT-UP collect downstream reactions to a received prune? 
>      According to the spec, it should lower its Oif-Timer to Oif-Delay-
>      Period and wait for a downstream join to increase the Oif-Timer
>      back to Join-Prune-Holdtime.

That depends :)  In the above scenario, when the (S,G)RPT originally gets
created in RT-UP, the interface where the prune was received, is deleted.
This is in the spec.

> 
>      However, should in it wait for a complete Oif-Delay-Period period
>      to collect all the reactions and behave accordingly. The following 
>      set of events explains the reason:
>           - RT1 sends a message

This creates (S1,G)RPT and (S2,G)RPT in RT-UP each with oif = NULL.

>           - RT2 and RT3 triggers 

This makes RT-UP to delete both (S1,G)RPT and (S2,G)RPT that were just
created.

>           - RT-UP receives RT3's message before RT2's message.
>             Since RT2's message is the last one, RT-UP will
>             prune the oif for (S1,G)RPT.

Remember, only Joins are triggered, not prunes.  So in this case, RT2 and/or
RT3 (depending on suppression) will only trigger (*,G).  Yes, this is 
inefficient, i.e. on RT-UP, (S1,G)RPT, (S2,G)RPT, and (S3,G)RPT are 
constantly being deleted and created every join/prune interval.

OK, come to the hard part :-)...

Now let say S3 is sending at a high rate (from downstream of RT2) which
causes RT-UP to switch to SPT.  If we don't have RT1 and RT3, it would
be simple, it should not even switch since there are no oifs.  However,
since RT1 and RT3 also want the data, RT-UP needs to send a SPT join toward
the shared LAN.  The tricky part is that when RT-UP switches, it creates
a (S,G).  However, the incoming interface of this (S,G) is the same as its
outgoing interface so this outgoing interface is NOT added on this entry.

In this case, the rule should be:

1. If the (S,G) created has no oifs and it has a (*,G) whose oif = iif of (S,G)
   and it has not been pruned by other neighbor which is not the upstream
   neighbor to the source, send a (S,G) join.

2. If a prune from a neighbor other than the upstream neighbor of the source,
   send a (S,G) prune toward the upstream neighbor of the source.  This would
   be the case if a last hop router switches to SPT (for example, RT3), RT3
   will need to prune the RT-UP and send a (S,G) join toward S3.  The other
   case would be a prune of a (*,G) which triggers a (S,G) from RT-UP toward
   the source S3.

--Billy

> thanks,
> Ardas

---

From: Liming Wei <[email-masked]>
Date: Wed, 10 Mar 1999 22:57:15 -0800 (PST)

> From: [email-masked] (Billy Ng)
> 

Make it "only joins are triggered to override prunes, Prunes are
not triggered to override other joins or prunes."

-Liming

---

From: Ardas Cilingiroglu <[email-masked]>
Date: Fri, 12 Mar 1999 11:32:10 -0500 (EST)

> not triggered to override other joins or prunes."

In the following scenario, when RT1 sends (*,*,RP) join and (*,G) prune,
shouldn't RT2 trigger (*,G) join and (S,G)RPT prune?

               RT-UP
                 |
   -------------------------------
     |                        |
    RT1                      RT2
   (*,*,RP), oif<>NULL      (*,G), oif<>NULL
   (*,G), oif==NULL         (S,G)RPT, oif==NULL

---

From: Liming Wei <[email-masked]>
Date: Fri, 12 Mar 1999 11:02:30 -0800 (PST)

> From: Ardas Cilingiroglu <[email-masked]>
> 

I guess so. Are you saying that there is a problem here too ?
Hmmm, I'll check and see if the spec has any inconsistencies on this.

In short, a router should not allow a prune on its incoming interface
to not be overriden if it is still in forwarding state. This might
cause more control traffic, but it does guarantee the correctness.

-Liming