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

"Jakob Heitz (jheitz)" <> Fri, 04 November 2016 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30ACF129503; Fri, 4 Nov 2016 06:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lfA5gPCSfnwY; Fri, 4 Nov 2016 06:50:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A3D412946B; Fri, 4 Nov 2016 06:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8338; q=dns/txt; s=iport; t=1478267434; x=1479477034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oH3lwZ6+BhMY66i9DyhgPplXOwpUfvmGVVxOXlrs3q8=; b=Z4yD/MOH+qzH4gxOThOf/wSSdf+4wMXUgXCAdQCl0KjmIRk4Ta063ErM Yx+O3Ixwsk/+g4mVwD/P/sOeUBDvzGjEyYP90ENm/7tFoB1/emy2TfCYB wjnv4INd5Y6jsnCW00e1XVyUJ7i8ojsxEmk91Yk5ENDczN0Try6BbB1iV Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="scan'208,217";a="344262040"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 13:50:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uA4DoXwB013288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 13:50:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 08:50:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 4 Nov 2016 08:50:32 -0500
From: "Jakob Heitz (jheitz)" <>
To: Jeffrey Haas <>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIKelQgACxKYCAABpngP//4vhM
Date: Fri, 4 Nov 2016 13:50:32 +0000
Message-ID: <>
References: <112dc01d235fd$57f9c370$07ed4a50$> <> <117ea01d23611$a28513e0$e78f3ba0$> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_980416852554452CB707C1AF26BE1FA7ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: IETF IDR WG <>, Sue Hares <>, "" <>
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 13:50:39 -0000

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.


On Nov 4, 2016, at 4:24 AM, Jeffrey Haas <<>> wrote:

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