[Lsr] Fwd: Open issues with Dynamic Flooding

tony.li@tony.li Mon, 08 April 2019 14:27 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 8D5C71203DC for <lsr@ietfa.amsl.com>; Mon, 8 Apr 2019 07:27:30 -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 UKoUqP2VKBI6 for <lsr@ietfa.amsl.com>; Mon, 8 Apr 2019 07:27:28 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D76651203D9 for <lsr@ietf.org>; Mon, 8 Apr 2019 07:27:28 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id b3so7426136plr.7 for <lsr@ietf.org>; Mon, 08 Apr 2019 07:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:content-transfer-encoding:mime-version:subject :message-id:references:to:date; bh=Od6tlygip0Ke6Hwn0h5igiPIqc/IKp8twNoLvM+ZQdU=; b=IP/5y6nA4p9Z3/+t6lJ/H7nrGYsyMWaN3jhMF/iaomLD2DkUAsnthU8j1EqpSaZptg v8CYRKlOciQh+/fo17vWWYcMJPdyrP9i4/ZOrwFrHrhzTYK1WLGkPHO9fbMXw00mD6My 4zHI07CRKQrm+7eVMhDclPPt10/1GOCa1O3tWdGCUXXbBsE/QwZua1ATEfOv2xzvSgnN cZZchY8fCuXLz7vrQ2Ef0h5W5oNme1k+qLpNty9hH9lG4B3pU1BDn/NzJv1CArbRwvfU zNfgp4bnSgKuIKL5X0JstEWkMdsBYctSK3ocHWKxefSIq9vx0MUShOZ95gzaA7wPP/6s JYHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:content-transfer-encoding :mime-version:subject:message-id:references:to:date; bh=Od6tlygip0Ke6Hwn0h5igiPIqc/IKp8twNoLvM+ZQdU=; b=P9FROMwyeRIn6YWRqjveC1OB3oLwHdkWlqtAcXyFm5Ymwgibsita9ElG4lJeiUPBJL KcyKkzqjY/1TQ/WdI0wjKjva9ZfLl/znkoeCO7KDGI585lUn9sSiOuCEDmytKVjZSe7z LjvJtUjDfisJf/Z2VZ3xKcGVFjyLxvV50OYhq12YShxqoJchscV5ZmyGSiVLIfyfFzdH d9K3s7MbPi1PGBtkp0RzhwfkF9l890Dk2vwOzodPVrOV7TAgx29izb2eRWzXMyyl+3+L LauI4G6lG/NmjLYaGrGpcIjxs3PzPE3XyeFOMFM2qtvfjtU8JsPWkqzWPUxTJWLWg5h+ Ln2w==
X-Gm-Message-State: APjAAAWyyUyrBPxlZWAS8xrbaCxFnVbS8XWDKSNix3ul8uu/F1aEL8oA hDvxzGklvMT0nSxOBltHgOzS3uru
X-Google-Smtp-Source: APXvYqzlctAsOImF8h95gEladv72mlcTgD9E/qT7w1ioUD23t8ShwC+995VUeWWYZ/l8sIR5oRDj7A==
X-Received: by 2002:a17:902:8c97:: with SMTP id t23mr30557574plo.110.1554733648084; Mon, 08 Apr 2019 07:27:28 -0700 (PDT)
Received: from [192.168.1.5] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id w18sm47402770pfg.75.2019.04.08.07.27.26 for <lsr@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 07:27:26 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <783C6E19-A730-4F18-9447-0582A8FCCA07@tony.li>
References: <15C35B7A-6402-4EE3-A85B-5FDCFAA20162@tony.li>
To: lsr@ietf.org
Date: Mon, 08 Apr 2019 07:27:25 -0700
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/4yW1QNeEH6ApeEgy7xrRKxFUm6Y>
Subject: [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: Mon, 08 Apr 2019 14:27:31 -0000

Hi all,

It’s been another week and we’ve had a few more very interesting conversations, but we seem to have not moved very far.

Have we converged?

Tony



> Hi all,
> 
> I hope that everyone had a safe and uneventful trip home from Prague and that no one else had the seat right in front of the screaming baby.  ;-)
> 
> I would like to re-open the discussion on the mailing list. Based on the off-line discussions that I had with folks, I believe that we’re leaning towards including the LANs in the signaling and rate limiting link addition during repair.
> 
> Dissent? Discussion?
> 
> Tony
> 
> 
>> On Mar 4, 2019, at 9:54 AM, tony.li@tony.li wrote:
>> 
>> 
>> Hello,
>> 
>> There are still two issues that need to be discussed and I was hoping that we could make progress on the mailing list before Prague.
>> 
>> 1) Temporary additions to the flooding topology
>> 
>>   There are several cases where we would like to make temporary additions to the flooding topology: repairing a partition of the flooding topology or adding a node to the base topology for the first time. We can:
>> 
>>   (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time.
>> 
>>   (b) For each node adjacent to the partition, add no more than a single link across the partition.  If that does not repair the partition in a while (LSP propagation time + SPF time), then add another link.  
>>        Iterate as necessary. This has the advantage that it minimizes the risk of creating a cascade failure.
>> 
>> 2) Inclusion of pseduonodes in the System IDs TLV
>> 
>>   In the general case, a topology can include LANs. If a LAN is in parallel with a P2P link, the Area Leader cannot currently distinguish between the two links. This can be of importance if there are other 
>>   systems also on the LAN that should be using their LAN interface for flooding.
>> 
>>   We propose to change the System IDs TLV to include a pseudo-node ID as well as the system ID.  It would also make sense to rename the TLV to be the “IS-IS Area Node IDs TLV”.
>> 
>>   Behaviorally, we should add a requirement that if the Area Leader includes a pseudonode in the flooding topology, then all systems with an adjacency on that LAN should use the LAN as part of the 
>>   flooding topology, whether or not they are explicitly listed as adjacent to the LAN in the Flooding Path TLV.
>> 
>> Thoughts? Comments? Flames?
>> 
>> Regards,
>> Tony
>> 
>