Hi Peter,
>-Original Message-
>From: Peter Psenak [mailto:ppse...@cisco.com]
>Sent: Monday, February 18, 2019 10:39 AM
>To: Huaimo Chen ; Acee Lindem (acee) ;
>Christian
>Hopps ; 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 ; Acee Lindem (acee)
>>> ; Christian Hopps ; 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 ; Acee Lindem (acee)
; Christian Hopps ; 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
___
