Re: [Idr] AD Review of draft-ietf-idr-large-community-09

"Jakob Heitz (jheitz)" <> Fri, 02 December 2016 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9D79129401; Fri, 2 Dec 2016 13:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Status: No, score=-17.417 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=-2.896, SPF_HELO_PASS=-0.001, 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 52v88H_YqQhJ; Fri, 2 Dec 2016 13:23:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8377B129409; Fri, 2 Dec 2016 13:23:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16084; q=dns/txt; s=iport; t=1480713830; x=1481923430; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uBog0WMqIq0wkEdRQ0PWoFTS/bgvc0KEFLSocB95bWg=; b=OnppCHNc44qZXQwMybaa62VHeFZW9FU+Y4RaULXOYyeI5wgT/VNDerxv QUY0WJ6igEBuTNM2u1N7FU44mHc0bokJhLP6rXRk7TTOEAXrc1xLEZ8Rg ueHrdAdTWGR7Zta5Q/ul6Tnywg1NTgxLSqGH7Kyzoj43MUel5MKGIJJ6J Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,288,1477958400"; d="scan'208,217";a="355249991"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 21:23:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uB2LNg3S023265 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 21:23:42 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 15:23:41 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 15:23:41 -0600
From: "Jakob Heitz (jheitz)" <>
To: Jeffrey Haas <>, Ignas Bagdonas <>
Thread-Topic: [Idr] AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzaD0l0wAgAAl5QCAAGAfAIAAEI6A///6qJA=
Date: Fri, 2 Dec 2016 21:23:40 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_44c0a3d7e3414775ab2b7ef237999953XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
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, 02 Dec 2016 21:23:55 -0000

communities (of any kind) are stored in a table.
Routes that have communities attached just keep a reference to the community.
Suppose three routes are received with the community attributes:
(1:1, 2:2), (2:2, 1:1), (1:1, 1:1, 2:2) respectively.
The system will store only (1:1, 2:2) and the three routes will reference that one community.

Therefore, duplicates are removed and order of transmission is of no significance.


From: Jeffrey Haas []
Sent: Friday, December 02, 2016 7:30 AM
To: Ignas Bagdonas <>
Cc: Alvaro Retana (aretana) <>om>;;;
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09

On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas <<>> wrote:

Removing and ignoring are obviously different things…  The text above is fine with me, but I would ask: what do the current implementations do?  If they remove (as originally specified), then I would suggest you keep that.

The implementations that I am familiar with do interpret first instance of the community value and do not react (=ignore) any other instances of the same community value on the receive side. Whether it is truly first instance as it appears on the wire or the first instance of the sorted received community is an implementation detail, the outcome is that single community value is interpreted only once. Therefore on the transmit side there are no duplicate values. This is based on decoding, processing, and then encoding the community attribute and not forwarding it as a binary object only - I am not aware of any implementation that does that. Could anyone familiar with implementations that behave differently please speak up?

Implementations that tend toward memory conserving typically implement it this way:
- Sort the elements.  (They have set semantics, so order is irrelevant.)
- Remove duplicate entries (redundant as John says)
- Having done the above, check against a data store for a previously existing version.  If it exists, simply bump its refcount.

The above gives the property of "discard redundant on receive".  If a similar canonicalization is done on entries that are to be sent with routes, it also removes duplicates/redundant entries on send.

Modern languages in many cases provide "set" semantics and would similarly give the above properties a bit more automatically.

That said, implementations need neither use modern languages (or mechanisms in those languages) or might not be memory conserving.  Thus, the text recommending removing redundant entries is still a good idea.

-- Jeff