| FWIW:
You open a can of worms here and I don't think there is a "right" answer.
RPF changes on a LAN are complicated by the fact that the spec says to send a prune to the old RPF neighbor. However, if you do this and there are two or more downstream neighbors, they will send a JOIN-OVERRIDE guaranteeing there will be duplicate packets on the network. Eventually an assert process chooses the winner and things go on from there.
You might think that the other downstream routers will eventually do their unicast convergence thereby avoiding the assert, and if the data rate is slow enough this will be true. But even for the rates that ping sends packets, I've seen a flurry of PIM JOIN/PRUNE messages on the LAN and things aren't resolved until the ASSERT happens.
If one is talking about p2p links, one might be tempted to say that pruning back the old RPF immediately is a good thing, so send a prune in that case. However, RPF changes are often route-flaps, so you end up having to trigger a join when you flap-back. Duplicate traffic to a non-RPF interface on a p2p link is a waste of BW, but making the choice to not send a triggered prune to the old RPF neighbor because of the route-flap potential is (I believe) a good trade-off if your concern is more about ensuring data delivery and keeping control traffic to a minimum rather than saving BW (which was being used before with no visible effects so what's the hurry in pruning it off?)
in 4.1.3 triggered joins are discussed for (*,G) state. RPF' is for asserts. That doesn't override what is said here or in 4.1.4 for (S,G) state
The last RPF neighbor towards the RP is stored because if the MRIB changes then the RPF neighbor towards the RP may change. If it does so, then we need to trigger a newJoin(*,G) to the newupstream neighbor and a Prune(*,G) to the old upstream neighbor.
On Jul 4, 2006, at 4:12 AM, JGSPrasad wrote: Hi Saurabh,
Your understanding is correct.
I think assert mechanism is best effort approach for optimal forwarding but does not guarantee in all cases.
However as an alternate thought, if indeed we need optimal forwarding :
Assuming all routers are running some dynamic routing protocol we see that when the metric of R2 becomes better than R1, the downstream router would also get a route change notification [saying the route to RP is better reachable through R2] and its nexthop in the routing table changes to R2.
The current RFC does not say anything about RPF(Nbr) change.It only says,change of RPF'(Nbr) change should trigger a join.So going by the current draft,since the RPF'(Nbr) does not change we do not trigger any join.
neighbor RPF'(S,G) {
if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return NBR( RPF_interface(S), MRIB.next_hop( S ) )
}
}
But by sending a join to the new RPF(Nbr) we could trigger an assert and thereby R2 would become the winner and optimal forwarding would continue.
We can have some new timer like override timer to prevent flooding of join packets during route change.
However this can work only if we have some dynamic routing protocol giving the correct metrics and not under static route configuration in the downstream router.
Its just a thought..Give your comments on the same..
Regards,
Prasad
Saurabh Goel wrote: Hi Everyone,
I have a question on the PIM Assert mechanism....
Consider two upstream routers, R1 and R2, on a LAN
both having (*,G) forwarding states. One of the
routers, say R2, with inferior mertic goes to the 'I
am Assert Loser' (L) state. The downsteam routers on
the LAN learn about the Assert Winner and
modify their RPF neighbor information to point to the
Winner. Hence R2 no more reveives any (*,G) joins.
Eventually (depending on the HoldTime advertised in
the last (*,G) Join message on this oif) the Expiry
Timer (ET) on its corresponding asserted oif expires
and transitions to NoInfo (NI). This in turn makes
CouldAssert(*,G,I) False. Now, even if the metric for
reaching RP(G) on R2 becomes better than that on R1,
it never becomes a Winner (CouldAssert(*,G,I) is
False)? Similar behavior would result for other more
complicated Assert wars. Is this the expected bahavior
or is my understanding not correct ? Please comment.
Thanks
saurabh
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim
--
SharadaPrasad JG
Senior Software Engineer, Embedded Business Unit
Huawei Technologies India Private Ltd,
Bangalore - 560008
Ph:+918041781770 Extn:1645
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ pim mailing list |
