Subject: [pim] PIM-SM DR election result used in other state macros

From: "Anttoni Nurkka " <[email-masked]>
Date: Tue, 08 Oct 2002 13:49:32 +1300

Hi there,

I am currectly working on the implementation of PIM-SM (and DM) on Allied 
Telesyn Research (based in NZ) routers and switches.

I have a query regarding the use of the DR election state in various state 
calculations.  These being pim_include(*,G), pim_include(S,G) and 
pim_exclude(S,G) macros, and the AssertTrackingDesired(S,G,I) and 
CouldAssert(S,G) defined in the "Protocol Independent Multicast - Sparse 
Mode (PIM-SM): Protocol Specification (revised)" in version "dratf-ietf-
pim-sm-v2-new-05.ps".

1) pim_include(), pim_exclude()

I am wondering why the I_am_DR(I) state is used in the macros for these 
downstream calculations.  

As far as I can tell, this will result in an interface not being in the 
pim_include() set, simply because another router has been elected DR, in 
the case that no assert messages have been exchanged yet. That is, 
lost_assert() will be FALSE, and AssertWinner() will be the default value 
of NULL, so the comparison to "me" fails.  

So for the an interface with local hosts only, the previous DR winner can 
now no longer win an Assert as the interface is not considered to be in 
the pim_include'd() state, so no longer is considered to be in any olist 
set.  This other router (the new DR winner) may not have the best route to 
any sender, but will be responsible for all forwarding.

2) CouldAssert()
Similarly for CouldAssert(S,G,I), which is dependent on pim_include() 
states, may return FALSE after a DR election, when only local hosts are 
responsible for the forwarding state.

3) AssertTrackingDesired()
And again, similarly for AssertTrackingDesired(S,G,I), on an interface 
with only local hosts, that is now not the DR, but has no assert state, 
can return FALSE, and cause transitions to the NO_INFO state of the assert 
state machine, even though the interface, in my opinion, should still 
track asserts.

4) Summary
IMHO, the DR election should only affect the DirectConnect(S) interface in 
the decision of whether to send a register to the RP.  The use of the DR 
election result on potential downstream interfaces appears to cause 
incorrect local membership tracking, assert states, and therefore can 
cause undesirable forwarding behaviour.

Many thanks in anticipation of your assistance in this matter.

Regards,

Anttoni Nurkka

-------------------------------------------------------------
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: Pavlin Radoslavov <[email-masked]>
Date: Thu, 10 Oct 2002 22:12:53 -0700

> any sender, but will be responsible for all forwarding.

In general, the DR is not responsible for forwarding data to the
local hosts on that LAN; rather, it is responsible for originating
the (*,G) Join messages (among other things). So, in your example
the new DR may actually send the (*,G) Join message to the old DR,
therefore the old DR will become the forwarder for that LAN because
of that Join. Hence, I don't see a problem here.

I don't understand the exact issues you describe in (2) and (3)
below, but if they are based on (1), then I guess the above answer
invalidates those issues as well.

Regards,
Pavlin