IETF Logo Mail Archive

Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies

Eric Rosen <erosen@juniper.net> Mon, 19 November 2018 16:08 UTC

Return-Path: <erosen@juniper.net>
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 388AB130DD5 for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 08:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level:
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 6ZdDzEVU_CFE for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 08:08:45 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 930A41294D0 for <lsr@ietf.org>; Mon, 19 Nov 2018 08:08:45 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAJFnXK9003103; Mon, 19 Nov 2018 07:52:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=nbPMmajHyqD7P9nh5Flk3vu1oXD3T5wl5MO81ox6xfc=; b=u6xvFD7rSA3gVhUiJDGleCNTdRonws4wwkdTGhZBj+6OqtB8dlciWdA341lIYSFxjacB VJFT5RuMfxEJ4bmtB+OTs682M940K2F6wKeHLREyWDY98ONtLVR51unBPGIo2Qc9aevq XYmIcW0rjoTYHJIPGqs6PoJyaNJm3LD+580pExnESMuodLwbBVmVJfjEEIZ18aaAb8aa eHrOXyiWFOU+WI4hCHdOiSDrYX7D3njZE+TYmqJUFUATKbr5lUaNmINJWbd/PLbxn3CZ 2SN2ZhQsi7OHx17Mc/b5rjmD4618jEoX+xDYZgVTwCP98ZaX3EfJR3QbbkeUV6yWmEUj Zg==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) by mx0a-00273201.pphosted.com with ESMTP id 2nv04br0ct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Nov 2018 07:52:30 -0800
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com (10.167.108.27) by DM5PR0501MB3847.namprd05.prod.outlook.com (10.167.108.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Mon, 19 Nov 2018 15:52:27 +0000
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf]) by DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf%5]) with mapi id 15.20.1361.013; Mon, 19 Nov 2018 15:52:27 +0000
From: Eric Rosen <erosen@juniper.net>
To: Henk Smit <hhwsmit@xs4all.nl>, "lsr@ietf.org" <lsr@ietf.org>
CC: Gunter Van De Velde <gunter.van_de_velde@nokia.com>
Thread-Topic: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies
Thread-Index: AQHUakD2hsB76W8wyU2shUrCQT0hoaVXazcA
Date: Mon, 19 Nov 2018 15:52:27 +0000
Message-ID: <ceb7d44d-20b5-9393-326b-710fdde02b23@juniper.net>
References: <b74d3ca68bf7782e97060dabeb0362da@xs4all.nl>
In-Reply-To: <b74d3ca68bf7782e97060dabeb0362da@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR11CA0093.namprd11.prod.outlook.com (2603:10b6:a03:f4::34) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3847; 6:81q4tcXH+JDuNhqImuVrOS52Dy11egSVcn1soB9odYT7gu0aYtrle9qgFwCu0w2k/AOca3tnRb5Do630UMsY46b5DeLfKmKmsVs21kiIPqKPh5rAtJsdRwDx2SR46v8mwZYT8y6Qm9yYGYRcCa37BEJuR66YmlhUtOUrQVO6uJFKCvH+3lODl02qzp9bdIaq2yC7qIUNB0bnXm+ixBLtNGtVcVpPrNdMop4KoRVXqSkDavu1U9gmbfV+GuQq3iUmfa4KtAhp44OV/OmdKtCCE6I0H3enYqelBsu3zJcja3puYWgi4XmKOJW2OmW5GB342zYqOmrY7yeVUpYlfJaS9hGNmE+azRxE2X44phHiwfqMpWA+arY28xgJoN7F3tIHRrEEsQY3TpbnI54hZfRpE8dQqz+RAyBRgzGduhMMR6/FjuV4cziQh1NaWyKmeTjYEuJmFYKJz/cy/aB0Lsl0ZQ==; 5:1TQhhIUDtStDRbzk3xFXfmiq6m7lQwXIWBBa7aidGYhst7YkCa6zpQpBVKiIvJhN5CBw7IWkxfhpoQswAlxUIZV2WOY5V3lSknzdrxLe0AmlcGJpExMihSYa0YsZ2tl5BkSjuCxpBRzFjbu4cWS0OTXl38LXNesp9+OXzoBEuPw=; 7:bPwvOMUHYqa6vVvtFGRo1afNDNhrq0yOt5IQlgSV7wBSMVfSzIqIAJ+YanXjAztzN8YLjj68rNYWCpbL2JUKQyMEqEStON1q6Uxi+QTLGV/+igQEuFQBihdWNMxDId008LxVbw1+mXcPhgV+jmKuUQ==
x-ms-office365-filtering-correlation-id: 6ec15b57-f38d-4bc5-4210-08d64e37016a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM5PR0501MB3847;
x-ms-traffictypediagnostic: DM5PR0501MB3847:
x-microsoft-antispam-prvs: <DM5PR0501MB3847A9CB4ED4C1764209EA3CD4D80@DM5PR0501MB3847.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231415)(944501410)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM5PR0501MB3847; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3847;
x-forefront-prvs: 08617F610C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(376002)(366004)(39860400002)(199004)(189003)(446003)(11346002)(102836004)(386003)(6506007)(31686004)(25786009)(26005)(186003)(68736007)(6246003)(14454004)(53936002)(478600001)(66066001)(6512007)(2906002)(229853002)(5660300001)(296002)(316002)(97736004)(36756003)(110136005)(8676002)(2501003)(81156014)(81166006)(6436002)(6486002)(71190400001)(71200400001)(8936002)(256004)(14444005)(99286004)(52116002)(106356001)(2900100001)(105586002)(86362001)(4326008)(486006)(2616005)(3846002)(76176011)(31696002)(476003)(6116002)(305945005)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3847; H:DM5PR0501MB3864.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: WG071/muCWIz/LHcmzmqrFmVY7W18vZPUkzEJ+dTZbd54UP5D+UwDymg/AxsaXRXcX3Oix1x5nJBm8YTjui448wG0cuxrxZ3wH3LBymAUQN5vwH8EYl3Jp/z5N9Nhl8CYhYSoo7PGpZFtfmFklTVgLfHqOVNCB7KBd44GjAkC1uKSTQ2UzXxNr9aqtjtdg/pxUp5LAhyo+YmcS9l6ayrcFFZAjFlkQp9qABYK0PJKhMcASSNsAuieXqFU87jvJwHi1OStRjCHpXkanaqVrYCovug360h1lOr69OwwpQTxfHnqw9uNHBrkjAdNbU3RzxlqE93dCtzbW/FONSrx1bPgma21mzrDzzXrTPEQTkVv/c=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <21A83F386A2688469BF279844FC76E2F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ec15b57-f38d-4bc5-4210-08d64e37016a
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 15:52:27.7255 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3847
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-19_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=675 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811190146
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UlFIqszWlMBlXSrCzYj0UYsukio>
Subject: Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies
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, 19 Nov 2018 16:08:47 -0000

Let's test out this simple algorithm on a simple topology:

A--B--C--D--E--F

where B and E are both configured as potential anchor nodes.

To make it even simpler, suppose we set this up in the lab, and power up all six routers at the same time.

Now there may be some moment at which:

- A and C have seen LSPs from A, B, C, and D, but have have not seen the LSP from E.

- D and F have seen the LSPs from C, D, E, and F, but have not seen the LSP from B.

So A, B, and C will choose B as the anchor, enabling flooding on AB and BC.

Also, D, E, and F will choose D as the anchor, enabling flooding on DE and EF.

C will request flooding to be disabled on CD, since it leads away from B.

D will request flooding to be disabled on DC, since it leads away from E.

So there is no flooding on CD/DC.

Now A, B, and C will never get an LSP from E, while D, E, and F will never get an LSP from B.

Since CD/DC was never down, there is no reason to do a database exchange over it.

It seems like the network is permanently broken, as the flooding topology is partitioned by CD/DC.

Did I miss something?

v2.23.0 | Report a Bug | By Email