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

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Wed, 11 Oct 2006 08:49:20 -0400

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.
************************************

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

---

From: Kannan K S <[email-masked]>
Date: Thu, 12 Oct 2006 10:26:31 +0800

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)

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

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

  _____  

Hi all, 

   As per RFC 3973; 

       neighbor RPF'(S,G) {

} else {

}

   }

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