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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 04 February 2019 16:11 UTC

Return-Path: <acee@cisco.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 92B42130E9B for <lsr@ietfa.amsl.com>; Mon, 4 Feb 2019 08:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.054
X-Spam-Level:
X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 ovnuek0JNJxD for <lsr@ietfa.amsl.com>; Mon, 4 Feb 2019 08:11:21 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8498130E86 for <lsr@ietf.org>; Mon, 4 Feb 2019 08:11:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9612; q=dns/txt; s=iport; t=1549296681; x=1550506281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4LVtWAZnrFgM7H1cnn8GL1YUb4nVqh6s+dufrUrUU20=; b=kyPP2L+77rfGCrvPV/rbZla8a1rVdLHmCvtmdbgoBN1YX9elBZi55R2i mgVIsSD+gfUo8TM28nSva5MmIP8vUlTxdpV4zHSBzP9yqOz5QTFgFQ5OC agW5nZRX3aGwLAdtMxY4SzZftXm2N4rcpF1hjSPyj5vMMWB8we76eIEDG E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACkY1hc/4wNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNngQMnCoN5iBqLc4INmA8UgWcLAQEYDYRHAheDCSI0CQ0BAwEBAgEBAm0cDIVLAQEDAQEBIRE6CxACAQYCDgwCJgICAiULFRACBAENBRuDBwGBeQgPjnObYYEvhC8BAwICgQ2EYwWBC4s2F4F/gTgfgkyDHgEBAgEXgRQBEgEfgwkxgiYCiVoViBiQawkChzCDYYR9gioZkkSKI4UvjAYCERSBJx84ZXFwFTsqAYJBhgqFFIU/QTGMOIEfgR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,560,1539648000"; d="scan'208";a="234978038"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2019 16:11:19 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x14GBJmg022897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Feb 2019 16:11:19 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 4 Feb 2019 11:11:18 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Mon, 4 Feb 2019 11:11:18 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Christian Hopps <chopps@chopps.org>, Aijun Wang <wangaijun@tsinghua.org.cn>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Thread-Index: AQHUuilUUaWOLI4OpkiOe3VLnvRruqXMjKUAgANrv4D//9vNgA==
Date: Mon, 04 Feb 2019 16:11:18 +0000
Message-ID: <F70D9169-9D27-4D2F-BC9B-5588C337A430@cisco.com>
References: <sa65zu31zqk.fsf@chopps.org> <sa64l9n1yqy.fsf@chopps.org> <D1E4AF1B-C6EA-4603-86CB-444554937AD7@tsinghua.org.cn> <sa6a7jbg05o.fsf@chopps.org>
In-Reply-To: <sa6a7jbg05o.fsf@chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="utf-8"
Content-ID: <32DE3B65111AF145972EFD4B68D5481C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YeBKL4y_ZFMEDQGMTt4w7JkMaUg>
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: Mon, 04 Feb 2019 16:11:24 -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" <lsr-bounces@ietf.org on behalf of chopps@chopps.org> wrote:

    
    Aijun Wang <wangaijun@tsinghua.org.cn> 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 <chopps@chopps.org> 写道:
    >>
    >>
    >> 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)
    >>
    >> _______________________________________________
    >> Lsr mailing list
    >> Lsr@ietf.org
    >> https://www.ietf.org/mailman/listinfo/lsr