Subject: RE: [pim] pim-sm router transitions from DR to non-DR

From: Prashant Jhingran <[email-masked]>
Date: Wed, 09 May 2007 11:44:26 +0530

Hi All,
 
Had it been PIM-DM instead of SM, then of course Assert
would have decided the forwarder on the LAN.  But in case of
PIM-SM, the RFC 4601 implicitly specifies how to handle such
a scenario.
 
Section  4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G)
Join/Prune Messages respectively specifies the following:
 
When JoinDesired (*,G) or (S,G)  => False 

Transition [J] state => [NJ] state ; Send respective Prune
message viz. (*,G) or (S,G); Cancel respective Join Timer

Note: JoinDesired(*,G), depends on pim_include(*,G) which in
turn depends on "I_am_DR( I )" bool.

Conclusion:
 
- On loosing DR Election, RT1 should send Prune mesg towards
upstream & should remove the entry as well.
- RT2 (new DR) should form the tree by triggering  Join mesg
upstream towards RP..
- Thus Assert mesg need not decide the forwarder on the LAN.

Regards,
Prashant Jhingran

Huawei Technologies
+91-80-41117676 Ext -5129
Mobile:+91-9448927814
============================================
"Sing, dance, serve, meditate and celebrate"
- Sri Sri Ravi Shankar      www.artofliving.org
<http://www.artofliving.org/>  
============================================

  _____  

From: Rajesh Nataraja [mailto:[email-masked]] 
Sent: Friday, April 27, 2007 12:40 AM
To: Satyanarayana Dillikar
Cc: [email-masked]; Binu TN
Subject: Re: [pim] pim-sm router transitions from DR to
non-DR

Hello,
 
I think the better way to do is to not care about being a DR
or not, and just  handle it based on what would happen if
someone asserts, are there compatability issues here? What
do authors say?
 
Thanks
Rajesh.

On 4/22/07, Satyanarayana Dillikar <[email-masked]>
wrote: 

Hi Binu,

 See inline

  _____  

From: Binu TN [mailto: [email-masked]] 
Sent: Saturday, April 21, 2007 9:38 PM
To: [email-masked]
Subject: [pim] pim-sm router transitions from DR to non-DR

Hi,

  I have a basic doubt in the pim-sm router transition from
DR to non-DR. Let's assume a scenario where a sm router
(e.g., RT1) is DR in a LAN and it has multicast route entry
and it is trigerring Join messages to RP (it is in some
other network) as it has some interesting hosts. If another
sm router ( e.g.RT2) with higher IP address comes into the
LAN of RT1, as per my understanding RT2 will become DR and
RT1 will become non-DR to that LAN. My doubts are,

1) whether the multicast route entries that are present in
RT1 before entry of  RT2 will be removed? 

[dsatya] Not necessarily, those entries will changed based
on the unicast route change to RP. (due to insertion of RT2)

2) Will RT1 stops trigerring Join messages to RP? Or RT1
will be trigerring Join messages for existing entries and
RT2 will be trigerring for any new entries? 

[dsatya] RT1 should not trigger Join Msgs to RP and RT2
should take up the job. 

Thanks

Satya

Please clear my doubts.
Thank you in advance.

Regards,
Binu.

  _____  

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=48245/*http:/autos.yahoo.com/new
_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWls
dGFncwRzbGsDbmV3LWNhcnM->  

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

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

---

From: John Zwiebel <[email-masked]>
Date: Wed, 9 May 2007 10:23:36 -0700

On May 8, 2007, at 11:14 PM, Prashant Jhingran wrote:

> Had it been PIM-DM instead of SM, then of course Assert would have  
> decided the forwarder on the LAN.  But in case of PIM-SM, the RFC  
> 4601 implicitly specifies how to handle such a scenario.
>
> Section  4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G) Join/Prune  
> Messages respectively specifies the following:
>
> Transition [J] state => [NJ] state ; Send respective Prune message  
> viz. (*,G) or (S,G); Cancel respective Join Timer
>
> Note: JoinDesired(*,G), depends on pim_include(*,G) which in turn  
> depends on "I_am_DR( I )" bool.
>
> Conclusion:
>

Guaranteeing that the receiver on this LAN will miss packets.

IMHO, it is up to the implementation to determine whether it wants to
rely on an assert or the RFC specified process.

A couple of toplogies that you might find interesting.

     RT1                 RT1         RT2
      |                   |           |
  ----+------+---       --+-+----+----+
      |      |              |    |
     RT2     H              H   RT3

    topo 1                  topo 2

What happens in topo1 when RT2 becomes the DR?  Do you really want
RT1 to send prunes upstream only to have RT2 reset the same path?

And in topo 2, when RT1 is the DR, but loses to RT3 and RT3 picks RT2  
as the
RPF router, now what happens?

Which then brings up my "favorite" conundrum, which has nothing to do
with this thread (well, perhaps in an peripheral way...) Make RT3 the DR
and have it switch RPF from RT1 to RT2 (with or without H), the RFC says
send a join to RT2 and prune to RT1.  On a multiaccess LAN this just
generates a lot of excess control traffic and, depending on the data  
rate,
probably won't avoid an assert anyway.  And if you have many  
downstream routers
the problem becomes even worse.

Of course an implementation has to consider whether it can deal well  
with
asserts, which are inherently evil.

And we are talking about a "corner case" since multiaccess-LANS are  
becoming
more and more rare.  Which then brings up the question on a P2P  
network, if a
router does an RPF change, is it more advantageous to Prune off the  
old link or
to just let it timeout.

                   R1       R2
                       \      /
                        R3

R1 is the RPF, it changes to R2, Pruning the R1-R3 link immediately  
gets you exactly what?
Consider what happens if it is a unicast routing flap.  Do you really  
want prunes sent up the R1
branch only to be followed immediately by joins when unicast "flaps  
back"?
Those messages are potentially sent all the way to the root of the tree.

I'm not offering any answers on the way it "should be done".

Oh, and we haven't addresses the fact that there may be an L2 switch  
in between which may or
may not participate in the forwarding decision.

---

From: Su Haiyang <[email-masked]>
Date: Thu, 10 May 2007 11:17:19 +0800

Dear All,

   I think more reliability of PIM-SM protocol should be considered at the
next draft.

   Considering that MPLS's LSP has the concept of "Make before break", why
the PIM WG 

leaves this issue as an implementation-specific one?

   Just like the topologies both of you have mentioned in your email, at
least when the DR switches and RPF changes, 

PIM should consider the mechanism of preventing data from losing.

Su Haiyang

  _____  

From: John Zwiebel [mailto:[email-masked]] 
Sent: Thursday, May 10, 2007 1:24 AM
To: [email-masked]
Cc: [email-masked]; 'Satyanarayana Dillikar'; 'Binu TN'
Subject: Re: [pim] pim-sm router transitions from DR to non-DR

Had it been PIM-DM instead of SM, then of course Assert would have decided
the forwarder on the LAN. But in case of PIM-SM, the RFC 4601 implicitly
specifies how to handle such a scenario.

Section 4.5.6. & 4.5.7 i.e. Sending (*,G) & (S,G) Join/Prune Messages
respectively specifies the following:

Transition [J] state => [NJ] state ; Send respective Prune message viz.
(*,G) or (S,G); Cancel respective Join Timer

Note: JoinDesired(*,G), depends on pim_include(*,G) which in turn depends on
"I_am_DR( I )" bool.

Conclusion:

- On loosing DR Election, RT1 should send Prune mesg towards upstream &
should remove the entry as well.

- RT2 (new DR) should form the tree by triggering Join mesg upstream towards
RP..

RT1 RT1 RT2

| | |

| | | |

RT2 H H RT3

topo 1 topo 2

And in topo 2, when RT1 is the DR, but loses to RT3 and RT3 picks RT2 as the

generates a lot of excess control traffic and, depending on the data rate,

probably won't avoid an assert anyway. And if you have many downstream
routers

Of course an implementation has to consider whether it can deal well with

And we are talking about a "corner case" since multiaccess-LANS are becoming

more and more rare. Which then brings up the question on a P2P network, if a

router does an RPF change, is it more advantageous to Prune off the old link
or

to just let it timeout.

R1 R2

\ /

R3

R1 is the RPF, it changes to R2, Pruning the R1-R3 link immediately gets you
exactly what?

Consider what happens if it is a unicast routing flap. Do you really want
prunes sent up the R1

branch only to be followed immediately by joins when unicast "flaps back"?

Oh, and we haven't addresses the fact that there may be an L2 switch in
between which may or

---

From: John Zwiebel <[email-masked]>
Date: Thu, 10 May 2007 09:24:12 -0700

Please feel free to propose a totally protocol, or whatever protocol  
changes you think
are in order,  that takes advantage of the last 15 years of multicast  
protocol development
and deployment.  I'm sure you'll not have any trouble gaining  
consensus and that
your plan will integrate seamlessly into legacy deployments.

On May 9, 2007, at 8:17 PM, Su Haiyang wrote:

> Dear All,
>
>    I think more reliability of PIM-SM protocol should be considered  
> at the next draft.
>
>    Considering that MPLS’s LSP has the concept of “Make before  
> break”, why the PIM WG
>
>    Just like the topologies both of you have mentioned in your  
> email, at least when the DR switches and RPF changes,
>