Re: [pim] Assert Mechanism and Joinn Expiry Timer (ET) interaction

[John Zwiebel <jzwiebel at cisco.com>]

On Jul 5, 2006, at 7:17 PM, Saurabh Goel wrote:

> (The discussion below assumes only SPT Vs SPT or RPT
> Vs RPT Asserts and not SPT Vs RPT)
>
> However, the Assert mechanism doesn’t seem to be
> resilient to route-flaps but rather seems to be
> sensitive to it because of the following mechanisms:

"route flaps" can mean a single event where the metrics
change in a network and then things immediately settle down,
or they could change and then change back again.  Or it could
mean continuous flip-flopping.

In the first two cases, I think the spec is fine.
In the last case, nothing is going to work.

> 1.  We know that upstream Assert Loser transitions to
> No Info and enables forwarding data on receiving a
> Join from a downstream. If the downstreams are
> flapping their RPFs, it would keep triggering new
> Assert wars. The rationale for this behavior is quick
> convergence as specified in section 4.6.5
>
> “6.   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.”

Remember the downstream routers also follow the assert exchange
and will RPF to the winner.  If they think the winner is the
wrong one, they should be in a position to override the upstream
routers.  Unicast metrics do not converge on all routers at the
same time.  (which was why I brought up the prune-the-old-RPF problem)

There is a small window of time where a join might be sent
at the same time an assert is being sent.  Canceling the assert
timer will cause the assert to happen again which will get all
the downstream routers to RPF to the winner (hopefully, things
could still break, but we're getting to a point of diminishing
returns.)  Convergence here means all the downstream routers
agree on which one is the winner.

> 2. Also, the upstream Assert Losers have a mechanism
> (orthogonal to (1) above) to convert back to NoInfo
> state and enables data forwarding if its metric
> becomes better than the current Winner.

Which causes an assert exchange and all the routers on the
LAN converge on the same winner.  A good thing.

> (However,
> convergence is slower when the Winner metric gets
> worse because the Loser finds this out only in the
> next Assert Winner message).

If convergence means getting the mpackets via the "best" path, you are
right.  But if your goal is to just get the mpackets without  
interruption,
it isn't important which system is forwarding on to the LAN as long as
one of them is.  (I can't offer an opinion on whether duplicate packets
or lost packets is worse since "it depends")

> Both these mechanisms enable rapid convergence but
> also make it sensitive to the route flaps. Even if (1)
> were absent, say in case of static routes on
> downstreams, (2) still makes it sensitive to
> route-flaps on the upstreams.
>
> After the initial Assert – assuming the (1) is not in
> effect (static routes on downstreams or downstreams
> already converged) – (2) remains in effect only till
> the Join Expiry Timer (ET) on the Assert Loser is
> alive. The question I have is that why do we do away
> with (2) after ET expires? Is it desirable to amend
> this behavior?

Are you forgetting that the assert winner is suppose to
send a new assert 3 seconds before it times out on the
loser?  If it doesn't do this, then it no longer has
forwarding state.  If the old winner isn't forwarding
on to the LAN, who is?

In all likelihood the loser won't get to this point
because it won't have an OIF either.  Having not specifically
tracked this (what I consider rare) case, I could be in error.
But the downstream routers should have converged on the winner
and should be sending joins to the winner.

> Thanks.

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim