Subject: [pim] some questions on draft-ietf-pim-bdr

From: <[email-masked]>
Date: Tue, 15 Mar 2022 10:43:32 +0800 (CST)

Hi authors, 
Thank you for your drafts! I have some questions on draft-ietf-pim-bdr. 
These issues seems like caused by the sticky solution (section 4.2.2) of draft-ietf-pim-bdr itself and can not be solved. 
Could you please make a clarification?

Q1, the election result of the sticky solution is uncertainly
Assuming that there are two devices A and B on the LAN, A has a higher priority. 
Device B first starts to send hello with Pri 0 on the interface, and then device A starts to send hello with Pri 0. 
Device B first reaches 1 hello period. It finds that the Pri of the other device (A) received is 0, so B considers itself to be the DR and sends its own Pri. 
A receives a hello whose Pri is not 0 from B before the end of one hello period of itself, A think B is DR. 
So DR is the device that whoever starts first. 
In the other hand, if the first hello period of A and B arrives at the same time, the two devices simultaneously send a hello which Pri is not 0, and both think that it is the DR and forwards traffic, which will cause duplicate traffic on the LAN. After the Assert process is triggered, a forwarder will be selected finally.
I am not sure it's what the network administrator wants.

Q2, the non-sticky and sticky solutions in draft-ietf-pim-bdr can't work together
Assuming that device A supports the non-sticky scheme and device B supports the sticky scheme, the priority of A is still higher than that of B. 
Assumed that device B starts to send hello with Pri 0 first, and device A starts to send hello with Pri 0 after that. 
After the B device reaches a hello period, it finds that the Pri of other devices (A) received is 0, then B considers itself to be the DR and sends its own Pri. (Until here, it is the same as Q1). 
Before the end of its own hello period, A receives a hello whose Pri is not 0 from B, but because device A supports the non-sticky scheme, device A considers itself to be the DR, A sends its own Pri, and A start to forward traffic after another period; 
Because device B supports the sticky scheme, even if it receives the Pri sent by A, it will not give way to A. 
As a result, A and B send traffic at the same time, and duplicate traffic will not be stopped until the Assert process. 

Q3, non-compatibility with RFC7761
Assuming that there is already device A on the LAN (device A is the standard RFC7761 process), device A is normally forwarding traffic as a DR. 
Device B joins the LAN and B supports the sticky scheme. B has a higher priority than A. 
When device B joins, it first send hello with Pri 0. 
B receives A's hello with Pri not 0 before the end of one hello period, B thinks that A is DR, so it does not intend to replace A, and will not forward traffic. 
B sends hello with own Pri later. When A finds that the priority sent by B is higher, it will stop forwarding the traffic, but B does not forward the traffic also, so neither device forwards the traffic.
This situation is worst because the network will not work until there is any manually adjustment. 

Therefore, it's hard to make the sticky solution without explicit signalling. 
But if my understanding of the solutions aren't correctly, it's great that you can make a clarification.
Thank you!
Best regards,
Sandy