IETF Logo Mail Archive

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

"Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com> Fri, 23 November 2018 09:52 UTC

Return-Path: <gunter.van_de_velde@nokia.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 9A17F130E0F for <lsr@ietfa.amsl.com>; Fri, 23 Nov 2018 01:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.361
X-Spam-Level:
X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 d0QVaU8nKGWY for <lsr@ietfa.amsl.com>; Fri, 23 Nov 2018 01:52:55 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC88B130DFC for <lsr@ietf.org>; Fri, 23 Nov 2018 01:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WN+kc1vVkBEszQ/81J1815Cu3vlpxF+Yv3eskZjgzeo=; b=nBRM2YJu5n/RINErCOS0qQdwbfbI0JFgwm+0WwoHh0Q+TjIPMCe5q54rkDH4b9tu/xW50YggnceuqseOQZmvJkE16aJykkShcmhKZNqR0QkHbIoQIuFKPM26MVVKVsBqP1uCKAFNJJG9CKwos3TZU6IaidaCecZEEeKlSI3J93M=
Received: from AM0PR07MB5137.eurprd07.prod.outlook.com (20.178.19.82) by AM0PR07MB5780.eurprd07.prod.outlook.com (20.178.116.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.13; Fri, 23 Nov 2018 09:52:52 +0000
Received: from AM0PR07MB5137.eurprd07.prod.outlook.com ([fe80::4c13:fd23:49bf:f519]) by AM0PR07MB5137.eurprd07.prod.outlook.com ([fe80::4c13:fd23:49bf:f519%2]) with mapi id 15.20.1361.018; Fri, 23 Nov 2018 09:52:52 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: Eric Rosen <erosen@juniper.net>, Henk Smit <hhwsmit@xs4all.nl>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies
Thread-Index: AQHUakDrnsuO1jQe6EuTXvAXtb49raVXazuAgAXe30A=
Date: Fri, 23 Nov 2018 09:52:52 +0000
Message-ID: <AM0PR07MB51378CA82CA13E337C45AB0AE0D40@AM0PR07MB5137.eurprd07.prod.outlook.com>
References: <b74d3ca68bf7782e97060dabeb0362da@xs4all.nl> <ceb7d44d-20b5-9393-326b-710fdde02b23@juniper.net>
In-Reply-To: <ceb7d44d-20b5-9393-326b-710fdde02b23@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.132.129.69]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5780; 6:PGECle83dFvB4Ejm2kHWseAUXzHF0Mlxl2epuVGb+sdEvhFYFqoneQ4/NZk5kqSip8vygEusW6RGkSsqW4BY/8KCyQF81s8dthodl2OnJflfyYnniDrvlugpgymqhyyz7HPJd2tSG4StEI8N0Ma29L78V8t9tCstEhVsuW9ZcTrO0BW7D715nc9BfDSyvX31lOx8PY1mB6aYuT6gv3z2XlwoFbqMLJNy8DwS+jv83bap6prjifBOEgTizD6nlCgh1zHx0IzGzYR2BKasWFij0EfvAM88r505aRmHSxUe4qDl30RRDJZ9+jx2H12d/YoGPjB2AAlxIkxcSOrW+U7k/w2rnJZheSCeFHtBHYEJjpPHlq3/dZeq8rZnWcOI32JGo8WN+xKjfjIt+khMBvzqAoZ3kT6ZLL09c/EfHkvRhEMlIBHo41QhMlJ3x8UFC5S0NRno36ZLyYRiWMar+S9Upg==; 5:4FUVTgmlddIdqnJEz3uyhbzGh0IAXyXpkUUt0qGMyfl0AfsabzrBpgJNGHORMpHQ1DpdAW23wI9Cz5DhHer1XY7YM80puGpD82HUNlnTqA75XvQZh7OJ7MFqzhAeCj49V+1FQX3F66C5YhtvGz0hKS+FXR9yaPMi5HZdv6k4O0k=; 7:NK6joOoOpeKEITH++YDx9fP5hZC1JRc5VAob4ykaCNwuIS0PmUEL5kayE5bqXc+DZup/NNj7+QZ5k5c1tGa++BsauN4jM7XOZNocEQSbBIqEFoD+VhDOn1XyvBE8Ks0u3rxKCtvUzqvMy5/j2kUudg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c7a7b601-fdba-4355-671f-08d651296f62
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB5780;
x-ms-traffictypediagnostic: AM0PR07MB5780:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com;
x-microsoft-antispam-prvs: <AM0PR07MB57807A4FC6C72EBA2218784AE0D40@AM0PR07MB5780.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231442)(11241501184)(806099)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5780; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5780;
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(39860400002)(366004)(346002)(13464003)(199004)(189003)(186003)(99286004)(7696005)(106356001)(86362001)(53546011)(76176011)(110136005)(6506007)(316002)(11346002)(102836004)(105586002)(26005)(66066001)(486006)(74316002)(8676002)(7736002)(2906002)(561944003)(81156014)(33656002)(446003)(305945005)(81166006)(8936002)(14454004)(478600001)(2900100001)(97736004)(3846002)(9686003)(55016002)(53936002)(6436002)(25786009)(6246003)(68736007)(5660300001)(6116002)(71200400001)(476003)(71190400001)(256004)(229853002)(14444005)(1941001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5780; H:AM0PR07MB5137.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EzvL+XnR7DAuDfww7MTVDNk8iXGNis0jylcFadzUYbztvW4vrS1FD10ULYHeaAkIYRszuR76ZW3kZuCqckkvE1P3eaFl2LkFvrOg5c9znsgBSP8E61z+eLgTe/Bk8+feGffe47nykcCL74L8GsdhwQLLjJ5hTesuS+c/tsIysB3cNXblQ4ZQZ0WqtWMyVAOwl7EfQaf9k3Labp6Zu7FWLRifm0xJxHjoXsMt+3n6FEWf9UzMKAytG74hYQ2JzzrzWAtW1laxmfgTLOP5emNqswOn4glsbGZjiW33WKv9xnNY+17Ax6sGzjeAS2nN7ijcG4PYIgkWRGKUoCCifQ7L17JNL3TMK8JxLpgXn2wxL6w=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7a7b601-fdba-4355-671f-08d651296f62
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 09:52:52.3107 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5780
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/iFWAEK4W87YgRBcZgYFDq2ZDrSI>
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: Fri, 23 Nov 2018 09:52:58 -0000

Hi Eric,

Indeed, my first impression is that you are indeed correct. Thanks from pointing this out. It seems to me a valid observation.
One of the first worries we had while crafting the draft is the potential of ending up with a fragmented control plane environment.

A first impression is that adding restrictions upon anchor placement when +1 flooding anchor is used (for example they must be 
directly connected (or at least not further away as "1-hop")) could resolve this. It would be less gracious, but the simplicity of the 
algorithm may compensate for it. 

Thanks again for sharing this observation.

G/


-----Original Message-----
From: Eric Rosen <erosen@juniper.net> 
Sent: Monday, November 19, 2018 16:52
To: Henk Smit <hhwsmit@xs4all.nl>; lsr@ietf.org
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Subject: Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies

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