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

From: Saurabh Goel <[email-masked]>
Date: Mon, 3 Jul 2006 23:56:00 -0700 (PDT)

Hi Everyone,

I have a question on the PIM Assert mechanism....

Consider two upstream routers, R1 and R2, on a LAN
both having (*,G) forwarding states. One of the
routers, say R2, with inferior mertic goes to the 'I
am Assert Loser' (L) state. The downsteam routers on
the LAN learn about the Assert Winner and
modify their RPF neighbor information to point to the
Winner. Hence R2 no more reveives any (*,G) joins.
Eventually (depending on the HoldTime advertised in
the last (*,G) Join message on this oif) the Expiry
Timer (ET) on its corresponding asserted oif expires
and transitions to NoInfo (NI). This in turn makes
CouldAssert(*,G,I) False. Now, even if the metric for
reaching RP(G) on R2 becomes better than that on R1,
it never becomes a Winner (CouldAssert(*,G,I) is
False)? Similar behavior would result for other more
complicated Assert wars. Is this the expected bahavior
or is my understanding not correct ? Please comment.

Thanks
saurabh

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: JGSPrasad <[email-masked]>
Date: Tue, 04 Jul 2006 16:42:58 +0530

Hi Saurabh,

Your understanding is correct.

I think assert mechanism is best effort approach for optimal forwarding
but does not guarantee in all cases.

However as an alternate thought, if indeed we need optimal
forwarding :

Assuming all routers are running some dynamic routing protocol we see
that when the metric of R2 becomes better than R1, the downstream
router would also get a route change notification [saying the route to
RP is better
reachable through R2] and its nexthop in the routing table  changes to
R2.

The current RFC does not say anything about RPF(Nbr) change.It
only says,change of RPF'(Nbr) change should trigger a join.So
going by the current draft,since the RPF'(Nbr) does not change
we do not trigger any join.

neighbor RPF'(S,G) {

if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {

return AssertWinner(S, G, RPF_interface(S) )

} else {

return NBR( RPF_interface(S), MRIB.next_hop( S ) )

}

}

But by sending a join to the new RPF(Nbr) we could trigger
an assert and thereby R2 would become the winner and optimal forwarding
would continue.

We can have some new timer like override timer to prevent flooding of
join packets during route change.

However this can work only if we have some dynamic routing protocol
giving the correct metrics and not under static route configuration in
the downstream router.

Its just a thought..Give your comments on the same..

Regards,

Prasad

Saurabh Goel wrote:

Hi Everyone,

Thanks
saurabh

--
SharadaPrasad JG

Senior Software Engineer, Embedded Business Unit

Huawei Technologies India Private Ltd,

Bangalore - 560008

Ph:+918041781770 Extn:1645

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

---

From: John Zwiebel <[email-masked]>
Date: Wed, 5 Jul 2006 12:01:32 -0700

FWIW:

You open a can of worms here and I don't think there is a "right"  
answer.

RPF changes on a LAN are complicated by the fact that the spec says  
to send
a prune to the old RPF neighbor.  However, if you do this and there  
are two or more
downstream neighbors, they will send a JOIN-OVERRIDE guaranteeing there
will be duplicate packets on the network.    Eventually an assert
process chooses the winner and things go on from there.

You might think that the other downstream routers will eventually do  
their unicast
convergence thereby avoiding the assert, and if the data rate is slow  
enough this
will be true.  But even for the rates that ping sends packets, I've  
seen a flurry of
PIM JOIN/PRUNE messages on the LAN and things aren't resolved until  
the ASSERT
happens.

If one is talking about p2p links, one might be tempted to say that  
pruning back the
old RPF immediately is a good thing, so send a prune in that case.   
However, RPF
changes are often route-flaps, so you end up having to trigger a join  
when you flap-back.
Duplicate traffic to a non-RPF interface on a p2p link is a waste of  
BW, but making
the choice to not send a triggered prune to the old RPF neighbor  
because of the
route-flap potential is (I believe) a good trade-off if your concern  
is more about
ensuring data delivery and keeping control traffic to a minimum  
rather than saving
BW (which was being used before with no visible effects so what's the  
hurry in pruning it off?)

in 4.1.3 triggered joins are discussed for (*,G) state.  RPF' is for  
asserts.  That doesn't override
what is said here or in 4.1.4 for (S,G) state

   The last RPF neighbor towards the RP is stored because if the MRIB  
changes then the RPF
   neighbor towards the RP may change. If it does so, then we need to  
trigger a newJoin(*,G) to the
   newupstream neighbor and a Prune(*,G) to the old upstream neighbor.

On Jul 4, 2006, at 4:12 AM, JGSPrasad wrote:

> I think assert mechanism is best effort approach for optimal  
> forwarding but does not guarantee in all cases.
>
> Assuming all routers are running some dynamic routing protocol we  
> see that when the metric of R2 becomes better than R1, the  
> downstream router would also get a route change notification  
> [saying the route to RP is better reachable through R2] and its  
> nexthop in the routing table  changes to R2.
>
> The current RFC does not say anything about RPF(Nbr) change.It only  
> says,change of RPF'(Nbr) change should trigger a join.So going by  
> the current draft,since the RPF'(Nbr) does not change we do not  
> trigger any join.
>
> neighbor RPF'(S,G) {
> But by sending a join to the new RPF(Nbr) we could trigger an  
> assert and thereby R2 would become the winner and optimal  
> forwarding would continue.
>
> We can have some new timer like override timer to prevent flooding  
> of join packets during route change.
>
> giving the correct metrics and not under static route configuration  
> in the downstream router.
>
> This e-mail and attachments contain confidential information from  
> HUAWEI, which is intended only for the person or entity whose  
> address is listed above. Any use of the information contained  
> herein in any way (including, but not limited to, total or partial  
> disclosure, reproduction, or dissemination) by persons other than  
> the intended recipient's) is prohibited. If you receive this e-mail  
> in error, please notify the sender by phone or email immediately  
> and delete it!

---

From: Saurabh Goel <[email-masked]>
Date: Wed, 5 Jul 2006 19:17:36 -0700 (PDT)

I appreciate how avoiding triggered Prunes can help
ensure better data delivery and contain unnecessary
control traffic during route flaps. 

(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:

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.”

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. (However,
convergence is slower when the Winner metric gets
worse because the Loser finds this out only in the
next Assert Winner message). 

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?

Thanks.

> >> or is my understanding not correct ? Please
=== message truncated ===

---

From: John Zwiebel <[email-masked]>
Date: Thu, 6 Jul 2006 10:45:38 -0700

> 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.

>      the prior Assert winner has undergone a topology

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.

> 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,

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")

> with (2) after ET expires? Is it desirable to amend

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.

---

From: Saurabh Goel <[email-masked]>
Date: Fri, 7 Jul 2006 05:50:40 -0700 (PDT)

> prune-the-old-RPF problem)
The downstream routers are always supposed to lose
because
they always compare their own metric (which is
infinite because
CouldAssert() is always false ) with the Upstream
Winners metric.
The Assert mechanism in itself never allows the
downstreams to 
compare the metrices of an 'Upstream Loser' against
the 
Winner.
I guess, the only way it affects Winner election is
'indirectly' when it finds
that its unicast routing indicates a different RPF
than its old RPF (not RPF'
which is the Assert Winner). This makes it send Prune
to the old RPF (probably
redundant wrt data forwarding if the old RPF is
already an assert loser) and
not RPF' and Join to the new RPF. In general, it is
this join to the new
RPF that causes another Assert war. Please correct me.

> forwarding state.  If the old winner isn't

Here I am talking about the Join ET (gets refreshed on
a Join)
and not the Assert Timer (AT) which is refeshed on
losers by an Assert Winner message. 

Assuming RPT Vs RPT case for the sake of specificity, 
Join ET directly affects the marco join (*,G) and AT
on the 
upstream loser affects lost_assert(*,G). 

join(*,G) which depends on ET (which is never refeshed
while the upstream is in the loser state)
determined the outcome
of CouldAssert(*,G, I) irrespective of value of AT. On
the 
upstream loser, if ET expires
CouldAssert(*,G, I) becomes false, and so does
AssTrDes(*,G,I)
which forces it to transition to NOInfo state even
though AT never expired.

This means that we lose mechanism (2) (though (1) is
still
in place) on the upstream loser discussed earlier
within the max value
of ET (which is the Holtime advertised in the Join
message it last
received before losing the Assert). To restate my
question
again, do we do this on purpose and if yes what are
the reasons? or we just chose to live with it to avoid
complexity ? I could see that this behavior may be
good enough if the route-flaps stabilize within ET
interval.

BTW, the avoiding prune-the-old-RPF in this case (not
all cases)
can actually cause us to lose the opportunity to
refresh the
ET on the 'going-to-be-loser' when a downstream 
triggers an Assert by sending Join to the
'going-to-be-winner'
and Prune to the going-to-be-loser. The Prune override
to 
going-to-be-loser actually refreshes the ET just
before assert
ensues giving mechanism (2) the max time.