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

"Susan Hares" <> Fri, 04 November 2016 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55E8512950D; Fri, 4 Nov 2016 09:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ImyfdF0j26P1; Fri, 4 Nov 2016 09:41:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9BDC1295C1; Fri, 4 Nov 2016 09:41:13 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Jeffrey Haas'" <>, "'Geoff Huston'" <>
References: <112dc01d235fd$57f9c370$07ed4a50$> <> <117ea01d23611$a28513e0$e78f3ba0$> <> <> <> <>
In-Reply-To: <>
Date: Fri, 4 Nov 2016 12:38:56 -0400
Message-ID: <043a01d236b9$f07058f0$d1510ad0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_043B_01D23698.695F7C40"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Archived-At: <>
Cc: 'IETF IDR WG' <>,
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Nov 2016 16:41:16 -0000



Should atomic-aggregate be deemed "historical" at this point?  This can
happen in parallel to this work. 




From: Idr [] On Behalf Of Jeffrey Haas
Sent: Friday, November 4, 2016 6:34 AM
To: Geoff Huston
Cc: IETF IDR WG; Sue Hares;
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt



On Nov 4, 2016, at 4:59 AM, Geoff Huston <> 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