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

Huaimo Chen <huaimo.chen@huawei.com> Sat, 02 February 2019 05:27 UTC

Return-Path: <huaimo.chen@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB7A128766 for <lsr@ietfa.amsl.com>; Fri, 1 Feb 2019 21:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek4mUJ5Q-Cig for <lsr@ietfa.amsl.com>; Fri, 1 Feb 2019 21:27:09 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41E4124D68 for <lsr@ietf.org>; Fri, 1 Feb 2019 21:27:08 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8A70A8B00BB9BE6A50F5 for <lsr@ietf.org>; Sat, 2 Feb 2019 05:27:06 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 2 Feb 2019 05:27:05 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.96]) by SJCEML703-CHM.china.huawei.com ([169.254.5.115]) with mapi id 14.03.0415.000; Fri, 1 Feb 2019 21:27:01 -0800
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Thread-Index: AQHUuilbECC1DxP5/E+8dX31Ej0g66XL9lOg
Date: Sat, 02 Feb 2019 05:27:00 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463B3B9D8@sjceml521-mbx.china.huawei.com>
References: <sa65zu31zqk.fsf@chopps.org> <sa64l9n1yqy.fsf@chopps.org>
In-Reply-To: <sa64l9n1yqy.fsf@chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.247.178]
Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463B3B9D8sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zKfnI_447H3VWRd5fb8_UhFjZww>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Feb 2019 05:27:12 -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-----

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

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

To: lsr@ietf.org

Cc: chopps@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 <chopps@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&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)