Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

joel jaeggli <joelja@bogus.com> Wed, 15 June 2016 04:30 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 079F212D0AA; Tue, 14 Jun 2016 21:30:04 -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 K9Y6Jr4mMGFw; Tue, 14 Jun 2016 21:30:02 -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 9137312D0A1; Tue, 14 Jun 2016 21:30:02 -0700 (PDT)
Received: from mb-2.local ([IPv6:2601:b00:c500:8b41:8c67:e9ca:344e:32cb]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u5F4TIhl023573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Jun 2016 04:29:19 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:b00:c500:8b41:8c67:e9ca:344e:32cb] claimed to be mb-2.local
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Nick Hilliard <nick@foobar.org>
References: <20160613132809.12486.44511.idtracker@ietfa.amsl.com> <575EB839.3050303@foobar.org> <0DE7AB8E-4CFD-44C5-898F-47F48B542599@kuehlewind.net> <575F2704.3050509@foobar.org> <CAKKJt-dUUyzR5M84hEK1vr9zUdbZx65cUyAbtcx4wP3GgRn2aw@mail.gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <3402d769-1683-5854-fdcb-295421a06f30@bogus.com>
Date: Tue, 14 Jun 2016 21:29:16 -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: <CAKKJt-dUUyzR5M84hEK1vr9zUdbZx65cUyAbtcx4wP3GgRn2aw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1kO9InqVUhLNOlIk02ooEbhis0BQUK3t1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/37KUvXGWQyb6qb_gP4_jTnwe1zA>
Cc: idr@ietf.org, idr-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, Susan Hares <shares@ndzh.com>, draft-ietf-idr-ix-bgp-route-server@ietf.org
Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-ix-bgp-route-server-11=3A_=28with_COMMENT=29?=
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: Wed, 15 Jun 2016 04:30:04 -0000

On 6/14/16 9:19 PM, Spencer Dawkins at IETF wrote:
> Hi, Nick,
> 
> On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard <nick@foobar.org
> <mailto:nick@foobar.org>> wrote:
> 
>     Mirja Kuehlewind (IETF) wrote:
>     > Great! Thanks!
> 
>     this is now changed as follows:
> 
>     >
>     https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508
> 
>     Nick
> 
> 
> I had the same question as Mirja, but balloted No Objection because the
> discussion was already taking place in this thread.
> 
> I've looked at
> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508,
> but I'm still confused. 
> 
> The document defines a route server as "not a router", because it
> doesn't forward packets - the text is 
> 
> Although a route server uses BGP to exchange reachability information
> with each of its clients, it does not forward traffic itself and is 
> 
>    therefore not a router. 
> 
> If the route server does prepend its own AS number to the AS_PATH, won't
> it then receive packets that it can't forward?

Nah, the AS path only counts for path selection. What matters as far as
forwarding goes is what the nexthop on the route is.

In a normally functioning exchange the routeserver will never set itself
to be the nexthop of a learned so the nexthop route will remain the
originator of the route which is another router on the same (connected)
subnet. Since the router(s) peering with the route-server all have the
subnet/netmask configured on their connected interface, they can resolve
all of the nexthops learned from the routeserver via arp.

> Can you help me understand what I'm missing here?

Probably that does it.


> Thanks!
> 
> Spencer