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, 27 April 2017 19:56 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 81DD31294D2 for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 12:56:45 -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 AWpJgICaftl9 for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 12:56:44 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 76E3E129B72 for <idr@ietf.org>; Thu, 27 Apr 2017 12:53:21 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id 70so22259296ita.0 for <idr@ietf.org>; Thu, 27 Apr 2017 12:53:21 -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=EuRWmvkBo3J0E2a5ABFqHh17Y1iiWeUt2Fr4OgXdyN4=; b=Gfuy1O+fb852DjwmOvpOmWi+Vp6Awnr7mrN/xzrytZ1mupcXa9zNAK8iVpJU1YKvZU d5qH40KqV0wsAoZWG03moGDAoi5e1j0943dc00PeBqWRA08cnOD85kIGAESTkDzknoSp O7zoZ00FZvZxLgelzfPor4TDN6sSuGkiDz3DEpdHsTIezfuNyZhluH0uXkYHNV++agwj as5nGnwZ0mNi5jf2Hmmqa9x+AAQlgmgAkv8tk9dAfcFOMnFft9bPpvI3bFow3K20kNwX x10uzOL8v967kjcC3pB77CRzzoPrcPfQa/7O5I16gDufVCySCHzFDpLqPpci3SsAx6bX ekiw==
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=EuRWmvkBo3J0E2a5ABFqHh17Y1iiWeUt2Fr4OgXdyN4=; b=KO60l965MKsSXOPB7h0fD7KsH5seoxhIIuhsxOilIGzmLDyOANOqwcbbFZNJ2DwGTo s4BLnBAfsMwpm0ZU+iI78INkGkA9A1sUS9tSu6s41XX0jwYmsOyajOaRRARctdgB6CrY dhpzizV+ntCftIkzKq7lImLa+JNKA7gxxuDL17V09PcdBKR6HT3gNhCB+tdLELz0QnQp tJq0TNP+RlLmt9DlKG180bR/tejZ9rZg8QbPia8Clsy5ZgsHfhG407WNjE89642zHIXs w9nyx3d5KkXSYy0TeLp5X0jBiQ+DO5VdXsPsX5x/hd3b+muSD2ydmgkxzt+cJuLGQeCr tUmw==
X-Gm-Message-State: AN3rC/7673YUACVY0DF5b/B2Xh64JLPo2DlOyOTkkgtc7jsD1kJOT7Qq XebOfTiWV0WaayjcO2vN8k7UjdmZYQ==
X-Received: by 10.36.46.69 with SMTP id i66mr5139500ita.59.1493322800349; Thu, 27 Apr 2017 12:53:20 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Thu, 27 Apr 2017 12:53:19 -0700 (PDT)
In-Reply-To: <CAHw9_i+1HA=o+Lh7NgUxzD-OFq8u6kR5Se5z=tHttkVQ_QaSzg@mail.gmail.com>
References: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com> <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com> <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com> <CAHgCvCNRYyH9wyT=vtVk34_Wc_rqrX0z1D9FCx+cZzLBOXmFLw@mail.gmail.com> <CAHw9_i+1HA=o+Lh7NgUxzD-OFq8u6kR5Se5z=tHttkVQ_QaSzg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 27 Apr 2017 15:53:19 -0400
X-Google-Sender-Auth: XHinTeqQ2gI5JRQq6HBuVaBzDXs
Message-ID: <CA+b+ERnezGCy4C6RGHZt2sP2Xv9jZX9q3uZZwAY0wNirSReD5g@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Alexander Azimov <aa@qrator.net>, Christopher Morrow <morrowc.lists@gmail.com>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a114ab26c0cebc3054e2b4f38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/V32lNZ7J7a77u9ue-WCOWyP8_nQ>
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, 27 Apr 2017 19:56:45 -0000

>
> Empty policy is fine -- I have a number of sessions where I
> intentionally have no policy. What I don't want to have happen is
> *accidental* sessions without policy


​BGP peers are usually configured using peer groups or peer templates.
Policy (especially empty one) would be part of such template anyway. So
changing the default ​would not help to prevent anything once the template
is applied. And session without template being applied would in vast
majority of cases not come up anyway.

Only in stub multi-homed small networks which someone configures peers by
hand the new default maybe will help.

As mentioned before for those cases much better would be to have BGP build
in protection.

*Example for new BGP rule: *

*IPv4 and IPv6 eBGP received routes to an AS (routes where AS_PATH contains
other then local ASN) may be advertised over eBGP session to other ASes
only when explicitly allowed by policy. *

Such change in default is actually much more practical to really help in a
lot of cases while not breaking anything to those which have little stub AS
and advertise their PI space of 4 routes. Such change also address cases
where someone just adds once "send all" to template.

Best,
Robert.