Re: [pim] Assert Mechanism and Joinn Expiry Timer (ET) interaction
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] Assert Mechanism and Joinn Expiry Timer (ET) interaction



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
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.