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

Susan Hares <shares@ndzh.com> Thu, 25 March 2021 15:06 UTC

Return-Path: <shares@ndzh.com>
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 4B4753A24E6 for <idr@ietfa.amsl.com>; Thu, 25 Mar 2021 08:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Level:
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pV5ljxvp-YnH for <idr@ietfa.amsl.com>; Thu, 25 Mar 2021 08:06:46 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A70C53A24DA for <idr@ietf.org>; Thu, 25 Mar 2021 08:06:35 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.124.96;
From: "Susan Hares" <shares@ndzh.com>
To: <idr@ietf.org>
Date: Thu, 25 Mar 2021 11:06:30 -0400
Message-ID: <012d01d72188$703be000$50b3a000$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdchiDe+IIA4ibDwS4yBxPd7p2/1KQ==
Content-Language: en-us
X-Antivirus: AVG (VPS 210324-0, 03/24/2021), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zfEgFhX_YldZJDZsB0B6fjkvtls>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23) - Extending call until 3/29
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: Thu, 25 Mar 2021 15:06:48 -0000

Greetings: 

Thank you for the active discussions.  I have extended this adoption call
until 3/29.  

I will send out additional feedback from the IDR chairs on Friday and you
will have the weekend to chat. 

Cheers, 
Susan Hares 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Nick Hilliard
Sent: Tuesday, March 23, 2021 11:02 AM
To: Jakob Heitz (jheitz)
Cc: 'IETF IDR'
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr