Subject: RE: Sparse mode

From: "Shekhar, Ravi" <[email-masked]>
Date: Fri, 4 Feb 2000 19:00:53 -0500

Hi Des,
  Assuming [after reading the complete mail], that you meant 
  new member to be only connected to C and similarly the sender 
  to be connected only to B (tabs make them look as if they 
  are attached to two routers)...  

  New member at C will cause C to send <*, G> join to RP. 
  This will result in RP adding oif to both its <*, G> and <S, G>.  
  In this case it so happens that the oif for <S, G> is same as its 
  iif. But RP should still generate SG-SPT joins for it. This scenario 
  of having iif same as oif (and no other oif) is not covered in the 
  spec and has been raised earlier (see attachment).   
  
  Hope that helps.
  - Ravi Shekhar. 

> Hi
> 
> I have a question about the SM behavior.
> 
> Conside the following topology.
> 
>                           Sender
>                               |
> Receiver --- A -------- B -------- C -------- RP
>                   |                                    |
>                    ------------------------------------
> 
> At first A sends (*,g) join to RP and RP sends decapsulated 
> packets to A.
> RP first decides to join SPT and sends join upstream.
> So C has only an (s,g) entry.
> 
> After sometime,  A decides to join SPT and does.
> Since A joins SPT, A then sends (s,g) rpt prune to RP.
> so, RP prunes the interface towards A from its (s,g) entry.
> so, its (s,g) has no outgoing interfaces and it now sends (s,g) prune
> upstream.
> 
> C has now an (s, g) entry with one interface in pruned list 
> and no interface
> in outgoing interface list.
> As no data packets come from B to C because of (s, g) prune,
> C's (s,g) entry timer will not refreshed by anything and 
> eventually goes
> off.
> 
> I was wondering is it a correct behaviour for C?
> If so, how come a new member joins from another interface to 
> C gets the data
> packets?
> ie.
>                           Sender    new member
>                               |           |
> Receiver --- A -------- B -------- C -------- RP
>                   |                                    |
>                    ------------------------------------ 
> 
> I would appreciate your help in understanding the protocol behaviour.
> 
> Thanks
> Des
> 

Subject: RE: PIM Working Group last call for draft-ietf-pim-v2-sm-01.txt
From: "Shekhar, Ravi" <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 1 Dec 1999 11:36:01 -0500

Liming,
  I am still curious to know how the following 
  scenario is covered by the draft.
  Regards.
  - Ravi Shekhar.

> > I was considering the following scenario:
> > 
> >               <*,G>->
> >    r---R1----R2------|I
> >                      |----RP
> >    s---R3---R4-------|
> >                <-<S,G> ???
> >               
> > 
> > r is the recvr, s is the sender.
> > RP decides to switch to shortest path.
> > Will R4 be able to detect and switch to SPT without
> > RP sending a <S, G> join to it?
> 
> No. The RP has to decide if it needs to switch to the SPT.

In that case, RP here has an <S, G> entry with iif as I and
oif list as "null" (only oif I is also iif so its not included
in the list). 
It will _not_ generate <S, G>join as per section
  3.2.1 Sending Join/Prune Messages
   Periodic Join/Prune Messages:
   point 2.3 
    "3 The oif list in the (S,G) entry is not null."
which requires it to be "not null".

Is it covered somewhere else/in some other form in the draft?
Thanks.

- Ravi Shekhar.

> 
> Folks,
> 
> This is a PIM Working Group last call for the PIM sparse mode draft,
> submitted as <draft-ietf-pim-v2-sm-01.txt>. This last call expires
> by Jan 1 2000. Please post comments on this mailing list.
> 
>  Thanks,
> -Liming Wei & Tom Pusateri
>