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

Huaimo Chen <huaimo.chen@futurewei.com> Mon, 25 May 2020 02:50 UTC

Return-Path: <huaimo.chen@futurewei.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 852FD3A08C5 for <lsr@ietfa.amsl.com>; Sun, 24 May 2020 19:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 Rj9bRLOp0G3a for <lsr@ietfa.amsl.com>; Sun, 24 May 2020 19:50:06 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2101.outbound.protection.outlook.com [40.107.223.101]) (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 EFC083A08C1 for <lsr@ietf.org>; Sun, 24 May 2020 19:50:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CSGgiEs0wYFO8Ot23R/seuFjiIojDTKtKkrbCeW1bYVEUGZ45/Uo49CRDZH3iwFtfbLdrK1RgNjefrINYSuFlArcuXW69bW+z1zung3YFiIk4MlwaJF4DhoO95BdRK6opjrFymVuM4Jh8ypScttgQJOoylR0L+dzJYZ8KeSA7zRGs5qk7werLXQP+cVyWRAjq7MphdVCO9DaF/T2kwY07VoqyYhzQD6Gif7vByoKoCOCIJgq9HNsSkRSZytJNARsJfk8FJ3Bb7RvDwgXtekVQegjqhwSjyu3P7a1nuq0gsCAJhAGKLrs5ij2P760axz87l3fjsX0+3gSUKc5cW+x6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LEs8NmOsuDS+whrmcx6PjsJEL8hWi1UxKj8JdlW7HEo=; b=EM+1MSBwYm4eoYKpMRIqCHZHYlbdYgi5I81OB/FqW0F2f56fsRcj4lAR5RzJhPz4cUGFjPNTojoBmKKncxESaPknl5BmPwgkJrdv9Y/zds+kboKQnNQxxNcjZCIu8yUpEGvz4Qz5uXPHLyLO4m50nHWwAQNtkv+mqAGcQSeEogatc0sqjykFMXtPJAsUnGNkiu0HaGEUT8ZbW7FqeYiRIo67LmzsYfPYbMmD4tgSjV+TNQlV9v7MQUHQen8Yu0YjGUeysEsx7PYT4TR5b1Mfajyq5AoJWLse/z3ZUefo/6W7s2yAA8WV1pJWsWrAMr3vlbg/SskvyYdX2eKPMy8Evg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LEs8NmOsuDS+whrmcx6PjsJEL8hWi1UxKj8JdlW7HEo=; b=sTsjuLplRLsGtljgTX/vgZlc0963RxtRCDbVvFW4Lw25SB/sC3OYUsf0yE2WRcrNA3//hWHNPRFni3brst8Dho1i9q/gx7DDxsIMTI/6txxC/54XnYA+uomD4Nh5+xYhoeC6psBkoHwqlajB5mkGx/sMzDhDxn3jVf6hP/gIs8A=
Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3992.namprd13.prod.outlook.com (2603:10b6:208:26c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.8; Mon, 25 May 2020 02:50:02 +0000
Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::d5b6:8550:9c40:eec2%7]) with mapi id 15.20.3045.009; Mon, 25 May 2020 02:50:02 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Thread-Index: AQHWKvCWbO+rNwui80Sty0q3wo/aI6iuQDRQgAC6fICAAVrmiIAAx0uAgADIYX+AAL9sAIAAAVeagAA06ID//+MZAIAARoiA///qD4CAAHjEgIAAvJSBgAC7/oCAAAXCgIABSiKAgAGv54CAAEJoMg==
Date: Mon, 25 May 2020 02:50:02 +0000
Message-ID: <MN2PR13MB3117B809AB72C7C07CEA959AF2B30@MN2PR13MB3117.namprd13.prod.outlook.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> <331DE9C9-BF8A-483D-B4D5-366D3FBF4C22@tony.li> <CABNhwV3-rokZfwTGJi9fwe_DEoJB9L1cEUqz9FvCG4EFmLXFKQ@mail.gmail.com>, <CABNhwV1XfWXbCidA5jMB9dOOoDtCuGRt33ttaFLRGDywZkyfSA@mail.gmail.com>
In-Reply-To: <CABNhwV1XfWXbCidA5jMB9dOOoDtCuGRt33ttaFLRGDywZkyfSA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2601:199:4300:8e5a:74ce:8eb8:ed16:ceb1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2b747fcc-080f-4a65-9519-08d800565294
x-ms-traffictypediagnostic: MN2PR13MB3992:
x-microsoft-antispam-prvs: <MN2PR13MB3992525B6AEA8FA3955D1AE4F2B30@MN2PR13MB3992.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0414DF926F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NbyHNqCxjsessSv7QPHBOpT2NQsHkYpt3FYVYE8m04CQtUiLIb1Y3YFGeDnxaz7j14zS3MpDh73ISoBqqShQFz6Mkqlu8IsuP/aL6UlugYaLk8/aVQVNPx/tTmj8zZjynkisNdmi+zUo3vxbtV6kQjvFP0h9GV/RCagBmw+N4eKv9HTbsd6hKOy9jiHvDzpJ1BPM+MpTSEDmV9H2FdkpP+I/6+u/XzErRq+ggo/6jTTutTz4uiyPPFyHuxMFzXVLLrNmWQl0ftIY6vtHO852ygDdJ1UhTO3lrY89IwEephKnHVtbfCeGZhZYY5updzJTPzFHRqEoR++sGH7K8D4vwzFjoYYy64No5xVG4hMxXo3GjiBoPY7S2e/8MiryFlvLLrQ+Ajk2Rl/Tk3oMKViMyg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39830400003)(366004)(396003)(346002)(136003)(376002)(55016002)(19627405001)(166002)(6916009)(9686003)(2906002)(316002)(44832011)(4326008)(186003)(52536014)(76116006)(66946007)(66556008)(66446008)(71200400001)(66476007)(64756008)(33656002)(5660300002)(478600001)(86362001)(54906003)(966005)(6506007)(53546011)(7696005)(8936002)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 8mQrKISICHNfWnP9Oou2FNJiwtkARJt2c1zoRyEOpeTfDLpGEf9yWPHYEdSJKl6mQ2QWKAy0oyzu4vBo9LqJ8y2EHryCRZLVaULfuKFoYkPYvaV9iOEi4UFkk66I8Z8b4Vx1Au5nhVkerXi+ldWe1mcPcMqxMO7ojqGewuHOsNioRg+0qtpcdSQjv7Ax48itCNgWeVPD9Xeci6puLcnx3kjYQAhyV5Ac2V3YrnMPuqir/Pwtucrf6kSoIE1O3K+Z92B+wCK5C1ud2wpK0oUIE8rUwOP20PSA72iOBzLpYrzbg3yokQKtWVR4gqfbFfdtCgZ/tKJBVAXVM2nuaaJkAFqvOtaYJHVj9N84fZOTjt8fjt7hXYegA5yNon/NLpu7RlqNNrvWkLyJF/fvGSCMnO4VL48GEw7k8CwG2P6CbgqTabVxuDMDZmAy+cdCzfzkuPTlFqhJrQWH43/5s7NyF4lb4CeB1t+19A+vrbw1nf+JQm9NhT0eJTsZQ7bvNMefsKWYHTO5beFYh4MUbfUYghjpXxlS2czhdwzIcgkGZhSA8wkMDn3Cg057b+qWsr7C
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117B809AB72C7C07CEA959AF2B30MN2PR13MB3117namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b747fcc-080f-4a65-9519-08d800565294
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2020 02:50:02.4682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SPiOlCPRZsB12gVOahnUhbZmdyStoQq/UhjihThqvaWBS3JZCl6YxSRIfnWr1VFWhaiU79ko2WQntqfC4/1XIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3992
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Mpn38oho7iygiUoV4YpTMcVZ3RY>
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: Mon, 25 May 2020 02:50:09 -0000

Hi Gyan,

Gyan> I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems to be geared towards Data Center  partial mesh high x ECMP leaf spine architecture, where redundant flooding is problematic using either centralized area leader or distributed flooding using same dynamic algorithm,  versus the call for adoption flood reduction algorithm seems to geared towards full mesh but from what I can tell would not be the preferred for clos multi tier DC leaf spine topology with high x ECMP paths.

[HC]: The algorithm in the call for adoption is also for (or say, gear towards) clos multi tier DC leaf spine topology with high x ECMP paths. In the Appendix of the draft, a full mess example topology of 5 nodes is used to illustrate the steps of the algorithm in some details. Using this topology is for easily "drawing" it and illustrating the steps of the algorithm. "Drawing" a clos multi tier DC leaf spine topology high x ECMP paths to illustrate the algorithm in details is very hard in the draft.

Best Regards,
Huaimo
________________________________
From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Sunday, May 24, 2020 6:29 PM
To: Sarah Chen <sarahchen@arista.com>om>; tony.li@tony.li <tony.li@tony.li>
Cc: Acee Lindem (acee) <acee@cisco.com>om>; Huaimo Chen <huaimo.chen@futurewei.com>om>; lsr@ietf.org <lsr@ietf.org>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Acee

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?

Cisco’s flooding algorithm does seem almost identical to dynamic flooding.

Cisco Dynamic flooding - Nexus 9k

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920543212&sdata=qVG4uwYPelL1syGzMViZSvOodKoWy2dlL1AyZ%2BljmB0%3D&reserved=0>


Dynamic Flooding - Arista - Sarah & Toni

https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-chen-lsr-dynamic-flooding-algorithm-00.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920553208&sdata=v400uLAa%2Fu3RwJlHfYhplTzR4sXVwMpCZA%2B%2BSM6adgI%3D&reserved=0>

Flood reduction- H Chen - WG adoption pending

https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-cc-lsr-flooding-reduction-08&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920553208&sdata=ZA%2F1DXQYGsbJHynkM5V8bj6Y5VnuwM%2FHftO02nlmzLk%3D&reserved=0>


I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems to be geared towards Data Center  partial mesh high x ECMP leaf spine architecture, where redundant flooding is problematic using either centralized area leader or distributed flooding using same dynamic algorithm,  versus the call for adoption flood reduction algorithm seems to geared towards full mesh but from what I can tell would not be the preferred for clos multi tier DC leaf spine topology with high x ECMP paths.

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.

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?

Gyan

On Sat, May 23, 2020 at 4:43 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:


On Fri, May 22, 2020 at 9:02 PM <tony.li@tony.li<mailto:tony.li@tony.li>> wrote:

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.

   Gyan>. Agreed.  The dynamic flooding really helps with X way ECMP prevalent in high density data center clos multi tier leaf spine parial mesh topologies that scale massive bandwidth breadth wise horizontally for E-W flows.

Regards,
Tony

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920563199&sdata=hZ4%2BnucAFIcZGAaq3Tx%2FnmLMuEP63mHgoIPhvNTjW6s%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920573196&sdata=oxuHfFd0YTOLZPTeLYMIEAuHzJhzNsjkPyjO8DqgFkA%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD