Re: [GROW] [Idr] operator inputs -- route leak solution
Gert Doering <gert@space.net> Thu, 23 March 2017 07:46 UTC
Return-Path: <gert@space.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7F131448 for <grow@ietfa.amsl.com>; Thu, 23 Mar 2017 00:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 zF5v3M8UphEO for <grow@ietfa.amsl.com>; Thu, 23 Mar 2017 00:46:01 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 196AB131443 for <grow@ietf.org>; Thu, 23 Mar 2017 00:46:00 -0700 (PDT)
X-Original-To: grow@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id ABC0C6165A for <grow@ietf.org>; Thu, 23 Mar 2017 08:45:57 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7294860B6B; Thu, 23 Mar 2017 08:45:57 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 63BA16BA8F; Thu, 23 Mar 2017 08:45:57 +0100 (CET)
Date: Thu, 23 Mar 2017 08:45:57 +0100
From: Gert Doering <gert@space.net>
To: Nick Hilliard <nick@foobar.org>
Cc: Gert Doering <gert@space.net>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Message-ID: <20170323074557.GK2367@Space.Net>
References: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com> <20170321205513.GA2367@Space.Net> <CAH1iCirbAnj+Tyn0rs5Zs9-RyY=Qj2onqNh=DehEkDQtPrRSJA@mail.gmail.com> <20170322143302.GG2367@Space.Net> <58D2F5E7.80205@foobar.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="H8PKZwTLj31pggDC"
Content-Disposition: inline
In-Reply-To: <58D2F5E7.80205@foobar.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/6JdNniqGMfdZW9XmuhHhXfKoMNk>
Subject: Re: [GROW] [Idr] operator inputs -- route leak solution
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 07:46:04 -0000
Hi, On Thu, Mar 23, 2017 at 12:08:39AM +0200, Nick Hilliard wrote: > Gert Doering wrote: > > If ISPs do not turn this *on* on their customer connections, it will not > > do anything - and given that those ISPs that *need* to turn this on are > > the ones that are not caring today, I'm still not seeing why they would > > turn this on tomorrow. > > the asns unlikely to turn on a feature like this are leaf customers, > which is intentional. In a topology "Upstream1<->customer<->Upstream2" the filtering, aka the "turning on of the new feature" needs to happen at both upstreams - both need to send the new attribute downstream, and filter prefixes coming in from their customer with the new attribute. If either upstream doesn't turn this on on their session to "cutomer", the mechanism will not work (and you can't make it default, as it would break upstream/peering sessions). Please explain to me how this is going to work if "lazy upstream ISP" keeps being lazy, and does nothing. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
- [GROW] operator inputs -- route leak solution Sriram, Kotikalapudi (Fed)
- Re: [GROW] [Idr] operator inputs -- route leak so… Gert Doering
- Re: [GROW] [Idr] operator inputs -- route leak so… Brian Dickson
- Re: [GROW] [Idr] operator inputs -- route leak so… Neil J. McRae
- Re: [GROW] [Idr] operator inputs -- route leak so… Gert Doering
- Re: [GROW] [Idr] operator inputs -- route leak so… Nick Hilliard
- Re: [GROW] [Idr] operator inputs -- route leak so… Nick Hilliard
- Re: [GROW] [Idr] operator inputs -- route leak so… Brian Dickson
- Re: [GROW] [Sidrops] operator inputs -- route lea… Randy Bush
- Re: [GROW] [Sidrops] operator inputs -- route lea… Brian Dickson
- Re: [GROW] [Sidrops] operator inputs -- route lea… Randy Bush
- Re: [GROW] [Sidrops] operator inputs -- route lea… Sriram, Kotikalapudi (Fed)
- Re: [GROW] [Idr] operator inputs -- route leak so… Gert Doering
- Re: [GROW] [Idr] operator inputs -- route leak so… Gert Doering
- Re: [GROW] [Sidrops] operator inputs -- route lea… Susan Hares
- Re: [GROW] [Idr] operator inputs -- route leak so… Andrei Robachevsky
- Re: [GROW] [Sidrops] [Idr] operator inputs -- rou… Randy Bush
- Re: [GROW] [sidr] [Idr] operator inputs -- route … Randy Bush