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> Thu, 20 April 2017 18:09 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 456711314A3 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:09:03 -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 Ox8nFG59nvLR for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:08:59 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 969D6129B74 for <idr@ietf.org>; Thu, 20 Apr 2017 11:08:59 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id r16so77361449ioi.2 for <idr@ietf.org>; Thu, 20 Apr 2017 11:08:59 -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=zR5GFRMIC75zQIt7bBGiYI/3o5x59dT3A0qFIVHnkRk=; b=SecDVodYF8LaTjKbH+fmy2LM0upaXUPXioDes+OrmSEFYfW+Ejeo4mghNYu2Vrzdko gumsnKvsdYSum6oArWWtbH83eYaqfdGw2lzWSn1PAv+127ZfEe4PERavgx6Ri6Al3isp JVZDTV7UhDa6JYkLeNpV69BT2hg9oGoFDZ0ORcqQZs013iLfH1g6r+w7ZdgBevJHL0EX 7NaO88ovr2/rA6z1KRrCwxy8/xPH2EZ8Rjy42tj8y0+aAoKQt4VhUwlOMI3OWHx2TvJh H3+sa59FSGNeaoKUAMz4UQK/xTvkqauLZQTn8CPCBSaGPK/mECzCTpsRfT6BO051JV1G DiOg==
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=zR5GFRMIC75zQIt7bBGiYI/3o5x59dT3A0qFIVHnkRk=; b=g7GdAeVDAnmZQJGQ4ZEuNaHftNLRtq358nVLDL/fiWnG7VgXqQifn8GeZh/e8Th19E nIsJWCbbNukbKBXSeviQyDbBM+YFreSbVnkYwchts50UicXWM1YnS9ykP4LhqL7t10xo dBhvmmx5bE24/HDYmeQvTM9IquN8uc3QlJpvy1C5oPaT7adbZ6ffEklSGE9BUmLDTJfB 0eMKuE5LJmxEMJ5ql7bjamNUU/IoKHQhW0YsPS60+IjANZoAaXNNcSXeK9XNp3Oj8UIn 0shLu+MwH65wj4DNPmqk/r8uAEkoWF3iXhYPhLgoZocBJmvEa39lCVwxJzwNkyL/tMyU lXTQ==
X-Gm-Message-State: AN3rC/77T5t3cl+6D4Zg8L1SKfh6/6+uKufPnnwVf1edJDO5r3OI/+RB XqisCXt2+1Z2GeOk8qTxyDpF1GRg9w==
X-Received: by 10.107.146.139 with SMTP id u133mr11733201iod.160.1492711737459; Thu, 20 Apr 2017 11:08:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.46.151 with HTTP; Thu, 20 Apr 2017 11:08:56 -0700 (PDT)
In-Reply-To: <75AC1A50-3DF8-4852-8FC6-BC302B121946@cisco.com>
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>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 20 Apr 2017 11:08:56 -0700
Message-ID: <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Cc: Jared Mauch <jared@puck.nether.net>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c055f4edd29d0054d9d0876
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pnMwi69iqcS5Ksr2OrDQUOJjqx8>
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 18:09:03 -0000

TL;DR: BCPs don't work; operators vary in experience, diligence, etc;
vendors don't have common defaults; "open", "route-leaks", and "reject"
work differently and are all needed; code changes will have a long tail of
non-upgraded routers for a long time.

BCPs don't work - see BCP38 for the canonical example.

If operators were consistent (as in globally, uniform, ubiquitous without
exception) in applying best practices, these proposals would not even
exist. Their mere existence is proof that they are needed.

"reject" will only help once implemented, on upgraded or newly deployed
routers; ditto for "open"; "route-leaks" requires operator configuration,
but uses a transitive-optional attribute (and thus works alongside
non-upgraded routers). All three are needed, for their respective
attributes (on by default; stop leak origination; limit leak propagation).

The long tail on upgrades is what makes all three needed. No single one is
sufficient by itself, unless/until every router has been upgraded AND
configured. The three together are an imperfect but scalable and
incrementally deployable set of improvements with real global results.

Trying to move things in a productive direction.

My $0.02.

Brian

On Thu, Apr 20, 2017 at 10:50 AM, Alvaro Retana (aretana) <aretana@cisco.com
> wrote:

> Jared:
>
> Hi!
>
> Not everyone in this thread was part of the initial conversations we had,
> so to give a little background:  I think (yes, still) that the document (as
> is in -05) should be marked as updating rfc4271 because it starts off
> saying that it “defines the default behavior of a BGP speaker…” and later
> (Section 2) describes specific changes pointing at pieces of rfc4271:
> “…MUST consider any routes advertised by an EBGP peer ineligible for route
> selection (section 9.1.1 [RFC4271])…”.
>
> Again, what gives me heartburn and the reason this document caught my
> attention is that change in the default – and from this thread, I can see
> that is an issue for others.
>
>
> Reading what you wrote below, about other potential options to achieve the
> same result, I agree with you that the bar doesn’t have to be as high as
> changing the default in rfc4271.  But the current document doesn’t reflect
> that.
>
> Maybe what we need is to describe the solution in a way that is not so
> rfc4271-specific.  Explain what the behavior should be (not how to achieve
> it), and even talk about the operational pain, and what operators should
> consider with the current not-specified behavior (which the document
> doesn’t do much of now).  I think that would be a very different document
> with a different set of discussion points, but one that could lead to the
> goal.
>
> During the early thread of this draft (a couple of years ago), several
> people suggested that the status should be a BCP.  I can see how a document
> explaining the pains and the considerations for Internet routers could be a
> BCP.
>
> Just trying to move the conversation forward.
>
> Alvaro.
>
>
>
> On 4/20/17, 12:07 PM, "Jared Mauch" <jared@puck.Nether.net>; wrote:
>
>         To make it clear: I don't want to break someones routers.
>
>         I do want to make it harder for someone to leak a table when they
> have a new router.
>
>         I don't belive the bar should be high, it can be embedded in
> whatever
> configuration/ZTP/automation/cut+paste template out there.  It could come
> in the form of yang over netconf, or a DHCPv6/DHCPv4 option.  It could
> come from a TXT record in DNS, or wahtever configuration method the vendor
> invents that is new and unimagined by th WG today.
>
>         I don't feel it requires updating 4271 to attain that goal, it's
> clear implementors have seen a path to do this today without having
> a concern with 4271, and I believe that Alvaro is wrong in the presumption
> this document updates 4271.  (I'm also willing to be told that I'm too
> rough
> for consensus :-).
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>