Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Nick Hilliard <nick@foobar.org> Tue, 23 March 2021 15:01 UTC

Return-Path: <nick@foobar.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4D3A1130; Tue, 23 Mar 2021 08:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hr3pbufzZSTC; Tue, 23 Mar 2021 08:01:44 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169793A1135; Tue, 23 Mar 2021 08:01:43 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 12NF1dB2046386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2021 15:01:40 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: 'IETF IDR' <idr@ietf.org>
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <000501d71940$e9b87420$bd295c60$@tsinghua.org.cn> <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com> <002901d71971$ed947f90$c8bd7eb0$@tsinghua.org.cn> <BYAPR11MB320729520FD51C969744AC7BC06B9@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <4768288b-d0dd-f078-e304-6f42e539a267@foobar.org>
Date: Tue, 23 Mar 2021 15:01:40 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.47
MIME-Version: 1.0
In-Reply-To: <BYAPR11MB320729520FD51C969744AC7BC06B9@BYAPR11MB3207.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ovZkVgKiPoaCl_VA7GXHHsBml58>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 15:01:45 -0000

Jakob Heitz (jheitz) wrote on 16/03/2021 00:03:
> This draft is a proposal to use large communities to make a better 
> extended community.

the original LC RFC specifies a global administrator field.  This draft 
attempts to retrofit semantics into various bits in that field.  I can 
see why it's tempting to attempt this, but it introduces a significant 
degree of interpretation semantics and, more importantly, backwards 
incompatibility.

At the time when we were still discussing 
draft-heitz-idr-large-community, the issue of future flexibility and 
semantic interpretation was extensively discussed, and the consensus of 
the authors + working group was that it was more important to get a 
draft out there which implemented "deployed + simple" rather than going 
for a slightly more complex design which would have allowed future 
extensibility.

The opportunity to use a more flexible structure was not taken at the 
time, for good reasons, and we knew at the time what those long term 
consequences of those decisions would be.

Retrofitting this complexity into rfc8092 reopens these arguments, but 
from the point of view of watching the ship after it's sailing past the 
horizon.

If we need a better asn32-compatible extended community, then we should 
define a better, asn32-compatible extended community and do the job 
properly.  We should not try to claim that rfc8092 provides an 
appropriate framework for this, because it doesn't and because if we try 
to bend LCs in this way, it will leave us with a legacy of perpetual 
dysfunction.

Nick