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

["Nicholas, Jonathan - CS" <Jonathan.Nicholas at itt.com>]

Hello,

 

If we assume that the Assert Loser is still receiving messages for (S,G) on its upstream interface, then the behavior described in PIM-SM would be desirable, since there would be no change to the upstream state.

 

However, if the upstream state is Pruned(S,G), transitioning to an Assert No Info(S,G) state on the downstream interface will cause the upstream state to transition to Forwarding (S,G), triggering a Graft(S,G) on the upstream interface with the state changes that implies potentially all the way back to the source.  Then, when messages flow, the router will lose the Assert, return to a Pruned(S,G) state on the upstream interface and so on.

 

While both techniques will eventually achieve the correct state, we believe that the specified action would be the more efficient technique in most cases.  This is partly because the upstream Graft/Prune cycle will be avoided, and partly because the Assert messages would occur immediately, rather than waiting for the message flow from upstream.  However, if the Assert Winner(S,G) has failed, the technique described in PIM-SM would be more effective. 

 

If PIM-DM were to ever be revised/updated (unlikely), this behavior could be revisited.

 

Jonathan Nicholas

---

From: pim-bounces at ietf.org [mailto:pim-bounces at ietf.org] On Behalf Of Shilpi Sinha
Sent: Thursday, April 16, 2009 8:35 AM
To: pim at ietf.org
Subject: [pim] PIM DM - RFC 3973: Expected behavior on reception of graft by an assert looser?

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

 

---

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.