[Lsr] Configuration of LSR routers in WRT dynamic flooding

Christian Hopps <chopps@chopps.org> Wed, 06 March 2019 13:48 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3302C124B19 for <lsr@ietfa.amsl.com>; Wed, 6 Mar 2019 05:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FA7q96dFmpaJ for <lsr@ietfa.amsl.com>; Wed, 6 Mar 2019 05:48:25 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org []) by ietfa.amsl.com (Postfix) with ESMTP id BBF2412423B for <lsr@ietf.org>; Wed, 6 Mar 2019 05:48:23 -0800 (PST)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 33073604D0; Wed, 6 Mar 2019 08:48:22 -0500 (EST)
From: Christian Hopps <chopps@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_1FE1845C-128A-417C-93F0-EC22EEB0CCE9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <43D99E72-6BA4-4B95-84EC-E7D497D607D7@chopps.org>
Date: Wed, 6 Mar 2019 08:48:21 -0500
Cc: Christian Hopps <chopps@chopps.org>
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1fovJZwmrpu2gF3jvLVPSSo6RnE>
Subject: [Lsr] Configuration of LSR routers in WRT dynamic flooding
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, 06 Mar 2019 13:48:30 -0000

Huaimo wrote:

> > Tony wrote:
> >
> >There is no need for a backup leader.  If the area leader is partitioned from the topology, then
> > leader election is repeated, resulting in a new leader.  Again, no configuration is required.
> The above does not talk about topology split, but about the leader down. After a user/operator has configured some things on the leader, and the leader has got them and distributed them in some form, and then some time later, the leader goes down, a new leader is selected. In this case, will the new leader take and maintain the configurations or the information derived from the configurations done on the old leader.I

Operators configure their routers using their management systems. When an operator chooses a distributed algorithm they SHOULD configure that choice consistently in their network if they don't expect changes based on leader election. This is something that can be stated in the document if it must be.

Yes, misconfiguration is possible due to NMS bugs, in which case it may be reasonable for the LSR protocol to detect and signal this misconfiguration.

We do not want to build a bunch of complexity into LSR protocols to treat misconfigurations as the normal state of things, as it is not.


> Best Regards,
> Huaimo