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 <> Fri, 21 April 2017 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 452C012946A for <>; Fri, 21 Apr 2017 00:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 neK8-YdfIXTU for <>; Fri, 21 Apr 2017 00:25:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22E92120724 for <>; Fri, 21 Apr 2017 00:25:22 -0700 (PDT)
Received: by with SMTP id r16so103028385ioi.2 for <>; Fri, 21 Apr 2017 00:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v9TjHcUFW6HyXtTRea895Dtoy4wi+IOn25pWLK7bgh8=; b=Zd+iZp30H5v7GUNQVnZMwfHOXaTyY0l5E6j46zNxAFp+MolERit+QCzPGrR6TZY7Cy I/YBrMAB3QYjBJtaNjPwEjxhlD+RhgwaZlvhFnyKuvUwvpZ4r3aZuym4xhq/VZix/jcJ rKnwf6NtWKtVyPVDF+9yelhkpI+6CV9brlIngsCDIVBAOJxkSPDIX35vWhcpL4Wo3Rks EzbYEpQM78KHFYOKW/jOPFQt5kgv3U1fbdhIExfXgR+O9DjiVa1DOShLlc1GJIGf4vsL vf8Ns+F5lmnFO1PN6N0UBQl9mAlWRY40feMsOf/lRuuEr16c8BvxnGwTlXkvIKOB3kHK H1GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v9TjHcUFW6HyXtTRea895Dtoy4wi+IOn25pWLK7bgh8=; b=GYShxGDf0l5CaDTlTbwerbtF0zq2EKI1HAl78kA/PKpeP0LIM2BDtDpzWFDJmhMpd/ WURXWFIPnjAgAqZxsbzPVGVxNIvorrdwaxn6u4WBBN6mpyUce7h0iMBUEeWEo+pCKKzu FdzsCLhifZrMlSFGLpmEXVjegxGIT+JHnC+Qm4kVUvgTNK8EmAiJpahnaxU9EGY+8f6T dffrUyX0fjhmrB+5vSMEdStzN1a6lklEFOzrmw0MO8GTHJIwG7+81Y8/gusensUkUc+d wBvVJNgzee+aSCC9qUG2cb0/H+qLRHj2vceKCuEsCIq7iSLqfXTBiEoPdRCx0VyBrp/P zLeA==
X-Gm-Message-State: AN3rC/757qOk/7PrLpfqQOHR6iB6mWR6QeknQkVRWvP6aQhZ5FRUJ9dR WO70x9dSxUvapEsfxKtYvKd43kyGvg==
X-Received: by with SMTP id 7mr14491805ioq.228.1492759519348; Fri, 21 Apr 2017 00:25:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Apr 2017 00:25:17 -0700 (PDT)
Received: by with HTTP; Fri, 21 Apr 2017 00:25:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Robert Raszuk <>
Date: Fri, 21 Apr 2017 09:25:17 +0200
X-Google-Sender-Auth: OAvEsLnt2eGa-IC4tx0iLwWCpiY
Message-ID: <>
To: "John G. Scudder" <>
Cc: Susan Hares <>, idr wg <>, Enke Chen <>
Content-Type: multipart/alternative; boundary="001a113fe9c2e2cf7d054da82874"
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: Fri, 21 Apr 2017 07:25:24 -0000


The entire new proposal is to help operate eBGP sessions. And this is
perhaps even cool for Internet sessions.

But I think silent route drops or making them invalid for best path ..
those options are not cool.

I would very much prefer to keep all eBGP sessions down ... not even send
out OPEN where such policy is not in place in new release or when someone
removes auto configured "bgp insecure mode". This is easy to troubleshoot,
to notice that something is not right and fix by anyone immediately or roll
back to previous release and come back to vendor with complain ;).

Having sessions to be up normally and getting silent drops on the peers
side where you can not login and check I find hard to accept as reasons for
it can be counted in 10s if not 100s.


On Apr 21, 2017 03:29, "John Scudder" <> wrote:

> #include individual contributor disclaimer
> > On Apr 20, 2017, at 9:08 PM, Enke Chen <> wrote:
> >
> > So *all* the new releases would generate "permit all" for any neighbor
> that does
> > not have an inbound policy?
> Something like that. We are into minutiae here but in my imagined case
> it's not a per-peer option, it's a global "emulate legacy defaults" option.
> (I think Jared called it "set bgp insecure-mode on" or something similarly
> provocative.)
> The global is only generated if (a) there is an existing config being
> upgraded and (b) it doesn't already have the command present (so, the way
> you turn it off is... configure it off).
> > I am confused - how is this "permit all" different
> > from today?
> It's not. That's the point. I had hoped to avoid rehashing this since it
> was already covered in the thread but as I recall the claimed advantages
> vs. "do nothing" included
> - there are no surprises for legacy deployments as you've been warning of,
> since as you say the black-box behavior is unchanged,
> - at least the default is explicit in the config so if you call it
> "insecure-mode" or something, maybe people will have incentive to flip it
> from "on" to "off",
> - new deployments (where a legacy config is not being upgraded) would
> start with the default "off" -- this is probably the most important point.
> --John
> _______________________________________________
> Idr mailing list