Subject: Re: assert cancel messages

From: "Jyotheeswara Rao Kurma" <[email-masked]>
Date: Mon, 09 Jul 2001 11:10:23 +0500

> No, the purpose of an assert cancel message is for a PIM speaker 
> to make its
> assert value as low as possible. Since (S,G) assert messages 
> always are 
> considered of a higher priority than (*,G) assert messages the 
> cancel message 
> must have the RPT bit set otherwise the cancel message would still 
> be prefered
> over (*,G) assert messages.

  Then how are we going to classify, an assert being (S,G) or (*,G),
some time back, it was discussed and said that the RP bit is the one 
that differentaites. Any way how about the source address fields in 
cancel masseges ?  

Can a (*,G) assert can trigger (s,g) assert state machine ?

Thanks, 
Jyotheesh

---

From: David Barnett <[email-masked]>
Date: Mon, 9 Jul 2001 08:53:23 -0400

> Can a (*,G) assert can trigger (s,g) assert state machine ?

The desired effect is for either FSM ( (*,G) or (S,G) ) to see the message
as "An inferior assert from the current winner". Regardless of which FSM
you are currently dealing with the assert cancel will be regarded as such
if the RPT bit is set.

-Dave

---

From: John Zwiebel <[email-masked]>
Date: Mon, 09 Jul 2001 10:31:28 -0700

> Can a (*,G) assert can trigger (s,g) assert state machine ?

Asserts are only triggered by receipt of data on the 
outgoing interface -- at least initially.

Think of it this way.  The purpose of the assert
is to make sure there is one and only one forwarded on
to the LAN.  That means that at least two routers have
to be forwarding on to the LAN to make the assert 
happen.  If a router sends an assert when it isn't 
actually forwarding packets for the source, you'll 
end up cutting off the receivers.

I'm _not_ saying that you don't reply to an inferior
assert, but if (for instance) you have an (S,G) and your
T-bit isn't set and you get an assert, you can't trigger
an assert.

Your questions, in general, are not starting from "scratch".
Your question about the router that gets a (S,G) join in
but had been the (*,G) assert loser shouldn't be addressed
as if the router had lost the (*,G) assert.  As soon as
that router created (S,G), all previous assert loses 
no longer matter.  Now that router 3 is asserting for 
(S,G), and the other routers have only (*,G) state,
of course router3 will win the assert.  The other routers
have to prune that source from the shared-tree by creating
(S,G,R) state.  In this case, the SPT is determined by the
downstream router which chose to send the (S,G) join to
router3.  

So, there's no need to "store" (S,G) assert information
with a (*,G) assert.  The (*,G) assert state machine
doesn't have to worry about accepting an (S,G) assert,
because no you have to deal with the (S,G) assert
state machine and that machine clearly states that
you'd create (S,G,R) state if I is the RPF to the
source.

If this isn't the case, the downstream router is going
to be sending (S,G,R) prunes which is going to create
(S,G,R) state on this router in any case.  If the 
downstream isn't sending these messages, then it doesn't
yet know that it has received traffic on the SPT.  How
does it know that?  When router3 sends the (S,G) assert,
because -- again -- that assert won't be sent until
router3 sets its T-bit.

So now the question becomes, why isn't (S,G,R) state
created on a router on the shared-tree as soon as it
gets an (S,G) assert?  Especially since the net result
is going to be to have (S,G,R) state on this router anyway.

Well, Fig 10 says that when you transition from "no info"
to "assert loser" you have to "store the assert winner" which
(to me) means you have to create (S,G) state because where else
do you store the assert winner for the (S,G).  Now, this router
joins toward the source and you have a new assert process take
place where the metrics for (S,G) are directly compared between
router3 and the other routers on the network.

At first glance this seems unnecessarily complicated.  But
there's no guarantee that the downstream routers have the
same metrics to chose an upstream neighbor for the source.
So the way the spec is written you keep the forwarding choice
in the upstream routers (via the assert) which isn't necessarily
a bad idea.

So the final question is, can you put together a topology where
this is going to happen?  Seems to me that it will be very 
infrequent.  I'm also afraid that there are going to be
implementation problems between various vendors, we'll have to
see since AFAIK, no one has come close to a complete implementation
of the new spec.

z

---

From: David Barnett <[email-masked]>
Date: Mon, 9 Jul 2001 13:56:48 -0400

> Can a (*,G) assert can trigger (s,g) assert state machine ?

Presumably the purpose of an Assert cancel message is to notify any neighbors
who consider you to be an assert winner that you no longer wish to have the
job of forwarding. I suppose you could have two assert messages, one for (*,G)
and one for (S,G) but since you can create the same result with one message 
you may as well. 

Keep in mind, the purpose of the message is basically to say "Hey I'm now worse
than you", and regardless of which state you are holding ( (S,G) or (*,G) ) 
an assert cancel with the RPT bit set is worse.

-Dave