IETF Logo Mail Archive

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

Geoff Huston <gih@apnic.net> Fri, 04 November 2016 18:11 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 A0D6E1294E1 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 11:11:11 -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 HVr_x2b3MNSa for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 11:11:09 -0700 (PDT)
Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::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 2DEF4129446 for <idr@ietf.org>; Fri, 4 Nov 2016 11:11:09 -0700 (PDT)
Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id 0e6e8c3a-a2ba-11e6-a41e-005056b6f213; Sat, 05 Nov 2016 04:11:07 +1000 (AEST)
Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 5 Nov 2016 04:10:48 +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: <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com>
Date: Sat, 05 Nov 2016 05:11:05 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <9C984D2D-F468-4E77-B693-09EA7FE569C4@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> <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net> <C85C0950-8D91-4695-A28A-FC17B9E5AFDC@pfrc.org> <98041685-2554-452C-B707-C1AF26BE1FA7@cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dZKiw9QPigzf91vXr9lZG-DLMw4>
Cc: IETF IDR WG <idr@ietf.org>, Sue 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 18:11:11 -0000

> On 5 Nov. 2016, at 12:50 am, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> The text in RFCs 1997 and 4360 is not a constraint:
> 
> If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes.
> 
> It does not describe how to aggregate if ATOMIC_AGGREGATE is present. The text is more constrained if ATOMIC_AGGREGATE is left out of it.
> 

My suggestion was a cut and paste from RFC4360. My motivation to propose this was along the grounds of consistent treatment of BGP communities irrespective of the size of the community value. If you want to specify a standard manner for BGP to treat ALL communities under aggregation and deaggregation of routes then please do so. But trying to achieve this by specifying inconsistent behaviours between the various community types is not the way to achieve a good outcome here, imho.

v2.23.0 | Report a Bug | By Email