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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 15 June 2016 05:00 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 4709C12B05B; Tue, 14 Jun 2016 22:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NOWT8r70V6TL; Tue, 14 Jun 2016 22:00:13 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AF912B03B; Tue, 14 Jun 2016 22:00:13 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id c72so10413551ywb.1; Tue, 14 Jun 2016 22:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NptP4w7RDxyfoGvHmSjE7ZsJOUbMRXGcVx8H2LmDPZU=; b=F/dc09weKkkohSAG3Ya2sMrUlVCetWNd7TmVAUsz2HwqykySsGvqentfuhZm7Y3l1z AOqUeobLCCkGukfiF8Yzqk3z6Xpz4elMYKC7dUnPR0/84gT23wJFgb4b/d9nAlxVdkWL jeUsmtKUMWecI6B3JUVUFEG/eVwSeIOzI3f6W1DOzm8Wa2y9ZLobvaKRq8SEaJKkWmsr 3CVjC9OxeQR9B5UhbzPTeX7zI1WFON7s/93piUVs/sH3mWgOYRExPQcvx6jtqkLQ5K/e 2S8m3yuPtZPl22H+/nLYsGb92i42xiPOnZOHwZ6FOA+Oe6EF+fp51GlsB3FqPjzPy0rt GEgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NptP4w7RDxyfoGvHmSjE7ZsJOUbMRXGcVx8H2LmDPZU=; b=T/H/5hANVn9aOqofQ7/ClFCX1PrQLVJ3UWMUP/twtVlZ09INo/4fVjNPSFHOHOlb6R Il7SnVz0VxPS4r4K1QUaiFqLgHoRvRJQSxIAYk+vcEIMKogWCG+f628kuyO7i1BHXVRc O0eqlR+2o8SO4jjQ/ToshJJy9Q9/0olHeaU+9RtqFJCGjHyGebLrGmcDUnQJPzociJjj cUHkl5LRwtwPqnC1x3A5My4fYscd+zzPGlC3NBegHGjsjAX/Dl3ACirtr0+6ayRkPwjT JjLJDafjyZA5MGYJY12d5b5oPh28QQJgtF/WMKZvLgYJ/kHofNXIQa3jffi0xb5tNIMP 8DUw==
X-Gm-Message-State: ALyK8tItVei/mR8o7YgYFYOAgCJw3vTGmNIvMnn0a3y6TTICw/Jwd/uEICiK5BfpDiVEp6b/BuXbVJRUMwvGJg==
X-Received: by 10.129.73.18 with SMTP id w18mr3920701ywa.176.1465966812407; Tue, 14 Jun 2016 22:00:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.101.84 with HTTP; Tue, 14 Jun 2016 22:00:11 -0700 (PDT)
In-Reply-To: <3402d769-1683-5854-fdcb-295421a06f30@bogus.com>
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> <3402d769-1683-5854-fdcb-295421a06f30@bogus.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 15 Jun 2016 00:00:11 -0500
Message-ID: <CAKKJt-f5nMCYf9tEW-dM7f=Nd2o+KSkdAHyHRKFTf-jo-GDYWQ@mail.gmail.com>
To: joel jaeggli <joelja@bogus.com>
Content-Type: multipart/alternative; boundary=001a114dae4a1b325b053549ff5c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mkW_2K2EmWzG5lB74rH31NrJSNY>
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 05:00:15 -0000

Joel,

On Tue, Jun 14, 2016 at 11:29 PM, joel jaeggli <joelja@bogus.com>; wrote:

> 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 - it does.

Spencer


> > Thanks!
> >
> > Spencer
>
>
>