Subject: [pim] Query on PIM-SM

From: "Sekuri, Yaminikrishna \(GE Indust, GE Fanuc\)" <[email-masked]>
Date: Mon, 7 Aug 2006 17:03:49 +0530

Hi,
I am novice to PIM-SM. 
I have few questions regarding the working of PIM-SM router:

1. What should happen in the PIM-SM router when the route towards the RP
has changed in its unicast routing table ?
2. What happens when the user disables PIM-SM on one of the router's
interface which has a connection towards the RP or if the interface
towards the RP is down ?
3. Is the state (*,*,RP) mandatory to be  implemented ? 

Thanks in Advance.

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

---

From: "Sekuri, Yaminikrishna \(GE Indust, GE Fanuc\)" <[email-masked]>
Date: Wed, 9 Aug 2006 14:57:27 +0530

Thanks all for the immediate replies.

As you are aware that even the smallest operation in PIM has a chain
reaction taking place most of which would be handled by the state
machines.
For example may be if we receive an IGMP join for (*,G) then we have to
the following things:
Assert Tracking Desired WC, SG; check if prune desired S,G,rpt and  join
desired S,G?;
Recalculate S,G assert metric; Is join desired *,G? etc

I would like to know explicitly what all actions that have to be
performed when:
a) turning PIM-SM off for an interface
b) a unicast route to an RP changing

Regards,
Yamini

-----Original Message-----
From: Prashant Jhingran [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 11:48 AM
To: [email-masked]
Cc: 'Anand S Natarajan'; Sekuri, Yaminikrishna (GE Indust, GE Fanuc)
Subject: RE: [pim] Query on PIM-SM

Hi,

Regarding the second point:
I think Yamini wants to say that disable (bring down) PIM-SM but not the
interface towards RP. 
This ideally should cause MRIB change because the multicast/PIM-SM
enabled interface towards RP changes however there would be no change in
unicast route towards RP. The action required is implementation specific
however it may be treated as RPF(RP) change and thus one can refer to
the section 4.5.6 of the latest draft for the same. 

Incase if there is no alternative RPF(RP) then the router will be
helpless and thus may either choose to maintain the *,G (without any
upstream info) and wait until it relearns RPF(RP) or simply delete *,G
entry.

Regarding the third point:
To my understanding there are many ambiguities (both in RFC 2715 and the
draft) even if one wants to implement *,*,RP stuff besides the fact that
its of no use.

-Regards,
Prashant Jhingran

Huawei Technologies
Shenzhen, P R China
Office +86-755-28976431
Mobile +86-13480651542
============================================
"Sing, dance, serve, meditate and celebrate" 
-Sri Sri Ravi Shankar www.artofliving.org
============================================

-----Original Message-----
From: Anand S Natarajan [mailto:[email-masked]]
Sent: Tuesday, August 08, 2006 10:57 AM
To: Sekuri, Yaminikrishna (GE Indust, GE Fanuc); [email-masked]
Subject: RE: [pim] Query on PIM-SM

1. Send Joins towards the new upstream neighbor in the RP path and
Prunes towards the old neighbor (Sec 4.5.6 of draft). 
2. Send a Hello packet with 0 holdtime to inform neighbors, whenever
possible. Neighbors need to clear the states that was learnt from
messages originating from this interface. If it were not possible to
inform, then the states time out in neighbors. Before which if the
interface that went down is back up again, GenID change in new Hello
messages helps neighbors to be aware of the down/up event that has
happened and clear the states.
3. Not sure about the terminology w.r.t being mandatory, but it does
tend to get skipped in implementations as there are not many important
uses for it today.

Anand

From: Sekuri, Yaminikrishna (GE Indust,GE Fanuc)
[mailto:[email-masked]] 
Sent: Monday, August 07, 2006 5:04 PM
To: [email-masked]
Subject: [pim] Query on PIM-SM

Hi, 
I am novice to PIM-SM.