Re: [Idr] Why do we define so many communities for BGP

Job Snijders <job@instituut.net> Tue, 08 November 2016 12:14 UTC

Return-Path: <job@instituut.net>
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 B7F1B129ACE for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 04:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 NLBXuUVWAFgS for <idr@ietfa.amsl.com>; Tue, 8 Nov 2016 04:14:30 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9888E129B09 for <idr@ietf.org>; Tue, 8 Nov 2016 04:14:04 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id t79so235259536wmt.0 for <idr@ietf.org>; Tue, 08 Nov 2016 04:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=691UsepOnz7DZvpJqdjFy4zxA+/swk7NwCik+a/3cAk=; b=j2ZKjM3+/WqK8a6nzrzX+zifDIGEdrtH4WfkmV1wQ0RzR2A1BU8iygy7NchHZDGG1G rN9c25uPIbdxJSRsGk96fXGj4XZsaASXqhxmtJ36PKss9zgBdBjSkwFca6xxDcBH9Faw k8eZfOcxeZL8BoplEE2EKl6lIm+zrqpm4NkHJtir48KvUq7sSQ2GMfFJuu62jF6FSDpB jNWT7mUO3GgnIQ8mGXYVfvrmmahcBQOTFDMb3fVhHdvc3Qq9zCqe38nsEjqGGA2y0qVp nd8DQe33m49gVk6w2CgV7WDr2gG7GCuKgRPOfpTF7sfeW07pDA5dpqrvuolvO4bDae4+ lfNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=691UsepOnz7DZvpJqdjFy4zxA+/swk7NwCik+a/3cAk=; b=kooCNIgFms6Cx7oSgnu9BM6LgfdQB/4gZam7gI6cNoNdUiyZWoua3PYi+IbHfSZk0I GBiyXfjwmwj7NNETLpba/9IKN2aAPwfOi/qPQuEPexBZr4pNCpDosoEFBZLiwvNNzrvG uSbMXftQpIFP6V3NC63Gk2/GWsKNiXdN3cTVde0TYxcSAFzaVcAUMR+88oVsHFE5YgED Lngbacxyx7Sf8wVdieKQTtE9IpiOz5qNIuqO7RKd9fbqy5kk3R41bGUTqxC4iOT3tc7O eo9rPZZDG5a5jR3DenUnX+r0hSTMf0MDTiQ0RGeimXck5aIU73ZAiaG0SeuunDzrktx/ NkPA==
X-Gm-Message-State: ABUngveiMfd7VjUq15O+QBmGF9Dyb7M6Im4w+/B9nVk9DEmJF71UplJm7GqiMub8G0SEuA==
X-Received: by 10.194.235.34 with SMTP id uj2mr9613831wjc.144.1478607242822; Tue, 08 Nov 2016 04:14:02 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:319f:c386:86c3:ad6a]) by smtp.gmail.com with ESMTPSA id i10sm36802769wjd.15.2016.11.08.04.14.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 04:14:01 -0800 (PST)
Date: Tue, 8 Nov 2016 13:14:00 +0100
From: Job Snijders <job@instituut.net>
To: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
Message-ID: <20161108121400.GF2473@Hanna.local>
References: <2016110819514874384911@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2016110819514874384911@chinamobile.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5lxYHHbPGwjO7WpZQdObrM-OVG4>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] Why do we define so many communities for BGP
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: Tue, 08 Nov 2016 12:14:32 -0000

Dear,

On Tue, Nov 08, 2016 at 07:51:52PM +0800, lizhenqiang@chinamobile.com wrote:
> I am confused by large community defined in
> draft-ietf-idr-large-community, wide community defined in
> draft-ietf-idr-wide-bgp-communities, extended community defined in
> RFC4360, community defined in RFC1997. Why do we need so many kinds of
> BGP communities?

It is healthy for the IETF that ideas can compete with each other.

Without competing drafts, the IETF would suffer from a anti-pattern
where someone (metaphorically) takes a cookie, licks it and puts it back
on the cookie tray, essentially preventing anyone else from having it,
but not eating it by himself or herself.

This anti-pattern can be often seen within volunteer communities when
discussing a certain issue or an improvement. Someone says "I've already
done draft on this topic,". This would prevent others from working on
the feature as there is already someone who started working on it. If
it's not followed up on by this person, it's essentially a dead project.
Nobody else touches it, but nothing real gets done.

Regarding RFC4360 - it has been documented that RFC4360 communities are
unsuitable, this is described as following in the draft:

    """Since the adoption of four-octet ASNs [RFC6793], the BGP
    Communities attribute can no longer accommodate the above encoding,
    as a two- octet word cannot fit a four-octet ASN.  The BGP Extended
    Communities attribute [RFC4360] is also unsuitable.  The six-octet
    length of the Extended Community value precludes the common
    operational practise of encoding four-octet ASNs in both the Global
    Administrator and the Local Administrator sub-fields."""

> Can the large community be encoded in type 3 wide community?

No. There was disagreement on the transivity behaviourisms between
various parties involved. And in the end, there is no reason the two
technologies can't co-exist.

I want to conclude with an emphasis on the fact that the Large BGP
Communities effort has running code, lots of it. Please take a look
here: http://largebgpcommunities.net/implementations/

You can see that not only the BGP implementations have taken on to
support Large BGP Communities, but that the entire ecosystem is being
upgraded to work with large communities: tcpdump, wireshark, pmacct,
pgbpp, zebra-dump-parser, mrtparse, and the list is growing weekly.

Perhaps the following saying is applicable?

兩鳥在林不如一鳥在手

Kind regards,

Job