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 <> Wed, 26 April 2017 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCFEA129B56 for <>; Wed, 26 Apr 2017 04:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iSVZas1tmPnH for <>; Wed, 26 Apr 2017 04:28:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91403129B55 for <>; Wed, 26 Apr 2017 04:28:52 -0700 (PDT)
Received: by with SMTP id a103so506038ioj.1 for <>; Wed, 26 Apr 2017 04:28:52 -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=8Y8GzQSx1d7Qc9p3/rXloKLNeyM7AV3Eb2b25O9/Jaw=; b=R5gWPLUmS4s7CB7rgMMz16XANxVLjiLnjVCY7ETGlVGUNc+94YYFBAPT53hT7TJyki Q7FmSAsGgDk3k7i2C8T+yOzi2CTwpoHN0lfy+VrvDYRp6XPXVA1PWHHd8Shsej59BoSh rOC8H68dkEsXB0EFdUHdp1HspLE3k8DvI+htxO3Gz7G/Dk/SP/6c0XWpcm/F41qysnJh ew767O0Wr30EgfsllX6vI0B7CjWALYebpAYvR2EZitMw69sGKnIAoAZNs39tKwwAeDT+ aJJluWMa1bMs7gGeyoMzpaQJE3cw2nYC8IWRBuQ2MUBzdi/oE5gk2a2qleocVB83geND KfsQ==
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=8Y8GzQSx1d7Qc9p3/rXloKLNeyM7AV3Eb2b25O9/Jaw=; b=gi1sK1CBkFddQXHXhRu0yDE6Fb1gLUeiKVJhNwnqwiQaLcX8uUNbEZu9R8j4yZJ7TX vYcLVMNma2jHgRqnj8xfFT8rWKbQgGBV+N8dhLHZW3kSC2wnM5xv4IMnWPvSw5UQOixr rUK4QKmAGpVIn1ROAMvo4FU/3vn9SAilJfDCY+zlEl7uDg5XgZZGMXjkvl4k39xE91oA 3K/oNZvHY8M/cQgr6QSjMABkhDvalhNotnlNogVl123FVbum2nL4gJ5GzE8mFsMBM5ZN o1Jqr1yhszurVfmwY3gkBSUKvVlJ30oxNZVU7Wj1dU2+3Q7gIau6F1I4RROaQKb7J/Fv 5WBQ==
X-Gm-Message-State: AN3rC/5aBzqpnL7nhSsNZdxkAoS8mgaliXhdOL385TBuDUlVQnoUFnNw XT4FG/Dqu/8sUyrIrt8ZnZcuHBv/aw==
X-Received: by with SMTP id 198mr19506590iof.186.1493206131929; Wed, 26 Apr 2017 04:28:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 04:28:49 -0700 (PDT)
Received: by with HTTP; Wed, 26 Apr 2017 04:28:49 -0700 (PDT)
In-Reply-To: <20170426095547.GP25069@Space.Net>
References: <> <> <> <> <> <> <> <> <023e01d2be72$031ac180$> <20170426095547.GP25069@Space.Net>
From: Robert Raszuk <>
Date: Wed, 26 Apr 2017 13:28:49 +0200
X-Google-Sender-Auth: AJzdFTax-aV7hhtuCDuWG_u9J08
Message-ID: <>
To: Gert Doering <>
Cc: idr wg <>, "t.petch" <>
Content-Type: multipart/alternative; boundary="001a113ebcb811f54c054e10259e"
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: Wed, 26 Apr 2017 11:28:55 -0000

Hi Gert,

Unless the result is not lost of connectivity but lost of BGP path
redundancy from your AS.

It is quite often and in fact good idea to have dual vendors as your ASBRs.

So unless proper cli is automagically added the problem may only  surface
weeks and months after upgrade and in fact far from given ASBR when
external link from still operational ASBR breaks.

Document should discuss that as well and recommend such auto cli.


On Apr 26, 2017 5:55 AM, "Gert Doering" <> wrote:


On Wed, Apr 26, 2017 at 10:45:57AM +0100, t.petch wrote:
> If you stop propagating routes, then you create black holes.  How many
> black holes of what size will this change create?  How will those black
> holes be detected?  What will be the damage to the Internet as a result?

Black holes get usually noticed very quickly by those *responsible* for

Routing leaks get noticed by the victims, usually not by those responsible.

Gert Doering
        -- NetMaster
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

Idr mailing list