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

2019-03-04 Thread Les Ginsberg (ginsberg)
Huaimo –

Some responses inline.

From: Lsr  On Behalf Of Huaimo Chen
Sent: Monday, March 04, 2019 8:16 PM
To: Tony Li 
Cc: lsr@ietf.org; Christian Hopps ; Acee Lindem (acee) 

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

Hi Tony,

>From: Tony Li [mailto:tony1ath...@gmail.com]
>Sent: Thursday, February 21, 2019 12:32 AM
>To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
>Cc: Peter Psenak mailto:ppse...@cisco.com>>; Acee Lindem 
>(acee) mailto:a...@cisco.com>>; Christian Hopps 
>>mailto:cho...@chopps.org>>; 
>lsr@ietf.org<mailto:lsr@ietf.org>
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>
>Hi Huaimo,
>
>>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.
>
>It’s true that a distributed solution will call more on an average node than a 
>centralized
>solution will. However, that is not the steady state for either. In the
>steady state, the flooding topology has been computed and has been put in 
>place already.
>Thus, the impact of the topology computation at the time of the
>topology change is nil.
>
>In addition, the amount of work to temporarily amend the flooding topology 
>should also
>be minimal, and by that, I mean O(log n).  The decision should only
>be whether or not to temporarily add a link to flooding, and the only 
>information that a node
>needs to do that is to determine if the node is already on the
>flooding topology. That should be a lookup in a tree that represents the nodes 
>on the topology,
>and that lookup should be O(log n). In other words, it’s fast
>and efficient and not a significant drain on resources.
>

When multiple failures happen, the current flooding topology changes, the 
procedure for fault tolerance to failures is triggered to run, and a new 
flooding topology is to be computed. We need to have a converged flooding 
topology as soon as possible.
In the distributed solution/mode, if a procedure for fault tolerance, which is 
not appropriate to it, is used, then we will have a converged flooding topology 
in a longer time.
For example, after multiple failures occur, one procedure (in rough idea) for 
fault tolerance includes: 1) determine whether the current flooding topology 
splits, 2) compute backup paths to connect the split flooding topology, 3) 
enable/request the temporary flooding on the backup paths through extensions to 
Hello protocol. We can see that this procedure for fault tolerance takes a 
longer time than the algorithm computes a new flooding topology. This procedure 
will delay the convergence of flooding topology, which is not appropriate to 
the distributed solution/mode.
So it is better for the distributed solution/mode to use a procedure for fault 
tolerance, which is more appropriate to it.

[Les:] Given that you do not define what you think we should do I cannot 
comment on whatever alternative you might have in mind.

I can say that your discussion does not acknowledge that BEFORE I can compute a 
new flooding topology I have to make sure I know what the updated full network 
topology is. This is what is compromised when the old flooding topology becomes 
partitioned. So the first priority has to be acquiring the updated topology.

It would be useful if you replied to the thread that Tony started earlier today 
where he asks for input on how best to use temporary additions to the flooding 
topology.

One extreme (my words – not Tony’s) would be to enable flooding on all links. 
This clearly risks introducing a destabilizing flooding storm.

The other extreme would be to enable temporary flooding on a “minimal set of 
links”. This clearly risks delaying convergence.

If this topic interests you, please reply to Tony’s new thread (“Open issues 
with Dynamic Flooding”).

>>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

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

2019-03-04 Thread Huaimo Chen
Hi Tony,

>From: Tony Li [mailto:tony1ath...@gmail.com]
>Sent: Thursday, February 21, 2019 12:32 AM
>To: Huaimo Chen 
>Cc: Peter Psenak ; Acee Lindem (acee) ; 
>Christian Hopps >; lsr@ietf.org
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>
>Hi Huaimo,
>
>>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.
>
>It’s true that a distributed solution will call more on an average node than a 
>centralized
>solution will. However, that is not the steady state for either. In the
>steady state, the flooding topology has been computed and has been put in 
>place already.
>Thus, the impact of the topology computation at the time of the
>topology change is nil.
>
>In addition, the amount of work to temporarily amend the flooding topology 
>should also
>be minimal, and by that, I mean O(log n).  The decision should only
>be whether or not to temporarily add a link to flooding, and the only 
>information that a node
>needs to do that is to determine if the node is already on the
>flooding topology. That should be a lookup in a tree that represents the nodes 
>on the topology,
>and that lookup should be O(log n). In other words, it’s fast
>and efficient and not a significant drain on resources.
>

When multiple failures happen, the current flooding topology changes, the 
procedure for fault tolerance to failures is triggered to run, and a new 
flooding topology is to be computed. We need to have a converged flooding 
topology as soon as possible.
In the distributed solution/mode, if a procedure for fault tolerance, which is 
not appropriate to it, is used, then we will have a converged flooding topology 
in a longer time.
For example, after multiple failures occur, one procedure (in rough idea) for 
fault tolerance includes: 1) determine whether the current flooding topology 
splits, 2) compute backup paths to connect the split flooding topology, 3) 
enable/request the temporary flooding on the backup paths through extensions to 
Hello protocol. We can see that this procedure for fault tolerance takes a 
longer time than the algorithm computes a new flooding topology. This procedure 
will delay the convergence of flooding topology, which is not appropriate to 
the distributed solution/mode.
So it is better for the distributed solution/mode to use a procedure for fault 
tolerance, which is more appropriate to it.

>>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.
>
>
>Actually, that’s not true.  An implementation is free to do its own internal 
>scheduling
>however it chooses, regardless of whether it implements a
>distributed or centralized implementation.
>
>
>>The procedure for achieving this is specific to the distributed mode/solution.
>
>More accurately, it is specific to a given implementation.
>
>
>>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.
>
>
>Actually, since the IETF should not be specifying the details of scheduling as 
>it is an
>implementation detail, as they do not affect the behavior of the protocol, it 
>should not be
>d

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

2019-02-20 Thread Tony Li

Hi Huaimo,


> 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.


It’s true that a distributed solution will call more on an average node than a 
centralized solution will. However, that is not the steady state for either. In 
the 
steady state, the flooding topology has been computed and has been put in place 
already. Thus, the impact of the topology computation at the time of the 
topology change is nil. 

In addition, the amount of work to temporarily amend the flooding topology 
should also be minimal, and by that, I mean O(log n).  The decision should only
be whether or not to temporarily add a link to flooding, and the only 
information that a node needs to do that is to determine if the node is already 
on the
flooding topology. That should be a lookup in a tree that represents the nodes 
on the topology, and that lookup should be O(log n). In other words, it’s fast
and efficient and not a significant drain on resources.


> 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. 


Actually, that’s not true.  An implementation is free to do its own internal 
scheduling however it chooses, regardless of whether it implements a
distributed or centralized implementation.


> The procedure for achieving this is specific to the distributed mode/solution.


More accurately, it is specific to a given implementation.


> 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.  


Actually, since the IETF should not be specifying the details of scheduling as 
it is an implementation detail, as they do not affect the behavior of the 
protocol, it should not be
discussed in any documents.

Regards,
Tony

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


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

2019-02-20 Thread Huaimo Chen
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. T

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

2019-02-18 Thread Peter Psenak

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.



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.


thanks,
Peter







There are no "other" parts specific for the distributed solution.

[HC] Some behaviors for the distributed solution/mode are described in 
draft-li-dynamic-flooding.
For example, there are a few of places from page 27 to 30, which define the 
behaviors specific
for the distributed solution/mode.


I strongly disagree. The fact that we say in centralized mode area leader 
recomputes and in distributed
mode all nodes recompute make no difference in behavior.


[HC] It seems better for some of them to be more general.

Best Regards,
Huaimo


thanks,
Peter

.



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


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

2019-02-18 Thread Huaimo Chen
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.  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.

>>
>> There are no "other" parts specific for the distributed solution.
>>
>> [HC] Some behaviors for the distributed solution/mode are described in 
>> draft-li-dynamic-flooding. 
>>For example, there are a few of places from page 27 to 30, which define the 
>>behaviors specific 
>>for the distributed solution/mode.
>
>I strongly disagree. The fact that we say in centralized mode area leader 
>recomputes and in distributed 
>mode all nodes recompute make no difference in behavior.

[HC] It seems better for some of them to be more general. 

Best Regards,
Huaimo

>thanks,
>Peter

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


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

2019-02-15 Thread Acee Lindem (acee)
I want to make sure I'm not misinterpreted here, I'm not asking for a new draft 
specifying these behaviors. I view these as flooding-algorithm-independent 
generic behaviors. If there is something wrong or missing from this basic set, 
they can be fixed via normal WG discussion and update. For a specific 
centralized of distributed flooding algorithm, these behaviors could be 
potentially be augmented with backward compatible enhancements. 

Thanks,
Acee

On 2/14/19, 6:00 PM, "Acee Lindem (acee)"  wrote:

Speaking as a WG member, 

I just re-read section 6.7 and all the actions for distributed computation 
are pretty much intuitive corollaries for the actions for the centralized 
solution. I see no real reason to remove these. However, there is nothing to 
prevent improvements to be proposed in an alternate draft. 

Thanks,
Acee

On 2/14/19, 8:58 AM, "John E Drake"  wrote:

Hi,

I completely agree with Peter.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> 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.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described 
in draft-
> li-dynamic-flooding. For example, there are a few of places from page 
27 to 30,
> which define the behaviors specific for the distributed solution/mode.
> 
> I strongly disagree. The fact that we say in centralized mode area 
leader
> recomputes and in distributed mode all nodes recompute make no 
difference in
> behavior.
> 
> thanks,
> Peter
> 
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2. 
distribution of the
> flooding-topology, which is specific to centralized mode 3. common 
behavior of
> the nodes that support the extension, which is independent of the 
mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines 
more,
> including concrete protections, operations, and algorithms for 
computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
> > thanks,
> > Peter
        > >
    > >
    > >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
    > >>
    > >> Hi Huaimo,
    > >>
> >>
> >>
   

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

2019-02-14 Thread Acee Lindem (acee)
Speaking as a WG member, 

I just re-read section 6.7 and all the actions for distributed computation are 
pretty much intuitive corollaries for the actions for the centralized solution. 
I see no real reason to remove these. However, there is nothing to prevent 
improvements to be proposed in an alternate draft. 

Thanks,
Acee

On 2/14/19, 8:58 AM, "John E Drake"  wrote:

Hi,

I completely agree with Peter.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> 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.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described in 
draft-
> li-dynamic-flooding. For example, there are a few of places from page 27 
to 30,
> which define the behaviors specific for the distributed solution/mode.
> 
> I strongly disagree. The fact that we say in centralized mode area leader
> recomputes and in distributed mode all nodes recompute make no difference 
in
> behavior.
> 
> thanks,
> Peter
> 
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2. distribution 
of the
> flooding-topology, which is specific to centralized mode 3. common 
behavior of
> the nodes that support the extension, which is independent of the mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more,
> including concrete protections, operations, and algorithms for computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
    > > thanks,
    > > Peter
    > >
    > >
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
    > >> Redux]
    > >>
> >>
> >>
> >> Hi Huaimo,
> >>
> >>
> >>
> >> See inline.
> >>
> >>
> >>
> >> *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> >> behalf of Huaimo Chen  >> <mailto:huaimo.c...@huawei.com>>
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "lsr@ietf.org <mailto:lsr@ietf.org>"  >> <mailto:lsr@ietf.org>>
> >> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Everyone,
> >>
> >>
> >>
> >> We proposed the distributed solution first, and Tony proposed the
> >> centralized solution first. Tony added the distributed solution
> >> (except for the algori

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

2019-02-14 Thread John E Drake
Hi,

I completely agree with Peter.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> 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.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described in 
> > draft-
> li-dynamic-flooding. For example, there are a few of places from page 27 to 
> 30,
> which define the behaviors specific for the distributed solution/mode.
> 
> I strongly disagree. The fact that we say in centralized mode area leader
> recomputes and in distributed mode all nodes recompute make no difference in
> behavior.
> 
> thanks,
> Peter
> 
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2. distribution of 
> > the
> flooding-topology, which is specific to centralized mode 3. common behavior of
> the nodes that support the extension, which is independent of the mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more,
> including concrete protections, operations, and algorithms for computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
> > thanks,
> > Peter
> >
> >
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Huaimo,
> >>
> >>
> >>
> >> See inline.
> >>
> >>
> >>
> >> *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> >> behalf of Huaimo Chen  >> <mailto:huaimo.c...@huawei.com>>
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "lsr@ietf.org <mailto:lsr@ietf.org>"  >> <mailto:lsr@ietf.org>>
> >> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Everyone,
> >>
> >>
> >>
> >> We proposed the distributed solution first, and Tony proposed the
> >> centralized solution first. Tony added the distributed solution
> >> (except for the algorithms to compute flooding topology) into his
> >> draft. And then we added the centralized solution into our draft. The
> >> latest versions of the two drafts have largely converged at least at
> >> the high level to a solution for solving the same problem.
> >>
> >>
> >>
> >> Our draft has multiple key technical advantages over Tony's draft as
> >> we described in our email to the LSR list, which are summarized below:
> >>
> >> 1.   It uses a fraction of flooding resource (i.e., it is multiple
> >> times more efficient in flooding topology encoding);
> >>
> >> 2.   It provides fault tolerance to multiple failures, minimizing
> >> impact on network convergence, thus minimizing traffic lose

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

2019-02-13 Thread Peter Psenak

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.


There are no "other" parts specific for the distributed solution.

[HC] Some behaviors for the distributed solution/mode are described in 
draft-li-dynamic-flooding. For example, there are a few of places from page 27 
to 30, which define the behaviors specific for the distributed solution/mode.


I strongly disagree. The fact that we say in centralized mode area 
leader recomputes and in distributed mode all nodes recompute make no 
difference in behavior.


thanks,
Peter



draft-li-dyanmic-flooding defines:

1. the signalling that is common and used by both modes 2. distribution of the 
flooding-topology, which is specific to centralized mode 3. common behavior of 
the nodes that support the extension, which is independent of the mode of 
operation.

[HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, 
including concrete protections, operations, and algorithms for computing a 
flooding topology.

Best Regards,
Huaimo

thanks,
Peter






Best Regards,

Huaimo

*From:* Acee Lindem (acee) [mailto:a...@cisco.com]
*Sent:* Sunday, February 3, 2019 11:45 AM
*To:* Huaimo Chen ; Christian Hopps
; lsr@ietf.org
*Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
Redux]



Hi Huaimo,



See inline.



*From: *Lsr mailto:lsr-boun...@ietf.org>> on
behalf of Huaimo Chen mailto:huaimo.c...@huawei.com>>
*Date: *Saturday, February 2, 2019 at 12:27 AM
*To: *Christian Hopps mailto:cho...@chopps.org>>,
"lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
Redux]



Hi Everyone,



We proposed the distributed solution first, and Tony proposed the
centralized solution first. Tony added the distributed solution
(except for the algorithms to compute flooding topology) into his
draft. And then we added the centralized solution into our draft. The
latest versions of the two drafts have largely converged at least at
the high level to a solution for solving the same problem.



Our draft has multiple key technical advantages over Tony's draft as
we described in our email to the LSR list, which are summarized below:

1.   It uses a fraction of flooding resource (i.e., it is multiple
times more efficient in flooding topology encoding);

2.   It provides fault tolerance to multiple failures, minimizing
impact on network convergence, thus minimizing traffic lose; and

3.   It is simpler and needs less processing time (i.e., faster and
more efficient) in multiple scenarios.

Based on the technical merits, our draft should be moved forward.
However, Chair proposed to move Tony's draft forward and have us work
on a distributed algorithm as we started with.



I think that the distributed solution in Tony's draft needs to be
removed and they work on the centralized solution. We remove the
centralized solution from our draft and work on the distributed solution.



I'm against "cutting the baby in half" given that the signaling for
the distributed solution is a proper subset of what is required for
the centralized solution. It is undesirable to have different
signaling for the two modes. For the distributed algorithm you are
proposing, do see problems with the signaling?



Thanks,

Acee



Best Regards,

Huaimo



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Friday, February 1, 2019 7:26 AM

To: lsr@ietf.org <mailto:lsr@ietf.org>

Cc: cho...@chopps.org <mailto:cho...@chopps.org>

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





Summary of where we are at with dynamic flooding reduction:



- We have a well written original work that came first and described
the problems as well as a TLVs to allow for a centralized solution
(draft-li-dyanmic-flooding). We do not need to standardize the
centralized algorithm.



- A small change to this work allowed for distributed algorithms and
for outside work on distributed algorithms to continue in parallel.



- We have another original work that 

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

2019-02-13 Thread Huaimo Chen
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.

There are no "other" parts specific for the distributed solution.

[HC] Some behaviors for the distributed solution/mode are described in 
draft-li-dynamic-flooding. For example, there are a few of places from page 27 
to 30, which define the behaviors specific for the distributed solution/mode.

draft-li-dyanmic-flooding defines:

1. the signalling that is common and used by both modes 2. distribution of the 
flooding-topology, which is specific to centralized mode 3. common behavior of 
the nodes that support the extension, which is independent of the mode of 
operation.

[HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, 
including concrete protections, operations, and algorithms for computing a 
flooding topology.

Best Regards,
Huaimo

thanks,
Peter


>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Sunday, February 3, 2019 11:45 AM
> *To:* Huaimo Chen ; Christian Hopps 
> ; lsr@ietf.org
> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
> Redux]
>
>
>
> Hi Huaimo,
>
>
>
> See inline.
>
>
>
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Huaimo Chen  <mailto:huaimo.c...@huawei.com>>
> *Date: *Saturday, February 2, 2019 at 12:27 AM
> *To: *Christian Hopps mailto:cho...@chopps.org>>, 
> "lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
> Redux]
>
>
>
> Hi Everyone,
>
>
>
> We proposed the distributed solution first, and Tony proposed the 
> centralized solution first. Tony added the distributed solution 
> (except for the algorithms to compute flooding topology) into his 
> draft. And then we added the centralized solution into our draft. The 
> latest versions of the two drafts have largely converged at least at 
> the high level to a solution for solving the same problem.
>
>
>
> Our draft has multiple key technical advantages over Tony's draft as 
> we described in our email to the LSR list, which are summarized below:
>
> 1.   It uses a fraction of flooding resource (i.e., it is multiple
> times more efficient in flooding topology encoding);
>
> 2.   It provides fault tolerance to multiple failures, minimizing
> impact on network convergence, thus minimizing traffic lose; and
>
> 3.   It is simpler and needs less processing time (i.e., faster and
> more efficient) in multiple scenarios.
>
> Based on the technical merits, our draft should be moved forward.
> However, Chair proposed to move Tony's draft forward and have us work 
> on a distributed algorithm as we started with.
>
>
>
> I think that the distributed solution in Tony's draft needs to be 
> removed and they work on the centralized solution. We remove the 
> centralized solution from our draft and work on the distributed solution.
>
>
>
> I'm against "cutting the baby in half" given that the signaling for 
> the distributed solution is a proper subset of what is required for 
> the centralized solution. It is undesirable to have different 
> signaling for the two modes. For the distributed algorithm you are 
> proposing, do see problems with the signaling?
>
>
>
> Thanks,
>
> Acee
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> -Original Message-
>
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
>
> Sent: Friday, February 1, 2019 7:26 AM
>
> To: lsr@ietf.org <mailto:lsr@ietf.org>
>
> Cc: cho...@chopps.org <mailto:cho...@chopps.org>
>
> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>
>
>
>
> Summary of where we are at with dynamic flooding reduction:
>
>
>
> - We have a well written original work that came first and described 
> the problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-flooding). We do not need to standardize the 
> centralized algorithm.
>
>
>
> - A small change to this work allowed for distributed algorithms and 
> for outside work on distributed algorithms to continue in parallel.

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

2019-02-06 Thread Robert Raszuk
Hi Peter,

Many thx for your comment.

What I had in mind here was use of multi instance (=2) over very reach
physical topologies. So when we construct flooding graph for each such
instance - even in centralized mode - the intention was to avoid flooding
to take common links (just to reduce the impact of any failure to have
effect on both instances). Yes of course data paths are different from
flooding graph so I was just talking about the latter.

I know that perhaps this should be moved to a different thread - the only
reason why I mentioned about it here was that it is not immediately obvious
to me if extensions which we have today defined in draft-li will be
sufficient. Perhaps for centralized indeed they would be just fine as
central graph compute oracle could be smart enough to address it. For
distributed I am not sure.

I did not want to derail the main topic though so let's shift it for other
chat.

Kind regards,
Robert.

primary/backup topologies are used for transmitting user data, not
> necessarily the flooding data. I don't see how they are related to the
> flooding topology, which is used for flooding only.
>
> To the point, if a new distributed algorithm is defined that needs more
> data to be signaled, then we will extend the existing signaling. I don't
> see that being a problem. The way the signaling is defined in
> draft-li-lsr-dynamic-flooding does allow for such thing.
>
> thanks,
> Peter
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-02-06 Thread Peter Psenak

Hi Robert,

On 03/02/2019 21:37 , Robert Raszuk wrote:


I fully agree and support proceeding with  draft-li-dyanmic-flooding and
to include protocol extensions in it for centralized topology
propagation as well as basic hooks like "execute dynamic protocol number
X" for distributed calculations.

However one may observe that separate distributed algorithms may define
their own protocol extensions and they should not break the above in any
way.

Then there is already some requirements of building two disjoined
topologies in any rich ECMP DC fabric one say for primary paths the
other for backup flows. (Case of active-active dual streaming
applications). Question arises if this would be addressed also as part
of basic spec, be combined with one or many of distributed algorithms or
will require yet one more document which in turn will "extend" all of
the above ?


primary/backup topologies are used for transmitting user data, not 
necessarily the flooding data. I don't see how they are related to the 
flooding topology, which is used for flooding only.


To the point, if a new distributed algorithm is defined that needs more 
data to be signaled, then we will extend the existing signaling. I don't 
see that being a problem. The way the signaling is defined in 
draft-li-lsr-dynamic-flooding does allow for such thing.


thanks,
Peter


And before anyone suggests multi instance approach with
logical or physical link separation it is not the right direction here.
If anything perhaps MTR or SR come a bit closer.

Kind regards,
Robert.


On Sun, Feb 3, 2019 at 9:14 PM mailto:tony...@tony.li>> wrote:


I think that this discussion would be greatly clarified if we
clearly separated the discussion between

a) the algorithm for computing the flooding topology, and
b) the signaling to indicate how to proceed.

I think that we are all in agreement that the algorithms can and
should be separated from the signaling.

I think that we are all in agreement that each algorithm should be
independent.

I’m of the opinion that the centralized signaling is a bit more
extensive than the signaling for the distributed mode, but that
there is also considerable overlap and that things would
be unnecessarily redundant if we were to separate them. I believe
that we are not in disagreement about the basics for the distributed
signaling.

If you disagree with this, please clearly articulate why you feel
the signaling should be separated.

Regards,
Tony



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



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


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

2019-02-06 Thread Peter Psenak

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.


There are no "other" parts specific for the distributed solution.
draft-li-dyanmic-flooding defines:

1. the signalling that is common and used by both modes
2. distribution of the flooding-topology, which is specific to 
centralized mode
3. common behavior of the nodes that support the extension, which is 
independent of the mode of operation.



thanks,
Peter






Best Regards,

Huaimo

*From:* Acee Lindem (acee) [mailto:a...@cisco.com]
*Sent:* Sunday, February 3, 2019 11:45 AM
*To:* Huaimo Chen ; Christian Hopps
; lsr@ietf.org
*Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]



Hi Huaimo,



See inline.



*From: *Lsr mailto:lsr-boun...@ietf.org>> on
behalf of Huaimo Chen mailto:huaimo.c...@huawei.com>>
*Date: *Saturday, February 2, 2019 at 12:27 AM
*To: *Christian Hopps mailto:cho...@chopps.org>>,
"lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
*Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]



Hi Everyone,



We proposed the distributed solution first, and Tony proposed the
centralized solution first. Tony added the distributed solution (except
for the algorithms to compute flooding topology) into his draft. And
then we added the centralized solution into our draft. The latest
versions of the two drafts have largely converged at least at the high
level to a solution for solving the same problem.



Our draft has multiple key technical advantages over Tony’s draft as we
described in our email to the LSR list, which are summarized below:

1.   It uses a fraction of flooding resource (i.e., it is multiple
times more efficient in flooding topology encoding);

2.   It provides fault tolerance to multiple failures, minimizing
impact on network convergence, thus minimizing traffic lose; and

3.   It is simpler and needs less processing time (i.e., faster and
more efficient) in multiple scenarios.

Based on the technical merits, our draft should be moved forward.
However, Chair proposed to move Tony’s draft forward and have us work on
a distributed algorithm as we started with.



I think that the distributed solution in Tony’s draft needs to be
removed and they work on the centralized solution. We remove the
centralized solution from our draft and work on the distributed solution.



I’m against “cutting the baby in half” given that the signaling for the
distributed solution is a proper subset of what is required for the
centralized solution. It is undesirable to have different signaling for
the two modes. For the distributed algorithm you are proposing, do see
problems with the signaling?



Thanks,

Acee



Best Regards,

Huaimo



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Friday, February 1, 2019 7:26 AM

To: lsr@ietf.org <mailto:lsr@ietf.org>

Cc: cho...@chopps.org <mailto:cho...@chopps.org>

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





Summary of where we are at with dynamic flooding reduction:



- We have a well written original work that came first and described the
problems as well as a TLVs to allow for a centralized solution
(draft-li-dyanmic-flooding). We do not need to standardize the
centralized algorithm.



- A small change to this work allowed for distributed algorithms and for
outside work on distributed algorithms to continue in parallel.



- We have another original work that started primarily as a distributed
algorithm

   (draft-cc-ospf-flooding-reduction)



- Finally we also have:

   - Cross-pollination of ideas.

   - Failed attempts at merging.

   - An authors list "Arms-Race".



Moving forward:



- During IETF 103 I proposed we have no conflict if we:



   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.

   2) have authors of draft-cc-lsr-flooding-reduction work on a
distributed algorithm as they started with.



- Acee agreed during the meeting (as chair) that this was the best way
forward. We had some agreement form the floor as well..



- Any good ideas regarding the distribution of a centralized topology
can be debated and added (with appropriate attribution) to the base
document after we adopt one.



- This is what happens when we adopt a document as WG work, we work on it.



- The original authors of the distributed solution can continue to work
on their distributed algorithm in a separate document which would also
need standardization.



Does anyone see a serious problem with this path forward?



Thanks,

Chris & Acee.

LSR Chairs.



Christian Hopps mailto:cho...@chopps.org>> writes:




We've had the authors of the individual conflicting drafts take a shot

at merging their work.






   This has failed.



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

2019-02-04 Thread Acee Lindem (acee)
I agree totally with Chris on these points. Furthermore, the choices that 
operators will have are with the flooding algorithms. We need work on the 
generalized signaling in order to allow the algorithm work to proceed. 

Thanks,
Acee 

On 2/4/19, 8:21 AM, "Lsr on behalf of Christian Hopps"  wrote:


Aijun Wang  writes:

> Hi, Christian:
>
> Based on your information, it is more fair to adopt these two drafts as 
WG documents at the same time. The reasons are the followings:
> 1. The centralized and distributed modes don’t conflict with each other. 
Anyone can contribute their thoughts on them at their interests.

No we do not adopt 2 documents solving the same relatively simple problem 
(signaling, primarily for centralized mode), we adopt one and incorporate any 
improvements needed, this isn't that hard a problem and we certainly don't need 
multiple solutions.

Work on algorithms *is* a hard problem and can and should continue to be 
done in parallel with no conflict.

> 2. They are both aiming to solve the same problem, which can give the 
operators more choices once they have been standardized.

There's literally *no* reason to do this. We need to do our jobs as a WG 
and produce a single standard for signaling.

> 3. The technique disputes between these two drafts are undergoing on the 
mailing list. If they are not well solved, we still need to discuss them after 
the adoption. It’s too hurry to make the adoption conclusion at current time.

We've had a *YEAR* of multiple author documents, we're not hurrying at all, 
it's time to move forward.

Thanks,
Chris.

>
> Aijun Wang
> China Telecom
>
>> 在 2019年2月1日,20:25,Christian Hopps  写道:
>>
>>
>> Summary of where we are at with dynamic flooding reduction:
>>
>> - We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.
>>
>> - A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.
>>
>> - We have another original work that started primarily as a distributed 
algorithm
>>  (draft-cc-ospf-flooding-reduction)
>>
>> - Finally we also have:
>>  - Cross-pollination of ideas.
>>  - Failed attempts at merging.
>>  - An authors list "Arms-Race".
>>
>> Moving forward:
>>
>> - During IETF 103 I proposed we have no conflict if we:
>>
>>  1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>>  2) have authors of draft-cc-lsr-flooding-reduction work on a 
distributed algorithm as they started with.
>>
>> - Acee agreed during the meeting (as chair) that this was the best way 
forward. We had some agreement form the floor as well.
>>
>> - Any good ideas regarding the distribution of a centralized topology 
can be debated and added (with appropriate attribution) to the base document 
after we adopt one.
>>
>> - This is what happens when we adopt a document as WG work, we work on 
it.
>>
>> - The original authors of the distributed solution can continue to work 
on their distributed algorithm in a separate document which would also need 
standardization.
>>
>> Does anyone see a serious problem with this path forward?
>>
>> Thanks,
>> Chris & Acee.
>> LSR Chairs.
>>
>> Christian Hopps  writes:
>>
>>> We've had the authors of the individual conflicting drafts take a shot 
at merging their work.
>>>
>>>   This has failed.
>>>
>>> Here is the full history (which I also summarized during IETF103 as 
well). I will send a second email discussing this.
>>>
>>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
drfat-li-dynamic-flooding-isis
>>>  published centralized solution.
>>>
>>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
draft-cc-ospf-flooding-reduction
>>>  published distributed solution.
>>>  - mention of centralized solution asserting it is not good choice.
>>>
>>> - IETF 101 (Mar 2018)
>>>  - Video: 
https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>>  - Minutes: 
https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
>>>  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
>>>- Generally well received.
>>>  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
>>>- Serious problems immediately found during presentation -- not 
fully baked.
>>>
>>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
>>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
>>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
>>> - 

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

2019-02-04 Thread Christian Hopps


Aijun Wang  writes:


Hi, Christian:

Based on your information, it is more fair to adopt these two drafts as WG 
documents at the same time. The reasons are the followings:
1. The centralized and distributed modes don’t conflict with each other. Anyone 
can contribute their thoughts on them at their interests.


No we do not adopt 2 documents solving the same relatively simple problem 
(signaling, primarily for centralized mode), we adopt one and incorporate any 
improvements needed, this isn't that hard a problem and we certainly don't need 
multiple solutions.

Work on algorithms *is* a hard problem and can and should continue to be done 
in parallel with no conflict.


2. They are both aiming to solve the same problem, which can give the operators 
more choices once they have been standardized.


There's literally *no* reason to do this. We need to do our jobs as a WG and 
produce a single standard for signaling.


3. The technique disputes between these two drafts are undergoing on the 
mailing list. If they are not well solved, we still need to discuss them after 
the adoption. It’s too hurry to make the adoption conclusion at current time.


We've had a *YEAR* of multiple author documents, we're not hurrying at all, 
it's time to move forward.

Thanks,
Chris.



Aijun Wang
China Telecom


在 2019年2月1日,20:25,Christian Hopps  写道:


Summary of where we are at with dynamic flooding reduction:

- We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.

- A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.

- We have another original work that started primarily as a distributed 
algorithm
 (draft-cc-ospf-flooding-reduction)

- Finally we also have:
 - Cross-pollination of ideas.
 - Failed attempts at merging.
 - An authors list "Arms-Race".

Moving forward:

- During IETF 103 I proposed we have no conflict if we:

 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.

- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well.

- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.

- This is what happens when we adopt a document as WG work, we work on it.

- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.

Does anyone see a serious problem with this path forward?

Thanks,
Chris & Acee.
LSR Chairs.

Christian Hopps  writes:


We've had the authors of the individual conflicting drafts take a shot at 
merging their work.

  This has failed.

Here is the full history (which I also summarized during IETF103 as well). I 
will send a second email discussing this.

- Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
drfat-li-dynamic-flooding-isis
 published centralized solution.

- Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
draft-cc-ospf-flooding-reduction
 published distributed solution.
 - mention of centralized solution asserting it is not good choice.

- IETF 101 (Mar 2018)
 - Video: 
https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
 - Minutes: 
https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
 - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
   - Generally well received.
 - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
   - Serious problems immediately found during presentation -- not fully baked.

- Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
- Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
- Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
- Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
 - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
 - Does not specify distributed algorithm only how to indicate one in use, 
small change.

- Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published

- IETF 102 (Jul 14, 2018)
 - draft-li-dynamic-flooding-05 presented.
 - draft-cc-ospf-flooding-reduction-02 presented.

- Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
 - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.

- Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)

- Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)

- IETF 103 (Nov 3, 2018)

 - Chairs give direction

   - draft-li-lsr-dynamic-flooding-05 having come first, being well written and 
not
 specifying a distributed algorithm (merely allowing for one) is the 
correct vehicle
 to adopt as 

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

2019-02-03 Thread Les Ginsberg (ginsberg)
Robert –

Let’s please not introduce issues which are not relevant. ☺

Any flooding optimization solution only applies to a single LSDB – and the set 
of nodes/links which support flooding of that LSDB. This means (in IS-IS speak):


· Level-1 is distinct from Level-2. I could choose to apply flooding 
optimizations to one level and not the other if I wished. Or use a different 
algorithm/level

· One MI instance is distinct from another

· MT is not relevant since all the MT specific advertisements for all 
supported topologies are contained within a single LSDB (I.e., we do not 
support MT specific flooding)

HTH

   Les


From: Lsr  On Behalf Of Robert Raszuk
Sent: Sunday, February 03, 2019 12:37 PM
To: Tony Li 
Cc: Huaimo Chen ; cho...@chopps.org; David Allan I 
; li_zhenqi...@hotmail.com; lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


I fully agree and support proceeding with  draft-li-dyanmic-flooding and to 
include protocol extensions in it for centralized topology propagation as well 
as basic hooks like "execute dynamic protocol number X" for distributed 
calculations.

However one may observe that separate distributed algorithms may define their 
own protocol extensions and they should not break the above in any way.

Then there is already some requirements of building two disjoined topologies in 
any rich ECMP DC fabric one say for primary paths the other for backup flows. 
(Case of active-active dual streaming applications). Question arises if this 
would be addressed also as part of basic spec, be combined with one or many of 
distributed algorithms or will require yet one more document which in turn will 
"extend" all of the above ? And before anyone suggests multi instance approach 
with logical or physical link separation it is not the right direction here. If 
anything perhaps MTR or SR come a bit closer.

Kind regards,
Robert.


On Sun, Feb 3, 2019 at 9:14 PM mailto:tony...@tony.li>> wrote:

I think that this discussion would be greatly clarified if we clearly separated 
the discussion between

a) the algorithm for computing the flooding topology, and
b) the signaling to indicate how to proceed.

I think that we are all in agreement that the algorithms can and should be 
separated from the signaling.

I think that we are all in agreement that each algorithm should be independent.

I’m of the opinion that the centralized signaling is a bit more extensive than 
the signaling for the distributed mode, but that there is also considerable 
overlap and that things would
be unnecessarily redundant if we were to separate them. I believe that we are 
not in disagreement about the basics for the distributed signaling.

If you disagree with this, please clearly articulate why you feel the signaling 
should be separated.

Regards,
Tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-02-03 Thread David Allan I
Makes sense to me, thanks for the clarity...

Dave

-Original Message-
From: Tony Li  On Behalf Of tony...@tony.li
Sent: Sunday, February 3, 2019 12:14 PM
To: Robert Raszuk 
Cc: Huaimo Chen ; lsr@ietf.org; cho...@chopps.org; 
li_zhenqi...@hotmail.com; David Allan I 
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


I think that this discussion would be greatly clarified if we clearly separated 
the discussion between

a) the algorithm for computing the flooding topology, and
b) the signaling to indicate how to proceed.

I think that we are all in agreement that the algorithms can and should be 
separated from the signaling.

I think that we are all in agreement that each algorithm should be independent.

I’m of the opinion that the centralized signaling is a bit more extensive than 
the signaling for the distributed mode, but that there is also considerable 
overlap and that things would be unnecessarily redundant if we were to separate 
them. I believe that we are not in disagreement about the basics for the 
distributed signaling.

If you disagree with this, please clearly articulate why you feel the signaling 
should be separated.

Regards,
Tony

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


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

2019-02-03 Thread Robert Raszuk
I fully agree and support proceeding with  draft-li-dyanmic-flooding and to
include protocol extensions in it for centralized topology propagation as
well as basic hooks like "execute dynamic protocol number X" for
distributed calculations.

However one may observe that separate distributed algorithms may define
their own protocol extensions and they should not break the above in any
way.

Then there is already some requirements of building two disjoined
topologies in any rich ECMP DC fabric one say for primary paths the other
for backup flows. (Case of active-active dual streaming applications).
Question arises if this would be addressed also as part of basic spec, be
combined with one or many of distributed algorithms or will require yet one
more document which in turn will "extend" all of the above ? And before
anyone suggests multi instance approach with logical or physical link
separation it is not the right direction here. If anything perhaps MTR or
SR come a bit closer.

Kind regards,
Robert.


On Sun, Feb 3, 2019 at 9:14 PM  wrote:

>
> I think that this discussion would be greatly clarified if we clearly
> separated the discussion between
>
> a) the algorithm for computing the flooding topology, and
> b) the signaling to indicate how to proceed.
>
> I think that we are all in agreement that the algorithms can and should be
> separated from the signaling.
>
> I think that we are all in agreement that each algorithm should be
> independent.
>
> I’m of the opinion that the centralized signaling is a bit more extensive
> than the signaling for the distributed mode, but that there is also
> considerable overlap and that things would
> be unnecessarily redundant if we were to separate them. I believe that we
> are not in disagreement about the basics for the distributed signaling.
>
> If you disagree with this, please clearly articulate why you feel the
> signaling should be separated.
>
> Regards,
> Tony
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-02-03 Thread tony . li

I think that this discussion would be greatly clarified if we clearly separated 
the discussion between 

a) the algorithm for computing the flooding topology, and
b) the signaling to indicate how to proceed.

I think that we are all in agreement that the algorithms can and should be 
separated from the signaling.

I think that we are all in agreement that each algorithm should be independent.

I’m of the opinion that the centralized signaling is a bit more extensive than 
the signaling for the distributed mode, but that there is also considerable 
overlap and that things would
be unnecessarily redundant if we were to separate them. I believe that we are 
not in disagreement about the basics for the distributed signaling.

If you disagree with this, please clearly articulate why you feel the signaling 
should be separated.

Regards,
Tony

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


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

2019-02-03 Thread Robert Raszuk
> The former will have all the good parts for the centralized solution, and
the latter will have all the good parts for the distributed solution.

And in your view which draft should contain required protocol extensions to
accommodate both solutions ?

Or are you suggesting that we should have completely different protocol
extensions for distribution of centralized computed graphs vs for
propagating parameters allowing customized distributed computation of
partial flooding topology ?

Thx,
R.


On Sun, Feb 3, 2019 at 5:44 PM Huaimo Chen  wrote:

> Hi Dave,
>
>
>
> There are two drafts containing the centralized solution and distributed
> solution already on the table too. If the two drafts are adopted, they need
> to be updated for one draft to focus on the centralized solution and the
> other on the distributed solution. The former will have all the good parts
> for the centralized solution, and the latter will have all the good parts
> for the distributed solution.
>
>
>
> Best Regards,
>
> Huaimo
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2019-02-03 Thread Huaimo Chen
Hi Acee,

I agree with you on keeping the signaling for two modes. The other parts 
for the distributed solution need to be removed.

Best Regards,
Huaimo
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Sunday, February 3, 2019 11:45 AM
To: Huaimo Chen ; Christian Hopps ; 
lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

See inline.

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Huaimo Chen mailto:huaimo.c...@huawei.com>>
Date: Saturday, February 2, 2019 at 12:27 AM
To: Christian Hopps mailto:cho...@chopps.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


Hi Everyone,



We proposed the distributed solution first, and Tony proposed the centralized 
solution first. Tony added the distributed solution (except for the algorithms 
to compute flooding topology) into his draft. And then we added the centralized 
solution into our draft. The latest versions of the two drafts have largely 
converged at least at the high level to a solution for solving the same problem.



Our draft has multiple key technical advantages over Tony’s draft as we 
described in our email to the LSR list, which are summarized below:

1.   It uses a fraction of flooding resource (i.e., it is multiple times 
more efficient in flooding topology encoding);

2.   It provides fault tolerance to multiple failures, minimizing impact on 
network convergence, thus minimizing traffic lose; and

3.   It is simpler and needs less processing time (i.e., faster and more 
efficient) in multiple scenarios.

Based on the technical merits, our draft should be moved forward. However, 
Chair proposed to move Tony’s draft forward and have us work on a distributed 
algorithm as we started with.



I think that the distributed solution in Tony’s draft needs to be removed and 
they work on the centralized solution. We remove the centralized solution from 
our draft and work on the distributed solution.



I’m against “cutting the baby in half” given that the signaling for the 
distributed solution is a proper subset of what is required for the centralized 
solution. It is undesirable to have different signaling for the two modes. For 
the distributed algorithm you are proposing, do see problems with the signaling?



Thanks,

Acee



Best Regards,

Huaimo



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Friday, February 1, 2019 7:26 AM

To: lsr@ietf.org<mailto:lsr@ietf.org>

Cc: cho...@chopps.org<mailto:cho...@chopps.org>

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





Summary of where we are at with dynamic flooding reduction:



- We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.



- A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.



- We have another original work that started primarily as a distributed 
algorithm

   (draft-cc-ospf-flooding-reduction)



- Finally we also have:

   - Cross-pollination of ideas.

   - Failed attempts at merging.

   - An authors list "Arms-Race".



Moving forward:



- During IETF 103 I proposed we have no conflict if we:



   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.

   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.



- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well..



- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.



- This is what happens when we adopt a document as WG work, we work on it.



- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.



Does anyone see a serious problem with this path forward?



Thanks,

Chris & Acee.

LSR Chairs.



Christian Hopps mailto:cho...@chopps.org>> writes:



> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.

>

>This has failed.

>

> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.

>

> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis

>   published centralized solution.

>

> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction

>   published dis

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

2019-02-03 Thread Huaimo Chen
Hi Dave,

There are two drafts containing the centralized solution and distributed 
solution already on the table too. If the two drafts are adopted, they need to 
be updated for one draft to focus on the centralized solution and the other on 
the distributed solution. The former will have all the good parts for the 
centralized solution, and the latter will have all the good parts for the 
distributed solution.

Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of David Allan I
Sent: Sunday, February 3, 2019 10:32 AM
To: li_zhenqi...@hotmail.com; rob...@raszuk.net; cho...@chopps.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

With all respect,  there are other distributed solutions on the table…

Cheers
Dave

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of li 
zhenqiang
Sent: Sunday, February 3, 2019 1:28 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>; Christian 
Hopps mailto:cho...@chopps.org>>
Cc: lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hello all,

At current situation, I think we'd better move both the two drafts foward in 
parallel keeping draft-li-dyanmic-flooding focus on  the centralized solution 
and  draft-cc-ospf-flooding-reduction on the distributed solution. Thanks.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Robert Raszuk<mailto:rob...@raszuk.net>
Date: 2019-02-02 20:20
To: Christian Hopps<mailto:cho...@chopps.org>
CC: lsr<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Sound like best plan fwd.

Thx,
R.

On Fri, Feb 1, 2019, 13:26 Christian Hopps 
mailto:cho...@chopps.org> wrote:

Summary of where we are at with dynamic flooding reduction:

 - We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.

 - A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.

 - We have another original work that started primarily as a distributed 
algorithm
   (draft-cc-ospf-flooding-reduction)

 - Finally we also have:
   - Cross-pollination of ideas.
   - Failed attempts at merging.
   - An authors list "Arms-Race".

Moving forward:

- During IETF 103 I proposed we have no conflict if we:

   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document..
   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.

- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well.

- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.

- This is what happens when we adopt a document as WG work, we work on it.

- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.

Does anyone see a serious problem with this path forward?

Thanks,
Chris & Acee.
LSR Chairs.

Christian Hopps mailto:cho...@chopps.org>> writes:

> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.
>
>This has failed.
>
> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.
>
> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis
>   published centralized solution.
>
> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction
>   published distributed solution.
>   - mention of centralized solution asserting it is not good choice.
>
> - IETF 101 (Mar 2018)
>   - Video: 
> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>   - Minutes: 
> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
>   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
> - Generally well received.
>   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
> - Serious problems immediately found during presentation -- not fully 
> baked.
>
> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>   - Does not specify distributed algorithm only 

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

2019-02-03 Thread Acee Lindem (acee)
Hi Huaimo,

See inline.

From: Lsr  on behalf of Huaimo Chen 

Date: Saturday, February 2, 2019 at 12:27 AM
To: Christian Hopps , "lsr@ietf.org" 
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


Hi Everyone,



We proposed the distributed solution first, and Tony proposed the centralized 
solution first. Tony added the distributed solution (except for the algorithms 
to compute flooding topology) into his draft. And then we added the centralized 
solution into our draft. The latest versions of the two drafts have largely 
converged at least at the high level to a solution for solving the same problem.



Our draft has multiple key technical advantages over Tony’s draft as we 
described in our email to the LSR list, which are summarized below:

1.   It uses a fraction of flooding resource (i.e., it is multiple times 
more efficient in flooding topology encoding);

2.   It provides fault tolerance to multiple failures, minimizing impact on 
network convergence, thus minimizing traffic lose; and

3.   It is simpler and needs less processing time (i.e., faster and more 
efficient) in multiple scenarios.

Based on the technical merits, our draft should be moved forward. However, 
Chair proposed to move Tony’s draft forward and have us work on a distributed 
algorithm as we started with.



I think that the distributed solution in Tony’s draft needs to be removed and 
they work on the centralized solution. We remove the centralized solution from 
our draft and work on the distributed solution.



I’m against “cutting the baby in half” given that the signaling for the 
distributed solution is a proper subset of what is required for the centralized 
solution. It is undesirable to have different signaling for the two modes. For 
the distributed algorithm you are proposing, do see problems with the signaling?



Thanks,

Acee



Best Regards,

Huaimo



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Friday, February 1, 2019 7:26 AM

To: lsr@ietf.org

Cc: cho...@chopps.org

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





Summary of where we are at with dynamic flooding reduction:



- We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.



- A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.



- We have another original work that started primarily as a distributed 
algorithm

   (draft-cc-ospf-flooding-reduction)



- Finally we also have:

   - Cross-pollination of ideas.

   - Failed attempts at merging.

   - An authors list "Arms-Race".



Moving forward:



- During IETF 103 I proposed we have no conflict if we:



   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.

   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.



- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well..



- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.



- This is what happens when we adopt a document as WG work, we work on it.



- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.



Does anyone see a serious problem with this path forward?



Thanks,

Chris & Acee.

LSR Chairs.



Christian Hopps  writes:



> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.

>

>This has failed.

>

> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.

>

> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis

>   published centralized solution.

>

> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction

>   published distributed solution.

>   - mention of centralized solution asserting it is not good choice.

>

> - IETF 101 (Mar 2018)

>   - Video: 
> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS

>   - Minutes: 
> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00

>   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101

> - Generally well received.

>   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.

> - Serious problems immediately found during presentation -- not fully 
> baked.

>

> - Mar 18, 2018 draft

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

2019-02-03 Thread Abdussalam Baryun
On Sat, Feb 2, 2019 at 11:06 AM Aijun Wang 
wrote:

> Hi, Christian:
>
> Based on your information, it is more fair to adopt these two drafts as WG
> documents at the same time. The reasons are the followings:
> 1. The centralized and distributed modes don’t conflict with each other.
> Anyone can contribute their thoughts on them at their interests.
>

I am not interested in two modes only if it is proved that they don't
conflict, I think two modes can cause problems.


> 2. They are both aiming to solve the same problem, which can give the
> operators more choices once they have been standardized.
>

I am interested to adopt different works/drafts, not similar solving same
problem within same WG, we need to work as a team and separate work. We can
make two drafts merged into one, but IMHO having many authors working on
two similar work is not good practice/process or not good adoption.

3. The technique disputes between these two drafts are undergoing on the
> mailing list. If they are not well solved, we still need to discuss them
> after the adoption. It’s too hurry to make the adoption conclusion at
> current time.
>

Why we adopt if they are not well solved into one draft, having two not
solved is worst than having only one, even in discussions in IETF, it is
very very difficult to discuss with authors of an adopted draft, it is
easier to discuss and change non adopted drafts. If I was  IETF WG chair I
will delay adoptions until we get authors to update their work and making
things clear to be well solved before WG adoptions.

> 在 2019年2月1日,20:25,Christian Hopps  写道:
>
>
> Summary of where we are at with dynamic flooding reduction:
>
> - We have a well written original work that came first and described the
problems as well as a TLVs to allow for a centralized solution
(draft-li-dyanmic-flooding). We do not need to standardize the centralized
algorithm.
>
> - A small change to this work allowed for distributed algorithms and for
outside work on distributed algorithms to continue in parallel.
>
> - We have another original work that started primarily as a distributed
algorithm
>  (draft-cc-ospf-flooding-reduction)


> >
> > - Finally we also have:
> >  - Cross-pollination of ideas.
> >  - Failed attempts at merging.
> >  - An authors list "Arms-Race".
> >
> > Moving forward:
> >
> > - During IETF 103 I proposed we have no conflict if we:
> >
> >  1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
> >  2) have authors of draft-cc-lsr-flooding-reduction work on a
> distributed algorithm as they started with.
> >
> > - Acee agreed during the meeting (as chair) that this was the best way
> forward. We had some agreement form the floor as well.
> >
> > - Any good ideas regarding the distribution of a centralized topology
> can be debated and added (with appropriate attribution) to the base
> document after we adopt one.
>

This can create big debates and many discussions after adoption. Best way
to discuss with-saving times is between authors and WG before adoptions
especially when we have many similar solution-drafts
..

> >
> > - This is what happens when we adopt a document as WG work, we work on
> it.
> >
> > - The original authors of the distributed solution can continue to work
> on their distributed algorithm in a separate document which would also need
> standardization.
> >
> > Does anyone see a serious problem with this path forward?
>

I think it is problem if we adopt without clear discussed-objectives of
each draft/author-team under investigation.

AB

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


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

2019-02-02 Thread Aijun Wang
Hi, Christian:

Based on your information, it is more fair to adopt these two drafts as WG 
documents at the same time. The reasons are the followings:
1. The centralized and distributed modes don’t conflict with each other. Anyone 
can contribute their thoughts on them at their interests.
2. They are both aiming to solve the same problem, which can give the operators 
more choices once they have been standardized.
3. The technique disputes between these two drafts are undergoing on the 
mailing list. If they are not well solved, we still need to discuss them after 
the adoption. It’s too hurry to make the adoption conclusion at current time.


Aijun Wang
China Telecom

> 在 2019年2月1日,20:25,Christian Hopps  写道:
> 
> 
> Summary of where we are at with dynamic flooding reduction:
> 
> - We have a well written original work that came first and described the 
> problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-flooding). We do not need to standardize the centralized 
> algorithm.
> 
> - A small change to this work allowed for distributed algorithms and for 
> outside work on distributed algorithms to continue in parallel.
> 
> - We have another original work that started primarily as a distributed 
> algorithm
>  (draft-cc-ospf-flooding-reduction)
> 
> - Finally we also have:
>  - Cross-pollination of ideas.
>  - Failed attempts at merging.
>  - An authors list "Arms-Race".
> 
> Moving forward:
> 
> - During IETF 103 I proposed we have no conflict if we:
> 
>  1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>  2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
> algorithm as they started with.
> 
> - Acee agreed during the meeting (as chair) that this was the best way 
> forward. We had some agreement form the floor as well.
> 
> - Any good ideas regarding the distribution of a centralized topology can be 
> debated and added (with appropriate attribution) to the base document after 
> we adopt one.
> 
> - This is what happens when we adopt a document as WG work, we work on it.
> 
> - The original authors of the distributed solution can continue to work on 
> their distributed algorithm in a separate document which would also need 
> standardization.
> 
> Does anyone see a serious problem with this path forward?
> 
> Thanks,
> Chris & Acee.
> LSR Chairs.
> 
> Christian Hopps  writes:
> 
>> We've had the authors of the individual conflicting drafts take a shot at 
>> merging their work.
>> 
>>   This has failed.
>> 
>> Here is the full history (which I also summarized during IETF103 as well). I 
>> will send a second email discussing this.
>> 
>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
>> drfat-li-dynamic-flooding-isis
>>  published centralized solution.
>> 
>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
>> draft-cc-ospf-flooding-reduction
>>  published distributed solution.
>>  - mention of centralized solution asserting it is not good choice.
>> 
>> - IETF 101 (Mar 2018)
>>  - Video: 
>> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>  - Minutes: 
>> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
>>  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
>>- Generally well received.
>>  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
>>- Serious problems immediately found during presentation -- not fully 
>> baked.
>> 
>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>>  - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>>  - Does not specify distributed algorithm only how to indicate one in use, 
>> small change.
>> 
>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
>> 
>> - IETF 102 (Jul 14, 2018)
>>  - draft-li-dynamic-flooding-05 presented.
>>  - draft-cc-ospf-flooding-reduction-02 presented.
>> 
>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
>>  - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
>> 
>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
>> 
>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
>> 
>> - IETF 103 (Nov 3, 2018)
>> 
>>  - Chairs give direction
>> 
>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written 
>> and not
>>  specifying a distributed algorithm (merely allowing for one) is the 
>> correct vehicle
>>  to adopt as a base document.
>> 
>>- Distributed algorithm work (the original basis for 
>> draft-cc-ospf-flooding-reduction)
>>  should continue as a separate document form the base which would thus 
>> we have no
>>  conflicts.
>> 
>> - In the meantime the authors try and merge work, this fails.
>> 
>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)

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

2019-02-01 Thread Jeff Tantsura
In favor!

Regards,
Jeff

> On Feb 1, 2019, at 08:02, Les Ginsberg (ginsberg)  wrote:
> 
> I am in favor of this proposal.
> 
>   Les
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Friday, February 01, 2019 4:26 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org
>> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>> 
>> 
>> Summary of where we are at with dynamic flooding reduction:
>> 
>> - We have a well written original work that came first and described the
>> problems as well as a TLVs to allow for a centralized solution (draft-li-
>> dyanmic-flooding). We do not need to standardize the centralized algorithm.
>> 
>> - A small change to this work allowed for distributed algorithms and for
>> outside work on distributed algorithms to continue in parallel.
>> 
>> - We have another original work that started primarily as a distributed
>> algorithm
>>   (draft-cc-ospf-flooding-reduction)
>> 
>> - Finally we also have:
>>   - Cross-pollination of ideas.
>>   - Failed attempts at merging.
>>   - An authors list "Arms-Race".
>> 
>> Moving forward:
>> 
>> - During IETF 103 I proposed we have no conflict if we:
>> 
>>   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>>   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
>> algorithm as they started with.
>> 
>> - Acee agreed during the meeting (as chair) that this was the best way
>> forward. We had some agreement form the floor as well.
>> 
>> - Any good ideas regarding the distribution of a centralized topology can be
>> debated and added (with appropriate attribution) to the base document
>> after we adopt one.
>> 
>> - This is what happens when we adopt a document as WG work, we work on
>> it.
>> 
>> - The original authors of the distributed solution can continue to work on
>> their distributed algorithm in a separate document which would also need
>> standardization.
>> 
>> Does anyone see a serious problem with this path forward?
>> 
>> Thanks,
>> Chris & Acee.
>> LSR Chairs.
>> 
>> Christian Hopps  writes:
>> 
>>> We've had the authors of the individual conflicting drafts take a shot at
>> merging their work.
>>> 
>>>   This has failed.
>>> 
>>> Here is the full history (which I also summarized during IETF103 as well). I
>> will send a second email discussing this.
>>> 
>>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-
>> flooding-isis
>>>  published centralized solution.
>>> 
>>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
>>> draft-cc-ospf-
>> flooding-reduction
>>>  published distributed solution.
>>>  - mention of centralized solution asserting it is not good choice.
>>> 
>>> - IETF 101 (Mar 2018)
>>>  - Video:
>> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-
>> 6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>>  - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-
>> 101-lsr-00
>>>  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
>>>- Generally well received.
>>>  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
>>>- Serious problems immediately found during presentation -- not fully
>> baked.
>>> 
>>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
>>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
>>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
>>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>>>  - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>>>  - Does not specify distributed algorithm only how to indicate one in use,
>> small change.
>>> 
>>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
>>> 
>>> - IETF 102 (Jul 14, 2018)
>>>  - draft-li-dynamic-flooding-05 presented.
>>>  - draft-cc-ospf-flooding-reduction-02 presented.
>>> 
>>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
>>>  - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
>>> 
>>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
>>> 
>>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
>>> 
>>> - IETF 103 (Nov 3, 2018)
>>> 
>>>  - Chairs give direction
>>> 
>>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written
>> and not
>>>  specifying a distributed algorithm (merely allowing for one) is the 
>>> correct
>> vehicle
>>>  to adopt as a base document.
>>> 
>>>- Distributed algorithm work (the original basis for 
>>> draft-cc-ospf-flooding-
>> reduction)
>>>  should continue as a separate document form the base which would
>> thus we have no
>>>  conflicts.
>>> 
>>> - In the meantime the authors try and merge work, this fails.
>>> 
>>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
>>> 
>>> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
>>> 
>>> - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> 

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

2019-02-01 Thread Peter Psenak

Hi Chris,

sounds good to me.

thanks,
Peter

On 01/02/2019 13:25 , Christian Hopps wrote:


Summary of where we are at with dynamic flooding reduction:

- We have a well written original work that came first and described the
problems as well as a TLVs to allow for a centralized solution
(draft-li-dyanmic-flooding). We do not need to standardize the
centralized algorithm.

- A small change to this work allowed for distributed algorithms and for
outside work on distributed algorithms to continue in parallel.

- We have another original work that started primarily as a distributed
algorithm
  (draft-cc-ospf-flooding-reduction)

- Finally we also have:
  - Cross-pollination of ideas.
  - Failed attempts at merging.
  - An authors list "Arms-Race".

Moving forward:

- During IETF 103 I proposed we have no conflict if we:

  1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
  2) have authors of draft-cc-lsr-flooding-reduction work on a
distributed algorithm as they started with.

- Acee agreed during the meeting (as chair) that this was the best way
forward. We had some agreement form the floor as well.

- Any good ideas regarding the distribution of a centralized topology
can be debated and added (with appropriate attribution) to the base
document after we adopt one.

- This is what happens when we adopt a document as WG work, we work on it.

- The original authors of the distributed solution can continue to work
on their distributed algorithm in a separate document which would also
need standardization.

Does anyone see a serious problem with this path forward?

Thanks,
Chris & Acee.
LSR Chairs.

Christian Hopps  writes:


We've had the authors of the individual conflicting drafts take a shot
at merging their work.

   This has failed.

Here is the full history (which I also summarized during IETF103 as
well). I will send a second email discussing this.

- Jan 2, 2018 Publication: draft-li-dynamic-flooding and
drfat-li-dynamic-flooding-isis
  published centralized solution.

- Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and
draft-cc-ospf-flooding-reduction
  published distributed solution.
  - mention of centralized solution asserting it is not good choice.

- IETF 101 (Mar 2018)
  - Video:
https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS

  - Minutes:
https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
- Generally well received.
  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
- Serious problems immediately found during presentation -- not
fully baked.

- Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
- Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
- Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
- Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
  - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
  - Does not specify distributed algorithm only how to indicate one in
use, small change.

- Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published

- IETF 102 (Jul 14, 2018)
  - draft-li-dynamic-flooding-05 presented.
  - draft-cc-ospf-flooding-reduction-02 presented.

- Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
  - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.

- Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)

- Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)

- IETF 103 (Nov 3, 2018)

  - Chairs give direction

- draft-li-lsr-dynamic-flooding-05 having come first, being well
written and not
  specifying a distributed algorithm (merely allowing for one) is
the correct vehicle
  to adopt as a base document.

- Distributed algorithm work (the original basis for
draft-cc-ospf-flooding-reduction)
  should continue as a separate document form the base which would
thus we have no
  conflicts.

- In the meantime the authors try and merge work, this fails.

- Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)

- Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)

- Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)




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



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


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

2019-02-01 Thread David Allan I
Agreed

Cheers
Dave

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: Friday, February 1, 2019 4:26 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


Summary of where we are at with dynamic flooding reduction:

 - We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.

 - A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.

 - We have another original work that started primarily as a distributed 
algorithm
   (draft-cc-ospf-flooding-reduction)

 - Finally we also have:
   - Cross-pollination of ideas.
   - Failed attempts at merging.
   - An authors list "Arms-Race".

Moving forward:

- During IETF 103 I proposed we have no conflict if we:

   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.

- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well.

- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.

- This is what happens when we adopt a document as WG work, we work on it.

- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.

Does anyone see a serious problem with this path forward?

Thanks,
Chris & Acee.
LSR Chairs.

Christian Hopps  writes:

> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.
>
>This has failed.
>
> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.
>
> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis
>   published centralized solution.
>
> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction
>   published distributed solution.
>   - mention of centralized solution asserting it is not good choice.
>
> - IETF 101 (Mar 2018)
>   - Video: 
> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>   - Minutes: 
> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00
>   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
> - Generally well received.
>   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
> - Serious problems immediately found during presentation -- not fully 
> baked.
>
> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>   - Does not specify distributed algorithm only how to indicate one in use, 
> small change.
>
> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
>
> - IETF 102 (Jul 14, 2018)
>   - draft-li-dynamic-flooding-05 presented.
>   - draft-cc-ospf-flooding-reduction-02 presented.
>
> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
>   - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
>
> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
>
> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
>
> - IETF 103 (Nov 3, 2018)
>
>   - Chairs give direction
>
> - draft-li-lsr-dynamic-flooding-05 having come first, being well written 
> and not
>   specifying a distributed algorithm (merely allowing for one) is the 
> correct vehicle
>   to adopt as a base document.
>
> - Distributed algorithm work (the original basis for 
> draft-cc-ospf-flooding-reduction)
>   should continue as a separate document form the base which would thus 
> we have no
>   conflicts.
>
> - In the meantime the authors try and merge work, this fails.
>
> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
>
> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
>
> - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)

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


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

2019-02-01 Thread Tony Li


+1

Tony


> On Feb 1, 2019, at 5:18 AM, John E Drake  wrote:
> 
> Chris & Acee,
> 
> This looks fine to me.
> 
> Yours Irrespectively,
> 
> John
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Christian Hopps
>> Sent: Friday, February 1, 2019 7:26 AM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org
>> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>> 
>> 
>> Summary of where we are at with dynamic flooding reduction:
>> 
>> - We have a well written original work that came first and described the
>> problems as well as a TLVs to allow for a centralized solution 
>> (draft-li-dyanmic-
>> flooding). We do not need to standardize the centralized algorithm.
>> 
>> - A small change to this work allowed for distributed algorithms and for 
>> outside
>> work on distributed algorithms to continue in parallel.
>> 
>> - We have another original work that started primarily as a distributed 
>> algorithm
>>   (draft-cc-ospf-flooding-reduction)
>> 
>> - Finally we also have:
>>   - Cross-pollination of ideas.
>>   - Failed attempts at merging.
>>   - An authors list "Arms-Race".
>> 
>> Moving forward:
>> 
>> - During IETF 103 I proposed we have no conflict if we:
>> 
>>   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>>   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
>> algorithm as they started with.
>> 
>> - Acee agreed during the meeting (as chair) that this was the best way 
>> forward.
>> We had some agreement form the floor as well.
>> 
>> - Any good ideas regarding the distribution of a centralized topology can be
>> debated and added (with appropriate attribution) to the base document after 
>> we
>> adopt one.
>> 
>> - This is what happens when we adopt a document as WG work, we work on it.
>> 
>> - The original authors of the distributed solution can continue to work on 
>> their
>> distributed algorithm in a separate document which would also need
>> standardization.
>> 
>> Does anyone see a serious problem with this path forward?
>> 
>> Thanks,
>> Chris & Acee.
>> LSR Chairs.
>> 
>> Christian Hopps  writes:
>> 
>>> We've had the authors of the individual conflicting drafts take a shot at
>> merging their work.
>>> 
>>>   This has failed.
>>> 
>>> Here is the full history (which I also summarized during IETF103 as well). 
>>> I will
>> send a second email discussing this.
>>> 
>>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-
>> flooding-isis
>>>  published centralized solution.
>>> 
>>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
>>> draft-cc-ospf-
>> flooding-reduction
>>>  published distributed solution.
>>>  - mention of centralized solution asserting it is not good choice.
>>> 
>>> - IETF 101 (Mar 2018)
>>>  - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-
>> 6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>>  - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-
>> lsr-00
>>>  - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
>>>- Generally well received.
>>>  - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
>>>- Serious problems immediately found during presentation -- not fully 
>>> baked.
>>> 
>>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
>>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
>>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
>>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
>>>  - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
>>>  - Does not specify distributed algorithm only how to indicate one in use, 
>>> small
>> change.
>>> 
>>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
>>> 
>>> - IETF 102 (Jul 14, 2018)
>>>  - draft-li-dynamic-flooding-05 presented.
>>>  - draft-cc-ospf-flooding-reduction-02 presented.
>>> 
>>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
>>>  - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
>>> 
>>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
>>> 
>>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
>>> 
>>> - IETF 103 (Nov 3, 2018)
>>> 
>>>  - Chairs give direction
>>> 
>>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written 
>>> and
>> not
>>>  specifying a distributed algorithm (merely allowing for one) is the 
>>> correct
>> vehicle
>>>  to adopt as a base document.
>>> 
>>>- Distributed algorithm work (the original basis for 
>>> draft-cc-ospf-flooding-
>> reduction)
>>>  should continue as a separate document form the base which would thus
>> we have no
>>>  conflicts.
>>> 
>>> - In the meantime the authors try and merge work, this fails.
>>> 
>>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
>>> 
>>> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
>>> 
>>> - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)
> 
> 

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

2019-02-01 Thread John E Drake
Chris & Acee,

This looks fine to me.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Friday, February 1, 2019 7:26 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> 
> Summary of where we are at with dynamic flooding reduction:
> 
>  - We have a well written original work that came first and described the
> problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-
> flooding). We do not need to standardize the centralized algorithm.
> 
>  - A small change to this work allowed for distributed algorithms and for 
> outside
> work on distributed algorithms to continue in parallel.
> 
>  - We have another original work that started primarily as a distributed 
> algorithm
>(draft-cc-ospf-flooding-reduction)
> 
>  - Finally we also have:
>- Cross-pollination of ideas.
>- Failed attempts at merging.
>- An authors list "Arms-Race".
> 
> Moving forward:
> 
> - During IETF 103 I proposed we have no conflict if we:
> 
>1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
> algorithm as they started with.
> 
> - Acee agreed during the meeting (as chair) that this was the best way 
> forward.
> We had some agreement form the floor as well.
> 
> - Any good ideas regarding the distribution of a centralized topology can be
> debated and added (with appropriate attribution) to the base document after we
> adopt one.
> 
> - This is what happens when we adopt a document as WG work, we work on it.
> 
> - The original authors of the distributed solution can continue to work on 
> their
> distributed algorithm in a separate document which would also need
> standardization.
> 
> Does anyone see a serious problem with this path forward?
> 
> Thanks,
> Chris & Acee.
> LSR Chairs.
> 
> Christian Hopps  writes:
> 
> > We've had the authors of the individual conflicting drafts take a shot at
> merging their work.
> >
> >This has failed.
> >
> > Here is the full history (which I also summarized during IETF103 as well). 
> > I will
> send a second email discussing this.
> >
> > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-
> flooding-isis
> >   published centralized solution.
> >
> > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> > draft-cc-ospf-
> flooding-reduction
> >   published distributed solution.
> >   - mention of centralized solution asserting it is not good choice.
> >
> > - IETF 101 (Mar 2018)
> >   - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-
> 6ZTP5j_HaBNdfPbgxGIp22cnaWS
> >   - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-
> lsr-00
> >   - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101
> > - Generally well received.
> >   - draft-cc-ospf-flooding-reduction-00 (4 authors) presented.
> > - Serious problems immediately found during presentation -- not fully 
> > baked.
> >
> > - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author)
> > - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author)
> > - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised
> > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
> >   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
> >   - Does not specify distributed algorithm only how to indicate one in use, 
> > small
> change.
> >
> > - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published
> >
> > - IETF 102 (Jul 14, 2018)
> >   - draft-li-dynamic-flooding-05 presented.
> >   - draft-cc-ospf-flooding-reduction-02 presented.
> >
> > - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors)
> >   - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*.
> >
> > - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors)
> >
> > - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors)
> >
> > - IETF 103 (Nov 3, 2018)
> >
> >   - Chairs give direction
> >
> > - draft-li-lsr-dynamic-flooding-05 having come first, being well 
> > written and
> not
> >   specifying a distributed algorithm (merely allowing for one) is the 
> > correct
> vehicle
> >   to adopt as a base document.
> >
> > - Distributed algorithm work (the original basis for 
> > draft-cc-ospf-flooding-
> reduction)
> >   should continue as a separate document form the base which would thus
> we have no
> >   conflicts.
> >
> > - In the meantime the authors try and merge work, this fails.
> >
> > - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
> >
> > - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors)
> >
> > - Jan 7, 2019  draft-cc-lsr-flooding-reduction-01 (8 authors)

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