IETF Logo Mail Archive

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

David Allan I <david.i.allan@ericsson.com> Wed, 10 April 2019 13:30 UTC

Return-Path: <david.i.allan@ericsson.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 4CABC1205F4 for <lsr@ietfa.amsl.com>; Wed, 10 Apr 2019 06:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 foratzoDZ1CM for <lsr@ietfa.amsl.com>; Wed, 10 Apr 2019 06:30:38 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730070.outbound.protection.outlook.com [40.107.73.70]) (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 829081203D1 for <lsr@ietf.org>; Wed, 10 Apr 2019 06:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0o+vwOX0gHXUv/6FF0e5kFkf0SAvr+22u/AjRvuJij8=; b=DhHZKPyGQgLGvkQdh3WR3DJx9P6ju4gikcumDjdblwPgAhZ7y4VP1ZJWfLE7YPozQ9ihrzva6S4u8xdoKkXbvhqUhG8tgwKKenQYiYS61p0SXdlQHHfHthopv2H4d1ji10ibqt4drtWgF8lKfOZYN0FNeXvWx7LCiQp51YjYZ7I=
Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB2760.namprd15.prod.outlook.com (20.179.157.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.19; Wed, 10 Apr 2019 13:30:35 +0000
Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::84c2:a1f3:4f63:c09a]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::84c2:a1f3:4f63:c09a%3]) with mapi id 15.20.1771.016; Wed, 10 Apr 2019 13:30:35 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: "tony.li@tony.li" <tony.li@tony.li>, Huaimo Chen <huaimo.chen@huawei.com>
CC: Les Ginsberg <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Fwd: Open issues with Dynamic Flooding
Thread-Index: AQHU7hdFncR5xXjhR0eo34rquP2VHKYz8CYAgAAKn4CAAAczgIABYOfA
Date: Wed, 10 Apr 2019 13:30:34 +0000
Message-ID: <BYAPR15MB3078453A883C628654B4E8E3D02E0@BYAPR15MB3078.namprd15.prod.outlook.com>
References: <15C35B7A-6402-4EE3-A85B-5FDCFAA20162@tony.li> <783C6E19-A730-4F18-9447-0582A8FCCA07@tony.li> <BYAPR11MB3638B650F1543A2AC2A2C511C12D0@BYAPR11MB3638.namprd11.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D463B8EF88@sjceml521-mbx.china.huawei.com> <9F6A74D7-5F7F-4B5A-891B-7DCA94F50569@tony.li>
In-Reply-To: <9F6A74D7-5F7F-4B5A-891B-7DCA94F50569@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com;
x-originating-ip: [45.72.210.44]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 64c8022c-f939-4b71-89a5-08d6bdb8b68a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:BYAPR15MB2760;
x-ms-traffictypediagnostic: BYAPR15MB2760:
x-microsoft-antispam-prvs: <BYAPR15MB276013685BDA76DDA5F980FAD02E0@BYAPR15MB2760.namprd15.prod.outlook.com>
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39850400004)(136003)(396003)(199004)(189003)(13464003)(85664002)(106356001)(52536014)(14444005)(105586002)(74316002)(256004)(4326008)(33656002)(25786009)(5660300002)(14454004)(6436002)(53936002)(6306002)(99936001)(966005)(478600001)(305945005)(6246003)(8676002)(7736002)(8936002)(81166006)(81156014)(186003)(55016002)(53546011)(26005)(9686003)(6506007)(102836004)(86362001)(7696005)(11346002)(316002)(76176011)(2501003)(476003)(486006)(99286004)(446003)(93886005)(3846002)(110136005)(54906003)(2906002)(66066001)(229853002)(68736007)(71190400001)(97736004)(71200400001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB2760; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KPcCFOTJop4o41Fm8wVBXXFRAJCNXaGuD/P88W44zalYCnr0qO6s7UMGtyNeSO5rZ56O3KW5eHi91JETG/rLoQVTkHzvHd56ZIYZfhbsJJYhHGD8kZDiSaINEt+889sadkG43rZzRKqXI7Gaghf07DiGbMc70Wpgq9yoQvQiiq5zE/5hsN7n6B7QwnPL/dzyrVR+/82MayaKBB+wt70adTwO3QTV4Vfw9GeZ+oVA+RA5OLgcaul0pcNpDzIy5oJxh6fTWiZwVegn5nkYXgvLcYRerwKEK1uGWqJvpEngp70xs1QQpJEjIIlTqgSXSZVzmRKjq6X7NvV4cAH1jsUxNMHyxDn3zOJQw/XbxBNYS+GUKtohZnF3bBdz7ok3YE9HJi8OVBe7jYlzese8/MriwN0Ks7lmV/zZReHRWQCmoYU=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0269_01D4EF80.0BB80A50"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 64c8022c-f939-4b71-89a5-08d6bdb8b68a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 13:30:35.1637 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2760
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/87m_kBM7uTYUyfKaXxm-lmVhl-8>
Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding
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: Wed, 10 Apr 2019 13:30:46 -0000

Hi Tony:

So for my edification/education, this is a general behavior that in the absence of any specific algorithm is postulated.  (?)

The piece I do not quite get is "adding until fixed".  Is the working assumption that things have broken down to the point that there is no synchronization of the topology and the repairs are "blind"? Hence "adding until fixed" is adding until IGP exchange appears to have  minimized the changes in the LSDB from some previous state of the FT or some other criteria?  

Just checking
Dave

-----Original Message-----
From: Lsr <lsr-bounces@ietf.org> On Behalf Of tony.li@tony.li
Sent: Tuesday, April 9, 2019 12:13 PM
To: Huaimo Chen <huaimo.chen@huawei.com>
Cc: Les Ginsberg <ginsberg@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding


Hi Huaimo,

>    For "add temporary flooding in a rate limited manner", can you give some details about how does the rate limit manner work for fixing a FT split?


Nodes that have adjacencies that appear to be crossing the FT partition can enable temporary flooding on that circuit. This will hopefully repair the partition.  If not, the node waits awhile, and then adds another link to the FT.  Iterate until healed.


> how does each node get the rate limit?


Rate limiting causes each node to do so ’slowly’, where the exact values for the rate limiting are implementation specific.


> Will every node add temporary flooding on a given number of links independently?


No, not every node.  Only those that have an adjacency with a node that appears to not be on the FT.


> If so, there are lots of links to be added into the FT temporarily for fixing the FT split.


Yes, because this is a distributed algorithm without any centralized coordination, you can easily imagine circumstances where there are many links that could repair the partition and thus many temporary additions could be made. This is why some feel that rate limiting is wise.


> This may cause some issues.


This may be an understatement. :-)

Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email