Subject: RE: [pim] question on pim assert

From: "Ju, Yu" <[email-masked]>
Date: Wed, 27 Mar 2002 10:23:07 -0500

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 9:13 PM
To: Ju, Yu
Cc: [email-masked]; 'Mark Handley'; [email-masked]
Subject: Re: [pim] question on pim assert 

On Tuesday, March 26, 2002, at 03:26 PM, Ju, Yu wrote: 

[Ju, Yu] I agree. But the current draft does allow a  (*,G) assert to affect
(S,G) assert state. That is what the table on page 78 says for (S,G) assert
state machine in the event of receiving assert with RPTbit set.  

Yes, it does and it should. 

This is the case where the shortest-path is suppose to win over the
shared-path. 

[Ju, Yu] Yes, it does. But is it a thing that (S,G) assert state must do
upon receiving a (*,G) assert with RPTbit set? What if the (S,G) assert
state doesn't change? Then the router with (S,G) forwarding state will
continue to forward and the router with (*,G) state will forward date for G.
I believe the downstream router will prune (S,G) when it sends (*,G) join to
the (*,G) assert winner.

I had said: 

Point: understanding of assert operation is extremely difficult if you think

that (*,G) asserts have any influence on (S,G) state and visa versa. 

But I also said: 

If you assume that  (S,G) -always- wins over (*,G) then things become 

much easier to understand. 

I was talking about (S,G) state as one would see it on a router with a 

"sh ip mr" command. A (*,G) assert will not affect the IIF or the Olist 

of that (S,G) state. 

Sorry for being incomplete.

---

From: John Zwiebel <[email-masked]>
Date: Wed, 27 Mar 2002 08:21:19 -0800

On Wednesday, March 27, 2002, at 07:23 AM, Ju, Yu wrote:
>
> [jz] This is the case where the shortest-path is suppose to win over 
> the shared-path.
>
> [Ju, Yu] Yes, it does. But is it a thing that (S,G) assert state must 
> do upon receiving a (*,G) assert with RPTbit set? What if the 
> (S,G) assert state doesn't change? Then the router with (S,G) 
> forwarding state will continue to forward and the router with (*,G) 
> state will forward date for G. I believe the downstream router will 
> prune (S,G) when it sends (*,G) join to the (*,G) assert winner.
>

You have to evaluate two different cases and come up with the same
plan for both.  Case 1 is with a downstream router and case 2 is
without a downstream router.

In Case 2, I believe it is obvious that (S,G) state must be installed
in both upstream routers so that the shortest-path will win over the
shared-path.  You don't want to have to depend on which router is
the DR and you don't want the asserts to have to be repeated
every 3 minutes, which leads (I believe) to the requirement that the
(S,G) KeepAlive timer be updated whenever packets are -seen- on
a router interface, not just when forwarded (as stated in 4.1.4, just
prior to 4.1.5).  However, it seems that some implementations
will have trouble accomplishing this.  Still, I haven't yet heard
any convincing argument against this change, and I don't see how
it will affect interoperability if one implementation uses
"forwarding" and another uses "packet presence".  So I'm not
going to lobby for a change in the spec.

Your question is concerning case 1:  In this case the downstream
router is required to track the upstream assert winner.  Your
statement "prune (S,G) when it sends (*,G) join to the (*,G)
assert winner", doesn't make sense to me.  If one router is
forwarding on (S,G) and the other is forwarding on (*,G), then
the (*,G) forwarder -must-stop- forwarding for that source.

There can be no (*,G) assert winner in this case since one router
is sending an (S,G) assert and the other is sending a (*,G)
assert, there is only the (S,G) assert winner and loser.

Let me repeat, "(S,G) state -always- wins over (*,G) state."
If there is a conflict, then you need to install (S,G) state
in all the routers participating in the conflict to resolve it.
There is no reason for the downstream router to prune (S,G) since
it has to track the upstream assert winner which -must- be the
(S,G) assert winner.  (In any case, how would the downstream
router have any info on (S,G) unless it installed the route
which would result in an (S,G,RP-bit) prune being sent up
the shared-path.

If part of your argument is that you want to be able to
switch back to (*,G) after (S,G) has been installed, don't
do that.  It doesn't work.  (assuming the source is
continuously sending.)

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim