Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Huaimo Chen <huaimo.chen@huawei.com> Mon, 27 August 2018 15:10 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 CA596130EC6 for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 08:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 b3vfbQhYh8lD for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 08:10:58 -0700 (PDT)
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 9B3F1130DF7 for <lsr@ietf.org>; Mon, 27 Aug 2018 08:10:58 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2BC5567F5FF88 for <lsr@ietf.org>; Mon, 27 Aug 2018 16:10:55 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 27 Aug 2018 16:10:56 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.188]) by SJCEML701-CHM.china.huawei.com ([169.254.3.173]) with mapi id 14.03.0415.000; Mon, 27 Aug 2018 08:10:50 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: Tony Przygienda <tonysietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Peter Psenak <ppsenak@cisco.com>
Thread-Topic: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
Thread-Index: AQHUOZzx1fG+ry0N80OZf0oWOKvmqqTMbEsAgAAEEgCAARKmgIAA6SMAgACpmYCAAGOpgIAACP4AgAAIsACAAAYrAP//l3GQgACpRYCAA+Bf0A==
Date: Mon, 27 Aug 2018 15:10:49 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463AC1E20@sjceml521-mbs.china.huawei.com>
References: <8F5D2891-2DD1-4E51-9617-C30FF716E9FB@cisco.com> <C64E476F-1C00-435E-9C74-BEC3053377E8@gmail.com> <2F5FDB3F-ADCA-4DB4-83DA-D2BC3129D2F2@gmail.com> <5B7E78DD.90302@cisco.com> <172728E8-49E6-4F43-9356-815E1F4C22E7@gmail.com> <5B7FCAB3.6040600@cisco.com> <3D1DEC37-ACE7-4412-BB2E-4C441A4E7455@tony.li> <CCF220A3-8308-47B8-8CC6-1989705FF05C@cisco.com> <CA+wi2hNv8AVyR81LRmJ=Pd5_p5rS2djCOjY9YDgKxG=KEO_MkA@mail.gmail.com> <39509D13-4D2D-49A9-8738-C9D1F7C54223@tony.li> <5316A0AB3C851246A7CA5758973207D463ABCF95@sjceml521-mbx.china.huawei.com> <54F4EE88-981B-4EB1-925B-B3573B28DAD3@tony.li>
In-Reply-To: <54F4EE88-981B-4EB1-925B-B3573B28DAD3@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.68]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dujh-Np-V9aBtIViSF6gHNMm-XQ>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Aug 2018 15:11:00 -0000

>> I think distributed is more practical too. 
>I would appreciate more detailed insights as to why you (and others) feel this way.  It is not at all obvious to me.
IGP is distributed in nature. The distributed computation of flooding topology like distributed SPF will keep IGP still distributed in nature. Introducing centralized feature into IGP will break IGP's distributed nature, which may cause some issues/problems. 

>> For computing routes, we have been using distributed SPF on every node for many years.
>True, but that algorithm is (and was) very well known and a fixed algorithm that would clearly solve the problem at the time. If we were in a similar situation, where we were ready to set an algorithm in >concrete, I might well agree, but it’s quite clear that we are NOT at that point yet.  We will need to experiment and modify algorithms, and as discussed, that’s easier with a centralized approach.
After flooding reduction is deployed in an operational (ISP) network, will we be allowed to do experiments on their network? 
After an algorithm is determined/selected, will it be changed to another algorithm in a short time? 

>> In fact, we may not need to run the exact algorithm on every node. As long as the algorithms running on different nodes generate the same result, that would work. 
>Insuring a globally consistent result without running the exact same algorithm on the exact same data will be quite a trick.  Debugging distributed problems at scale is already a hard problem.  Having >different algorithms in different locations would add another order of magnitude in difficulty.  No thank you.
In some existing networks, some nodes run IGPs from one vendor, some other nodes run IGPs from another vendor, and so on. Some may use normal SPF, some others may use incremental SPF. It seems that we have had these cases for many years. 
>Tony

Best Regards,
Huaimo