Hi Peter,

>-----Original Message-----
>From: Peter Psenak [mailto:ppse...@cisco.com] 
>Sent: Monday, February 18, 2019 10:39 AM
>To: Huaimo Chen <huaimo.c...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; 
>Christian 
>Hopps <cho...@chopps.org>; lsr@ietf.org
>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:ppse...@cisco.com]
>>> Sent: Thursday, February 14, 2019 2:30 AM
>>> To: Huaimo Chen <huaimo.c...@huawei.com>; Acee Lindem (acee) 
>>> <a...@cisco.com>; Christian Hopps <cho...@chopps.org>; lsr@ietf.org
>>> 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:ppse...@cisco.com]
>>>> Sent: Wednesday, February 6, 2019 4:58 AM
>>>> To: Huaimo Chen <huaimo.c...@huawei.com>; Acee Lindem (acee) 
>>>> <a...@cisco.com>; Christian Hopps <cho...@chopps.org>; lsr@ietf.org
>>>> 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

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to