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

"Alvaro Retana (aretana)" <> Thu, 20 April 2017 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76D811314B2 for <>; Thu, 20 Apr 2017 10:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IkIQT1V7C5n5 for <>; Thu, 20 Apr 2017 10:50:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDE401314A8 for <>; Thu, 20 Apr 2017 10:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3502; q=dns/txt; s=iport; t=1492710637; x=1493920237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AvsTHFcUfVwevP7TMTGqK1xs2228RFC72YPIqkAEuiw=; b=TyTwuxae9/4fYKRPaAu6o0yrN/8eKcsUMQ1B+wDrT18dDuqqAeDOodic 8iiTDyn0W8sSgQbZj22gizeWngUQnFufkxoRl4b002kPwOHd16vF3Pgzm ELl09xBFz64qGH52n4BOFdDdcxwTDC++1iqL+V2t6/1Y8kkLf61ldTRiP M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208";a="233567906"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 17:50:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3KHoaZA011388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 17:50:37 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 12:50:35 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 12:50:36 -0500
From: "Alvaro Retana (aretana)" <>
To: Jared Mauch <>
CC: Job Snijders <>, "" <>
Thread-Topic: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Date: Thu, 20 Apr 2017 17:50:36 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 17:50:40 -0000



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.


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 :-).