Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]

Jeffrey Haas <jhaas@pfrc.org> Mon, 07 November 2016 19:26 UTC

Return-Path: <jhaas@pfrc.org>
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 838BA1294CF for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 11:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-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 gyG9aaviDiAu for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 11:26:27 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3586F129517 for <idr@ietf.org>; Mon, 7 Nov 2016 11:26:27 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3866D1E1F0; Mon, 7 Nov 2016 14:29:08 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
Date: Mon, 7 Nov 2016 14:26:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2CB5991-C05B-4593-9909-45875BDD1B94@pfrc.org>
References: <20161031205515.GA25507@pfrc.org> <5818E126.2090202@foobar.org> <20161101185759.GA23458@pfrc.org> <CAO367rUUHO5zDLMzeLYbka_04k7WyFrw6BM83tyJeM4rZ8RZKQ@mail.gmail.com> <20161107152616.GB25256@pfrc.org> <6FE43655-81D0-45E9-9817-D5583213DE2D@juniper.net>
To: John Scudder <jgs@juniper.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LiDVLgLPCvPPCIKR48R1RGF9Ze4>
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-extended-experimental-00.txt]
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: Mon, 07 Nov 2016 19:26:28 -0000

> On Nov 7, 2016, at 1:15 PM, John G. Scudder <jgs@juniper.net> wrote:
> 
> 
>> On Nov 7, 2016, at 10:26 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>> 
>> Marco,
>> 
>> On Sun, Nov 06, 2016 at 08:23:36PM +0100, Marco Marzetti wrote:
>>> On Tue, Nov 1, 2016 at 7:58 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>>> 
>>>> 
>>>> A feature such as this one, perhaps extended with a per-attribute form of
>>>> draft-ietf-idr-bgp-attribute-announcement along with enough information to
>>>> figure out when filtering wasn't done could provide some safety.
>>>> 
>>>> The related changes to this proposal would be to simply add the 4-octets of
>>>> the attribute announcement scoping and potentially the attaching AS.
>>>> However, given even such vendor features are likely to need to work in an
>>>> inter-as fashion, generating scopes of containment become tricky.
>>>> 
>>>> 
>>> I have always wondered if we should add and N bit to
>>> draft-ietf-idr-bgp-attribute-announcement to limit the advertisements to
>>> neighbor ASes only.
>> 
>> Such a thing was discussed among the authors of the attribute-announcement
>> draft.  What this would mean is such a bit would need to be set and then
>> automatically reset into the M-bits (C+A) at the next boundary.
> 
> I'll also observe that we already have the NO_EXPORT community which has virtually the same semantics if you apply it as you're sending the route to your peer. And then there was AS_PATHLIMIT, which never achieved escape velocity. Regarding NO_EXPORT, you might remark that you have to apply it at your border router instead of at the origin, and that's true, but I'm not sure if it's a big deal. You might also remark that NO_EXPORT doesn't survive if your neighbor strips inbound communities (or explicitly blows away NO_EXPORT), and that's true too -- but if operators are deliberately dishonoring NO_EXPORT, is there any reason to think they wouldn't insist implementations have a way to dishonor the mooted N bit?

Agreed.  Also, arguably the issue is worse during initial deployment of the attribute-announce feature due to the number of boxes that simply don't understand it.

That said, this is one step beyond "no-export".  It's "set no-export at my asbr boundary".

-- Jeff

> 
> --John