Re: [Lsr] Flooding Negotiation bit

Huaimo Chen <huaimo.chen@huawei.com> Mon, 20 May 2019 20:55 UTC

Return-Path: <huaimo.chen@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 4BFEC12011D for <lsr@ietfa.amsl.com>; Mon, 20 May 2019 13:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 NzI5-s5z2EwL for <lsr@ietfa.amsl.com>; Mon, 20 May 2019 13:55:46 -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 B976A1201EC for <lsr@ietf.org>; Mon, 20 May 2019 13:55:45 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EE5B574E966D48BE8394; Mon, 20 May 2019 21:55:43 +0100 (IST)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 May 2019 21:55:43 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.85]) by SJCEML703-CHM.china.huawei.com ([169.254.5.233]) with mapi id 14.03.0439.000; Mon, 20 May 2019 13:55:38 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Flooding Negotiation bit
Thread-Index: AdUKj7ElhKNRmW1sRcavpBGnUMkPMwAPuxkAABfWarAAedRXAACMwZ9g
Date: Mon, 20 May 2019 20:55:38 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463BC5950@sjceml521-mbx.china.huawei.com>
References: <5316A0AB3C851246A7CA5758973207D463BB69D9@sjceml521-mbx.china.huawei.com> <C9C79F82-D68C-4843-91EF-2EC38833C51F@tony.li> <5316A0AB3C851246A7CA5758973207D463BB6C9B@sjceml521-mbx.china.huawei.com> <BYAPR11MB363885F9441C029341C5436CC10B0@BYAPR11MB3638.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB363885F9441C029341C5436CC10B0@BYAPR11MB3638.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.244.254]
Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463BC5950sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/wecy51EJvvenXjptp4Xq2ej1NvY>
Subject: Re: [Lsr] Flooding Negotiation bit
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, 20 May 2019 20:55:56 -0000

Hi Les,

The problem/case is raised by Tony on 3/6.

I think that it needs to be addressed too from flooding reduction’s perspective.  After a node with 1K links reboots and has 1K adjacencies up to full states,  we should not add 1K links to the FT temporarily. “Adding all of them is likely to trigger a cascade failure. “ from Tony.

To address this problem, we should have a Flooding Negotiation bit. Through using this bit, we can add one or just a few links (from 1K links) to the FT temporarily after 1K adjacencies are fully formed.

It seems that the various methods you mentioned do the work and are for reducing the load before 1K adjacencies are fully formed.

Best Regards,
Huaimo
==== A case from Tony on 3/6 ====
If the node that rebooted has 1000 interfaces, which interfaces should be temporarily added?  Adding all of them is likely to trigger a cascade failure.  The TLV allows us to signal which ones should be enabled.

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, May 17, 2019 2:02 PM
To: Huaimo Chen <huaimo.chen@huawei.com>; tony.li@tony.li
Cc: lsr@ietf.org
Subject: RE: Flooding Negotiation bit

Huaimo –

It seems to me from your description that you are trying to deal with the startup case where a node reboots, has a large number of neighbors which need to be formed, and if this is done all simultaneously there will be a lot of redundant flooding between the new node and each of its neighbors.

If so, this is a well known problem which has nothing to do with optimizing flooding across the network. Clever implementers have already devised strategies wherein neighbors are not all brought up in parallel and the use of various protocol mechanisms (OL bit, max-metric, the SA bit from RFC 5306) are used to prevent the rebooting router from being used as a transit router until it has fully synced with all of its neighbors.

This has nothing whatever to do with the problem being addressed in the flooding optimizations draft – and there are no protocol extensions required to address the issue. I don’t think what you propose is needed – and if it were needed I do not think it would belong in flooding optimizations draft.

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Huaimo Chen
Sent: Wednesday, May 15, 2019 8:07 AM
To: tony.li@tony.li<mailto:tony.li@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Flooding Negotiation bit

Hi Tony,

There are two different cases in which a link is to be added to the FT temporarily.
In one case, a negotiation is needed to be done before a link is to be added to the FT temporarily.
In the other case, no negotiation is needed. It is determined that a link is added to the FT temporarily.

In section 5.1.5 or section 5.2.7, it seems that there is no details on negotiations.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of tony.li@tony.li<mailto:tony.li@tony.li>
Sent: Tuesday, May 14, 2019 4:31 PM
To: Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: Flooding Negotiation bit


Hi Huaimo,

If I understand you correctly, this seems to have almost the same semantics as the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 5.2.7).

If I’m not understanding you, could you please clarify the differences and why the current mechanisms are insufficient.

Tony


On May 14, 2019, at 1:09 PM, Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>> wrote:

Hi Tony,

For the case you described below, in order to add one or a limited number of links to the flooding topology temporarily, a new bit, called Flooding Negotiation bit (FN bit for short), should be defined and used. In OSPF, the FN bit is defined in Extended Options and Flag (EOF) TLV in OSPF Hello. In IS-IS, the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) of the nodes connected to node N will establish an adjacency with node N. During the process of the adjacency establishment between node X and node N, node X sends a FN-bit set to one in its Hello to node N, node N selects one link/node (or a limited number of links) for temporarily flooding and sends only to this selected node a FN-bit set to one in its Hello. Node N adds the selected link/node to the FT temporarily after receiving the FT bit set to one from the selected node. After receiving the FN bit set to one from node N, the selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT temporarily after it sends and receives the FT bit set to one to/from node N; node N adds a selected link to the FT temporarily after it receives and sends the FT bit set to one from/to node Y.

Best Regards,
Huaimo

==== A case from Tony on 3/6 ====
If the node that rebooted has 1000 interfaces, which interfaces should be temporarily added?  Adding all of them is likely to trigger a cascade failure.  The TLV allows us to signal which ones should be enabled.