[TIPC] Enabling an already-enabled bearer triggers brief link flap (~243ms down) despite 1000ms tolerance

Hi, 

We are observing brief TIPC link flaps when re-issuing a tipc bearer enable command on a bearer interface that is already enabled and active.
When tipc bearer enable is invoked on an active bearer, the link drops almost immediately (~168ms later) and remains down for 200-250ms before recovering, even though the configured TIPC tolerance is set to 1000ms.

Log:
16:28:50.067  system("tipc bearer enable ...") invoked on eth dev
16:28:50.280  system("tipc bearer enable ...") re-invoked
16:28:50.448  TIPC mgmt link DOWN (168ms after re-enable)
16:28:50.547  system("tipc bearer enable ...") re-invoked
16:28:50.691  TIPC mgmt link UP   (link down duration: 243ms)

Questions:
  1. Behavior: Is re-enabling an already-enabled bearer expected to reset the link?
  2. Tolerance: Why does the link go down for 200ms when tolerance is 1000ms?
  3. API Design: Is there an idempotency option for bearer enable?
  
Thanks,
Srilatha


***  Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***