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> Fri, 05 May 2017 22:24 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 3BC19126E64 for <idr@ietfa.amsl.com>; Fri, 5 May 2017 15:24:13 -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 Z8HjundeWp2X for <idr@ietfa.amsl.com>; Fri, 5 May 2017 15:24:11 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 9C5FD126DED for <idr@ietf.org>; Fri, 5 May 2017 15:24:11 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id c15so38584970ith.0 for <idr@ietf.org>; Fri, 05 May 2017 15:24:11 -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=rEn92PwuWBRUkM9Y1rFLPalFtJv/dylQ+XMxxEEzrsk=; b=J7i34BEN25mmzHD03a2uvDHhNWfGAbrK6BmqOZ00aI3bbfouvRi6SoNRCjZiZF2kqE Y/OCSr2WN7BPo/b/DwbHy5XCjmn6b32bhC8C0HcO7dHh0eqqPFjpZy4i2yBej6uu3o4W 6tln32AosoeFJSZ3MOvyeAJgJm5L4QXcRfO7vVG/+MpUtTx+4eSpLkUQFybz9p+bH70N GBH27cOYughmkQP+gkRIMkrlq10rT3rZMRt86vr/jOmv5ljuFv+ReN+lHCDqDeXkR3PG uJAthJ4LDeeXp4nw80FDTDbc1eiqy95o9lXERWNS8fxoFe3Rr/4OeavtUk2/3aAY7jCT 3vKg==
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=rEn92PwuWBRUkM9Y1rFLPalFtJv/dylQ+XMxxEEzrsk=; b=N6ZQUcSoPi8wFe6hQk24gD5Ua2/fvR2ozvBSVf09uaKPqHpX+MS7YL7nBUExDFxRsf xUhZJHsttXJ43fxmvUYF25oV+WvWlbEUApQOWXw6n7IBEHW/F9EAFdNp3SNRAfiBCgot hI9Fts94sUOCuXvMsQzz5b5DotRTKbqvP4LqiYIMKdpJ5tZN+c0XlYwEzMxy4pD34b2b SvPmnTUqvLb9ZcF/Eg/lFmCLLkUFOVTzlF00es9KWIKRhtJXjxQS+FhvIdBzfJiICczK KQ1xZP5ywVFK+WknDX/ISU+eGFTtg9piVDNGfEqsg1iKqHE5gmrEy3Ot61vL6faKC4lL jHaw==
X-Gm-Message-State: AN3rC/6LG5ZJzjeHPKb8JN82pIu79PZilqZBt2f4DjYSnuO8iSD2FAU1 wxZaq7Ja4D+SV5JaitSjY9SgjpbZVb2E
X-Received: by 10.36.94.138 with SMTP id h132mr12217630itb.104.1494023051013; Fri, 05 May 2017 15:24:11 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Fri, 5 May 2017 15:24:10 -0700 (PDT)
In-Reply-To: <CAH1iCioOMDtR1LYVxZ5NxuCxDtChwKQ7P8g+_aOXL3C6pj609w@mail.gmail.com>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <CA+b+ERkt-B65dPrWRULBE1iOqHQpujjoEwqGxZjOWcR9OVbqPA@mail.gmail.com> <CA+b+ERmkEy2rJYLAGyaVVCBOxukjx8u2AJM9t8JkU1GThG0tNg@mail.gmail.com> <CA+b+ERmTVWRBt5RYhDXF9FRcL+zh0rMJbdDoodOueuiTqdO3pw@mail.gmail.com> <CA+b+ERkFXEGf9YXbFksvYvgcz8hEYsTZJP38GFFoWr8DSihDKA@mail.gmail.com> <CA+b+ERmMTq4gEu7s8_sBX-WQat8Fn2MUJUyXAbvdr0K=+WdPew@mail.gmail.com> <CA+b+ER=_WCeU_HPpBm5XFjEd1autFCnzVqV33pvXrOOjtuG=Nw@mail.gmail.com> <CA+b+ERmKT5PTJb7bdCG-vGjebAmvKYjWtyqRKPQiLP37RjFSmA@mail.gmail.com> <CA+b+ERmCruh1pr_22kF8OsLn0oW8reJfoe1nKjBd6kjAC1Y_vA@mail.gmail.com> <CA+b+ERm6UFgTrfkPA_wrbt9trUejyby56vvFedrmn5FP4Sg28w@mail.gmail.com> <CA+b+ERkmZZuU7W-n2CPtu0xfPGO=E3K9Gy9o8aOZqj5uf5duCg@mail.gmail.com> <CA+b+ERnRqisRs3sdtxTm9R7H_HpLw82qd+7kAqaTZbRFi1ZGww@mail.gmail.com> <CA+b+ERkxwXS9u7Kt4uEA4=P6JA9M+8Ha96ny2+kOGFeDe+NYAA@mail.gmail.com> <CA+b+ERk6U1VZTdoNtve8b-HqxNBPkymF0i-++ixw5bN+yXAWcA@mail.gmail.com> <83ea4c7c-5d17-b92d-19a4-cfa572b3f070@cisco.com> <CAH1iCioOMDtR1LYVxZ5NxuCxDtChwKQ7P8g+_aOXL3C6pj609w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 06 May 2017 00:24:10 +0200
X-Google-Sender-Auth: PPbG1QsqrEna4fJMrNrNMY7iczg
Message-ID: <CA+b+ER=G_jYo6WsruKftaGs4TdtRim5eiweRL-95563zfaP77w@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a114252723df82e054ece5974"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ISRsaywjj4BmfWQxjchEhZC9oN0>
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: Fri, 05 May 2017 22:24:13 -0000

Hi Brian,


> 1) CE - either existing CE stuff can handle this during upgrades (qv
> discussion about upgrade vs out-of-the-box), and/or suitable warnings.
> Use of "permit all" policy achieves the desired effect on CE, and
> satisfies the requirements of this standard.
>

​And accomplishes nothing useful for BGP.

There is so many default we can change in all protocols which will
accomplish nothing other then getting new RFC then I see a lot of
opportunities for 100s of new drafts. ​

​Conclusion:​

​However I have reconsidered and changed my mind on this draft today. I
fully support ​it's publication as MUST DO IMMEDIATELY and to be proposed
standard and to update RFC4271.

What I have been missing till today is that this draft makes BGP harder to
configure and harder to use by vast majority of non transit ISP users.

And perhaps this is the real hidden beauty of it which is to discourage
users from using BGP as common application transport. Great doc !

Kind regards,
Robert.