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

From: "Anttoni Nurkka " <[email-masked]>
Date: Wed, 18 Sep 2002 16:46:55 +1200

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

---

From: "Nicholas, Jonathan" <[email-masked]>
Date: Mon, 23 Sep 2002 12:43:14 -0500

The scenario described below should not occur because State Refresh messages
will maintain the pruned state until messages from S stop or a downstream
router sends a Prune Override (Join).

However, it is reasonable that an Assert Loser should use a Prune Hold Time
of 180 seconds in case the network is not State Refresh Capable.  I think
this is a better solution to this case than the added timer described below.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

> information, please feel free to contact me.

************************************ 
If this email is not intended for you, or you are not responsible for the
delivery of this message to the addressee, please note that this message may
contain ITT Privileged/Proprietary Information.  In such a case, you may not
copy or deliver this message to anyone.  You should destroy this message and
kindly notify the sender by reply email.  Information contained in this
message that does not relate to the business of ITT is neither endorsed by
nor attributable to ITT. 
************************************