Subject: [Lsr] Flooding Reduction Draft Redux

From: Christian Hopps <[email-masked]>
Date: Fri, 01 Feb 2019 07:04:35 -0500

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&list=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)

---

From: Christian Hopps <[email-masked]>
Date: Fri, 01 Feb 2019 07:25:57 -0500

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.

---

From: John E Drake <[email-masked]>
Date: Fri, 1 Feb 2019 13:18:16 +0000

Chris & Acee,

This looks fine to me.

Yours Irrespectively,

John

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Friday, February 1, 2019 7:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> 
>  - 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.
> 
> - 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.
> 
> - The original authors of the distributed solution can continue to work on their
> distributed algorithm in a separate document which would also need
> standardization.
>

---

From: Tony Li <[email-masked]>
Date: Fri, 1 Feb 2019 07:46:12 -0800

+1

Tony

> On Feb 1, 2019, at 5:18 AM, John E Drake <[email-masked]> wrote:
> 
> Chris & Acee,
> 
> This looks fine to me.
> 
> Yours Irrespectively,
> 
> John
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: David Allan I <[email-masked]>
Date: Fri, 1 Feb 2019 15:49:36 +0000

Agreed

Cheers
Dave

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: Friday, February 1, 2019 4:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

 - Finally we also have:

Moving forward:

Thanks,
Chris & Acee.
LSR Chairs.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 1 Feb 2019 16:51:15 +0100

Hi Chris,

sounds good to me.

thanks,
Peter

On 01/02/2019 13:25 , Christian Hopps wrote:
> 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.
>
>   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.
>
> - The original authors of the distributed solution can continue to work
> on their distributed algorithm in a separate document which would also
> need standardization.
>
>> Here is the full history (which I also summarized during IETF103 as
>> well). I will send a second email discussing this.
>>
>>   - Video:
>> https://www.youtube.com/watch?v=qHmT4ytMn4w&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS
>>
>>   - Minutes:
>> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Feb 2019 16:02:36 +0000

I am in favor of this proposal.

   Les

> Sent: Friday, February 01, 2019 4:26 AM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> debated and added (with appropriate attribution) to the base document
> after we adopt one.
> 
> - The original authors of the distributed solution can continue to work on
> their distributed algorithm in a separate document which would also need
> standardization.
> 
> > Here is the full history (which I also summarized during IETF103 as well). I
> will send a second email discussing this.
> >

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 1 Feb 2019 16:38:30 +0000

Hi Everyone,

    My comments are inline below with prefix [HC].

Best Regards,
Huaimo
-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Friday, February 1, 2019 7:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Lsr] Flooding Reduction Draft Redux

    This has failed.

 - IETF 101 (Mar 2018)

[HC] All the problems have been resolved in our latest draft.
Some people indicated that the distributed solution is better than the centralized one. In addition, on the LSR mailing list, some people said that the distributed solution is more practical. 

 - IETF 103 (Nov 3, 2018)

   - Chairs give direction

[HC] Coming first and being well written are important. However, technical merits or advantages are at least equally important.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 01 Feb 2019 12:02:38 -0500

> Some people indicated that the distributed solution is better than the centralized one. In addition, on the LSR mailing list, some people said that the distributed solution is more practical.

Great. And it makes sense to have a document dedicated to your distributed algorithm solution. That is the proposal I just put forward.

> [HC] Coming first and being well written are important. However, technical merits or advantages are at least equally important.

Technical merits are very important, and we (the WG) should have discussions about and make any changes that might be needed to the centralized solution document -- once we adopt one.

It only makes sense to adopt the original centralized solution work for working on the centralized solution -- especially since it's well written, and it came first.

Thanks,
Chris.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 1 Feb 2019 22:44:06 +0000

Support the proposal.

Regards,
- Naiming

> On Feb 1, 2019, at 4:25 AM, Christian Hopps <[email-masked]> wrote:
> 
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 1 Feb 2019 20:36:55 -0800

In favor!

Regards,
Jeff

> On Feb 1, 2019, at 08:02, Les Ginsberg (ginsberg) <[email-masked]> wrote:
>

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 2 Feb 2019 05:27:00 +0000

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.

Best Regards,

Huaimo

-----Original Message-----

To: [email-masked]

Cc: [email-masked]

- Finally we also have:

Moving forward:

Thanks,

Chris & Acee.

LSR Chairs.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 2 Feb 2019 17:06:26 +0800

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 <[email-masked]> 写道：
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 2 Feb 2019 13:20:05 +0100

Sound like best plan fwd.

Thx,
R.

On Fri, Feb 1, 2019, 13:26 Christian Hopps <[email-masked] wrote:

> (draft-li-dyanmic-flooding). We do not need to standardize the centralized
> algorithm.
>
> - 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.
>

---

From: li zhenqiang <[email-masked]>
Date: Sun, 3 Feb 2019 09:27:40 +0000

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
________________________________
[email-masked]

From: Robert Raszuk<mailto:[email-masked]>
Date: 2019-02-02 20:20
To: Christian Hopps<mailto:[email-masked]>
CC: lsr<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]> wrote:

 - Finally we also have:

Moving forward:

   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.

Thanks,
Chris & Acee.
LSR Chairs.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 3 Feb 2019 16:40:27 +0200

On Sat, Feb 2, 2019 at 11:06 AM Aijun Wang <[email-masked]>
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.

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

> on their distributed algorithm in a separate document which would also need
> standardization.
> >

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

AB

---

From: David Allan I <[email-masked]>
Date: Sun, 3 Feb 2019 15:31:53 +0000

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

Cheers

Dave

From: Lsr <[email-masked]> On Behalf Of li zhenqiang
Sent: Sunday, February 3, 2019 1:28 AM
To: Robert Raszuk <[email-masked]>; Christian Hopps <[email-masked]>
Cc: lsr <[email-masked]>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hello all,

Best Regards,

Zhenqiang Li

  _____

[email-masked]<mailto:[email-masked]>

   Date: 2019-02-02 20:20

   Thx,

   R.

       - Finally we also have:

      Moving forward:

      Thanks,
      Chris & Acee.
      LSR Chairs.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 3 Feb 2019 16:44:42 +0000

Hi Huaimo,

See inline.

From: Lsr <[email-masked]> on behalf of Huaimo Chen <[email-masked]>
Date: Saturday, February 2, 2019 at 12:27 AM
To: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Everyone,

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:

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

To: [email-masked]

Cc: [email-masked]

- Finally we also have:

Moving forward:

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

Thanks,

Chris & Acee.

LSR Chairs.

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 3 Feb 2019 16:44:47 +0000

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:[email-masked]] On Behalf Of David Allan I
Sent: Sunday, February 3, 2019 10:32 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Cheers
Dave

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of li zhenqiang
Sent: Sunday, February 3, 2019 1:28 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hello all,

Best Regards,
Zhenqiang Li

Thx,
R.

 - Finally we also have:

Moving forward:

Thanks,
Chris & Acee.
LSR Chairs.

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 3 Feb 2019 16:58:02 +0000

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:[email-masked]]
Sent: Sunday, February 3, 2019 11:45 AM
To: Huaimo Chen <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

See inline.

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Date: Saturday, February 2, 2019 at 12:27 AM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Everyone,

Thanks,

Acee

Best Regards,

Huaimo

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

- Finally we also have:

Moving forward:

Thanks,

Chris & Acee.

LSR Chairs.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 3 Feb 2019 18:01:49 +0100

> 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 <[email-masked]> 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
>
>

---

From: [email-masked]
Date: Sun, 3 Feb 2019 12:14:10 -0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 3 Feb 2019 21:37:26 +0100

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 <[email-masked]> wrote:

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 3 Feb 2019 21:28:45 +0000

A very strong +1.

   Les

> From: Lsr <[email-masked]> On Behalf Of [email-masked]
> Sent: Sunday, February 03, 2019 12:14 PM
> To: Robert Raszuk <[email-masked]>
> Cc: Huaimo Chen <[email-masked]>; [email-masked]; David
> Allan I <[email-masked]>; [email-masked];
> [email-masked]
> 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

---

From: David Allan I <[email-masked]>
Date: Sun, 3 Feb 2019 21:33:19 +0000

Makes sense to me, thanks for the clarity...

Dave

-----Original Message-----
From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Sunday, February 3, 2019 12:14 PM
To: Robert Raszuk <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; David Allan I <[email-masked]>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

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.

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 3 Feb 2019 21:37:42 +0000

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Sunday, February 03, 2019 12:37 PM
To: Tony Li <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked]; David Allan I <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Tony

---

From: Lizhenbin <[email-masked]>
Date: Mon, 4 Feb 2019 09:36:16 +0000

Hi Chris & Acee,

>   published distributed solution

Thanks for your summary we know the fact that at beginning there was not any confliction between the two drafts.

>   - Does not specify distributed algorithm only how to indicate one in use, small change.

I do not think it is a small change. It is to introduced the totally new solution which was already defined in the other existing draft. It is not an appropariate behavior and the root cause of the potential confliction. 

I also think the distributed solution includes more than the algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  defined in the draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. Since the co-authors could not merge the draft, though the existing suggestion proposed is try to separate the two drafts, there is still overlap on the distributed solution between the two drafts which may be the source of continuous confliction in the future. In order to avoid the situation I would like to propose following suggestions:
- move both the two drafts forward in parallel keeping draft-li-dynamic-flooding focus on the centralized solution and draft-cc-lsr-flooding-reduction on the distributed solution.
- draft-li-dynamic-flooding can keep on refining the centralized solution without mentioning distibuted solutions.
- draft-cc-lsr-flooding-reduction can keep on refining the distributed solutions. For the sigalling which can be shared by the two modes, the draft can indicate the distributed solutions reuse the signalling defined in draft-li-dynamic-flooding without defining new signalling. 
- both drafts change the draft names to reflect different solutions without causing confusion.

Thanks & Regards,
Zhenbin (Robin)

________________________________________
发件人: Lsr [[email-masked]] 代表 Christian Hopps [[email-masked]]
发送时间: 2019年2月1日 20:25
收件人: [email-masked]
抄送: [email-masked]
主题: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

 - Finally we also have:

Moving forward:

Thanks,
Chris & Acee.
LSR Chairs.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 04 Feb 2019 08:20:51 -0500

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

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

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 04 Feb 2019 08:42:14 -0500

> I do not think it is a small change. It is to introduced the totally new solution which was already defined in the other existing draft. It is not an appropariate behavior and the root cause of the…

It added 8 bits to signal which distributed algorithm (if any) was in use. How is that not small?

> I also think the distributed solution includes more than the algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  defined in the draft-cc-lsr-flooding-reduc…

Yes, the CC draft added a ton of new signaling after the fact. We didn't need this, and it has been the root cause of the conflict.

The signaling is not the hard part to solve here and we don't need to be spending all this time and effort (15 authors now?!) on it.

Instead of spending more time on signaling, we need to get rid of this conflict, and have people working on the *actual hard problems* of the flooding topology calculation. There's no conflict here, there's room for multiple solutions, and it's the hard part.

Thanks,
Chris.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 4 Feb 2019 16:04:37 +0000

In favor of moving both drafts forward. 

Linda Dunbar

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Monday, February 04, 2019 3:36 AM
To: Christian Hopps <[email-masked]>; [email-masked]
Subject: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Chris & Acee,

Thanks & Regards,
Zhenbin (Robin)

 - Finally we also have:

Moving forward:

Thanks,
Chris & Acee.
LSR Chairs.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 4 Feb 2019 16:11:18 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Thanks,
    Chris.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 6 Feb 2019 10:57:37 +0100

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:[email-masked]]
> *Sent:* Sunday, February 3, 2019 11:45 AM
> *To:* Huaimo Chen <[email-masked]>; Christian Hopps
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>
>
> Hi Huaimo,
>
>
>
> See inline.
>
>
>
> *From: *Lsr <[email-masked] <mailto:[email-masked]>> on
> behalf of Huaimo Chen <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Saturday, February 2, 2019 at 12:27 AM
> *To: *Christian Hopps <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *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
>
> 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
>
>
>
> To: [email-masked] <mailto:[email-masked]>
>
> Cc: [email-masked] <mailto:[email-masked]>
>
> forward. We had some agreement form the floor as well..
>
>
>
> Christian Hopps <[email-masked] <mailto:[email-masked]>> writes:
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 6 Feb 2019 11:11:31 +0100

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Feb 2019 13:32:41 +0100

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.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 11 Feb 2019 08:47:01 +0000

Support moving forward with the centralized and distributed solutions specified in separated drafts. As discussed in previous mails, the procedure and protocol extensions needed for the two modes could be different, and a particular network may only want to use one mode.

As for the centralized solution, maybe it could be refined with the advantage of the centralized part in both existing drafts.

Best regards,
Jie

> Sent: Monday, February 04, 2019 5:36 PM
> I do not think it is a small change. It is to introduced the totally new solution which
> was already defined in the other existing draft. It is not an appropariate behavior
> and the root cause of the potential confliction.
> 
> 
> I also think the distributed solution includes more than the algorithms defined in
> the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  defined
> in the draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. Since the
> co-authors could not merge the draft, though the existing suggestion proposed is
> try to separate the two drafts, there is still overlap on the distributed solution
> between the two drafts which may be the source of continuous confliction in the
> future. In order to avoid the situation I would like to propose following
> suggestions:
> - move both the two drafts forward in parallel keeping draft-li-dynamic-flooding
> focus on the centralized solution and draft-cc-lsr-flooding-reduction on the
> distributed solution.
> - draft-cc-lsr-flooding-reduction can keep on refining the distributed solutions.
> For the sigalling which can be shared by the two modes, the draft can indicate the
> distributed solutions reuse the signalling defined in draft-li-dynamic-flooding
> without defining new signalling.
> debated and added (with appropriate attribution) to the base document after
> we adopt one.
>

---

From: Huzhibo <[email-masked]>
Date: Mon, 11 Feb 2019 10:03:13 +0000

Support to promote the centralized and distributed solutions in two separated drafts.

Best regards,
Zhibo
-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Monday, February 11, 2019 4:47 PM
To: Lizhenbin <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

Best regards,
Jie

> Thanks for your summary we know the fact that at beginning there was 
> not any confliction between the two drafts.
> 
> 
> >   - Does not specify distributed algorithm only how to indicate one 
> > in use,
> small change.
> 
> I do not think it is a small change. It is to introduced the totally 
> new solution which was already defined in the other existing draft. It 
> is not an appropariate behavior and the root cause of the potential confliction.
> 
> 
> I also think the distributed solution includes more than the 
> algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the 
> overlapped signallings  defined in the 
> draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. Since 
> the co-authors could not merge the draft, though the existing 
> suggestion proposed is try to separate the two drafts, there is still 
> overlap on the distributed solution between the two drafts which may 
> be the source of continuous confliction in the future. In order to 
> avoid the situation I would like to propose following
> suggestions:
> - move both the two drafts forward in parallel keeping 
> draft-li-dynamic-flooding focus on the centralized solution and 
> draft-cc-lsr-flooding-reduction on the distributed solution.
> - draft-li-dynamic-flooding can keep on refining the centralized 
> solution without mentioning distibuted solutions.
> For the sigalling which can be shared by the two modes, the draft can 
> indicate the distributed solutions reuse the signalling defined in 
> draft-li-dynamic-flooding without defining new signalling.
>  - 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 
>  - A small change to this work allowed for distributed algorithms and 
> for outside work on distributed algorithms to continue in parallel.
> 
> - The original authors of the distributed solution can continue to 
> work on their distributed algorithm in a separate document which would 
> also need standardization.
> 
> > We've had the authors of the individual conflicting drafts take a 
> > shot at merging
> their work.
> >
> >    This has failed.
> >
> >     - Serious problems immediately found during presentation -- not 
> > fully
> baked.
> >
> >   - Does not specify distributed algorithm only how to indicate one 
> > in use,
> small change.
> >
> >     - 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
> >       should continue as a separate document form the base which 
> > would
> thus we have no
> >       conflicts.
> >

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 13 Feb 2019 21:50:56 +0000

Hi Peter,

    My explanations/answers are in line below with prefix [HC].

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, February 6, 2019 4:58 AM
To: Huaimo Chen <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

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

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

> 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:
>
> 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 
> 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
>
>
>
>> shot
> at merging their work.
> fully baked.
>> in
> use, small change.
> written and not

---

From: li zhenqiang <[email-masked]>
Date: Thu, 14 Feb 2019 03:17:05 +0000

Support

Zhenqiang Li

发件人： Dongjie (Jimmy)<mailto:[email-masked]>
发送时间： 2019-02-11 16:47
收件人： Lizhenbin<mailto:[email-masked]>; Christian Hopps<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题： Re: [Lsr]答复: Moving Forward [Re: Flooding Reduction Draft Redux]
Support moving forward with the centralized and distributed solutions specified in separated drafts. As discussed in previous mails, the procedure and protocol extensions needed for the two modes could be different, and a particular network may only want to use one mode.

Best regards,
Jie

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Feb 2019 08:29:53 +0100

Hi Huaimo,

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

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

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Feb 2019 13:57:37 +0000

Hi,

I completely agree with Peter.

Yours Irrespectively,

John

> From: Lsr <[email-masked]> On Behalf Of Peter Psenak
> Sent: Thursday, February 14, 2019 2:30 AM
> To: Huaimo Chen <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> > To: Huaimo Chen <[email-masked]>; Acee Lindem (acee)
> > <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> >>     I agree with you on keeping the signaling for two modes. The
> >> other parts for the distributed solution need to be removed.
> 
> 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] 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
> 
> >
> > 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
> >>
> >> - Acee agreed during the meeting (as chair) that this was the best
> >> way forward. We had some agreement form the floor as well..
> >>
> >>
> >>
> >> work on their distributed algorithm in a separate document which
> >> would also need standardization.
> >>
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_
> >> watch-3Fv-3DqHmT4ytMn4w-26list-3DPLC86T-2D6ZTP5j-
> 5FHaBNdfP&d=DwICAg&c
> >> =HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-
> h5LGhEW
> >> H-
> s_xXXup3HzvBSMRj5VE&m=kykK2jUejhafPHOrWXu0yvNk7XsXUoDYsWjFoFGHeT
> g&s
> >> =cBWxI4Hu1GZNWxuUZRREnZNg-cZZYbdrLHRXKsUama4&e=
> >> bgxGIp22cnaWS
> >>
> >>>   - Minutes:
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
> >> .org_meeting_101_materials_minutes-2D101-2Dlsr-
> 2D00&d=DwICAg&c=HAkYuh
> >> 63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXX
> >>
> up3HzvBSMRj5VE&m=kykK2jUejhafPHOrWXu0yvNk7XsXUoDYsWjFoFGHeTg&s=
> 1UTDcj
> >> zO1b-Ful7k87ItzHcvqzRveIK_m_FI9eIDLFs&e=
> >>
> >>> is
> >> the correct vehicle
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
> >> lman_listinfo_lsr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWz
> >> oCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=kykK2jUejhafPHOrW
> >>
> Xu0yvNk7XsXUoDYsWjFoFGHeTg&s=BTZ1l1KpTxr_U3n0pZnknvuPBGxRM9ul08q
> CKpaE
> >> eXk&e=
> >>
> >
> > .
> >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lsr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0
> UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=kykK2jUejhafPHOrWXu0yvNk7XsXUoDYsWjFoFGHeT
> g&s=BTZ1l1KpTxr_U3n0pZnknvuPBGxRM9ul08qCKpaEeXk&e=

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Feb 2019 23:00:22 +0000

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" <[email-masked]> wrote:

    Hi,

    Yours Irrespectively,
    
    John

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Feb 2019 16:35:58 +0000

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)" <[email-masked]> wrote:

    Speaking as a WG member, 

    Thanks,
    Acee

        Hi,

        Yours Irrespectively,
        
        John

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 18 Feb 2019 15:28:36 +0000

Hi Peter,

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

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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 18 Feb 2019 16:38:48 +0100

Hi Huaimo,

On 18/02/2019 16:28 , Huaimo Chen wrote:
> 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

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

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 21 Feb 2019 01:28:02 +0000

Hi Peter,

>Sent: Monday, February 18, 2019 10:39 AM
>>> 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.
>> In addition to the common parts, there are still some 
>> rules/procedures/behaviors that are different from one mode to another 
>> mode. For example, the rule/procedure for fault tolerance to failures 
>> used in the centralized solution/mode will be different from that used in the distributed solution/mode.

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

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

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

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

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

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

Best Regards,
Huaimo

---

From: Tony Li <[email-masked]>
Date: Wed, 20 Feb 2019 21:31:56 -0800

Hi Huaimo,

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

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

> 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