IETF Logo Mail Archive

Re: [Lsr] Option B from "Migration between normal flooding and flooding reduction"

Tony Li <tony1athome@gmail.com> Mon, 27 May 2019 04:19 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 808B61201D2 for <lsr@ietfa.amsl.com>; Sun, 26 May 2019 21:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 5tWmSlA1EAAc for <lsr@ietfa.amsl.com>; Sun, 26 May 2019 21:19:41 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 3C352120033 for <lsr@ietf.org>; Sun, 26 May 2019 21:19:41 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id z3so3720196pgp.8 for <lsr@ietf.org>; Sun, 26 May 2019 21:19:41 -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=Mw5lvh+3C2mvPibS0U4NDs0q4dVhaEns/l621+RqxQw=; b=cMQBiBfF+VtBxIhAIcuLfYBbFgMA7Cbrc1e0wIX2Mp+yFioV+RQZU4v+moQe7cItNG OwBhyZjL+R+dl0+b+80avXVDpmXKI/2QjVdSBs+3gk/Ov/OeigWM0hTkDFocu1biXjNd Z1TwlQ0esDyIkw6+37Fu4h+vm4alDJhMMug+ZCiO8A/MF67V57CxyNmWYd8+gf1o294u n1Cs4KL/1OA1G9WvTFCekyZL7ujhrvSV/tG+Ws+YhpoGYL1YpX72YzWxhchdMMzTT73e hNpCnoLUuTEj8kPB3kO05wgg01giUT5LSLOOxUdmHYHtNDS29XFJcQcDFNYmNRDXXtAq xP1Q==
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=Mw5lvh+3C2mvPibS0U4NDs0q4dVhaEns/l621+RqxQw=; b=EUXvscQIXHnfEulB4exwKFlJ/hXBtvLlMcnbfLqOibspzi/cUP/AP9Wtcg9Sur5RlB 8Mm8GRWbVIs2z0XeUI7kf78yk+GB/njOMFvDsYjQvgMUTdZJJEn1Z1iQ+Klyc5PqMhLI vE/QO6QGGfqjUDQvnAFkdWCZGftCb/1KZRmDxQ3lsd33m8QujynosZYfD1LjDrFRRLGE SBbi4OqCRKQapVSvRatnd7UVMR5G1oL9AEA9m5jWST/MpQUdzL8XKJfmTvc/+bw/nMbZ lX9YnTNAcm8tdDUvR/dEm1F86wQdy1oAmsbXQF32/G6huxiHz4kG63yIswDC7CXklhvh tlfg==
X-Gm-Message-State: APjAAAWuUgKNnyNETWzEceJRgJe+OcdKkpFdnT2uBjsjA3y571uo1DWs 3Qlrm7fPKZDrRx2VTROBXc1I94dSdkA=
X-Google-Smtp-Source: APXvYqzxW0Nr7ka2tTtwI1ZnnDxEkxhcrRgQMlGeqcx/+tyoaZw4xnAOlFN9t2qVh/va5vMgOATw/w==
X-Received: by 2002:a17:90a:cb84:: with SMTP id a4mr28355993pju.104.1558930780580; Sun, 26 May 2019 21:19:40 -0700 (PDT)
Received: from [192.168.1.5] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id i7sm9641953pfo.19.2019.05.26.21.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 May 2019 21:19:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Tony Li <tony1athome@gmail.com>
In-Reply-To: <CAOj+MMGDodnxktZCuqPfVDCRbu0+yUR--DiZKTqVQ=4thAM5rw@mail.gmail.com>
Date: Sun, 26 May 2019 21:19:39 -0700
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DFD8BB4-AA63-4BE6-9927-4557AB32ABD9@gmail.com>
References: <5316A0AB3C851246A7CA5758973207D463BBD21B@sjceml521-mbs.china.huawei.com> <CF5E5FE7-C2E2-4200-AE8A-6BF5E558258C@tony.li> <5316A0AB3C851246A7CA5758973207D463BC58F5@sjceml521-mbx.china.huawei.com> <BYAPR11MB3638190EC8AD3235AB2304E7C1060@BYAPR11MB3638.namprd11.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D463BC5C32@sjceml521-mbx.china.huawei.com> <BYAPR11MB3638722A90E40777657001B8C1000@BYAPR11MB3638.namprd11.prod.outlook.com> <CAOj+MMEijyB7qd4oUaOe7W19j+76CjH+mzJ3mvcVtOjn5fvmdw@mail.gmail.com> <BYAPR11MB363863B393A181264E07B042C1000@BYAPR11MB3638.namprd11.prod.outlook.com> <MN2PR13MB3470B24A328311A23BAAC5B8A3000@MN2PR13MB3470.namprd13.prod.outlook.com> <MN2PR13MB34701B410A172A950BAE6B5EA31C0@MN2PR13MB3470.namprd13.prod.outlook.com> <FB4EDF4B-C94D-4654-8D3A-A1567E0D76B1@gmail.com> <CAOj+MMGDodnxktZCuqPfVDCRbu0+yUR--DiZKTqVQ=4thAM5rw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/r4OqOTF_8zc5VHK_oJd_hSEFZq4>
Subject: Re: [Lsr] Option B from "Migration between normal flooding and flooding reduction"
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, 27 May 2019 04:19:43 -0000

Hi Robert,

> The current draft is pretty robust in terms of area leader election. It also says that  "Any node that is capable MAY advertise its eligibility to become Area Leader” 


Correct.  This can be all systems. It can be one. For redundancy, a few would be sensible.


> With that can you confirm the procedure to "resign" as area leader ?


Stop advertising the Area Leader sub-TLV.  It’s that simple.


> Especially that under those circumstances just having active area leader to resign clearly is not enough to change given flooding scheme. 


If there are multiple potential area leaders, then all of them would have to resign.  


> In some deployments all eligible nodes may advertise such capability which in turn the "resign" procedure would require NMS action to disable such capability by configuration and re-flooding it. Not that I am advocating it nor see need for complex migration procedures, but just would like to better understand the "resign" part. 


Correct, this is rightfully an NMS operation.

Tony

v2.23.0 | Report a Bug | By Email