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

Tony Li <tony.li@tony.li> Mon, 13 June 2022 18: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 D7DC9C14CF0B for <lsr@ietfa.amsl.com>; Mon, 13 Jun 2022 11:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.506
X-Spam-Level:
X-Spam-Status: No, score=-1.506 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 j0iOzIRMtLuk for <lsr@ietfa.amsl.com>; Mon, 13 Jun 2022 11:11:45 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 BA9C3C14F74C for <lsr@ietf.org>; Mon, 13 Jun 2022 11:11:45 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id l4so5169236pgh.13 for <lsr@ietf.org>; Mon, 13 Jun 2022 11:11:45 -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=aWcuEhz2xV6BehHeWW3xmZjiCKiXEKmqC362s5yQXQ4=; b=WHDwhWP0BjvDpD4baGFyqboY7Sxwhryt+LtzUdwK7qJH8Rtie3Gzz/Atj7dJ511glL To5TdRxg1hAK0UMzkUZWa5CkOZ2w6ZH2SzWUJ6rCqZ10CyL8KKBqRX4LimTjyXzOe10Q 1RM4wC0JfCFDE+RhXL0+MHQ7fYk+UTvNQvJ0+m1Uuoz5uKb5Fgd6uS9Cn6I5t0YABXjm X/LnijciucuRG6KXmDT+KG16KpF4SUsnhfYZns4rSR7mkcJgQSLBX1RnZ5oCjuO6Idej nuQDyKm22alg6pE8+yOuKURnbz0BVMtU1cWZAevQffNMezY6cxJm59CwnF9p2JZj4ZTD iBCA==
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=aWcuEhz2xV6BehHeWW3xmZjiCKiXEKmqC362s5yQXQ4=; b=pKWCopz4AR6UJgOMG0E/VEEyZBuo9OlVOd3FHFlD3LShI3WUEcfcmHjq812oeBj17k biZqvlQA71hK4hiYNAcdeyzQJXkXoaBTuYHyW6OU4yWZGArCXer0VT9nkURonoICdACn bN3Hh9mrXT0nvRPK+9QvGC2X3vuqkiaiPIGpSaQGVADhL2XnFzdC10WKbqKsLAIrLsZ4 wx04tQIyUT6nRgE5mXOm88ujpKFu21LDwAAzrMzxywo9McpoqGbd3NfCaDnBvJd1zpkU tL3n2fwbRlc2mUj4SKgY7vkKhHHDAH00KVRhhyh3JVwjzQTbq6rweY4s/vxL5epXRM2i k9zQ==
X-Gm-Message-State: AOAM531q7Qeu62HgR4B/jlm6jqfmSbgYIK969aVIMy7zykLSL5nxzfAK AV+Rdjxu/4bMkygVIazRnB/GcwSIyr9FOQ==
X-Google-Smtp-Source: ABdhPJwgdMevnDdXvXl1F1muwIaENk+gK1gqa4KnljxmNEPQvgC/fK+XCfDmsYKkQxnODKiMsyVG0g==
X-Received: by 2002:a63:884a:0:b0:3fc:bcef:5685 with SMTP id l71-20020a63884a000000b003fcbcef5685mr715158pgd.349.1655143905134; Mon, 13 Jun 2022 11:11:45 -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 z15-20020a170903018f00b0015eb200cc00sm5411679plg.138.2022.06.13.11.11.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jun 2022 11:11:44 -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: <BY5PR11MB43377349791AE499BE49682DC1AB9@BY5PR11MB4337.namprd11.prod.outlook.com>
Date: Mon, 13 Jun 2022 11:11:42 -0700
Cc: tom petch <ietfc@btconnect.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E5027F4-5A78-4AC0-BB24-5A0E13D2F979@tony.li>
References: <AC1AF8B2-07D5-46CB-85B9-DC8607C5E88B@cisco.com> <AM7PR07MB6248CDBA763EF1A0BAF626ADA0AB9@AM7PR07MB6248.eurprd07.prod.outlook.com> <8C14FCF1-C477-4D9C-A7C2-2260F2B7B7A5@tony.li> <BY5PR11MB43377349791AE499BE49682DC1AB9@BY5PR11MB4337.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/zE7rixceuN9dymC3WYEek9qYU-c>
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 18:11:46 -0000

Les,

The market looked at the technology and decided that it was not interested.  If that’s not the definition of ‘obsolete’, I don’t know what is.

Tony


> On Jun 13, 2022, at 10:27 AM, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
> 
> Tony -
> 
> "Historic" is for 
> 
> " A specification that has been superseded by a more recent
>   specification or is for any other reason considered to be obsolete..."
> 
> Hard to see how that applies here.
> 
> Although I appreciate Tom's concern, the fact that we may not be clear on how to transition from Experimental to Standard (for example) seems to me to be a problem to be solved outside of the context of this specific draft - not something that should prevent us from using Experimental.
> 
> In regards to the state of the draft, here is my summary:
> 
> 1)There are multiple implementations of the draft
> 2)I am not aware that interoperability of the implementations has been demonstrated 
> 3)To the extent that interoperability could be demonstrated, I think only centralized mode could be validated at this time
> 4)Interoperability of distributed mode requires standardization of one or more algorithms - which means the drafts defining those algorithms first have to progress
> 
> To me, that makes "Experimental" the right track as further work is required before we can say that all aspects of the draft are mature enough to consider Standards track.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Tony Li
>> Sent: Monday, June 13, 2022 10:12 AM
>> To: tom petch <ietfc@btconnect.com>
>> Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr@ietf.org
>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
>> flooding
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr