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

Jeffrey Haas <jhaas@pfrc.org> Fri, 02 December 2016 15:30 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 01AF112953C; Fri, 2 Dec 2016 07:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, 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 KCEHBO4zOHGC; Fri, 2 Dec 2016 07:30:08 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA701294E7; Fri, 2 Dec 2016 07:30:08 -0800 (PST)
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 155C31E341; Fri, 2 Dec 2016 10:33:30 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EAA0D612-4221-4967-ACCA-AA94BA02A7BE"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
Date: Fri, 2 Dec 2016 10:30:07 -0500
Message-Id: <477C42EC-359B-41DC-BCEC-9130A245DD67@pfrc.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
To: Ignas Bagdonas <ibagdona.ietf@gmail.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CI4svCmz4cYlsW6XPy5Odfim9CE>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
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, 02 Dec 2016 15:30:11 -0000

> On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas <ibagdona.ietf@gmail.com>; 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