Re: [Lsr] Flooding Negotiation bit

tony.li@tony.li Tue, 14 May 2019 20:31 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 39EEE120223 for <lsr@ietfa.amsl.com>; Tue, 14 May 2019 13:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 v2QioP998SjV for <lsr@ietfa.amsl.com>; Tue, 14 May 2019 13:31:07 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 A6F061200DE for <lsr@ietf.org>; Tue, 14 May 2019 13:31:07 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d21so165778plr.3 for <lsr@ietf.org>; Tue, 14 May 2019 13:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o17PGDQuqQI+D0pNo/hivSpkW/8Mz/ICcCLVFb0JlfI=; b=KHrxQGrOTop1qYHYhn4L634TGPDmu75uHLhHlPLJkeNanFFci+Ik3dySbiLNSsTF3q EnJOMtZKx60vZ1mR6vf5l1ZRvsoESIaiiqtACkvKt0lZRq1f4DifEERrZ3xqxJ6MwpGo E6GfingJN/fpCUVraiZKMQbKSEn5Vuj7oRwxwX+PnpwUwhLEBQmlMtDIzm410jHWzaro glwOw58rDeG/tySYLX10b4jzAPhrzJACeND/J8k1P/mY92yVN6fxWqtUALvAgkqtuy7K 67cqohMWqktmzM4v1rUrfRXQ7YiiUHsK4X2WhdrQ6T1P/udoEALhGQz4qqG8F7Cj6fHV /04g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o17PGDQuqQI+D0pNo/hivSpkW/8Mz/ICcCLVFb0JlfI=; b=LX1BZxTsUippFzPv3wGGGONYza0IPeQV9lvnPZbCsyJMW/QFhigzU7j3ErZOPG9//P UpnMwZPmCvL+BtLEbuPV6J2QOHuXsdv4ThFc8hA5NDOCqtfj74sjXiACJsUR5vwNDeWr 6ZKZEygpb6RiY3Rg706KluCr3tZDNCUrCXfh7HsOCcckYAbu3gEjBpoVJsxCxBFy4yFU svGyyxNsrLvehT0Oo1FuXhxCsfhZCwenWSGJe3PdP5RGf4ZFoOIRREJj3KEX1Nc9gnT5 DmP0XyZe57WChBXbd/cnwZybzMJKD3wGcGw2SCvtKUEFlMETfmnonotFqXE/u38L11jM a7RQ==
X-Gm-Message-State: APjAAAW1E4vwaRVQFB/5LLRdydvo1pAM6j+emg9YkLqsJIdcyqYb1OBV 0QxPWksve30+kmXwawj1K08=
X-Google-Smtp-Source: APXvYqwMMksOVO0MyFBqRJW8LfIYf4EN99q+9vyAs3l2Hb0UG6+NCBnCxsu1RU9LRdLRc85ExozgbA==
X-Received: by 2002:a17:902:9343:: with SMTP id g3mr39408963plp.260.1557865866523; Tue, 14 May 2019 13:31:06 -0700 (PDT)
Received: from [172.22.228.83] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id e16sm26840915pfj.77.2019.05.14.13.31.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 13:31:05 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <C9C79F82-D68C-4843-91EF-2EC38833C51F@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C25D91CB-C482-4BA9-AFB5-F076D912F5D1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Tue, 14 May 2019 13:31:00 -0700
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463BB69D9@sjceml521-mbx.china.huawei.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
To: Huaimo Chen <huaimo.chen@huawei.com>
References: <5316A0AB3C851246A7CA5758973207D463BB69D9@sjceml521-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/67PTZG-Qlm_1iHPHExQiXW8Jmlk>
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: Tue, 14 May 2019 20:31:09 -0000

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