IETF Logo Mail Archive

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

tony.li@tony.li Sat, 23 May 2020 01:02 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 A32C13A0E7C for <lsr@ietfa.amsl.com>; Fri, 22 May 2020 18:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Zwgp6QSNpaDR for <lsr@ietfa.amsl.com>; Fri, 22 May 2020 18:02:17 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 93D4A3A0E81 for <lsr@ietf.org>; Fri, 22 May 2020 18:02:17 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id j21so5777342pgb.7 for <lsr@ietf.org>; Fri, 22 May 2020 18:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=knwraGd8vqkDHJFfiEryDh2vYQHwLWo8rL7i9yZ+oiw=; b=rznWSbhUroC5H4JSi1pGgmNjEeZd4ATjM+zbfnA/NmXCHxodZRJEnQGq1jUGp5IKjT yah5Y/YltwjyHoR3zeMDuzz7t5JnxctFbvJhlY+LDKEh48k0Y8TD89ZtcBSs7UClU7TR y9Rydzo4pxcEeVc84oT0hd63nb06SuWpPcyU0UNHSZZsd37GNqgdOg42YBiXCzRGnzEd Eh4q+jgj0NetBJ39VrXTZ1swTTjqAdJ4CVAQGax15kMUbLSUYx+IexYe5DWNPh05Y9pf lWY1WJNLGvIooWQFMH7ZbL9y4G/MSLe1QVD5FWf1/TCcOIMB486/LSRs/s9IGqTQYkQO R8jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=knwraGd8vqkDHJFfiEryDh2vYQHwLWo8rL7i9yZ+oiw=; b=QgIyMJMHEgNXmA/98nzxSJMH0qe9/TQ9xSMSa6lsN2g8N+KGBrF9v+j6NFDzajPNuO d24aXK/RhnhtyBX2La4gKOR7W4JCyq0GPssTQ7gf9S9cuvs4nNy42T9FkSvO3F8wkFXs fbUgWOoMZepGkChiwprnCqsP3rs7uTNNJ0ftEc9MyPxlpn9mVNRMGlN7MXs2enrLTydy 4DisHtDEktRxNK5z5O7c06CbgH6203sGt0Ap9WbwlbJlqn8hZW4KeDYyBsDZQ5tDT5O3 l34jdcQkSj8lw5210nSy5z/sO0BEEjHJYr9OehdfwnSd8CBLjl3nJOIlN5E46Ng/TaMJ 83rg==
X-Gm-Message-State: AOAM5313bNYcJhvVUmMTofE9Hu9uw1tEnajz45tYz0xm4twJPnNM9pph wWrpUAPhqobYlu3TxfgB6iA=
X-Google-Smtp-Source: ABdhPJwzEzagZWgKhEuuiDU/+E0q6U8lv2zM4IXwlalFtQyjzoCP6udiZMHVkDqtaPWYbyTXZbflow==
X-Received: by 2002:a62:b402:: with SMTP id h2mr6581138pfn.221.1590195736277; Fri, 22 May 2020 18:02:16 -0700 (PDT)
Received: from [10.95.93.131] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id z18sm7879794pfj.148.2020.05.22.18.02.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 18:02:15 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <331DE9C9-BF8A-483D-B4D5-366D3FBF4C22@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E55AD659-D2FD-41E9-A9B2-45FA5ED1E894"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 22 May 2020 18:02:13 -0700
In-Reply-To: <CABNhwV0CC6wBrPkiA+vKjpX--JPBPfRzJ=0GDP3BqH4NPaecKQ@mail.gmail.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
References: <63330FD6-EDE8-4938-AA85-948279C57E34@cisco.com> <DM6PR06MB509842BA0E42A4938ACB2B94EEB80@DM6PR06MB5098.namprd06.prod.outlook.com> <CABNhwV3jQ=C6ynJBsKhJW_b=hkq7CKPFG2ci0vXE_0jZH9KtXQ@mail.gmail.com> <MN2PR13MB3117C43CA052E4E29D7428CBF2B60@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV2Y3kemTdHYBamZwAB+m5DefxqTC0shPan2cGHd9TARTg@mail.gmail.com> <MN2PR13MB3117E84C778B11D71FAF8135F2B70@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV1W3EDJpqUjLGj3-E-8L1R=75oAgtHX==9qkfrvrZy2ZQ@mail.gmail.com> <MN2PR13MB3117A5E68B341A203266C64AF2B70@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV3e_qm=RmTQyQ+yCWN+pt_d1Aw8-W9gkRwH+_kAyphu8Q@mail.gmail.com> <424B17B1-D66D-4708-A819-855E972841AF@cisco.com> <CABNhwV2cDoNotaePw30eZa5wE61NC_vh8cFaZHh_nPqs1ibFsg@mail.gmail.com> <E093695B-78DE-4332-B4E7-87343077624E@cisco.com> <CABNhwV1cfOE+trZGM-s44xU0su5RUgL2c7ubRCdc3EFCWsdujw@mail.gmail.com> <MN2PR13MB31179DB87C96DA218F9EB1D0F2B40@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV0CC6wBrPkiA+vKjpX--JPBPfRzJ=0GDP3BqH4NPaecKQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xuPd1npKWAhVTlkUGhCVjBjcKbs>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
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, 23 May 2020 01:02:20 -0000

Hi Gyan,

> I think with clos spine leaf the mesh is much more intensive and problematic with ECMP then a circular topology nodal mesh that results in duplicate redundant flooding that slows down convergence.  With spine leaf it’s like an X horizontal width axis and then depth is spine to leaf links.  With spine leaf as you grow sideways and the spine expand the redundant ECMP grows and redundant flooding grows exponentially and is much worse then circular nodal mesh.  

One very nice thing about dynamic flooding is that it computes a flooding topology at the node level.  If the adjacency between A and B is on the flooding topology, then any single link between them may be used for flooding.  If you have 128 way parallel links, this is an immediate 128x improvement in flooding overhead.  What’s more, A and B do not need to agree on which link they are using and can use different links, resulting in an asymmetric situation, without any loss of correctness or performance. 

Regards,
Tony

v2.23.0 | Report a Bug | By Email