Subject: [pim] Reg: Prune(*, G) does not affect Prune(S, G, rpt) downstream state machine

From: "Ganga Prabha" <[email-masked]>
Date: Wed, 29 Aug 2007 15:16:18 +0530

Dear All,
      I need a clarification on the below topology.

       -----------                               -------------------
     |  RT1     |           I1              |                    |
     |             | ---------------------------|      RT2        |
       ----------                               |                   |
       -----------                               -------------------
     |    S1     |                                       |
     |             |                                       |
       -----:-----                                         |
            :                                              |
       -----:-----                                         |
     |    RT3   |             I2                        |
     |             | --------------------------------------|
       ----------

RT2 : BSR
RT3 : RP for Group G1.

Steps:
     1) All the routers aware of the their respective neighbors ,RP and BSR.
     2) RT1 sends Join(*,G1) Message with upstream neighbor as RT2 and Hold
time as 210 secs to RT2 on the interface I1.
     3) Now RT2 interface I1 moves to Join(*,G1) state.
     4) RT1 sends Prune(S1,G1,RT3) Message with upstream neighbor as RT2 and
Hold time as 10 secs to RT2 on the interface I1.
     5) Now RT2 interface I1 moves to Prune (S1,G1,RT3) state immediately as
there is only one neighbor.
     6) RT1 sends Prune(*,G1) Message with upstream neighbor as RT2 and Hold
time as 210 secs to RT2 on the interface I1(This message is sent before the
expiry of Prune (S1,G1,RT3) timer).

After expiry of Prune(S1,G1,RT3) timer (10 secs), If the RT2 receives
multicast data packets from S1 via RT3 , will RT2 forward the Multicast data
packet to its down stream interface(To RT1).

I am expecting this behaviour as mentioned in the RFC 4601 Section
4.5.4Page 61 Last Paragraph.

" Notes:
 Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state
machine."

It will be of Great help if someone could tell me whether my expectation is
correct. If it is not correct please clarify me .

Thanks and  Regards,
K.Ganga Prabha
_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Christopher Thomas Brown <[email-masked]>
Date: Wed, 29 Aug 2007 15:49:08 -0700

>       I need a clarification on the below topology.

No. Why would it? The interface is not in the olist regardless of whether the
S,G,RPT prune state is maintained. There is no immediate olist nor an
inherited olist.

I think its pretty common for implementations to get rid of the S,G,RPT state
when there is no longer any associated *,G state. It will get reestablished
if and when the *,G is reestablished.

Additionaly, I don't know of an implementation out there that will send
different J/P holdtimes on the same interface.

Chris

---

From: "Ganga Prabha" <[email-masked]>
Date: Thu, 30 Aug 2007 13:37:32 +0530

Dear Chris,
         As per the RFC 4601 Page 61,
" Notes:
  Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state
machine."

That is why i expected when the Prune(S,G,rpt) timer is running, sendig of
Prune(*,G) should not affect. Could please explain me the significance of
the state machine in the RFC 4601 Page 61 which i have refered above.

Thanks and Regards,
K.Ganga Prabha

> different J/P holdtimes on the same interface.

-

---

From: Su Haiyang <[email-masked]>
Date: Thu, 30 Aug 2007 17:33:58 +0800

I think that any state transition of (S,G,RPT) downstream state from Pruned
to NO_INFO never  potentially cause adding this interface back to  the
downstream list.

So it's no use to move any (S,G,RPT) downstream state back to NO_INFO when
receiving (*,G) prune.

Moving such (S,G, RPT) downstream state back to NO_INFO would be a tough
work if there are many (S,G) with RPT prune state.

So it's better to leave them alone.

  _____  

From: Ganga Prabha [mailto:[email-masked]] 
Sent: Thursday, August 30, 2007 4:08 PM
To: Christopher Thomas Brown
Cc: [email-masked]
Subject: Re: [pim] Reg: Prune(*, G) does not affect Prune(S, G,rpt)
downstream state machine

Dear Chris,

Thanks and Regards,
K.Ganga Prabha

>       I need a clarification on the below topology.

No. Why would it? The interface is not in the olist regardless of whether
the
S,G,RPT prune state is maintained. There is no immediate olist nor an
inherited olist. 

I think its pretty common for implementations to get rid of the S,G,RPT
state
when there is no longer any associated *,G state. It will get reestablished
if and when the *,G is reestablished.

Chris

-

---

From: Christopher Thomas Brown <[email-masked]>
Date: Thu, 30 Aug 2007 14:49:10 -0700

> the state machine in the RFC 4601 Page 61 which i have refered above.

I think the authors were just pointing out that even though receiving a
Join(*,G) affects the (S,G,RPT) downstream state machine receiving a
Prune(*,G) does not affect the state machine.

Chris

---

From: Christopher Thomas Brown <[email-masked]>
Date: Thu, 30 Aug 2007 18:58:13 -0700

> to NO_INFO never  potentially cause adding this interface back to  the

Not when there is no additive state. If there is no (*,*,RP) state or
(*,G) state to add the interface to the inherited olist then the interface
will not end up in the olist regardless of whether (S,G,RPT) state is
maintained or not.

Which was my somewhat terse answer to his question. When the (*,G)
prune pending timer expired there was no longer an additive element to
inherited_olist(S,G) so the olist became NULL and no data would be forwarded.

> work if there are many (S,G) with RPT prune state.

How useful or tough something is will be greatly implementation dependent
and contrained by the deployment senario for the implementation.

>From PIM-SM RFC 2363:
When the timer expires, the route entry is deleted; if the
entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT-
bit entries are also deleted.

I think it likely that it is common for this legacy behavior to still
exist in many 'updated' implementations.

The harm is does depends on an implementation's intended deployment senarios.
The worse case senario is when the first downstream sends a Join(*,G) and
includes one or more of the (S,G,RPT) prunes and those previous (S,G,RPT) expiry
timers would not yet have expired. If so, then there is a small window when
unwanted data may flow down that branch until the prune pending timers expire.
This seems only probable where there are downstream routers on the SPT
(like first hop routers) or where there is IGMPv3/MLDv2 exclude state.

Chris