Subject: [pim] RP changes

From: "Jyotheeswara Rao Kurma" <[email-masked]>
Date: Mon, 29 Oct 2001 18:52:21 +0500

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 

--------------------------------------------------------------------
Every moment is a golden one for him who has the vision to recognize it 
as such. 
-- Henry Miller

---

From: John Zwiebel <[email-masked]>
Date: Mon, 29 Oct 2001 12:45:51 -0800

> flowing from DR to RP and Rp to receivers down the shared tree. Now RP

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.

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.

What did the PRUNE sent from C to A accomplish?  IMHO, nothing. 
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.

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

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