IETF Logo Mail Archive

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

Jeffrey Haas <jhaas@pfrc.org> Fri, 04 November 2016 10:34 UTC

Return-Path: <jhaas@pfrc.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 5E30612954D; Fri, 4 Nov 2016 03:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-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 W4s-8mdk7o6J; Fri, 4 Nov 2016 03:34:28 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9A12952F; Fri, 4 Nov 2016 03:34:28 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A96621E369; Fri, 4 Nov 2016 06:37:03 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6D25885C-CB98-4BB6-807B-F86B267219A0"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <08C97932-4E8B-4EBC-B780-3A2F54A1EEF2@apnic.net>
Date: Fri, 04 Nov 2016 06:34:27 -0400
Message-Id: <C85C0950-8D91-4695-A28A-FC17B9E5AFDC@pfrc.org>
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>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YNFbt6nI6vpvs0JW2YTpjEyFW-s>
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 10:34:35 -0000

> On Nov 4, 2016, at 4:59 AM, Geoff Huston <gih@apnic.net> wrote:
> 
> 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

The relevant point from the thread is that the atomic-aggregate attribute is largely protocol noise.  It's a vestigial organ from the BGP-3 to BGP-4 transition, and a poorly specified one at that.  We shouldn't include its use in specifications, particularly where discussing aggregation.

The only place its discussion would be relevant is as part of *de-*aggregation of a prefix.

-- Jeff

v2.23.0 | Report a Bug | By Email