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

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Mar 2021 11:06:30 -0400

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:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr