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

joel jaeggli <> Tue, 14 June 2016 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FBD012D861; Tue, 14 Jun 2016 10:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.326
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j6XCq9FbvH97; Tue, 14 Jun 2016 10:01:18 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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 (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
X-Authentication-Warning: Host [IPv6:2620:11a:c081:20:7df9:7167:e9d9:6b3a] claimed to be mb-2.local
To: Nick Hilliard <>
References: <> <> <> <>
From: joel jaeggli <>
Message-ID: <>
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: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="knGsNBjVcK0XwDvkqr5oVLxhTcmrRlPLD"
Archived-At: <>
Cc:,, The IESG <>,,
Subject: Re: [Idr] Joel Jaeggli's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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