Subject: PIM-SM non-DR router on sender subnet...

From: [email-masked] (Ravi Shekhar)
Date: Wed, 30 Dec 1998 17:13:40 -0500 (EST)

I am wondering how the following situation is taken care of 
    in PIM-SM (for a given group G).

        Consider the follwing topolgy.
          h is the host on subnet s.
          DR is the DR on the subnet s.
          X is the upstream router for Y (towards RP).

                        RP
                        /\
                       /  \
                      /    \
                     DR     X
                     |      |
                    ---------- s
                     |      |
                     h      |
                            Y

        Lets say Y wants to join the group G and sends a join towards X.
        X in turn sends a join to RP.

        Now, if h starts sending data for group G, DR will encapsulate it and 
        send it to RP. RP will decapsulate it and send it to X. 
        
        X will put it on subnet s (intended for router Y). But the data will 
        be picked up by DR too and will be encapsulated and sent back to RP.
        Which in turn will decapsulate it and send it to X and so on.
        So there is a loop present here.

        If I am missing something here, I would appreciate it if someone can 
        point me to the right place in the document where it is covered.

        If not, then there are at least two possible actions following this:
            a) X could create the <S, G>RPT entry and send a prune to RP for 
               <S, G> (similar to what DR would have done if it had any <*, G> 
               entry). 

            b) X can initiate an assert when it receives packets from h on 
               its outgoing intf for (*, G). Would DR reply to assert in this
               case?? (h is only a sender, not a recvr. So assert is recvd on
               the incoming intf of the DR, not the outgoing intf). 

        Thanks.
          - Ravi Shekhar.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Dec 1998 14:23:10 -0800 (PST)

>>         So there is a loop present here.

    X will not put the packet on subnet s because it created (S,G) state when
    the original packet was sent by h. So the packet coming down the shared
    tree will RPF fail on the (S,G) entry.

Dino

---

From: [email-masked] (Ravi Shekhar)
Date: Wed, 30 Dec 1998 18:03:51 -0500 (EST)

>    tree will RPF fail on the (S,G) entry.
    
    Thanks Dino. A followup question.

    Is the <S, G> you mentioned created because <S, G>RPT entry should be
    created by X (point a. in my original mail) ?

    If so, I couldnt find this in the document. Document requires only DR to
    create such an entry - point 4. under Triggered Join/Prune Messages

>     4 Receipt of a packet at the DR from a directly connected
>       source S, on the subnet containing the address S, triggers a
>       Join/Prune message towards the RP with S in the prune list and
>       the RPT-bit set under the following conditions: a) there is no
>       matching (S,G) state, and b) there exists a (*,G) or (*,*,RP)
>       for which the DR is not the RP.

    Or is it covered in some other way in the document?

    - Ravi Shekhar.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Dec 1998 15:16:35 -0800 (PST)

>>     created by X (point a. in my original mail) ?

    It could only if the (S,G,RP-bit) Prune came to X before the data packet
    did. This could happen if the packet wasn't received by X. But if (S,G)
    state was present in X and then the (S,G,RP-bit) Prune was received, it
    does not overwrite existing (S,G) state.

>>     create such an entry - point 4. under Triggered Join/Prune Messages

    Right. And I think that is correct. X should only prune off the shared
    tree, if it is a leaf router and has (*,G) forwarding state through it.

>>     Or is it covered in some other way in the document?

    I don't think so.

Dino

---

From: Ahmed A-G Helmy <[email-masked]>
Date: Wed, 30 Dec 1998 15:26:48 -0800 (PST)

>         So there is a loop present here.

This case is taken care of by the rule that 'a packet is never forwarded 
to the subnet from which is was originated'... this register loop 
problem was discovered by some of my simulations,  using a new method for 
automatic protocol testing, and I think the fixes were added to the 
latest RFC before the final submission [see section 3.4 'Multicast Data 
Packet Forwarding', 2nd item, 1st subitem 'excluding the subnet 
containing S'].
[pls check my web page for further details on this register looping 
problem and how it is fixed,... chk my resume/publications 'Simulation-based 
STRESS testing case study...' the longer version].

If I understand correctly, this is the problem and the solution you're 
looking for,

Regards,
-A

---

From: [email-masked] (Ravi Shekhar)
Date: Wed, 30 Dec 1998 20:03:45 -0500 (EST)

>If I understand correctly, this is the problem and the solution you're 
    
    Yes, thanks. 

    So this test might result in a NEW <S, G> state creation if it turns out 
    that an oif needs to be removed from the existing <*, G> entry and there
    does not exist an <S, G> entry. (Probably might be worth stating next to 
    that test statement.)

    And then prunes will be sent for S towards RP as per section 3.2.1

    > 3 The Join/Prune message is being sent to the RPF
    >   neighbor toward the RP, and there exists a (*,G) entry and
    >   (S,G) entry for a directly connected source.

    - Ravi Shekhar.