Subject: RE: [pim] RE: DR election

From: "Smith, Don" <[email-masked]>
Date: Thu, 3 Mar 2005 19:37:44 -0600

PIM Folks,
Sorry for the previous email with the "Subject"  missing..
Don

Ganesh,
 
I understand your point, but when switching from RPT to SPT, isn't it
the DR (R1 in the example below) that sends the PIM-SSM?  If so, then
the resulting SPT would continue to have an extra hop through R1.  On
the other hand, if R2, which is not the DR, sends the PIM-SSM, then it
would be as you described.
 
There is a statement in the v11 draft, page 10 

To obtain lower latencies or more efficient bandwidth utilization, a
|
router on the receiver's LAN, typically the DR, may optionally initiate
a transfer from the shared tree to a source-specific shortest-path tree
(SPT). 

This is not absolute, but it indicates that the DR typically sends the
source specific join.
 
Another situation to consider is when R2, in the example below, wants to
join a group, with a source specific (S,G) request.  In this case, the
extra hop seems to be permanent, since R1, the DR, sends the source
specific join.
 
As always, your comments are welcome.
 
Thanks,
Don

________________________________

From: Ganesh [mailto:[email-masked]] 
Sent: Thursday, March 03, 2005 3:52 AM
To: Smith, Don; 'Isidor Kouvelas'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [pim] RE: DR election

Don,
 
I think the one extra hop count you meant will happen for only one
packet/time. As soon as the Receiver receives the first packet from the
Source, it will break the RPT and forms SPT(PIM-SM). From next packet
onwards mcast traffic will follow the shortest path. 

Thanks
Ganesh.

"Smith, Don" <[email-masked]> wrote: 

	Isidor,
	
	Thanks for the quick reply. Thinking about it a little more,
consider
	the following.
	
	Suppose R1 and R2 are on the ends of the p2p link, and R1 is the
DR, and
	R2 wants to join a group on the interface on that link. This
would mean
	that R1 would send the join, not R2. If R1 and R2 both have p2p
links
	to R3, and R3 is the way to get to the RP (PIM-SM) or the source
	(PIM-SSM), then the join would go from R1 to R3. It all works,
but when
	multicast traffic comes back there is an extra hop: R3 to R1 to
R2. 
	
	If R2 had been the DR, then would it not send the join to R3? In
this
	case, there would be one less hop, compared to the above. It
seems that
	if a router wanted to join a group, then the most efficient
result would
	be obtained if that router itself sends the join, even in more
general
	cases than the one described. 
	
	I'm not sure if this is the correct interpretation of what
should occur.
	In any case, your thoughts would be welcome.
	
	Thanks,
	Don 
	
	-----Original Message-----
	From: Isidor Kouvelas [mailto:[email-masked]] 
	Sent: Tuesday, March 01, 2005 4:23 PM
	To: Smith, Don
	Cc: [email-masked]; [email-masked];
[email-masked];
	[email-masked]
	Subject: Re: DR election
	
	One of the two routers may join a multicast group on its p2p
link
	interface. The DR on that link is responsible for initiating the
	relavant joins.
	
	Isidor
	
	Smith, Don wrote:
	> PIM Folks,
	> 
	> In draft-ietf-pim-sm-v2-new-11.txt, Protocol Independent
Multicast 
	> -Sparse Mode (PIM-SM):Protocol Specification (Revised), there
is a 
	> comment
	> 
	> We note that some PIM implementations do not send Hello
	> messages on point-to-point interfaces, and so cannot perform
	> DR election on such interfaces. This in non-compliant
	> behavior. DR election MUST be performed on ALL active PIM-SM
	> interfaces.
	> 
	> 
	> Please let me know why DR election is useful even on
point-to-point 
	> links. The reason for Hellos is clear, but not DR election.
Perhaps 
	> I'm missing an important point.
	> 
	> Thanks,
	> Don Smith
	> 
	
	_______________________________________________
	pim mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/pim

 
Thanks and Regards,
 
Ganeshbabu V
________________________________________________________________________
__________________________ 
"Tomorrow's life is too late. Live today." 

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