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

tony.li@tony.li Tue, 09 April 2019 16:13 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 4F4DD1203BF for <lsr@ietfa.amsl.com>; Tue, 9 Apr 2019 09:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 P-68gcCyQBDW for <lsr@ietfa.amsl.com>; Tue, 9 Apr 2019 09:12:59 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 C820312086A for <lsr@ietf.org>; Tue, 9 Apr 2019 09:12:53 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id b3so9672215plr.7 for <lsr@ietf.org>; Tue, 09 Apr 2019 09:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eHW9uxEkZwEB6HhhD8YLSwCavAb+1fDiobaM7qca7Pc=; b=a6cnziXDqv2MeijQUJapFb0pxh0mV5SAKtTCdpBL932XZHr5VudU5DI8QFpccuiMji DOW4Vu9b4v9X54CLeGkPrmVYFlF59oNaWiJn9WCvbZn77lKaX3vQg+z+erLn/Hfsgx1m k5Xiyvs9Vj51M53zJtkbneRz3GhXiUP/Xrpwj7LHCO8TF/+otdEfQ9G+X0fu3tpFRDJQ ugtGLfJHKQhmTk7t8A/FivRLOw0MWWmM0Md4yDoW9vhr+Xpgll3nwehBfGXaCANg4Hmj CWRaGvVvotQJ7mLg5UlwxxCaYe3+JSpBy+KGp5QUTi5wBPAKYCYBH6IDysV3/4brvTyz cA6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=eHW9uxEkZwEB6HhhD8YLSwCavAb+1fDiobaM7qca7Pc=; b=lQpXzB7Ep8mw2IhrTzfSUSH0eyM+4yVXAeE2/dIT/uX8Amv/ckmoHsU2hD7atwmKVB m0uF6AuYlcnr0BMsRdLS3nTcqQtqYCv2wLn+Y0hQ1ge5p46UkJW1nyS14ZTqR7tmwMnY pG/duS/9k2MDAiYvTXa/mmMsJ+p68mXMNjmlF94axbMd59U2L0zU8bnGjJY9Dcksxhye dsvLe46gAlTRXcE+nuLF9P/nzljAre5wwZ113YUrZY7Zs5wwtt7wgf5OF8Q0HEACjADl bxtxuN6KsuPZl//YLmtc8GhBxQiCktdK/0LE40MNLK/j+DBmu3g3wW87yy4DGKW+WYBO grpA==
X-Gm-Message-State: APjAAAXiKuituMvR562gRQiC9MIOGQNe6wNne3CP4Kh7ngLwdKwClBcb UB+yMtxaBOLDEceEYiZRgBk=
X-Google-Smtp-Source: APXvYqwXj2/DSK5B9FQe8NF4pRRVzKOXgzepp6Q7Cu6D1NNlpDDs3qw6ATc+NUqBV6tBZAO32rnZig==
X-Received: by 2002:a17:902:9a0c:: with SMTP id v12mr11209460plp.184.1554826373269; Tue, 09 Apr 2019 09:12:53 -0700 (PDT)
Received: from [172.22.228.229] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id 6sm14608800pft.64.2019.04.09.09.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 09:12:52 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: tony.li@tony.li
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B8EF88@sjceml521-mbx.china.huawei.com>
Date: Tue, 09 Apr 2019 09:12:49 -0700
Cc: Les Ginsberg <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F6A74D7-5F7F-4B5A-891B-7DCA94F50569@tony.li>
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>
To: Huaimo Chen <huaimo.chen@huawei.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Og93MhIpxBDxV-OYShkN2MQ7JKs>
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: Tue, 09 Apr 2019 16:13:01 -0000

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