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

----- Original Message -----

From: Ganesh

To: don_smith <at> labs.sbc.com ; 'Isidor Kouvelas'

Cc: fenner <at> research.att.com ; holbrook <at> cisco.com ; M.Handley <at> cs.ucl.ac.uk ; pim <at> ietf.org

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

The BSR draft authors have recently submitted draft-ietf-pim-sm-bsr-05.txt.  This email is to give a brief update on the status of the draft.  We will go over this in more detail in the presentation to the WG in Minneapolis.

We have made good progress in this revision, reducing our issues list from 25 pages (70 items) down to 11 pages (30 items).  In particular, in this revision we have concentrated on addressing the many issues relating to administrative scoping, particularly with respect to IPv6.

However, there is still a lot of work to be done before we will have resolved all the known issues, including the following.

o  Finalizing the RP Set maintenance model (the so-called "IW/EW" issue that was discussed in Washington DC and on the mailing list around that time).

o  Resolving several issues with the Bootstrap FSM.

o  Issues to do with semantic fragmentation.

o  Further editorial work (in particular, to continue to improve the explanation of the protocol with respect to administrative scoping).

Feedback is very welcome on the latest version of the draft, particularly on the administrative scoping changes that we have made in this revision.  However, please bear in mind if you do a full review of the document that there is much work left to be done; for this reason, it may be more productive to wait until the next revision of the draft before doing a detailed review.

There are a few specific points on which we require input from the WG.  We will be sending an email to the mailing list about these in the next few weeks.

James, Nidhi, Alex and Stig.

--
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/