Mohamed Riyaz | 3 Mar 2005 13:52
Favicon

Re: (no subject)

For implementations that follow the RFC 2362 word-by-word (not sure if there are any::)  where one needs to keep the stats for all the packets received and switches to SPT only if packet count is above threshold, Don's argument makes sense.
 
I guess one thing that could be done in such case is if R2 wants to join the group and R1 doen't have any other oifs, then we might use a version of assert to make R2 the DR for the time being. If a receiver comes and gets attached to R1 at any point of time, let R1 take over as DR again. Just a thought.....
 
-Riyaz
 
----- Original Message -----
From: Ganesh
Sent: Thursday, March 03, 2005 5:34 PM
Subject: [pim] (no subject)

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. Definitely we should have DR for p2p links too, so that the multicast link is under one router control.
 
 
Thanks
Ganesh.


"Smith, Don" <don_smith <at> labs.sbc.com> 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:kouvelas <at> cisco.com]
Sent: Tuesday, March 01, 2005 4:23 PM
To: Smith, Don
Cc: fenner <at> research.att.com; M.Handley <at> cs.ucl.ac.uk; holbrook <at> cisco.com;
pim <at> ietf.org
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
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
 
 
 
Thanks and Regards,
 
Ganeshbabu V
__________________________________________________________________________________________________ 

"Tomorrow's life is too late. Live today."

 

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Gmane