Re: [GROW] New Version Notification for draft-ymbk-grow-bgp-collector-communities-01.txt

Emile Aben <emile.aben@ripe.net> Mon, 05 October 2015 11:17 UTC

Return-Path: <emile.aben@ripe.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCD31A92E2 for <grow@ietfa.amsl.com>; Mon, 5 Oct 2015 04:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 wvbSwXuUebuz for <grow@ietfa.amsl.com>; Mon, 5 Oct 2015 04:17:18 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72DB1A92E3 for <grow@ietf.org>; Mon, 5 Oct 2015 04:17:17 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <emile.aben@ripe.net>) id 1Zj3lb-000Ax9-1I; Mon, 05 Oct 2015 13:17:16 +0200
Received: from gibbon.ripe.net ([2001:67c:2e8:1::c100:1ce] helo=[127.0.0.1]) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from <emile.aben@ripe.net>) id 1Zj3la-0008NI-Sj; Mon, 05 Oct 2015 13:17:14 +0200
To: Job Snijders <job@instituut.net>, Randy Bush <randy@psg.com>
References: <20150907102335.17422.49880.idtracker@ietfa.amsl.com> <20150907105015.GW1025@Vurt.local> <m2d1xupkkd.wl%randy@psg.com> <20150907112304.GX1025@Vurt.local> <m2zj0xjec8.wl%randy@psg.com> <m2mvwxj6ib.wl%randy@psg.com> <20150908151538.GE1025@Vurt.local>
From: Emile Aben <emile.aben@ripe.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <56125C3A.8000001@ripe.net>
Date: Mon, 05 Oct 2015 13:17:14 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150908151538.GE1025@Vurt.local>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: b702aeccd6b1b86cf194e696b157d5489afe7955fe2a1e613dff149a6dfd4f70
Archived-At: <http://mailarchive.ietf.org/arch/msg/grow/ViHqTYNpFTXuDiX8BjxH7vr-wLw>
Cc: Beards <grow@ietf.org>
Subject: Re: [GROW] New Version Notification for draft-ymbk-grow-bgp-collector-communities-01.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 11:17:19 -0000

On 08/09/15 17:15, Job Snijders wrote:
> On Tue, Sep 08, 2015 at 05:05:48PM +0200, Randy Bush wrote:
>>>> I do not feel comfortable overloading locally administrated bits with
>>>> something that represents global significance. The 64xxx communites
>>>> come dangerously close to codepoints we use internally. I'd prefer
>>>> that the local portion of BGP Communities remains truely local.
>>>
>>> only problem is that completely blows the purpose of the exercise, a
>>> global tagging to help ops and researchers be more sure of what they
>>> are seeing in the collectors.
>>
>> i think i misunderstood you.  you are suggesting using 42-44 or
>> whatever, not 65000 space.  sure.  i do not care what the numbers
>> are.
> 
> I suggest to take the codepoint(s) from 0xFFFF0000 - 0xFFFFFFFF
> http://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml
> as we then at least have made the most effort to avoid clashes with
> locally significant values.
> 
> At the very least I see operational value in having a well-known
> community to tag "customer" prefixes with, this is something I'd use
> internally, in public documentation and BCOPs/guides how to set up a BGP
> transit network. A "CUSTOMER" community could benefit a group braoder
> then the research community.

Proposal specifically is about 16-bit (not 32-bit) values, because it's
useful to have the first half be the (16 bit) ASN to which this
information applies, ie. <asn>:<color>. This allows route-collectors to
also collect this type of information from networks other then their
direct peers (modulo bgp selection process, community-stripping).

Also if you'd go 32-bit community, because BGP communities are optional
transitive, they can easily leak, simple scenario:
- 32bit community for tagging customer cone becomes standard
- your peer decided to put the 32bit community on all of their customer cone
- you receive this feed from your peer
- you don't strip the 32bit community either on entrance or exit
- result: your competitors customer cone appears tagged as your customer
cone to a route collector

cheers,
Emile