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

From: Shilpi Sinha <[email-masked]>
Date: Thu, 16 Apr 2009 18:05:17 +0530

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

---

From: Shilpi Sinha <[email-masked]>
Date: Thu, 16 Apr 2009 18:06:50 +0530

Hi,

 

On Assert looser

Thanks and regards

Shilpi

---

From: "Nicholas, Jonathan - CS" <[email-masked]>
Date: Thu, 16 Apr 2009 09:18:54 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Shilpi Sinha
Sent: Thursday, April 16, 2009 8:35 AM
To: [email-masked]
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

       GraftAck(S,G).

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

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.

---

From: "Prashant Jhingran (pjhingra)" <[email-masked]>
Date: Thu, 16 Apr 2009 18:58:42 +0530

Hi,
 
We should also consider that there is a difference in Assert FSM between
the two PIM modes:
 
PIM-SM: If Assert Winner's Timer expires then it remains in Assert
Winner's state and sends out an Assert message. Looser restarts AT timer
on reception of Assert mesg.
 
PIM-DM: If Assert Winner's Timer expires then router transitions to No
Info state. Thus forcing assert to happen once again (once AT expires on
looser)
 
Thus, Assert is in a way is forced in case of SM where as it would
happen automatically (on AT expiry) in case of DM.

Regards,
Prashant Jhingran

Phone:   +91-80-442 61800

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas, Jonathan - CS
Sent: Thursday, April 16, 2009 6:49 PM
To: 'Shilpi Sinha'; [email-masked]'
Subject: Re: [pim] PIM DM - RFC 3973: Expected behavior on reception of
graft by an assert looser?

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Shilpi Sinha
	Sent: Thursday, April 16, 2009 8:35 AM
	To: [email-masked]
	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.

	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.