Re: [Lsr] Open issues with Dynamic Flooding

Peter Psenak <ppsenak@cisco.com> Tue, 05 March 2019 07:38 UTC

Return-Path: <ppsenak@cisco.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 11D34130FB1 for <lsr@ietfa.amsl.com>; Mon, 4 Mar 2019 23:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dDRRGs_h9Enn for <lsr@ietfa.amsl.com>; Mon, 4 Mar 2019 23:38:23 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826A2124408 for <lsr@ietf.org>; Mon, 4 Mar 2019 23:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1551771502; x=1552981102; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4F6cFwdIt/eR2sNzHBaQFLB+FBoUOXyllS+SzIuDr9U=; b=NrNVMzUQ4r5MfucenqiOodyEzs0HeanciK0P3r2uScG8H3Tn5Jgoa2TR h7dG8j8+yQrMeMcnXJqvIKjkxKfgjMifQE2+1TKkyj6xeK0dz/BpREn1N fLe7XIog9OmsZulZmPQXWYm0KIP3VSCy/F7h6dlyrCK9ydFwKDB4/4T9v 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAADeJX5c/xbLJq1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUwIBAQEBAQsBgneBAyeECIh5jHiYIYF7DRgLhEkChEk2Bw0BAQMBAQMBAwJtHAyFSgEBAQMBAQEhDwEFNhsLGAICJgICJzAHDAYCAQGDHgGBbQgPqFuBL4VEhGQFgQskAYRZhmWBQD+BEAEngj0ugx4BAYRrglcCpAQJkm4GGYp4iCqKZJJKgU4CL4FWMxoIGxU7gmyJPoFOhUA+AzCOSCqCIwEB
X-IronPort-AV: E=Sophos;i="5.58,443,1544486400"; d="scan'208";a="10491704"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 07:38:20 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x257cINt016574; Tue, 5 Mar 2019 07:38:19 GMT
To: tony.li@tony.li, lsr@ietf.org
References: <AAD29CF0-F0CA-4C3C-B73A-78CD2573C446@tony.li>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <c1adac3a-cd4b-130e-d225-a5f40bf0ef55@cisco.com>
Date: Tue, 05 Mar 2019 08:38:18 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <AAD29CF0-F0CA-4C3C-B73A-78CD2573C446@tony.li>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Fk5J_MvkKGi5LFF6wAHOdBYkMZI>
Subject: Re: [Lsr] 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, 05 Mar 2019 07:38:25 -0000

Hi Tony,

On 04/03/2019 18:54 , 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.

I prefer (a) because of the faster convergence.
Adding all links on a single node to the flooding topology is not going 
to cause issues to flooding IMHO.

>
> 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.

given that the flooding on the LAN in both OSPF and ISIS is done as 
multicast, there is currently no way to enable flooding, either 
permanent or temporary, towards a subset of the neighbors on the LAN. So 
if the flooding is enabled on a LAN it is done towards all routers 
connected to the it.

Given that all links between routers are p2p these days, I would vote 
for simplicity and make the LAN always part of the FT.

thanks,
Peter



>
> Thoughts? Comments? Flames?
>
> Regards,
> Tony
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>