Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

Robert Raszuk <robert@raszuk.net> Sun, 23 April 2017 13:42 UTC

Return-Path: <rraszuk@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 A080B127909 for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 06:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 rzbqOt9Yy9RQ for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 06:42:35 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 2E293124B0A for <idr@ietf.org>; Sun, 23 Apr 2017 06:42:35 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id r16so151835639ioi.2 for <idr@ietf.org>; Sun, 23 Apr 2017 06:42:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YubXERoYaqJgs77o7Wkh+fK+FMx2TTLxpQxdwChP/mc=; b=UQTTQXqr00hTZDwVpNo1QeRvkea1212yGqVqkpuNSYxuimW6L2jIfpXyc+YXASc5BV 71SfoMhLdRTAkIxDNPdQdX724RdxOZiiPlxOn2XX6quoarq+OuBzjEnuVlFe1hXy/qVm qx7JLGI7Ua5zGuxNDcF1EzjzsuYkdQSJWQ2IHgR+JzHqDMVBXCiFMSmV+FfZ+H3x9Szu 98sccSXsHO9YiMIxHlHWFftlUsCiYbz54cjvsJHaAEh6UljtOzH9Kva4akNWBBAwzy5J FdZNkrsq//XRkd1mesOycPVHQivL25PqvAjC931jMZMKlhhQq6EYeJoy7MzfQ2lWY1Mv AfIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YubXERoYaqJgs77o7Wkh+fK+FMx2TTLxpQxdwChP/mc=; b=N3oYcnAYBmdowq8L05DBXa8694Yu0Ni52tZIW07KXQmzbuh7zdfSgdXhMq0hxsjRdS yzVv8Wb0Z8Yrk0+niEQ3PDhAdRqtvnvYxZzq4w0Eh01Fc/J2Jg779goQXePCM9yQFsZ+ WpoX5llg61L3B0XRCtKNgiMOVbeZ2ehpI9Ysg7dxpCL1Q8ZjhqYkXHakygJSk/ujiFf3 d3IVd26FyzKZYJwTTgMOkKpngTLrTE0CU7BAKNo1UYdzly8ZjQAshYr7+c3P27Pza6n+ LSxI++91LXscHQv0c5e/nDIMTBf0VgyQidPdqEF9X7JKT12iXMeWidSiaFkY5lzWdfhb gxrw==
X-Gm-Message-State: AN3rC/7E/NWE0A3sS4S0amfRSHov+fg85x/U+UXJyfdQ/yIOu5d9exF8 D97sgWgOMSmpP9A/PfCdowYRpYaaDQ==
X-Received: by 10.107.140.10 with SMTP id o10mr2052313iod.139.1492954954501; Sun, 23 Apr 2017 06:42:34 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Sun, 23 Apr 2017 06:42:33 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1704231447550.5591@uplift.swm.pp.se>
References: <68B29403-9AD9-4F06-9FE4-3F077E793D9F@puck.nether.net> <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com> <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com> <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net> <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com> <4CE4AF1E-0C80-423E-B19D-5750FCAFAD89@juniper.net> <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421084638.l6pbvtznfsxnq2wy@Vurt.local> <23291_1492766305_58F9CE61_23291_9725_1_53C29892C857584299CBF5D05346208A31CC399E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421095839.sralcy7aos5mzzic@Vurt.local> <d57ed214-945a-54b8-e04f-cb8610f789e4@cisco.com> <alpine.DEB.2.02.1704231447550.5591@uplift.swm.pp.se>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 23 Apr 2017 15:42:33 +0200
X-Google-Sender-Auth: YrH-LoiQfIyPM68p9B2XoULS068
Message-ID: <CA+b+ER=iuA=bipQJedh7Z=Q-wo6ShjhmgBsHdQ-SYKesEH_C2Q@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Enke Chen <enkechen@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c06084cba9ae5054dd5a9af
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QP6C9XryCzSbl0iD3zTx_GmX3n8>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 23 Apr 2017 13:42:37 -0000

> If this doesn't make sense,

No one said here that it does not make sense. All comments so far are
rather about few points:

-  what real problem does it solve
-  should it apply to all address families or just 1/1 & 2/1 and all
profiles of BGP use
-  if done should it be silent ? (**)
-  should routes still be in BGP Adj_RIB_In and be sent by BMP (further
hiding the issue)


> why was it chosen for IOS XR back in the early 00ds?

Because 3 first major customers of XR said they prefer AF centric BGP
config and to have such policy for eBGP route announcement. As XR was not
deployed anywhere making that default was zero pain for anyone.

** Making route ineligible for best path and local RIB insertion is one
thing. But if you also are using say "add-paths  all" I would not be
surprised if those bgp implementation which care less if the route is
inserted in RIB and FIB before propagation would advertise it anyway to
iBGP peers (**) making even bigger mess in your network.

- - -

Besides to make sure the BGP policy is there before route is annouced or
accepted very is much simpler way. It is not about changing default, mess
with 100s of corner cases in the code. BGP configuration parser may just
not allow to configure "activate" under a given neighbor in selected (or
all) AFs if policy is not there. Done and makes everyone happy ! On upgrade
to new OS optionally you can still run fine with auto-addition of this
proposed "bgp insecure-mode" global bgp config line.


Example:

router bgp 65000

neighbor  192.168.1.1 remote-as 65001
address-family ipv4 unicast

neighbor 192.168.1.1 activate

                                          ^^^^^^^^^

!!! COMMAND NOT ACCEPTED .. ACTIVATE NOT ALLOWED BEFORE POLICY FOR EBGP
PEER IS SET.

//R

On Sun, Apr 23, 2017 at 2:56 PM, Mikael Abrahamsson <swmike@swm.pp.se>;
wrote:

> On Fri, 21 Apr 2017, Enke Chen wrote:
>
> Job,
>>
>> IMO the most important point from the discussion is that any BGP extension
>> or behavior change must be backward compatible, which this document is
>> lacking
>> or even missing.  After more than 20 years of BGP deployment, the world
>> is no
>> longer "green field" any more.
>>
>
> I have been involved in running core networks since late 90ties. I've
> deployed several vendors gear. Yes, going from IOS to IOS XR with the
> change to XR having default deny if there is no policy, that was a single
> occasion "oh", and then I knew that. The good part here is that it's
> failsafe "close", so that you don't announce anything by accident. In IOS
> you have to basically paste two lines at once, with the first line being
> the creation of the neighbor, the second line being shutdown. Then you can
> configure the rest. Otherwise there is a race condition in the immediacy of
> a per-line, immediate committing operating system such as IOS.
>
> This is just bad design. It's "fail open" default. If you somehow fail to
> paste that second shutdown line, you're now fully-open, announcing and
> accepting all routes.
>
> If IOS would be changing its defaults, the CLI line migration code could
> by default insert a PERMIT-ALL policy statement, or some other means where
> an upgrade would keep the behaviour of the box intact across operating
> system versions.
>
> So I fully support draft-ietf-grow-bgp-reject-05 because it just makes
> more operational sense than the old default that for instance IOS
> implements. We need default fail-close, because it just creates less
> problems than default fail-open.
>
> If this doesn't make sense, why was it chosen for IOS XR back in the early
> 00ds?
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>