IETF Logo Mail Archive

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

tony.li@tony.li Mon, 27 August 2018 15:53 UTC

Return-Path: <tony1athome@gmail.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 4763D130EE3 for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 08:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WRSxbp9TIWUE for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 08:53:53 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4C7130E0D for <lsr@ietf.org>; Mon, 27 Aug 2018 08:53:53 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id l9-v6so7933750pff.9 for <lsr@ietf.org>; Mon, 27 Aug 2018 08:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3rQ7f2SiL3cKV2rBTKQTiM0xoeXoT41TZO/g8v74FI=; b=r2w5jbWOYK6AqGl+PtIriW4XJQwZFjNSjJwZ/ue77qYoZHjd7zGfBsYV0kSwaChowl q1EdEhJwurzlx7GW59M1hBmPlFdCsETr3KEtHbdUmBpUzDxB7TUdNUR20KQNRhGwEGDy cDlZHdjadBB135DLqQmkE1QmSdooeJZ7LDIJ7aiCvWbPleZE1aX6pHLEbtNhiIboEH2j JweEq/E30Frz24bQAjt5o8B9ghgzt1cCU3NIaWNjay+PcErLfDpHGKh9fr7THxT1AP2Y mjcKxVQtGzeQsUfSDtptlEd0KxxfT6J1Dmr9zudZnRcIDPffY7Ey3oAKwW2hpDt4mNku Xt2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=M3rQ7f2SiL3cKV2rBTKQTiM0xoeXoT41TZO/g8v74FI=; b=k6++SGONfRLLZAlBMcDuNXI2moq9K2iBw14gC18Q6lzdJ9s/hGLjIZAy1BwB0a5YBf 1VKIDzQaEH0xJ+0OQYQ2NC1gJscaneAOiEhFJXu/T/J/BLeKZpK8mN1lVGirYCwsWqPH hBi6rmfx6YqLi4KpLNq87N1Oob/ugeBVT+I052hXXWtSno6B3TsI0ELz+jOMU7hLcTTp WostIz1RVbicbyXVcClyOHsx8eTNcdMaBEK2fIxOgu9p5yjFySuuJ0Ij0V7fABQOcxfq XDCeT2WXqx+nwukjTFP0fGFELvpnhF8+0WE/tLH3/aBAXrpUvzOumgvtLGgr/G/99RaO oXYA==
X-Gm-Message-State: APzg51Dd9essQOqYLszHzd1TmJDr+pLzHq59XpmrHJlJlUW9HqAhOqEP P6/pHu18KL2OxazRvf4Wyeg=
X-Google-Smtp-Source: ANB0VdZXvarf77dxD8DEaaZFMUBDYGeLhFDmUJHVb0TE1HpW1p3HpfbWImmA4SPh2kX6q4cESrInjw==
X-Received: by 2002:a63:da04:: with SMTP id c4-v6mr13033169pgh.398.1535385233337; Mon, 27 Aug 2018 08:53:53 -0700 (PDT)
Received: from [10.95.83.183] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id q6-v6sm2970736pgq.19.2018.08.27.08.53.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 08:53:52 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: tony.li@tony.li
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463AC1E20@sjceml521-mbs.china.huawei.com>
Date: Mon, 27 Aug 2018 08:53:51 -0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AA872E4-71A0-4B29-800B-B08C3731056C@tony.li>
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> <5316A0AB3C851246A7CA5758973207D463AC1E20@sjceml521-mbs.china.huawei.com>
To: Huaimo Chen <huaimo.chen@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/avpTVKWasIeBnhP87KgMIRgw8_o>
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:54:05 -0000

Hi Huaimo,


> After flooding reduction is deployed in an operational (ISP) network, will we be allowed to do experiments on their network? 


Some may well permit it.  Certainly in lab scenarios they may be very willing.  It all depends on their motivation to achieve improvements.

It should be remembered that we are where we are today because some people were willing to work towards better technology and understood that there would be issues while we worked out issues with implementations. All protocols, features, and implementations have growing pains. We are where we are because we work through them.


> After an algorithm is determined/selected, will it be changed to another algorithm in a short time? 


Possibly. Someone may have an insight that produces theoretical breakthrough and gives us a completely different algorithm. Or, more likely, someone discovers a catastrophic bug in an algorithm and moves to fix it.


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


I’m unaware of anyone trying to get EIGRP to interoperate with IS-IS at the protocol level.  ;-)

I’m also unaware of anyone trying to implement anything other than SPF.

And that’s what I think you’re proposing…

Tony

v2.23.0 | Report a Bug | By Email