Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

joel jaeggli <joelja@bogus.com> Tue, 14 June 2016 17:01 UTC

Return-Path: <joelja@bogus.com>
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 4FBD012D861; Tue, 14 Jun 2016 10:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 j6XCq9FbvH97; Tue, 14 Jun 2016 10:01:18 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 5624E12D85C; Tue, 14 Jun 2016 10:01:18 -0700 (PDT)
Received: from mb-2.local ([IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5EH19DI020509 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Jun 2016 17:01:10 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a] claimed to be mb-2.local
To: Nick Hilliard <nick@foobar.org>
References: <20160614153754.19291.870.idtracker@ietfa.amsl.com> <57602C27.10803@foobar.org> <ba3ad464-b4aa-50ef-a5b2-f48bc3ad9d92@bogus.com> <57603642.4000900@foobar.org>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <62fec2b2-355f-1f52-0313-073224cfc2d1@bogus.com>
Date: Tue, 14 Jun 2016 10:01:08 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <57603642.4000900@foobar.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NXTeR9SleNE00HfHXjPjJRMh2s8>
Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, shares@ndzh.com, draft-ietf-idr-ix-bgp-route-server@ietf.org
Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)
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, 14 Jun 2016 17:01:20 -0000

On 6/14/16 9:52 AM, Nick Hilliard wrote:
> joel jaeggli wrote:
>> IF L is a customer of A and B sure.
> 
> you mean, if L is a downstream of A and B - not necessarily a customer.

if it's a peer we'd view either of them sending it to the exchange as a
leak. The difference between in the downstream cone and customer route
is defintional

>> If it's L's policy that's doing the blocking
> 
> This is the point - it's not L's policy that's doing the blocking.  If A
> blocks L's prefixes at the RS, it will block all paths, via both A and
> B, even though it should have no control over B's paths if it decides to
> take itself out of the equation.

sure, easy enough to concede.

Albiet I rather prefer to take b out of the equation when it's my prefix.

> Nick
>