Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen <[e-mail]>]

Hi Peter,

>-----Original Message-----
>From: Peter Psenak [mailto:[e-mail]] 
>Sent: Monday, February 18, 2019 10:39 AM
>To: Huaimo Chen <[e-mail]>; Acee Lindem (acee) <[e-mail]>; Christian 
>Hopps <[e-mail]>; [e-mail]
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>Hi Huaimo,
>
>On 18/02/2019 16:28 , Huaimo Chen wrote:
>> Hi Peter,
>>
>>> -----Original Message-----
>>> From: Peter Psenak [mailto:[e-mail]]
>>> Sent: Thursday, February 14, 2019 2:30 AM
>>> To: Huaimo Chen <[e-mail]>; Acee Lindem (acee) 
>>> <[e-mail]>; Christian Hopps <[e-mail]>; [e-mail]
>>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
>>> Redux]
>>>
>>> Hi Huaimo,
>>>
>>> On 13/02/2019 22:50 , Huaimo Chen wrote:
>>>> Hi Peter,
>>>>
>>>>     My explanations/answers are in line below with prefix [HC].
>>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:[e-mail]]
>>>> Sent: Wednesday, February 6, 2019 4:58 AM
>>>> To: Huaimo Chen <[e-mail]>; Acee Lindem (acee) 
>>>> <[e-mail]>; Christian Hopps <[e-mail]>; [e-mail]
>>>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
>>>> Redux]
>>>>
>>>> Hi Huaimo,
>>>>
>>>> On 03/02/2019 17:58 , Huaimo Chen wrote:
>>>>> Hi Acee,
>>>>>
>>>>>
>>>>>
>>>>>     I agree with you on keeping the signaling for two modes. The 
>>>>> other parts for the distributed solution need to be removed.
>>>
>>> optimized flooding is not only about algorithm to calculate the 
>>> flooding topology and the way it is distributed/computed. It is also about local rules to make sure the flooding remains consistent.
>>> These are _independent_ of centralized/distributed modes. And it make 
>>> no sense to specify these rules in two drafts.
>>
>> [HC] The rules/procedures/behaviors that are common to both the 
>> centralized and distributed solution/mode should be in one document. These common parts will be used by both solutions/modes.
>> They are described in the two drafts and should be merged based on technical merits.
>>
>> In addition to the common parts, there are still some 
>> rules/procedures/behaviors that are different from one mode to another 
>> mode. For example, the rule/procedure for fault tolerance to failures 
>> used in the centralized solution/mode will be different from that used in the distributed solution/mode.

>I don't think there is any significant difference needed. And I believe these local rules for both 
>modes should reside in a single document as most of them are applicable to both modes.

The way in which the flooding topology converges in the centralized mode/solution is different from 
that in the distributed mode/solution. In the former, after receiving the link states for the failures,
the leader computes a new flooding topology and floods it to every other node, which receives
and installs the new flooding topology. The working load on every non leader node is light. It has more 
processing power for a procedure/method for fault tolerance to failures.
However, in the latter, every node computes and installs a new flooding topology after receiving 
the link states for the failures. It has less processing power for a procedure/method for fault tolerance.
It is better to let each of the two modes use its own procedure/method for fault tolerance to failures,
which is more appropriate to it.

>> In the distributed solution/mode, there will be a set of 
>> rules/procedures/behaviors that are common to the algorithms for 
>> computing flooding topology and specific to the distributed 
>> solution/mode. For example, a specific procedure for scheduling an algorithm to compute a flooding topology will be used on every node for the distributed solution/mode.

>scheduling a distributed versus centralized computation is not something that makes the 
>behavior different. Sure, you can put a scheduling details for a particular algorithm in the 
>document that describes the distributed algorithm itself.

In the centralized solution/mode, scheduling an algorithm to compute flooding topology happens 
only on the leader, and then on the backup leader after the leader fails. The parameters for 
scheduling on the leader may be different from those for scheduling on the backup leader. 
However, in the distributed solution/mode, scheduling an algorithm to compute flooding topology
occurs on every node. The parameters for scheduling on all the nodes need to be the same. 
The procedure for achieving this is specific to the distributed mode/solution.

If every particular algorithm for computing flooding topology in the distributed solution/mode
describes a procedure for scheduling in details itself, there will be duplicated descriptions of 
the same procedure in multiple algorithms, one of which is selected to compute flooding
topology on every node. It is better for the same scheduling procedure for multiple algorithms 
to be described in one document.  

Best Regards,
Huaimo

>thanks,
>Peter