Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

Jeffrey Haas <jhaas@pfrc.org> Mon, 07 November 2016 16:42 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 971B9129850 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 08:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 f3rZ02NgpBH8 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 08:42:04 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAFC12973D for <idr@ietf.org>; Mon, 7 Nov 2016 08:42:04 -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 37DF81E1F0; Mon, 7 Nov 2016 11:44:45 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20161107162059.GE79185@Space.Net>
Date: Mon, 7 Nov 2016 11:42:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1369BD67-5A14-4A37-AAF7-3B05BA518191@pfrc.org>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <CA+b+ERk8NgT4RB9Hv_yrPRb2Gv2RVU9EjXUpdMc=mg0U7TeykQ@mail.gmail.com> <20161107121251.GT79185@Space.Net> <CA+b+ER=8U7kww=8KpOjSDh=XpK+O2LVmStLDf4KuG+FGjp3-UQ@mail.gmail.com> <B245D36A-DB4D-402E-87ED-3DBF31699B2B@cisco.com> <20161107162059.GE79185@Space.Net>
To: Gert Doering <gert@space.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/E_jQi2GvpsNsNz_vsCfUvISfuH4>
Cc: heasley <heas@shrubbery.net>, idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
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: Mon, 07 Nov 2016 16:42:05 -0000

Gert,

> On Nov 7, 2016, at 11:20 AM, Gert Doering <gert@space.net> wrote:
> 
> Hi,
> 
> On Mon, Nov 07, 2016 at 04:14:32PM +0000, Jakob Heitz (jheitz) wrote:
>> 5539:100 is used by 5539 to tell its neighbors that the route was learned in Frankfurt/DECIX.
>> http://www.space.net/static/bgp_communities.html
> 
> Indeed, and sorry for the 5539:70 and 5539:130 example, these were 
> obviously incorrect - the list (and our configs) say it's 5539:3070,
> 5539:3100 and 5539:3130 to set local-pref in our network.
> 
> But this example prominently documents why operators think that the model
> "5539 defines the namespace for 5539:*" is the only thing that makes sense
> - there are communities set *by* 5539, to declare "information about a 
> prefix", and there are other community values sent *to* 5539 to cause some 
> sort of policy effect in our network, but both have to be declared by 
> 5539 to be a valid reflection of our configured BGP policy.

The general issue is that the context for the use of the community is a bit overloaded.  

If the namespace, e.g. AS 5539, has communities meant to be addressed *to* it and it also has communities internal that it sets itself, it likely should use 5539:*:* for both.  The thing that keeps the properties of the externally originated and internally originated would have to be the Local1:Local2.  Enforcement of this can be done via import policy dropping internal communities at ASBRs.

The same would hold for items attached by the context AS as information for external consumers.  Unfortunately, nothing stops an external party from attaching such a community; it's up to the downstream consumer to check the AS_PATH to see if the route has transited 5539 and to hope that none of the intervening routers have added 5539 internal communities.  

With regard to the internal vs. externally added routes, this is part of the motivation in the common header in the wide communities draft.  In that header, the SRC AS is the one attaching the community whereas the Context AS is how you interpret it.  Externally vs. internally attached communities are clear in that case, although with no additional protections against maliciously setting values in the protocol.

-- Jeff (and even SIDR wasn't willing to touch that in their first pass...)