Subject: Re: [pim] draft-ietf-pim-dm-new-v2-01.txt dated February 15 2002

From: "Prashant Jhingran" <[email-masked]>
Date: 23 Sep 2002 15:37:12 -0000

hi Anttoni,
I am unable to get the following points:-
1. Why an assert looser shall send prune to the winner???, it 
shall only     send a prune to its upstream router which has to be 
different
     from the assert winner.
2. more over what is prune holdtime??
3. how can a router receive data pkts on its downstream interface,       
    thinking that this is not the link through which the looser
    is connected to the winner.

  Can you pls clear the above listed doubts regarding the 
scenario.
  thanks and regards,
  Prashant

On Wed, 18 Sep 2002 Anttoni Nurkka   wrote :
>Hi,
>I have a query regarding the (S,G) Assert State Machine event "An 
>(S,G)
>Data packet received on a downstream interface" having no actions 
>when in
>the "Loser" state.
>
>The scenario:
>1) There is an assert negotiation on an link.
>2) The loser sends a prune to the winner with prune hold time = 
>60s.
>3) The assert time defaults to 180s, as it is not transmitted, 
>so
>    uses the default.
>4) The prune hold time on the winner times out.
>5) The winners interface is now able to forward, so gets in the 
>olist.
>6) The loser starts to receive data, but will do nothing for a
>    further 120s.
>
>This results in wasted bandwidth on a link that doesn't need 
>data.
>
>I believe that the state machine for this state/event should 
>be:
>
>
> >--------------------------------+  
>-+---------------------------+
> >                                    |  Previous State           
>|
> >                                    
>+---------------------------+
> >             Event                  |      Loser                
>|
> >--------------------------------+  
>-+---------------------------+
> >Rx (S,G) data on downstream         | -> Loser                  
>|
> >                                    | if (assertPLT not 
>running)|
> >                                    |   Send Assert (S,G)       
>|
> >--------------------------------+  
>-+---------------------------+
> >
> >where assertPLT is a new per (S,G) interface timer used in a 
>similar
> >fashion as the PLT(S,G), but tracks whether this router's 
>assert driven
> >prune would have timed out on the assert winner.
>
>
>with some additional text like:
>
> >Transitions from Loser State
> >
> >When in "I am Assert Loser" state, the following transitions 
>can occur:
> >
> >Receive (S,G) Data on a downstream interface
> >  The assert winners prune hold time has expired, so it has 
>started
> >  forwarding data again.  Since this router still doesn't 
>expect
> >  data from the assert winner, and the assertPLT is not running 
>(i.e.,
> >  this router's assert driven prune hold time has expired), 
>then
> >  this router SHOULD send an Assert(S,G) on the interface to
> >  initiate an Assert negotiation.  The assert state machine 
>stays in
> >  the Assert Loser state.
>
>Which would solve the problem, as the assert negotiation will 
>cause the
>winner to resend its assert, causing the loser to re-send it's 
>assert
>driven prune.  If no other routers require data, the link is not 
>wasting
>bandwidth on unwanted multicast.  If another router does want 
>data, it
>would send it's override Join, and the assertPLT prevents 
>assert/prune
>thrashing.
>
>I hope my explanation and solution have made sense. If you want 
>any more
>information, please feel free to contact me.
>
>Regards,
>
>Anttoni
>
>
>-------------------------------------------------------------
>Anttoni Nurkka           27 Nazareth Avenue
>Software Engineer        PO Box 8011
>Allied Telesyn Research  Christchurch
>phone +64 3 339 3000     New Zealand
>fax   +64 3 339 3002     email: 
>[email-masked]
>                          web: http://www.alliedtelesyn.co.nz/
>-------------------------------------------------------------
>
>
>_______________________________________________
>pim mailing list
>[email-masked]
>http://catarina.usc.edu/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: "Nescafe" <[email-masked]>
Date: Tue, 24 Sep 2002 11:46:05 +0800

Hi, everyone
 RFC2362 says:
  When a router with a (S,G) entry and a cleared SPT-bit starts to
   receive packets from the new source S on the iif for the (S,G) entry,
   and that iif differs from the (*,G) entry's iif, the router sets the
   SPT-bit, and sends a Join/Prune message towards the RP, indicating
   that the router no longer wants to receive packets from S via the
   shared RP-tree.

I am puzzled with the bold condition when (S, G) decides whether to change
the SPT bit.If SPT is exactly the same as the RPT at the last hop router and
the router just before it, so data arriving at the last hop router at the
same interface as (*, G), so who will initiate the switch to SPT, the SPT
bit won't be set forever?

Thanks a lot

Nescafe

---

From: John Zwiebel <[email-masked]>
Date: Mon, 23 Sep 2002 22:33:19 -0700

First: you might want to not use 2362 since there are some significant
changes between that
 and the new PIM draft.  The holes in 2362 are too big to not move to the
new draft ‹ even though
 its a draft.  

WRT setting the SPT bit, the last-hop does not have to set the SPT bit to
determine whether or
 not to send an (S,G) join on the shortest-path.  It can (and should) do
this immediately (if you¹ve
 configured it to join the SPT ‹ which is generally recommended.)

The T-bit is useful only to determine whether or not to send (S,G,R) prunes
and if the
 RPF for the (*,G) and the (S,G) are the same there is no reason to send
such a prune.
 Therefore, no need to set the T-bit on this router.

You are right, the T-bit will not be set ³forever².  A ³good² thing.

On 9/23/02 8:46 PM, "Nescafe" <[email-masked]> wrote:

> SPT-bit, and sends a Join/Prune message towards the RP, indicating    that the
> router no longer wants to receive packets from S via the    shared RP-tree.
>  
>  
> I am puzzled with the bold condition when (S, G) decides whether to change the
> SPT bit.If SPT is exactly the same as the RPT at the last hop router and the
> router just before it, so data arriving at the last hop router at the same
> interface as (*, G), so who will initiate the switch to SPT, the SPT bit won't
> be set forever?
>  
> Thanks a lot
>  
> Nescafe
> ____________________________________________________
>  <http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9>   IncrediMail -
> Email has finally evolved - Click Here
> <http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9>

---

From: "Nescafe" <[email-masked]>
Date: Tue, 24 Sep 2002 14:01:13 +0800

Thank you very much. I will follow your advice.
But I still doubt that if SPT and WRT are only partly the same 
as each other just near the last hop router, in fact they branch at some
other point. DO we should switch to SPT?I think it's more reasonable, but
who will send (S, G) join first?

-------Original Message-------

From: John Zwiebel
Date: 2002年09月24日 13:33:28
To: Nescafe; [email-masked]
Subject: Re: [pim] a problem about switching to SPT

new draft ― even though
 its a draft.  

WRT setting the SPT bit, the last-hop does not have to set the SPT bit to
determine whether or
 not to send an (S,G) join on the shortest-path.  It can (and should) do
this immediately (if you’ve
 configured it to join the SPT ― which is generally recommended.)

You are right, the T-bit will not be set “forever”.  A “good” thing.

 Hi, everyone
 RFC2362 says:
  When a router with a (S,G) entry and a cleared SPT-bit starts to
   receive packets from the new source S on the iif for the (S,G) entry,   
and that iif differs from the (*,G) entry's iif, the router sets the   
SPT-bit, and sends a Join/Prune message towards the RP, indicating    that
the router no longer wants to receive packets from S via the   shared
RP-tree.

Thanks a lot

Nescafe
____________________________________________________
 <http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9>   IncrediMail - Email has finally evolved - Click Here <http://www.incredimail.com/redir.asp?ad_id=309&amp;lang=9>