Subject: [pim] Query regarding Assert State Machine in PIMDM

From: Krish... <[email-masked]>
Date: Tue, 20 Nov 2007 19:22:17 +0530

This is a query regarding the Assert State machine in PIMDM (RFC3973).

Consider the following scenario:

----------------------------------------------------
          -----
Host---| A |-------|
          -----       |
            |       -----
            |       | C |-----Source
            |       -----
          -----       |
Host---| B |-------|
          -----
----------------------------------------------------

Initially, A's and B's Upstream is C.
When data flows, A and B assert on their connected downstream interface.
Assume A is the Assert Loser and B is the Assert Winner.
A being the loser sends a Prune to B so that B stops forwarding on
this interface.
So, On B's Downstream interface, AT and PT will be running and these
timers will be refreshed with State Refresh messages.

Now, Assume a case wherein A's Upstream Link (towards C) is Down.
A's new upstream will now be towards B.

But B will never send data to A as its AT and PT will be refreshed with SRMs.
In such a case, it makes sense for A to send a Graft to B to rejoin the tree.
On receipt of the Graft message, B's PT will be cancelled and data
will be forwarded.
But the AT will still get refreshed with SRMs and B will always be
Assert Winner.

As per the draft, the Assert State machine remains in Assert Winner
state upon the receipt of a Graft message.
Any reasons behind this?

But, it makes sense that B's Assert state to move to NoInfo upon the
receipt of a Graft message on the downstream interface.

Please correct me know if I missed anything.

Any comments on this are welcome.

Thanks & Regards,
Krish...

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Tue, 20 Nov 2007 09:36:25 -0500

Krish,

Your assessment is essentially correct.

The reason the Assert State Machine remains in the Assert Winner state
for B is that (from an abstract specification point of view) there could
be other Assert Losers on the A-B network that would become Assert
Winners if B were to transition out of the Assert Winner state.

Since the externally observable behavior of an Assert Winner is
identical to an Assert No Info state, you could transition out of the
Assert Winner state to an Assert No Info state and remain compliant with
the specification *if* you determined that no other candidate upstream
routers remained on the interface.  However, the PIM-DM specification
contains no mechanisms for making such a determination, so it seems
safer to just maintain the Assert Winner state.

Jonathan Nicholas

> -----Original Message-----
> From: Krish... [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2007 8:52 AM
> To: [email-masked]
> Subject: [pim] Query regarding Assert State Machine in PIMDM
>
> A being the loser sends a Prune to B so that B stops
> forwarding on this interface.
> So, On B's Downstream interface, AT and PT will be running
> and these timers will be refreshed with State Refresh messages.
>
> On receipt of the Graft message, B's PT will be cancelled and
> data will be forwarded.
> But the AT will still get refreshed with SRMs and B will
> always be Assert Winner.
>
> As per the draft, the Assert State machine remains in Assert
> Winner state upon the receipt of a Graft message.
> Any reasons behind this?
>
> But, it makes sense that B's Assert state to move to NoInfo
> upon the receipt of a Graft message on the downstream interface.
>

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.