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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 24 April 2017 04:43 UTC

Return-Path: <brian.peter.dickson@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 0791F126BF0 for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 21:43:12 -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 cKLCDtZQN3oR for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 21:43:09 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 81E61126B6D for <idr@ietf.org>; Sun, 23 Apr 2017 21:43:09 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id b134so4627543iti.1 for <idr@ietf.org>; Sun, 23 Apr 2017 21:43:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjefBA2PlOOgwJ5YHM2irFGODzLNfdGXfC86YUxVEFk=; b=WQcpFAos209lI5E7lB3I9Sk2YJM7c3rnwzHp7QGoTp8Vhq9Qu8VLzY7GouJ6hRsXao dnIAbYCYI1X/N9lZphiEiOBIxVYhBb8zpc3cTtv+YysQYPuLzpnjb5Sq45m3r4hj+cvA oE1lGgwECtX8n/4+68vXAUruUWZE0TvonBVnnQjme6I/FeXlP3r31cPjbUcb2TVRMdgZ 6J/clWo/5x6B57aIscGzj8tOAJ4fwOIxn6wp+YHw0zriyBzFlqI6gdnjP3heEEbrTUcc CwHSWCV7cmDOCyGTn2SCj0blvNLPZ9E2NNbWyvQB72ibpwSRvKpRSo2fN+0tfwbQ8Q4a HP8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjefBA2PlOOgwJ5YHM2irFGODzLNfdGXfC86YUxVEFk=; b=nod6vqc++W0LF/IHvWE9jayJWodrEED6OgTADtFr4nEg97GGyu6Nx1GGaUXoixveD4 Vpa0NU3NwylMFeXPvgbluEzVshD1PClBNHvwv3eu8joHthVUebt3QVknx9WZTDAUpAp8 qZbNFNM31o+6ZF+vbzxVTzH8uJ9Yaj4LZJKpWdcHs7SP37oMQ7X7hT/Mno584ss4qPzE xaAEgS0VacQrwdAiTH6Zs8s0q+DTSR3qCgiBQYlQLdPpSrbS1RHjo7/OdN7glXVm4ktM 4BpphUJ87B+7V7+q/w917d6xYU7Ny0mSQwezVlekTpoMWcspdNVfm+V5x7Hfj6SXiK2x 6vaA==
X-Gm-Message-State: AN3rC/5Ga1bD6r6yccXvrC5g8HRZxetzJA1duhUmI55O+opJs6ngOOZz mqqTBhEImLTcOk9utR0G9Jk+4VLheQ==
X-Received: by 10.36.73.155 with SMTP id e27mr11641829itd.6.1493008988908; Sun, 23 Apr 2017 21:43:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.46.151 with HTTP; Sun, 23 Apr 2017 21:43:08 -0700 (PDT)
In-Reply-To: <CA+b+ER=iuA=bipQJedh7Z=Q-wo6ShjhmgBsHdQ-SYKesEH_C2Q@mail.gmail.com>
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> <CA+b+ER=iuA=bipQJedh7Z=Q-wo6ShjhmgBsHdQ-SYKesEH_C2Q@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Sun, 23 Apr 2017 21:43:08 -0700
Message-ID: <CAH1iCipQK-odotOJ+TOvJq6i9kDC40-dYgifkkDA4=YSsCGLTQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c154966e381d054de23e0d
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/i6vyzVUT8vz5dvVi-1Xl9CSi5Fs>
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: Mon, 24 Apr 2017 04:43:12 -0000

For those not intimately familiar with non-Internet AFI/SAFI use cases (ie
other than 1/1 and 2/1), could someone explain which ASNs get used?

I am wondering if applying the "new rules" only when global ASNs (those not
reserved for private use) would be a suitable alternative to specific
AFI/SAFI combos?

And, to be clear, IMHO, the difference across AFI/SAFI should probably be
MUST vs SHOULD (or maybe MAY).

Also, don't at least some vendors have different code bases depending on
the use case, in which case the default could differ by code base?
E.g. ISP vs Enterprise vs (whatever other groupings/labels exist).

Plus, IMHO, a global knob to change the default is something that would be
wise to implement; I don't know whether recommending that belongs in the
document

Brian

On Sun, Apr 23, 2017 at 6:42 AM, Robert Raszuk <robert@raszuk.net>; wrote:

>
> > 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
>>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>