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

Tony Przygienda <tonysietf@gmail.com> Thu, 20 April 2017 18:25 UTC

Return-Path: <tonysietf@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 33E4D1314CA for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 gvXn7JYqZWp8 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:25:07 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 2CE941314BB for <idr@ietf.org>; Thu, 20 Apr 2017 11:25:07 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id z109so41096285wrb.1 for <idr@ietf.org>; Thu, 20 Apr 2017 11:25:07 -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=zavAmLCX6hIox0GKMQ4L/tdBttHfu6XmDRAlwCrlRBQ=; b=kXde5vmcvbHwstd3si0mYGleNYgfD/wUC7vBoBlGYL6wYzBjkqxOcEqn+HlTLcfxKO 6tpFnpUF6djY+OadlTflz0zNrVmzcalK8vFFM4Le9ISnO5TRou+rnf585Gr2yjjEapOx LtAf8tzdRo5qOSiyRDzFe35ozJyMGepxCxlzm1tPs8Qylbb1/sQEaB4S5rpaHaMAI1Sr Gglr9bXJWekqzj8qoNZQuIw9iMUU8wIqJnDxvwPkM8pRgNdvakINsj62P+Ql9lRXc0J9 ybgNog5kFd4BW5G3VdBp8JV/qEWyFXcjr7TK9wXt0wHkUCGjV+x7jvsiU/hDQ9aw8lkH zmpw==
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=zavAmLCX6hIox0GKMQ4L/tdBttHfu6XmDRAlwCrlRBQ=; b=aHq1el/wNdN5jSm0WuZ2omr6zlrAnk8FW/DB6ZxYeibEmIviJB+HKhmwo4YirDf2Hy oCgZKkiV2tlIszKKHw6yrOOcLI/7sB/6TU7wQIrwNlAvr8cL6hJAbfClS802p8nEYAfI rxj7URg4gBMFtOyXfYlIpYNwLhO9HKfrP0MB8Qo8/r+fbO7c7536xX46B/v97whdgXIy 1QCZ0EznddzKyFVM5KgMD+ua6QxPicBW5uqxjkXEojKjOtY7EnLoxSAD2Hpu6ATPe+UB Cx411OqBVoAqrdSFnEinF9AIlMQB+rokM2kn/xtJ/Z9cAjRxjn3BiMtp3UGCsGkE2nlk R8VQ==
X-Gm-Message-State: AN3rC/7DwvftSvQZkrSt0TKWw+2Zua4wGidgWY7sz1rx/RAm8K/l2xt3 lMrbpj7IoqIPBjpZYsIMIuS6FWQ0Vn32
X-Received: by 10.223.139.215 with SMTP id w23mr9240370wra.169.1492712705663; Thu, 20 Apr 2017 11:25:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.136.9 with HTTP; Thu, 20 Apr 2017 11:24:24 -0700 (PDT)
In-Reply-To: <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.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> <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Thu, 20 Apr 2017 11:24:24 -0700
Message-ID: <CA+wi2hMPYcwbNhHtuWKWUXb4Lg3x81p786yLqeNEHFV1okGRvg@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "Alvaro Retana (aretana)" <aretana@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=f403045ec49892b237054d9d421b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gSksbf85n4TAGAqu4fPlUx8nZHY>
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:25:10 -0000

Can't miss that food fight ;-) So couple observations:

i) as often, when an RFC tries to mandate anything beyond things on the
wire & the procedures to treat it, it tries ultimately to mandate
implementations and this is seldom wise
ii) +1 Enke, +1 Acee.  I understand operators here wanting "their default"
but large, diversified codebases have to serve (especially with BGP) a wide
spectrum of customers with different needs and with that, different
defaults make sense. And I remember routers booting up with a question list
of "press 1 if you're an evil syndicate, press 2 if you're a bedroom ISP,
press 3 if you think this is a toaster" to get the right defaults set ...

Having said that, I think this is BCP material at best and if this is a BCP
then

i) a "backward compatibility a.k.a which end of the stick is sharp" section
is very advisable
ii) the BCP should describe which customer segment is best served with
which default

--- tony

On Thu, Apr 20, 2017 at 11:08 AM, Brian Dickson <
brian.peter.dickson@gmail.com>; wrote:

> 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
>>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>


-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky