Subject: RE: RP on a stick scenario

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Fri, 22 Jun 2001 20:57:16 -0500

So, RP should somehow mark this scenario when its (S,G) OIF is Null and it receives (*,G) on IIF without (S,G) RPT Prune. This state would tell it to send periodic (S,G) Joins towards source. One more question related to this is - in the topology mentioned below, when R1 sends (S,G) RPT Prune on LAN for the first time, how does R2 override that Prune - with (S,G) RPT Join ? If yes, will R2 keep sending (S,G) RPT Joins periodically ?

--
Sonum

>         ---------------------------------LAN
>         |       |       |
>         R1      RP      R2----Rcvr
>         |
>         R3---Sender
>         |
>         Rcvr

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 3:27 PM
To: Mathur Sonum-CSM109
Cc: [email-masked]'
Subject: Re: RP on a stick scenario

Mathur Sonum-CSM109 wrote:

If R2 doesn't send (S,G) joins (which you would have had to specifically
configure it to do because even though the IIF for the RPT and the SPT
may
be the same, that has nothing to do with which tree that router is
joined to).

-- then it must be sending (*,G) joins, which means that the RP should 
have a non-NULL olist for the (*,G).

An RP that is receiving a (*,G) join without a (S,G,RP) prune (and R2
has
to be sending the (*,G) join part as long as there is a member and if
it "never joins the shortest-path" as you said then it doens't include
the (S,G,RP-bit) prune in the message) should know that it must continue
to send (S,G) joins for the group.  The specifics on you you want to
make this 
happen are up to you.

[NOTE: any router that receives a JOIN/PRUNE message with only a (*,G)
part
and no (S,G,rp-bit)prune part has received some very important
information
that it should act on.]

Let me say again that if you are looking at RFC2362, you're wasting your
time.

> 
> When RP has an (S,G) entry with Null OIF and IIF is on a shared link,  which has some other recievers, there is a possibility of data hole. This was one of the issues in RFC 2362 as specified in PIM-SM issue #27: Turnaround rules incompletely specified
> 
>         ---------------------------------LAN
>         |       |       |
>         R1      RP      R2----Rcvr
>         |
>         R3---Sender
>         |
>         Rcvr
> 
> R2 never sends (S,G) Join directly to source (as it never goes to shortest path tree) and RP doesn't send periodic (S,G) Join as its OIF is Null and is not forwarding. This may lead to no data on LAN.
> 
> RP needs to have some state (or special flag in (S,G) entry) which indicates that it has to send periodic (S,G) Joins to source to get data on LAN. If this issue has already been resolved in the new spec, please explain how.
> 
> Thanks
> --
> Sonum
> _______________________________________________
> Pim-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/pim-external

---

From: John Zwiebel <[email-masked]>
Date: Fri, 22 Jun 2001 20:12:31 -0700

Mathur Sonum-CSM109 wrote:
> 
> So, RP should somehow mark this scenario when its (S,G) OIF is Null and it >receives (*,G) on IIF without (S,G) RPT Prune. This state would tell it to send >periodic (S,G) Joins towards source.

You don't have to limit this to just the RP.  Any router that has the
shared-tree intersect with the shortest-path between the source and 
the RP could use this same functionality.  (That way you don't
have to have data flow up to the RP that you aren't interested in)
BTW, this is the X-flag.

> One more question related to this is - in the topology mentioned below, when R1 >sends (S,G) RPT Prune on LAN for the first time, how does R2 override that Prune - >with (S,G) RPT Join ? If yes, will R2 keep sending (S,G) RPT Joins periodically ?

R2 doesn't have to override the prune if you do your implementation
correctly.
And as you suggest, having to override an (s,g,r) prune every time is
kind of
painful.  (I believe the new PIM draft does say something about an
(s,g,r) join but is pretty clear that this is a unique event that is
only triggered -- this event/topology is not unique.)

If I go any farther though I'll tell you how it was done at Cisco and 
it took me an awful long time to get (nameless) to pay attention to me
on
this point.  :-)  (Truthfully, I'm not sure its all right to get that 
specific, but if you had a couple of ciscos, you'd be able to watch it
happen and figure it all out in about an hour.  Now, if someone from
Cisco wants to tell you, that's fine.) There are different trade-offs.

In any case, I'm also pretty sure the new pim spec addresses this.  (But
I have a very bad memory and haven't read it in at least 4 months).