[pim] PIM DM - RFC 3973: Expected behavior on reception of graft by an assert looser?

[Shilpi Sinha <shilpi at juniper.net>]

Hi,

 

I had the following query with regards to the expected behavior when an assert looser on the LAN gets a graft from its downstream router. As per RFC, the behavior should be

       Receive Prune(S,G), Join(S,G), or Graft(S,G)

       A Prune(S,G), Join(S,G), or Graft(S,G) message was received on

       interface I with its upstream neighbor address set to the

       router's address on I.  The router MUST send an Assert(S,G) on

       the receiving interface I to initiate an Assert negotiation.  The

       Assert state machine remains in the Assert Loser(L) state.  If a

       Graft(S,G) was received, the router MUST respond with a

       GraftAck(S,G).

The rationale explaining this is

        An Assert loser that receives a Prune(S,G), Join(S,G), or

        Graft(S,G) directed to it initiates a new Assert negotiation so

        that the downstream router can correct its RPF'(S).

I could not get the advantage of router remaining in “Assert Looser” state except for avoiding duplication probably? Please correct me in case I am missing something. If I understand correctly being in Assert looser state means that router would not forward despite getting a graft from downstream. If I understand correctly, we are initiating the assert negotiation to reduce duplication of packet on the LAN and the trade-off here is between duplication against drops. Now in a scenario where the assert winner happens to go off silently, wouldn’t we end up dropping packets for a longer interval (atleast till AT expires or NLT expires, whichever is earlier). IMO, It is likely that the downstream router got to know of assert winner going off first and that’s why it initiated the graft towards the new RPF neighbor.

 

What’s the harm if we get into forwarding immediately on reception of graft and assume ourselves as assert-winner and start the assert war? Even with this approach, an assert war would resolve the issue and downstream router would be able to correct it’s RPF’(S) now if at all it had sent to the wrong RPF earlier. But at, least in this case, I feel we would be able to converge faster and minimize the drops. Am I missing something majorly here or have mis-interpreted the RFC?

 

I just referred the SM RFC 4601, and it’s behavior on reception of a join appears to be similar to what I thought it should be. Pasting the relevant clipping from RFC 4601.

 

On Assert looser

Receive Join(S,G) on Interface I

          We receive a Join(S,G) that has the Upstream Neighbor Address

          field set to my primary IP address on interface I.  The action

          is to transition to NoInfo state, delete this (S,G) assert

          state (Actions A5 below), and allow the normal PIM Join/Prune

          mechanisms to operate.  If whoever sent the Join was in error,

          then the normal assert mechanism will eventually re-apply, and

          we will lose the assert again.  However, whoever sent the

          assert may know that the previous assert winner has died, and

          so we may end up being the new forwarder.

Behavior: An assert loser that receives a Join(S,G) with an

       Upstream Neighbor Address that is its primary IP address on that

       interface cancels the (S,G) Assert Timer.

Rationale: This is necessary in order to have rapid convergence

       in the event that the downstream router that initially sent a

       join to the prior Assert winner has undergone a topology change.

 

Request you to kindly help me with the expected behavior.

 

Thanks and regards

Shilpi