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> Mon, 24 April 2017 06:37 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 7489D128ACA for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 23:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 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] 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 RkFIO219DLCL for <idr@ietfa.amsl.com>; Sun, 23 Apr 2017 23:37:45 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 52DD1128AB0 for <idr@ietf.org>; Sun, 23 Apr 2017 23:37:45 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id x188so39518880itb.0 for <idr@ietf.org>; Sun, 23 Apr 2017 23:37:45 -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=4PySh/VlgwuC5R8TahUEM2bAonVrGG+cfm8X6sF6LdU=; b=fkT0/47202/SZJusjinfyPHuiqAw8mMym0fTYY6r1U0pU9dbgt1Lk2VAhcJCiy+S15 gfNJpPHqP4NdJp4HmUvFMUXixOsiXuFLXfYPshxICdYtkBfc/vGxOHUPi1Qpf4gmtkqT JuDVAj8j5p92wN1KDWGGQjOJYemS6fC0ywZeQ8JgpAnP+VFr3vYkQv6CLR6hb69WZ3t+ 1cu0N3ImGyT3kLmRNtGWkXeMKIWtekbCbXv0ampHc5d+g/DswgfZ3zyzboNOd3MTaKsw q/3f/rig1y8LNvfEwkHWaHzoEDz+Jadhdwp1ZK8omUS4wmp7oKixVddl4pqk0O38Md9K s2vw==
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=4PySh/VlgwuC5R8TahUEM2bAonVrGG+cfm8X6sF6LdU=; b=opVrV0JweuYvt9Lvyec1WfAeITZUtfLpKcQJbzqnujvThf3X54RQaJnzIdGKHZ5K/x yTM41jtvL+HeOpBcXxHZE9cav+6UqdGHqjlIn7qq+K1pgNx8EYWtmSkvYDaYmu7ujViv CDd71frgHFcSgdfdKNJncgwet9ndH/Uw6GWURTXyLKqXeXRNE1KVBHBdSvfhB60lg0+b K9sHqqMuoHUZNxuHM+Lic6Jq6u5H1NoS9j9dtlaLFK98kuFqrrWDWlBS7jCmaA/Sy551 AOzzY8n1PUPe8zo+m+fyqvVjXbmeORKh55nV8f+OEucawMnfxqgimdBNChKo1fjDdlmp AKwA==
X-Gm-Message-State: AN3rC/7BHNiQWbwgcwRsRZA0RPSWIeoH6HStGt1UgXl0Kht7+O/S7CKe 8vlsYA7C9z307BgOxf6XPgFWmc9stg==
X-Received: by 10.36.48.149 with SMTP id q143mr11725493itq.25.1493015864592; Sun, 23 Apr 2017 23:37:44 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Sun, 23 Apr 2017 23:37:42 -0700 (PDT)
Received: by 10.79.170.4 with HTTP; Sun, 23 Apr 2017 23:37:42 -0700 (PDT)
In-Reply-To: <CAH1iCipQK-odotOJ+TOvJq6i9kDC40-dYgifkkDA4=YSsCGLTQ@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> <CAH1iCipQK-odotOJ+TOvJq6i9kDC40-dYgifkkDA4=YSsCGLTQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 24 Apr 2017 08:37:42 +0200
X-Google-Sender-Auth: WbcRywLuaeGZI7-fN-7QPiiMDto
Message-ID: <CA+b+ER=_fOCoU7_Q=f_R-ySa+bpJ2xRBh0d-mYpCc9c6WFOJ+g@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: idr wg <idr@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
Content-Type: multipart/alternative; boundary=001a1140b16040e1ed054de3d885
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pn1IK538o7MAEKkXQWktjr8uWxg>
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 06:37:48 -0000

Hi Brian,

Today global ASN is used for any eBGP session irrespective on address
family. There was few requests in the past to implement per AF ASN but to
the best of my knowledge it was never implemented.

MAY for other AFI/SAFIs works for me .. but let observe that if someone
goes with parser based solution this while accomplishes the goal is clearly
not a Standards Track thing but local implementation.

ISP vs Enterprise images differ in features enabled not different behaviour
of the same feature and everybody tries to still build from same branch. So
that distinction would not work.

//R.





On Apr 24, 2017 06:43, "Brian Dickson" <brian.peter.dickson@gmail.com>;
wrote:

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
>
>