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

7riw77@gmail.com Sat, 19 December 2020 12:49 UTC

Return-Path: <7riw77@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 B95B53A1059 for <lsr@ietfa.amsl.com>; Sat, 19 Dec 2020 04:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 Cjo7W72ZgxMt for <lsr@ietfa.amsl.com>; Sat, 19 Dec 2020 04:49:27 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 E72353A0A2D for <lsr@ietf.org>; Sat, 19 Dec 2020 04:49:26 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id a109so4650672otc.1 for <lsr@ietf.org>; Sat, 19 Dec 2020 04:49:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=NpLw66/lqNfuBLm0dlwkfHMF8eabW1m94mVr/ojJWnw=; b=QWG9gRafmE4rMEUZuYGcspN7jPNCk0wTOj+fk8yNMa7YkSuzUAnJWlHAeO+q2VY1zL ulnObZgYN804QaKgzwyMgyt26X1uKl4WJ6dYgXaFVG419yYCrEJQkUPV/J2bPaSYwvbn 6ssxbX0CiC2O4YuKKjMLJNPcXwckVCOhughkOZubEeFoEL0TCyLZTZbUj62FLn1MFHvH U5WQC23vRBQmTEe27HVGZjFHrUqFGYZ57GwyehBs6DHlt+qUra4ADU5CiVhf/q08Hgn5 w/YDk2TvFEcVab/aD88KEG9PgQIyHrVbkPrgqyVr1TgU2NuOITG2nnzIhLqcAjuY5e66 IDsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NpLw66/lqNfuBLm0dlwkfHMF8eabW1m94mVr/ojJWnw=; b=RlaF16EZkA7KjFmHC+sYhzatYbi7G7SEjTUcX3jccyaxKfUoFKVLxnNgDsvwY8A2R5 QX6gTlkNAJvFe3/l4hrCL+oSzEgsF/oP0/VF1OcHo4137L3urHxWHxzb9whBIghfCW+A 8aHnDF6CfHhPJWccTKx4bPcDpL926FLruJiixF/wJySo4MgzX8ffc3D5037rxSqyxWIX zqX9pcg7Lf7MiUdG7ijoJ2PXcHXZrZx1TmWPlfQVO+jZsAXHziiOiEIaM0Zx8K+KUIwF ndCoVpY0hjBhqSYIj/uqTj+RPQ8gax/VTSeTctJzxDvPo/l8oDzHnbJEjR7bZZ16Ul60 lIpQ==
X-Gm-Message-State: AOAM530uh2ogy2WakULRSiYjLv8Un44ly6Ulg2ljcv+FadrbZAqMbbRQ xnMjiszJ2bOMS5WTGDHRheCAlyBk8ad+MA==
X-Google-Smtp-Source: ABdhPJxBqnqC9SNNKnDrY2hCfVqxtD9ZQziaZySWMQJ696FrOaoPrZOJTRO90F3yjzmXOoOj8i4ruw==
X-Received: by 2002:a9d:64da:: with SMTP id n26mr6187341otl.283.1608382166057; Sat, 19 Dec 2020 04:49:26 -0800 (PST)
Received: from RussSurface ([2600:1700:720:1050:4111:5f6:c4b1:fe6e]) by smtp.gmail.com with ESMTPSA id a15sm2391546oii.50.2020.12.19.04.49.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 04:49:25 -0800 (PST)
From: <7riw77@gmail.com>
To: "'Les Ginsberg \(ginsberg\)'" <ginsberg=40cisco.com@dmarc.ietf.org>, "'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>
In-Reply-To: <BY5PR11MB43372E27477FFE936AC0A8EEC1F30@BY5PR11MB4337.namprd11.prod.outlook.com>
Date: Sat, 19 Dec 2020 07:49:22 -0500
Message-ID: <06ed01d6d605$60d15380$2273fa80$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJZQwfAeeft0F2RFLP7elTrZEFT3wEvUBwfAhdOKbQBugpqFgGw4HwWqMP10EA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7L_6fOc-EZLm02XEvLKmfuXVEUk>
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: Sat, 19 Dec 2020 12:49:29 -0000


> Given the base work defined in draft-ietf-lsr-dynamic-flooding why is
> the use of Circuit Scoped LSPs required/useful?

Circuit scoped flooding is required to prevent unnecessary floods from being
carried beyond where they are needed in the network.

One thought ... the way I originally worded the draft was not to have two
separate databases, but rather just to insert LSPs received as circuit local
in the normal database and then clear the SRM for those LSPs, so the local
flooding process believes they have already been flooded, but they will be
included in the CSNP, etc., as normal. I'm not certain why we need two
databases here.

> [Les:] If you use the mechanisms defined in
> draft-ietf-lsr-dynamic-flooding there would be no need to use Circuit
> Scoped Flooding to send normal area scoped LSPs.

> Each node in the topology would know to which neighbors it should have
> flooding enabled - either because you operate in centralized mode and
> the Area Leader distributes the flooding topology or because you operate
> in distributed mode and all nodes employ the same algorithm. (The latter

Using an area leader, even to centrally calculate a flooding topology,
breaks the distributed nature of the solutions, and creates a much more
complex solution. If you operate in distributed mode, with a common
algorithm, I think you still need to specify what that algorithm is ... this
draft describes such an algorithm ... I think ... ??

> The fact that you apparently do NOT want to use the extensions defined
> in the dynamic-flooding draft means that (as you agree above) you have
> to introduce additional protocol extensions which aren't really
> necessary. This makes the solution much less appealing to me -
> independent of the merits/demerits of the algorithm itself.

Not really... we are modifying already existing protocol extensions, rather
than creating new ones. 

The process described in this draft has already been tested, and is widely
used, in OSPF, btw (and doesn't use two databases there).

> The use of Circuit Scoped LSPs to send traditional area scoped LSPs is
> not at all what RFC 7356 intends. And it causes difficulties (as you
> have noted above) in what the content of CSNPs should be and how the
> different LSPDBs are used internally.

> The dynamic flooding draft wasn't in existence when Russ wrote the
> early versions of this draft. I am suggesting you might want to rethink
> your approach to take advantage of what dynamic flooding draft has
> defined.

The dynamic flooding draft assumes an area leader, which is what this draft
is attempting to avoid.

/r