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 <> Thu, 20 April 2017 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33E4D1314CA for <>; Thu, 20 Apr 2017 11:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvXn7JYqZWp8 for <>; Thu, 20 Apr 2017 11:25:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CE941314BB for <>; Thu, 20 Apr 2017 11:25:07 -0700 (PDT)
Received: by with SMTP id z109so41096285wrb.1 for <>; Thu, 20 Apr 2017 11:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id w23mr9240370wra.169.1492712705663; Thu, 20 Apr 2017 11:25:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Apr 2017 11:24:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Tony Przygienda <>
Date: Thu, 20 Apr 2017 11:24:24 -0700
Message-ID: <>
To: Brian Dickson <>
Cc: "Alvaro Retana (aretana)" <>, "" <>
Content-Type: multipart/alternative; boundary="f403045ec49892b237054d9d421b"
Archived-At: <>
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-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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 <> 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) <
>> 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" <> 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 mailing list

*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