Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call Sun, 24 May 2020 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DAE23A0DC8 for <>; Sun, 24 May 2020 15:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W32zicTXTK8r for <>; Sun, 24 May 2020 15:41:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36D273A0BDD for <>; Sun, 24 May 2020 15:41:24 -0700 (PDT)
Received: by with SMTP id x10so6789342plr.4 for <>; Sun, 24 May 2020 15:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1CSuEPbSQ7Vr7PX9swq/INk1poFdpJOwrZohRPPruuw=; b=T3Ivop4/dwA9LooNS3yQ/4k5VvAw1ztLWuq1dc85Zehig8nmjSTOKmNeDRX07Qlu8h 0Fs00CdFiCst5a/OATHYeGahQw3yZ+negDjnQEfvIrCByprHMfuftG9uUbeMenh/BpA9 4aPRACMN/SCOKrqK18+SAnNLui6Gcofrw/qUu8XdPVtKslKHRTjtg+uLcsYhXhTkSLRU eefkRPbCNZO+xjiP4ZdVFfrNHLW/+DZqj3VUmvQ3akqpdJ/FcEMvf9+e/stvD4q+S7W6 fGJDGZ90JVvmwk811Lp7DkZMt/lv+p7MAXHMWtSzsRhvgeB6lsQW/09ArYjjcJpMNCn0 YFYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=1CSuEPbSQ7Vr7PX9swq/INk1poFdpJOwrZohRPPruuw=; b=tTHWvP/pi4Jv4hWWDlC7rBlr6wm7gPL6D956kt9mvJL1Haw3FrsGE4kFQ45mKldMD3 BEfhNJGYHSGpnGzPKLv9jBl2dIY+WyzAvzc4o7PxW6Y/C9cbc60lmqmYAJMmtH2oMslR IFyJifedD2toDoV6IlBRp4aoNSHlZpeJ8BarocXjv4O4Op3ifnUk6kO5jAT0EDDP0Ysf 9EUzUch5sB95yIrmGJsPHHrKxrZFi88ywA9Ebnlaag8DNs+fkKrpYBYomQWv9C73dtm2 A+3Y35FLxQHPohy6IBKLGKQdkk0aNHtFxYQhnQHrk0klc74LwgQVfETmygnmSJPSHJNf H/+A==
X-Gm-Message-State: AOAM530fusaRWsi3nEtSFy1Nj6pblju0f+bq7f5xEjT4kxxafUYELMjX rCOMVvqo+Pi+Lmg190zLgMY=
X-Google-Smtp-Source: ABdhPJw8B8xcoR/6agVNWmks9GRI82pKgbl8qvfSi7zKNoZ90opcpwZmEyDBkQP+38toalFTlGpiOA==
X-Received: by 2002:a17:90a:a60a:: with SMTP id c10mr17155411pjq.143.1590360083767; Sun, 24 May 2020 15:41:23 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id c24sm1072906pfo.124.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2020 15:41:23 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
In-Reply-To: <>
Date: Sun, 24 May 2020 15:41:21 -0700
Cc: Sarah Chen <>, "Acee Lindem (acee)" <>, Huaimo Chen <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Gyan Mishra <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 May 2020 22:41:26 -0000

Hi Gyan,

> Do you know if the dynamic flooding algorithm discussed during interim ietf by Sarah and Toni is the same as the one implemented by Cisco on Nexus platform or is Cisco’s Dynamic flooding a proprietary implementation?

It appears not to be.  Our algorithm is not limited to leaf-spine topologies and has been tested against numerous other dense and sparse topologies.

> Why would we not want to adopt the best algorithm that is best for both full mesh and non full mesh leaf spine topology algorithm that works for all physical topologies and adopt that draft.  

Proving that an algorithm is ‘optimal’ is going to be very difficult, both from a theoretical and market standpoint. As is frequently the case with IETF, we are proposing many ideas and trying to sort through them.

> Unless a one size fits all won’t work I would like to understand why one best solution draft we come up with for an FT algorithm for all possible physical topologies cannot be picked for WG adoption.
> Why would we want to adopt multiple flooding algorithms?

Adoption does not imply that it will be standardized.  It merely means that it’s part of the working group’s effort.  It is up to the WG and the market to decide which algorithms we should pursue.  Some may be enhanced, some may be revised, and some may be discarded. We can also adopt all of them and let the market sort it out.  That’s probably not the optimal approach from a technological perspective, but making real decisions in the modern IETF is very hard.