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> Thu, 20 April 2017 20:19 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 C1A00129C3D for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 13:19:49 -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 gEoNwQRSzJ0h for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 13:19:48 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 D545513162F for <idr@ietf.org>; Thu, 20 Apr 2017 13:19:47 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id a103so86167029ioj.1 for <idr@ietf.org>; Thu, 20 Apr 2017 13:19:47 -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=6bK40W10xmTjBd+xn39s8K3XIEVXQM6W1SF6gPx1PvM=; b=SBmHxD2sAv10GlOUbdnuPyeRSbzlnAKy+jiHGb6c6mVx5jp1awr2Igsmbz3AS+WaXg 82WgXxUC8eDTsGXHcxsS7YfJ6AIQuK4tXO3pzJOeHOj/1h+2OXUIHDefWZJ4WgiY//79 kmhuuMqkn6I9+zkKTk3KUK4XII6XnJhcXtC1OU4+u9HkfL4Mo0e8oue/76+jyB4ezYoI 4UoOJUcoSzAY/AstJL1O04LL82aT0t+hfVlaxA0JZ9D8XvSA8D+LW9l1+euBv1TDO2DV Jkhcedln/bCqx4irne+j72Q1sHIHfaXLeHs2Ge2Mk+XiImmEjBU3qePlZ5kmoRivwBTE A/VQ==
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=6bK40W10xmTjBd+xn39s8K3XIEVXQM6W1SF6gPx1PvM=; b=hnO04OBcQ+AZkKKIW4ADG1LuOALngXm6yZp8e+BrrfSUoYLZAEbMNqTTLyr20onD4L nIanADSNdprDTldZqUBvRQkNDIOEN6piI5dAIShV2Ce7ChKsImO5n+tC7pUsftdIJwBV LXnkI2nPq7EzypfqgRUEUppr9EhDJo6iqX4a1zGYrHfSgQYoWBdAk4qxXD5nkHHpmSMA JGx6/MVFqpP8fiK2EAm8f/NnGZTn+16Xros/cxXDHW2gqL2fw93tTQlOoaSn1brZWLnV IBvfrhnaSZT4/DXVji294MDb+PI40gyvL26maSP6lubQXFEpSGfJ99kSf06fnFUMIOVr 5PAw==
X-Gm-Message-State: AN3rC/6mVVX1AOJnfcmsFuZOl1Sr55vdQDA1UlKUO/8OzjZzFqX9b3sb i/0ABZutHPNcYBcWVmrZHMc+7wybyg==
X-Received: by 10.36.46.81 with SMTP id i78mr6103207ita.39.1492719586092; Thu, 20 Apr 2017 13:19:46 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 13:19:44 -0700 (PDT)
In-Reply-To: <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <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> <20170420160736.GB15676@puck.nether.net> <75AC1A50-3DF8-4852-8FC6-BC302B121946@cisco.com> <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.com> <CA+wi2hMPYcwbNhHtuWKWUXb4Lg3x81p786yLqeNEHFV1okGRvg@mail.gmail.com> <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 22:19:44 +0200
X-Google-Sender-Auth: RZ9v5ncaWtGCsMz_Bn-5qHEBUHo
Message-ID: <CA+b+ERnGJYUAiZLxG99gE9Km-R_pTFPp3ehk1kvXmv7sXS4cbg@mail.gmail.com>
To: Eric C Rosen <erosen@juniper.net>
Cc: Tony Przygienda <tonysietf@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a93ceadad4f054d9edc8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5nnwI3sM8rupGptlveWHhezTUgY>
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: Thu, 20 Apr 2017 20:19:50 -0000

> I can't wait to see what happens when the "trust nobody" folks get
> together with the "zeroconfig plug and play" folks ;-)

Brilliant analogy !

The crux of the issue is that BGP is used in completely different
scenarios, but completely different users. Some care about Internet some do
not.

For some BGP should be as simple as RIP. For the others it is not even BGP
protocol but BGP policy what is the most critical and important.

It's like cooking big pot of soup .. for some it will always be too spicy
... for others way too mild regardless how much piri-piri you add to it.
That's why restaurants have a concept of menu.

I think it is time to propose proven in other working groups the concept of
profiles for eBGP and perhaps also for iBGP:

*eBGP internet-profile* - will have all the defaults on to make sure
Internet is as secured as possible

*eBGP dc-profile* - will optimize BGP to work in tor-leaf-spine env if
someone needs to use it there

*eBGP ix-profile* - will have set of functionality to work well over NBMA
and auto detect NH liveness across IX

*eBGP home-profile* - will allow to exchange routes and subnets without
much clue about BGP attribiutesm policy and communities

*iBGP maximum-rebustness* - will enable add-paths, best external, enable
PIC etc ...

*iBGP weak-hardware* - will only send and accept one path and slow down
best path runs

etc ..

And all of those profiles will actually differ in the vendor's defaults
optimal to each use case of BGP. And most important it will be backwords
compatible too !

Just a suggestion. If someone is willing to work on draft on it - I can
volunteer to help.

Cheers,
Robert