Subject: Re: Alternative bidir PIM proposal

From: [email-masked] (Billy Ng)
Date: Sun, 24 Oct 1999 23:38:18 -0400

Some comments to your draft (since I will not be able to make the next
IETF):

....

   When a router receives a Join message addressed to it for a bidir
   group G with rendezvous point RP, it must determine if it is the DF
   on the link for this group.  To do this it consults (*,G) state or
   the RP election information if no (*,G) state exists.  If the router
   is not the DF, it must ignore the Join message.  If it is the DF,
   then the following steps are taken:

In the unidirectional case, a join is sent toward the RPF neighbor.  With
this new bidir case, what if the targetted RPF neighbor is not the DF?
or are you saying this should never happen so the upstream always accepts
the downstream join if it is the DF on the lan?

....

3.2.1 Source-only Branches

   Source-only branches of the distribution tree for a group are
   branches which do not lead to any receivers, but which are used to
   forward packets traveling upstream from sources towards the RP.
   Routers along source-only branches do not have an olist for the group
   and hence do not need to maintain (*,G) state. Upstream forwarding
   can be performed using (*,*,RP) state.  An implementation may decide

doesn't (*,*,RP) pulls down all other sources back to the source only tree?
can you explain in more detail on how this state is created?

A scenario with source sending should be given.  I am still not clear
when the (*,*,RP) state should be created.

....

4.2.6 Winner Dies

   Whenever the DF dies, a new DF has to be elected. The speed at which
   this can be achieved depends on whether there are any downstream
   routers on the link.

   If there are downstream routers, then typically their RPF neighbor
   reported by the unicast routing protocol will be the DF. They will
   therefore notice a change in RPF neighbor away from the DF.  They
   will then restart the election by transmitting Offer messages.  If
   the RP is now reachable through the link via another upstream router,
   then they will use an infinite metric in the Offer.

   If no downstream routers are present then the only way for other
   upstream routers to detect a DF failure is by the timeout of the PIM
   neighbor information, which will take significantly longer.

since there are periodic winner message from the DF, other neighbor
could time out on this message which could be made shorter than the
PIM hello timeout.

....

4.3.2 Message Summary

   The election uses the following control messages:

        Offer (OfferingID, Metric)
            Sent by routers that believe they have a better metric to
            the RP than the metric that has been on offer so far.

        Winner (DF-ID, DF-Metric)
            Sent by a router when assuming the role of the DF or when
            re-asserting in response to worse offers.

        Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric,
                 BackoffInterval)
            Used by the DF to acknowledge better offers. It instructs
            other routers with equal or worse offers to wait till the DF
            passes responsibility to the sender of the offer.

        Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric)
            Used by the old DF to pass forwarding responsibility to a
            router that has previously made an offer.  The Old-DF-Metric
            is the current metric of the DF at the time the pass is
            sent.

it would be nice to draw a flow diagram of the above transitions.

Thanks,

--Billy

---

From: Isidor Kouvelas <[email-masked]>
Date: Sun, 24 Oct 1999 22:40:48 -0700

>Some comments to your draft (since I will not be able to make the next

Thanks for the comments. Reply is inline.

>the downstream join if it is the DF on the lan?

Right this shouldn't happen. Even if it did, a non DF router will ignore the
Join and optionally the DF can intercept it and send a Winner message.

>when the (*,*,RP) state should be created.

In case no "downstream" routers have joined for a particular source, there
will be no olist and hence (*,G) state at a DF. If data packets for that
source are received that need to be forwarded upstream, then the DF can 
create (*,G) state to do the upstream forwarding.

         RP
         |
         Rtr-A
         |DF
        --------------
         |        |
       Src1      Src2

In the example above, if src1 sends to group G1 and src2 sends to group G2,
then router A can create (*,G1) and (*,G2) state to forward packets upstream
to the RP. As both (*,G1) and (*,G2) will have a NULL olist, creating them is
not necessary and (*,*,RP) state can be created instead to forward both
groups. The (*,*,RP) state will also have a NULL olist and hence no Join will
be generated upstream and it will not pull any traffic from the RP.

>could time out on this message which could be made shorter than the

There are no periodic winner messages. We have tried to avoid constant control
traffic.

>it would be nice to draw a flow diagram of the above transitions.

Will work on one.

thanks
Isidor