Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Wed, 13 May 2020 11:02 UTC

Return-Path: <gengxuesong@huawei.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 637033A0DE6 for <lsr@ietfa.amsl.com>; Wed, 13 May 2020 04:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 CyNvCz5Vt8rs for <lsr@ietfa.amsl.com>; Wed, 13 May 2020 04:02:10 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0C9083A08E3 for <lsr@ietf.org>; Wed, 13 May 2020 04:02:10 -0700 (PDT)
Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D380CC11CBA64E44A56C for <lsr@ietf.org>; Wed, 13 May 2020 12:02:07 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 13 May 2020 12:02:06 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 13 May 2020 19:02:03 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Wed, 13 May 2020 19:02:03 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>, "sarahchen@arista.com" <sarahchen@arista.com>
Thread-Topic: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04
Thread-Index: AdYlyowYbZl6t8IpSKWUsfFF00+SFQAGECIAAGyWhID//7u1gP/81yFA
Date: Wed, 13 May 2020 11:02:03 +0000
Message-ID: <cd7fb45d780b472687fdf9ee4e1f032e@huawei.com>
References: <28604621f41f45a5a6b870413c4318e0@huawei.com> <15BFEDE9-5FCB-4FF2-A373-96231AECE607@tony.li> <5fae04a3f0c5429f84af69f3ba001abf@huawei.com> <4E9DA0B6-4867-48D5-ADF8-0E4500E067B7@tony.li>
In-Reply-To: <4E9DA0B6-4867-48D5-ADF8-0E4500E067B7@tony.li>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.157]
Content-Type: multipart/related; boundary="_004_cd7fb45d780b472687fdf9ee4e1f032ehuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/IeLgBQn9Y6LqBGN0OWbcYqPThtQ>
Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04
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, 13 May 2020 11:02:12 -0000

Hi Tony,

The whole process of temporary flooding is much more clear for me. Thank you for your explanation!

Best Regards
Xuesong

From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of tony.li@tony.li
Sent: Tuesday, May 12, 2020 1:03 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Cc: sarahchen@arista.com; lsr@ietf.org
Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04


Hi Xuesong,

Thank you for giving detailed proof, and it is very helpful to understand the mechanism.
As I understand, it is showed in the proof that if there is proper temporary flooding in R = E - E* - E’, same connectivity could be achieved by the flooding topology F’ just as G’. I agree with this.


I’m glad it helped.



The problem for me now is how to enable the temporary flooding properly.
Here is an example:
<image001.png>
The solid line presents the physical link inside flooding topology, and the dashed line presents the physical link out of flooding topology.
From the view of me, when multipoint failure happens, node 3 is supposed to enable the temporary flooding between 3 and 4, in order to connect with the nodes inside the red box, while the other dashed line between node 1 and node nobody is not supposed to do temporary flooding although node 1 is connected to the failed link directly.
It seems a little unclear for me about how the node itself could decide whether a dashed line should do temporary flooding or not in this case.


The problem that you’re asking about is partition detection.

To explain this, I’ve taken the liberty of adding some more labels to your diagram.

To start, each node has its link state database and the flooding topology.  Each node should receive link state updates from nodes in its partition, but will not receive updates from other nodes, thus the link state database is partially inconsistent and must be treated with care.

For example, node 2 will see updates from nodes 1, 6, and 7, informing it of the failure, but it will not receive an update from node 8.

Now, the job of each node is try to compute the partitions of the flooding topology.  In particular, each node needs to understand which nodes are in its partition. A node cannot know all of the partitions that exist, but it turns out that that’s irrelevant.

Once a node understands which nodes are in its partition, then it is a simple matter to see which links should be enabled for temporary flooding.  If a neighbor is in the same partition (e.g., nodes 1 and 5), then adding the link adds no value. If the neighbor is not in the same partition (e.g., nodes 3 and 4), then it becomes a recovery link.

The actual computation of the partitions is straightforward, with one caveat: we always want to perform a two-way check for connectivity.  An implementation should be doing this during SPF already, so this should be familiar. The reason for doing this is quite clear: in node 2’s link state database (LSDB), the LSP for node 8 will show connectivity to node 1 even after the failure. However, node 1’s LSP will clearly show that the adjacency has failed.  We can only infer connectivity when we see both sides of the adjacency are up.

Given this, the specific algorithm that you choose is an implementation detail.  You could do a breadth-first search or a depth-first search. Our implementation chooses to walk the entire flooding topology, building a tree of the partitions that it detects. [IPR note: we have a IPR claim for this approach, with the “don’t sue us, we won’t sue you” terms.]

I hope this helps.

Regards,
Tony


[cid:image001.png@01D6294A.F14F40B0]