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

Jared Mauch <> Thu, 20 April 2017 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D5D4124D37 for <>; Thu, 20 Apr 2017 07:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Inmp-Guf1V6D for <>; Thu, 20 Apr 2017 07:06:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F40F1205F0 for <>; Thu, 20 Apr 2017 07:06:50 -0700 (PDT)
Received: from [IPv6:2603:3015:3603:8e00:25c2:4c02:5849:c73d] (unknown [IPv6:2603:3015:3603:8e00:25c2:4c02:5849:c73d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9EE5B540C09; Thu, 20 Apr 2017 10:06:44 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jared Mauch <>
In-Reply-To: <>
Date: Thu, 20 Apr 2017 10:06:26 -0400
Cc: Keyur Patel <>, "Acee Lindem (acee)" <>, Hares Susan <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Robert Raszuk <>
X-Mailer: Apple Mail (2.3273)
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 14:06:52 -0000

> On Apr 20, 2017, at 9:50 AM, Robert Raszuk <> wrote:
> Jared,
> - Vendors can take the N+1.x and N+2.x release strategy, where in N and N+1 they generate their equivalent of IOS-XR and the "bgp unsafe-ebgp-policy” policy to prevent their customers from breaking
> - In a release N+2(or more) that would become the “default”.
> ​In the past things like that were also actually solved within single release by automatically generating this line of "missing" configs if no other policy was configured. However for this specific case I am not sure what does it buy you in practice. Maybe consistency across BGP implementations.  ​

I see value in consistent behaviors.  We have vendors that do different things here, and are inconsistent amongst themselves as well.  I’m surprised that PM types haven’t pushed for a consistent behavior, but this may more reflect internal company cultures.

> > At least doing it as part of OPEN msg will be immediately indicated to both ends.
> This is you promoting a different draft, I recommend another thread for that draft.
> ​Well if both drafts can solve the same problem maybe there is a room to discuss it and pick one to go forward with. 

I think the other drafts have some value, but I’ve not yet been able to wrap my head around where the technical and business pieces intersect and would cause operational issues.  I’ll leave my detailed comments for the other document, but they have been raised at the microphone at the past 2 WG meetings re: the Open message draft.  (let me go find the thread or start some comments on those).

- Jared