Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

opens@riw.us Mon, 04 January 2021 18:01 UTC

Return-Path: <opens@riw.us>
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 E74AB3A0EEB for <lsr@ietfa.amsl.com>; Mon, 4 Jan 2021 10:01:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 2sepcHSoFhYo for <lsr@ietfa.amsl.com>; Mon, 4 Jan 2021 10:01:53 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9C43A0F0F for <lsr@ietf.org>; Mon, 4 Jan 2021 10:01:04 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 571B65C01D7; Mon, 4 Jan 2021 13:01:03 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 04 Jan 2021 13:01:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HZjsegeggzHYQUVb9Cxf6440vLNY2MkBuYqIPWT7X Jw=; b=IH2r0++15nz/V+fbiVYJaxhvfx8gB7HroODA5mQRR6nsvQOajLSCxJjcY rqqbmcdLr3B4fCOd1dk5eHtefu/nibnPdwDyj9Gw2TQdy71nquxaJE+JAtwg8923 /ZJL08/Nw1kMEOTaKMbgRoC/kjZMgC3O0NuhqmYR6jTBKrvNcYslgUbOil5AkVah Ygx85ZEnDQ8TNS121wBkSKZlK1+j2Qjt+1qviYvo4qfqGbvpi1HrmFan4jOXC2M6 IRJOo4bEZV+WIVBzLN3TuuRQCHol43hPZR/Jmj1sZIqw5Jzz5xZVHn0o/J2a+Un0 hEIxEXwKYl8MQUg9ww9ie9w6U8laA==
X-ME-Sender: <xms:31fzX2HM2c1BY1K84r319Tfw8Sr3fip9EcQju3PwYOeEhGc1-m5DnA> <xme:31fzXwSpjcRFPXNS-tehw8dYW5vvg5uoK2YwgUYUAUx4nh2vYUYK9jshvQP57o4Ft KEy2R4zPEnZNY1D3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeffedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfhfjgfufffkgggtgffothesthhqghdtvddtjeenucfhrhhomhepoeho phgvnhhssehrihifrdhusheqnecuggftrfgrthhtvghrnhephfekgfeivddtlefhheffje eivefhgefhgefhudeigeeigeeivdelffehveeuieetnecukfhppeduiedvrddvvdelrddu kedtrdejjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehophgvnhhssehrihifrdhush
X-ME-Proxy: <xmx:31fzXyF6ctv10UahDIPU8ZGT7J5cBiAuewpxOBXqSZaSjjgpAdzBoA> <xmx:31fzX89YeFnP6CdPHbLDIG7sqnOlF_YsSO8Rts3ksy7biJfMNyLAog> <xmx:31fzX8LBrUqhpJxFtxehJ4hP7MXbVHEtxtUIFoyk0eYvq8gs0RO7vQ> <xmx:31fzX4CnB-t4mnowJLigLF-dmIW7OlYRk7ClFaCvKO1MieoUzr695Q>
Received: from RussSurface (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id E41281080066; Mon, 4 Jan 2021 13:01:02 -0500 (EST)
From: opens@riw.us
To: "'Les Ginsberg (ginsberg)'" <ginsberg=40cisco.com@dmarc.ietf.org>, 7riw77@gmail.com, 'Shraddha Hegde' <shraddha=40juniper.net@dmarc.ietf.org>, lsr@ietf.org
References: <160671052823.23617.10172332926989361067@ietfa.amsl.com> <CY4PR05MB35769A9821F4B527851C6287D5F50@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB43378F8D1E12A7EFA591C014C1F50@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB3576C0E406B5976561916274D5F30@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB43372E27477FFE936AC0A8EEC1F30@BY5PR11MB4337.namprd11.prod.outlook.com> <06ed01d6d605$60d15380$2273fa80$@gmail.com> <BY5PR11MB4337596CD6111EB6B230011FC1D20@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337596CD6111EB6B230011FC1D20@BY5PR11MB4337.namprd11.prod.outlook.com>
Date: Mon, 04 Jan 2021 13:01:03 -0500
Message-ID: <054601d6e2c3$917125e0$b45371a0$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJZQwfAeeft0F2RFLP7elTrZEFT3wEvUBwfAhdOKbQBugpqFgGw4HwWAtNu8C0Bk02V1qi6OzcQ
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/wNLf4ZdZrgFvMJ5ra4DvN0zTa2Y>
Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt
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, 04 Jan 2021 18:01:55 -0000

> [Les:] Signaling is required in your solution to indicate whether the neighbor
> should/should not propagate the LSP(s) received from a given neighbor.
> But Circuit Scoped LSPs as defined in RFC 7356 do not provide this functionality.
> 
> A Circuit Scoped LSP is to be used to send information originated by a node to a
> specific neighbor of that node. This information has circuit scope - meaning it is
> NEVER meant to be flooded on other circuits.
> It is not an encapsulation mechanism to forward area/domain scoped LSPs
> originated by other nodes in the network.

I guess I'm not seeing the conflict here ... I'm okay with defining a new way to signal an LSP should not be reflooded, but it seems like re-using the existing mechanism is a better way to move forward.

> [Les:] I assume what you are referring to here is MANET and the Multipoint
> Relay (MPR) functionality.

No -- RFC5820, which was implemented by Cisco, and is widely deployed.

> [Les:] It does seem that you do NOT want to use dynamic flooding extensions.
> Which makes me wonder why you suggest (Section 3) the election of an Area
> Leader. What purpose does this serve in your solution?

When this draft was first proposed, I received several emails stating it MUST fit within the framework of the larger framework document, so I proposed a way to indicate this type of flooding reduction within that larger framework. There is no "leader" in this draft of any kind.

There seem to be two general criticisms here. The first is that it doesn't fit into the general pattern of "elect a leader of some kind." IMHO, this is not a bug but a feature. The method described in this draft has been proven to work--there are two implementations, both of which show large reductions in flooding. Further, the general concept has been proven to work in implementations deployed in the real world. I'm not entirely certain what to make of this criticism -- we aren't trying to replace the existing proposals, but rather provide a complimentary option. I don't see why it should be that every possible solution must elect a leader in some way to be valid or acceptable.

The second criticism seems to be that it doesn't use signaling correctly ... While I don't really understand this criticism, I think we can work together to resolve it.

😊 /r