Subject: [pim] Some comments on draft-ietf-pim-dr-improvement

From: Stig Venaas <[email-masked]>
Date: Fri, 18 Mar 2016 09:10:49 -0700

Hi

Hoping to get some good WG discussion on the list on this interesting
topic, so please chime in on this thread.

As was brought up in the last meeting, people often configure a
specific router to be the preferred DR on a LAN. It would be good that
when the router with the highest configured DR priority goes away and
comes back, that it eventually becomes the DR again. This happens
today, the problem though is that it often causes disruption because
it doesn't have the appropriate state when becoming DR again. One way
of doing this with the existing DR priority would be to use say DR
priority 0 at first. Then after a while when all receivers should be
known (and perhaps also joining upstream to receive multicast, but not
forward onto the LAN yet) start announcing the configured priority,
and forward the streams. It is hard doing this with no disruption
though, and there may be asserts happening, in which case the new DR
may not necessarily become the forwarder. Hence you might need a way
for the new DR to not forward until the previous DR stopped
forwarding. In some deployments it might be more important to avoid
disruption and no need to reelect DR when a router comes up.

Instead of introducing new Hello options I'm wondering if one simply
could use the existing DR priority where the router with the next
highest priority (the route that would be the DR if it wasn't for the
existing DR) can be BDR. But there are some difficulties as I wrote
above.

Generally, the case when a new router should become DR is harder than
existing DR going away. That is, when existing DR goes away there may
be a little bit of loss until say BFD on BDR detects it, but to have
no loss or duplication when a new DR gets elected is hard. If a small
amount of duplication is OK, then one could rely on asserts. Otherwise
you may need some extra signaling, there is always a chance of packet
loss from when the previous DR stops forwarding until the new DR
starts forwarding. Maybe using asserts and a small amount of
duplication is best?

Stig

---

From: [email-masked]
Date: Mon, 21 Mar 2016 10:45:01 +0800

Hi Stig,

    Thank for your comments. 

    At first I clarify the recovery function in existed 
pim-dr-improvement draft. The DR/BDR function is same as the 
definition in OSPF. If DR fails, BDR is incharge of all the flows
forwarding.
    If we want DR to go back again, we can configure the highest 
priority in DR at first, and express that we want the DR goes back 
again through recovery configuration. When DR recovers, DR sends 
the highest priority hello packet which the DR is set to itself. 
After BDR and other routers receives the hello packet, they elect 
the old DR as DR again according to the algorithm. 
    In case we do not want the recovery of DR, we may not configure 
the highest priority and the recovery configuration. When DR comes 
back, it will send the hello packet with null DR and null BDR the 
same as other new comers. Then the BDR(now DR) will not be influenced.

    Use the priority is interesting, but I think it may be ambiguous.
For example, there are three potential router in the network: R1 with 
priority 1, R2 with priority 2, R3 with priority 3. The DR should be 
R3.
    According to your priority function, in the initial period of 
network, the three routers send hello packets with priority 0 at first. 
After receive the packets, the three routers will all think that 
itself is DR. And they may all join the upstream routers but not 
forward flows. After a moment( the period is hard to define.), they 
all forward flows and announce that itself as DR. Then the network 
oscillates, after a period, the R3 is elected DR, the three routers 
make concensus and withdraw superfluous joins.
    If a new comer with higher priority comes in, there are many 
new joins due to the DR changing. In case some new router is forced to 
be DR, we can archive the goal through the DR/BDR function with the 
highest priority and convery configuration. Though DR/BDR function 
seems like that it make a change to existed hello packet format and 
DR election funtion, it seems be more stable, is it?
    Thanks a lot.

Best Regards,
Sandy