Subject: RE: [pim] PIM DM - RPF' (S, G)

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Thu, 12 Oct 2006 08:41:13 -0400

Again, I think the scenario is not realistic.  However, if you read the
details of the state transition, you will find that the OT(S,G) will
only be canceled if the Join(S,G) is received on RPF_Interface(S).  
 
Having said that, if you feel your implementation will be more robust if
RPF'(S,G) also returns RPF_Interface(S), then do so.
 
Jonathan Nicholas

________________________________

	From: Kannan K S [mailto:[email-masked]] 
	Sent: Wednesday, October 11, 2006 10:27 PM
	To: Nicholas, Jonathan - ACD ; [email-masked]
	Subject: RE: [pim] PIM DM - RPF' (S, G)

	Consider another scenario where the router's upstream state is
Forwarding (or AckPending) and OT is running. 

	Now router receiving a (S, G) Join (with upstream neighbor
address == RPF' (S, G)) from one of the downstream interface. So this
router will cancel OT. 

	The point is, RPF' (S, G) should return both the RPF Interface
and next_hop. 

	Kannan

________________________________

	From: Nicholas, Jonathan - ACD
[mailto:[email-masked]] 
	Sent: 2006-10-11 8:49 PM
	To: Kannan K S; [email-masked]
	Subject: RE: [pim] PIM DM - RPF' (S, G)

	Hm, your scenario would seem to assert that 

	A) Two different neighbors (on different interfaces) are using
the same link local address (possible)

	B) Those neighbors are both using link local addresses in their
unicast routing protocol (totally irresponsible)

	C) A Graft is sent to the upstream neighbor and the *other*
neighbor sends *unicast* a GraftAck for the *same* Source and Group to
the Grafting router (a mind boggling coincidence even with some
misbehavior on the part of the Grafting router)

	I don't believe this is possible without misbehavior on the part
of both the neighboring routers and the Grafting router, and even then
it is highly unlikely.

	Jonathan Nicholas

________________________________

		From: Kannan K S [mailto:[email-masked]] 
		Sent: Wednesday, October 11, 2006 5:29 AM
		To: [email-masked]
		Subject: [pim] PIM DM - RPF' (S, G)

		Hi all, 

		   As per RFC 3973; 

		       neighbor RPF'(S,G) {

		if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {

		   return AssertWinner(S, G, RPF_interface(S) )

		} else {

		  return MRIB.next_hop( S )

		}

		   }

		In case of IPv6, next_hop (S) maybe a link-local address
then RPF' (S, G) should return both RPF Interface and next_hop, not only
next_hop since the same link local address can be configured on many
interfaces. 

		Consider a scenario where Intf1 is in AckPending state
and when it receives a GraftAck from another interface say Intf2 with
same RPF' neighbor address will cause the upstream state in Intf1 to
move to Forwarding state. 

		Kannan.

	************************************
	This e-mail and any files transmitted with it are proprietary
and intended solely
	for the use of the individual or entity to whom they are
addressed. If you have
	received this e-mail in error please notify the sender. Please
note that any views
	or opinions presented in this e-mail are solely those of the
author and do not
	necessarily represent those of ITT, Inc. The recipient should
check
	this e-mail and any attachments for the presence of viruses. ITT
accepts
	no liability for any damage caused by any virus transmitted by
this e-mail.
	************************************

************************************
This e-mail and any files transmitted with it are proprietary and intended solely
for the use of the individual or entity to whom they are addressed. If you have
received this e-mail in error please notify the sender. Please note that any views
or opinions presented in this e-mail are solely those of the author and do not
necessarily represent those of ITT, Inc. The recipient should check
this e-mail and any attachments for the presence of viruses. ITT accepts
no liability for any damage caused by any virus transmitted by this e-mail.
************************************

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Nidhi Bhaskar <[email-masked]>
Date: Thu, 12 Oct 2006 09:02:53 -0700 (PDT)

I haven't read through the PIM-DM draft & can't comment on this
particular case.

However, when implementing other flavors of PIM for IPv6, we did need
to update RPF neighbor comparisons to also take the interface into
account. In IPv6 RPF neighbor addresses are most likely linklocal
addresses and need the interface context to uniquely identify the
actual node sending/receiving a PIM message.

Nidhi.