Re: [Idr] Review of draft-ietf-large-community-06.txt

Geoff Huston <gih@apnic.net> Fri, 04 November 2016 09:00 UTC

Return-Path: <gih@apnic.net>
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 28EA2129513 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 02:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.398
X-Spam-Level:
X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable 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 8QX23JlK83av for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 02:00:03 -0700 (PDT)
Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A97D1294F1 for <idr@ietf.org>; Fri, 4 Nov 2016 02:00:02 -0700 (PDT)
Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 0eec55a1-a26d-11e6-b23e-005056b685e3; Fri, 04 Nov 2016 18:59:56 +1000 (AEST)
Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Nov 2016 18:59:58 +1000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com>
Date: Fri, 4 Nov 2016 19:59:57 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <C2DABF02-D3CB-4646-B869-FBCE5F05FDA1@apnic.net> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <CED07D95-A426-469C-85B4-DB2FBE52D14A@apnic.net> <4080cfba032744f590fcbbb710f0d618@XCH-ALN-014.cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/N7rgbrqQgoTJbMI_phZcIRLY-58>
Cc: IETF IDR WG <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 04 Nov 2016 09:00:06 -0000

> On 4 Nov. 2016, at 2:54 pm, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> Thanks Geoff, I'll fix them.
> 
> One thing about the aggregation.
> I first had the condition "do not include the ATOMIC_AGGREGATE".
> Then someone commented on the list that ATOMIC_AGGREGATE was dead.
> I reviewed the function of ATOMIC_AGGREGATE and what our code does.
> ATOMIC_AGGREGATE means that information was lost by aggregation.
> In our code (and other code that I have worked on), when we
> aggregate, we always add the ATOMIC_AGGREGATE attribute.
> There is no case when we aggregate without adding the ATOMIC_AGGREGATE
> attribute. Being of no consequence, I removed that part of the text.
> I mean, the text tells you how to aggregate if the ATOMIC_AGGREGATE
> is absent, but says nothing about how to aggregate if it's present.
> 
> Personally, I'm fine either way. It will not change any code I write.
> 

I just noted that RFC1997 and RFC4360 had these constraints.

It seems strange to me that an implementation would handle aggregation differently, treating communities and extended communities one way and large communities in a subtly different manner.

Frankly I would prefer to see a consistent treatment of communities in the case of aggregation, and reproducxing the RFC4360 text kinda makes that clear (at least to me)

Omitting it invites different handling and that would be not good

Geoff