Subject: RE: [pim] RP changes -- Really, this is about RPF changes.

From: "Sundeep Singatwaria" <[email-masked]>
Date: Mon, 29 Oct 2001 16:48:13 -0800

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]]
Sent: Monday, October 29, 2001 12:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] RP changes -- Really, this is about RPF changes.

Jyotheeswara Rao Kurma wrote:
> 
> Hi All :
> 
>    I have a small question regarding events that will happen when RP
> changes for a group G. Assume shared tree is formed, and packets are
> flowing from DR to RP and Rp to receivers down the shared tree. Now RP
> for this group changed.
> 
>                       ----------
>                       |  OLD- RP |
>                       -----------
>                           |
>                           |
>                           |
>                           |
>                       ----------
>                       |  R1     |
>                       ----------
>                           |
>                           |
>                       ----------
>                       |   DR    |
>                       ----------
> 
> 
> DR at the receiver will send prune to towards
> old-rp, and will send it to the RPF'(*,G), what this prune message will
> contain in its source field (i.e source field of (*,G) message ) Is it
> OLD-RP or NEW-RP . The next intermedaite router R1 also
> will send it's own prune towards the old rp. And this router R1 will
> start a prune pending timer after receiveing prune from its down stream
> router.(DR). Now R1's Prune Pending Timer will expire and will do
> what ? Will it send another prune towards old-rp and new rp ? (i.e this
> prune is as a result of receiving prunes for down stream towards old rp
> (i.e noone will override this prune )??? should it forward this again
> towards old-rp ) or it has already sent ignore the prune from the
> downstream routers ?
> 
> Thanks in advance,
> Jyotheesh
> 

My response doesn't directly deal with your question but...

2cents follows:

My experience has shown that sending a PRUNE to the old RPF neighbor is
not an effective method of controlling data delivery.  On its face, it 
appears to be the right choice and I certainly believed it the correct
action for a very long time.

However, this assumption rests on the mistaken belief that a URIB
routing
change is realized atomically by all the routers in a network.  This is
certainly not true.

Consider the following topology:

     [2 source]            [2 source]
        |                       |          
        |                       |
        A                       B
        |                       |
        |                       |          
       -+--+-----------------+--+-         
           |                 |             
           |                 |
           C                 D
           |                 |
           |                 |             
       [2 receiver]      [2 receiver]

At t0 the RPF is via A.
"Something happens" and the RPF changes to B.
C and D will not realize this RPF change at the same time, let's assume
C is first.

Under the current spec, C will send a PRUNE toward A and a JOIN toward
B.
D will see the PRUNE to its RPF neighbor and will send an immediate 
JOIN message to override that prune.

[Sundeep] There is no reason why it should take forever for D not to 
process the routing change but still send an overriding Join. The only
case which I can think of is router D receives a huge number of unicast
route changes but processes only couple of them every delta seconds. In this
case upstream for C and D can be different.

In any case, because it is a multiaccess LAN A will have to wait for
some 
period of time before it actually prunes the interface.  But, remember
the
join that was sent toward B?  There are now two data paths on to the LAN 
resulting in an assert.

[Sundeep] Shouldn't happen.

What did the PRUNE sent from C to A accomplish?  IMHO, nothing. 

[Sundeep] Pruning the path from A. 

Consider a
network that has even more downstream routers.  Consider that the URIB
routing
changes on all of them _may_ be uniformly distributed between the MIN
time
to change and the MAX time to change RPF.  As each of the downstream
routers
recognizes the RPF change, the current spec specifies sending a PRUNE to
the
old RPF neighbor.  Each time this happens, the remaining routers will
send
a JOIN override to that neighbor.  

Now, remember the assert process that _must_ happen on the RPF change? 
What
does the JOIN override do, but reopen an interface that had been pruned
by
an assert process.  There is a huge flurry of control packets exchanged
across
the LAN, with a significant portion of CPU on all the routers devoted to
changing the RPF, all without actually making any difference since, in
the end,
the change is realized by an assert.

It has been suggested that my analysis is in error because I'm assuming
a metric change -- for example on the upstream interface on A, rather
than
a router failure or line cut on the data path through A. (The SPT
through A)
In which case, there would be no data arriving on the path through A and
so no immediate reason to send the PRUNE to A.

[Sundeep] If you are assuming only a metric change for that route than 
there is no reason why C and D should have different upstream. What extra
stuff is D doing that it doesn't have CPU cycles to process the unicast
routing change ??

HOWEVER, this should not be interpreted to mean that there are not cases
where sending a prune to the old RPF neighbor is not a good thing.  Over
p2p links -- especially for hardware that has difficulty dealing with 
data arriving on a non-RPF interface -- such a prune can save BW and may
even keep the network up.

Therefore, I'm planning to lobby for a change to:

  4.4.5.  Sending (*,*,RP) Join/Prune Messages
    MRIB.next_hop(RP) changes

  4.4.6.  Sending (*,G) Join/Prune Messages
    MRIB.next_hop(RP(G)) changes   

  4.4.7.  Sending (S,G) Join/Prune Messages
    MRIB.next_hop(S) changes  

Which states that a PRUNE _MAY_ be sent to the old RPF neighbor.

So, getting back to your question.  I believe the process I outlined
above
fits into a more broadly scoped rule for PIM implementations that can be
summarized by the question: "Which is worse, duplicate packets or no
packets?"
IMHO, the answer is "no packets".

[Sundeep] PPT is 5 seconds. Also assert should happen which will take
take of duplicate packets. 

Sundeep

Therefore I argue for hysteresis when making changes to multicast
forwarding.
Be aggressive in JOINing to the data path (SPT or RPT) but conservative
in
PRUNing the data path.  Duplicate packets on a multiaccess network will 
result in the assert process, more rapidly eliminating the duplicates
than
sending a PRUNE.

If data arrives on two interfaces of a router, that router will only
forward
one of those streams.  So the "thing" the spec is trying to "protect" or
conserve is the wasted BW on that old data path.

Consider that many -- if not most -- URIB changes are routing flaps.  If
you
prune the old data path only to rejoin it 3 to 180 seconds later, have
you
actually "saved" anything?  How far up the tree would the PRUNE
propogate
requiring router CPU to process (I would argue a much more precious
resource
than BW given the structure of today's hardware).

So getting back to your original question, if you are going to send the
PRUNE,
it would have to be with the OLD-RP address.  If it has the new RP
address, 
what does the upstream router "do" with that information since it may
still
have the OLD-RP address and therefore couldn't process the prune.  All
in all
though, I wouldn't recommend sending a PRUNE at all.

However, this presents a problem for (*,G) asserts doesn't it.  :-)
These asserts do not contain the RP address.  Only an RP-bit.
There is also a problem with (S,G,R) messages which do not specify 
"which RP" the message applies to.

FWIW, changing RP addresses is a very infrequent operation.  I'd prefer
ignoring this problem and _assume_ all routers have the same RP
information.

z

---

From: "Jyotheeswara Rao Kurma" <[email-masked]>
Date: Tue, 30 Oct 2001 09:42:45 +0500

> So getting back to your original question, if you are going to 
> send the PRUNE,

   Here you are assuming that upstrm router will still have the OLD-RP
 address, which may not be TRUE always. It might have the NEW RP-SET 
i.e same as the down-strm router. Receiving prune from the down-strm 
routers ensures an up-strm router that down-strm routers are also 
having the same RP-SET (if up-strm router learns the new RP_SET by the 
time it receives prune form down-strm routers, in the other case any 
way it is same as sending a prune to the rp ). I prefer sending a prune 
so that an up-strm router will know that down-strm routers are also  in 
sync wrt to RP-set, (i.e sending old-rp address in the (*,G) prune). So 
I prefer sending prunes from dwn-strm routers and ignoring them at the 
up-strm routers for the old-rp.
Then question comes, if ignoring ?? why sending at all ? It is just for 
making sure that the other guy's RP_SET is same as what I think of.
 
Any comments are welcome ... 

> FWIW, changing RP addresses is a very infrequent operation.  I'd 
> preferignoring this problem and _assume_ all routers have the same RP
> information.

 I agree that this is a very infrequent operation, but since draft 
discusses it explicitly, I want to know that intention, of the actions 
that are specified, and its merits/demerits. 

Thanks,
Jyotheesh