IETF Logo Mail Archive

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

Tony Li <tony.li@tony.li> Mon, 13 June 2022 17:11 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 1D4CDC14F73A for <lsr@ietfa.amsl.com>; Mon, 13 Jun 2022 10:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level:
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45St4vxXYaFd for <lsr@ietfa.amsl.com>; Mon, 13 Jun 2022 10:11:48 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712E5C14F72E for <lsr@ietf.org>; Mon, 13 Jun 2022 10:11:48 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id 31so4451074pgv.11 for <lsr@ietf.org>; Mon, 13 Jun 2022 10:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGgvvZGFwDVjTnQ3V+5WcaA/2fDbzC5JBEkIvgdnvQU=; b=nbBG/+Y1XEcm/U9fDCnfwcUu7d68MroUrHaVFoDhQlo+Xn5r85H92jhNtLC48toEe6 Vb1CI8YVlQu4Un/zuFYPjFlb7hxBAfG2v5A1pjtp+Epi0yMNUhTEGgcFXFtbYDqFwwv3 qUWRXUll3iEYKEgy5jcRHHPXRaXgfRM838tP1cKbDU3EfW9cYW57aISOo2mfR4PdutTM FtmEMoDZJ7ftD3PEwj5QtGPtVhe0xbPLejhqYnHI2XLcPn/ORivNayGT3yb8eDyJp6kv Wr5Lp0MTdfhFRMMku86ZI1mLOE1Bo+b4nMOnkIf1XCAbxKGEh4RJ6UX8nd1l1uPMFvSg OPCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=sGgvvZGFwDVjTnQ3V+5WcaA/2fDbzC5JBEkIvgdnvQU=; b=yNBDFbF7HoiD3UDuISCjtAZFJuSIAAuX8i70swNA4qvM1QMZ+ppaBFvy/GEelBEsa9 wj5qSh1hy40X2cdiMyov4/kYNTkBVYEcBDAoBGszZA7R9aCpomIJ4IzlU17zSBE9B92J g+ewi9tgeYjMKMofEGFPTzPrD45trzNWSudhkedZxBEcnD3VcKHGdxyNOoWZEZqEUq49 DG0KrYNcjxtnxWP5fGjDykqI24DO5jBq4oIQObTDK6DAkz6Ustoqp//RdudVNcxb1ZKf BuO84NlAKPVh3MUXz7tHXoPZf0pATYLCx7yWzyqPBEMsIC8LMv9Htyun+6OzBoX0DAzV IQAQ==
X-Gm-Message-State: AOAM531cw09FfrDvZpGbTcWbJlbbMmcp70np4AqZXvxMWiW4tjeRjvSE iN4UpvOK6ZHOznWWGmh7VQs=
X-Google-Smtp-Source: ABdhPJxC4m8dDido7072qs2gxkYv401qWLE7M1uOwTjaWcYV/iH8/igcWMugOfm7N97ikEB9fi2pPQ==
X-Received: by 2002:a63:1209:0:b0:3fc:e453:5424 with SMTP id h9-20020a631209000000b003fce4535424mr526899pgl.131.1655140307816; Mon, 13 Jun 2022 10:11:47 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id g9-20020a633749000000b003c619f3d086sm5728664pgn.2.2022.06.13.10.11.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jun 2022 10:11:47 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <AM7PR07MB6248CDBA763EF1A0BAF626ADA0AB9@AM7PR07MB6248.eurprd07.prod.outlook.com>
Date: Mon, 13 Jun 2022 10:11:46 -0700
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C14FCF1-C477-4D9C-A7C2-2260F2B7B7A5@tony.li>
References: <AC1AF8B2-07D5-46CB-85B9-DC8607C5E88B@cisco.com> <AM7PR07MB6248CDBA763EF1A0BAF626ADA0AB9@AM7PR07MB6248.eurprd07.prod.outlook.com>
To: tom petch <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MJSfvBLULP5hqGAMXVaxJbr_B7o>
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Jun 2022 17:11:52 -0000

Tom,

In this particular case, I believe the choices are Experimental or Historic.  I’m fine with either.

T


> On Jun 13, 2022, at 8:43 AM, tom petch <ietfc@btconnect.com> wrote:
> 
> From: Lsr <lsr-bounces@ietf.org> on behalf of Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
> Sent: 10 June 2022 15:10
> 
> Initially, there was a lot interest and energy in reducing the flooding overhead in dense drafts. Now, it seems the interest and energy has waned. IMO, this draft contains some very valuable extensions to the IGPs. I discussed this with the editors and one suggestion was to go ahead and publish the draft as “Experimental”. However, before doing this I’d like to get the WG’s opinion on making it experimental rather standards track. Additionally, I know there were some prototype implementations. Have any of those been productized?
> 
> <tp>
> The trouble with experimental is what happens next?  Does it stay experimental for ever or is there some assessment at some point when it becomes Standards Track?  What are the criteria?  I am not aware of an RFC describing such a process and the IPPM WG seemed uncertain what to do with RFC8321 and RFC8889 when such an issue arose.
> 
> The shepherd report for 8321 said
> 'the measurement utility of this extension still is to be demonstrated at a variety of scales
>   in a plurality of network conditions'
> as the justification for experimental but did not state how that might later be demonstrated.
> 
> Tom Petch
> 
> Thanks,
> Acee
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email