Hi Huaimo,

On 13/02/2019 22:50 , Huaimo Chen wrote:
Hi Peter,

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

-----Original Message-----
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, February 6, 2019 4:58 AM
To: Huaimo Chen <huaimo.c...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; 
Christian Hopps <cho...@chopps.org>; lsr@ietf.org
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

On 03/02/2019 17:58 , Huaimo Chen wrote:
Hi Acee,

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

optimized flooding is not only about algorithm to calculate the flooding topology and the way it is distributed/computed. It is also about local rules to make sure the flooding remains consistent. These are _independent_ of centralized/distributed modes. And it make no sense to specify these rules in two drafts.

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.


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 

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


Best Regards,


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

Hi Huaimo,

See inline.

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

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?



Best Regards,


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


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


Chris & Acee.

LSR Chairs.

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

We've had the authors of the individual conflicting drafts take a
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

  published centralized solution.

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

  published distributed solution.

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

- IETF 101 (Mar 2018)

  - Video:

  - Minutes:

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


  - Does not specify distributed algorithm only how to indicate one
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)


- 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

      should continue as a separate document form the base which
thus we have no


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

Reply via email to