Re: [Lsr] Flooding Negotiation bit

Gyan Mishra <hayabusagsm@gmail.com> Wed, 15 May 2019 01:56 UTC

Return-Path: <hayabusagsm@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 811E4120229 for <lsr@ietfa.amsl.com>; Tue, 14 May 2019 18:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 WV4ExLlo15L0 for <lsr@ietfa.amsl.com>; Tue, 14 May 2019 18:56:15 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 719B0120088 for <lsr@ietf.org>; Tue, 14 May 2019 18:56:15 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id t1so1456777qtc.12 for <lsr@ietf.org>; Tue, 14 May 2019 18:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ejd2ywI1kGSOniXXKuVRFwM2FtGMAlnn9cPZ7S84aF0=; b=F6Xx6XBiin/iq1ll9n2hBurwTERBUPOr+JmaZ6LRX+yurQtO4AYc066jE0TFX5Vmpu 0nhWC17flhaj2DSY/ieuSlRHV1HMNqxN1x4cSdL2DeiShIOqikXyE932W9vhBxDUFutT 4Ap1TcNIO3YtiqOM199iSelmavV7eV/FV8Ml3VhvGJh1cti8Zvp8WIGoW1gQMMwgQb4/ GkXIsL9paGdtHdl6ne7EJrc+SVxCGBwa+faMUhLKJOjw/m10GxX5kP5tlTtp7eylT70B VkQxaYvHMfVa2CGFVYyqB8L6tLsLgOT+ZUN+1kDVlN44QTRTBh/Ba5eJM/rxmsdk/mWo W5Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ejd2ywI1kGSOniXXKuVRFwM2FtGMAlnn9cPZ7S84aF0=; b=ZV24d1N4S0KfoyORYN3obYA6xk7PF6O/HIGl1qsaCyn96Qu9Zx0j0qQSSaCmDWSWhR jI5tWl3tz3UlhSzhUWxABHsXPxFdpoDzT6XJ78F5hpeslN4FaQ6pBK6+n0JlkLdaLJdr hCw/rCnoCcRMrc6Fj/uS9lPvw7lcoWistHPxoyfj5nzvLZGWF/f5bu/cVh+9mIGeXOqA m5GLLMSCjqdSwn5N/fFoLr0ml6BAveN+uQ4mOWD8FEBQJb2HcovEZa+a3DsMz5bXFeI4 qo5KVpOvHY9wLoVEZM/6b3LJE0LhFqBAcp4l45Yom1Vha3UEwzk7SPFuV8wr1rqW3u5o nUPg==
X-Gm-Message-State: APjAAAUzjRpAYqC6GOhoIiwsCeOZBxBIYcH3hSqXfvWV4RqSKboSTMCE 3JYL5vyfu+rGwEWzqOdXMPg=
X-Google-Smtp-Source: APXvYqyupL3zMtgZ2XNrJnukpnU4v1CFIbmcZDboDwUqTwt+p5XzOfxfo+56briTATZPNjunwMPC9A==
X-Received: by 2002:ac8:1c53:: with SMTP id j19mr33351737qtk.152.1557885374395; Tue, 14 May 2019 18:56:14 -0700 (PDT)
Received: from ?IPv6:2600:1003:b00b:6473:f9c7:c8b6:93a3:d406? ([2600:1003:b00b:6473:f9c7:c8b6:93a3:d406]) by smtp.gmail.com with ESMTPSA id x126sm275817qkd.34.2019.05.14.18.56.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 18:56:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-A5BDD4FF-CD3D-4155-A188-1F33636C83E6"
Mime-Version: 1.0 (1.0)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <C9C79F82-D68C-4843-91EF-2EC38833C51F@tony.li>
Date: Tue, 14 May 2019 21:56:11 -0400
Cc: Huaimo Chen <huaimo.chen@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <9A7C5531-EB4F-4FBB-B984-2E430939A4A8@gmail.com>
References: <5316A0AB3C851246A7CA5758973207D463BB69D9@sjceml521-mbx.china.huawei.com> <C9C79F82-D68C-4843-91EF-2EC38833C51F@tony.li>
To: tony.li@tony.li
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xZO-houN0Ty_apdpdAsbf8d8FJY>
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: Wed, 15 May 2019 01:56:19 -0000

Is this a new option that does not exist today in OSPFv3 or ISIS.

Operators have the ability to mark interfaces as passive so only router stub LSA is generated which helps assist in full SPF calculations flooding.

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com


Sent from my iPhone

> On May 14, 2019, at 4:31 PM, tony.li@tony.li wrote:
> 
> 
> 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.
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr