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

[Saurabh Goel <getsaurabhgoel at yahoo.com>]

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.


--- John Zwiebel <jzwiebel at cisco.com> wrote:

> 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:
> 
> > 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,
> >>
> >> 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
> >> pim at ietf.org
> >> https://www1.ietf.org/mailman/listinfo/pim
> >>
> >>
> >
> >
> > -- 
> > SharadaPrasad JG
> >
> > Senior Software Engineer, Embedded Business Unit
> >
> > Huawei Technologies India Private Ltd,
> >
> > Bangalore - 560008
> >
> 
=== message truncated ===


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

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