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

<> Fri, 21 April 2017 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3F8812948E for <>; Fri, 21 Apr 2017 00:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WL-2vuM0ZvMB for <>; Fri, 21 Apr 2017 00:32:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48AB1120724 for <>; Fri, 21 Apr 2017 00:32:32 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) by (ESMTP service) with ESMTP id CDCE6205F0; Fri, 21 Apr 2017 09:32:30 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by (ESMTP service) with ESMTP id 99AD21A0064; Fri, 21 Apr 2017 09:32:30 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 09:32:30 +0200
To: John Scudder <>, "" <>
CC: Hares Susan <>, Enke Chen <>
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
Thread-Index: AQHSugWjFx6qnNOc8UaJCUOYEKex/KHOnYWAgAACnoCAAMk28A==
Date: Fri, 21 Apr 2017 07:32:29 +0000
Message-ID: <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Fri, 21 Apr 2017 07:32:34 -0000

> From: John Scudder  Sent: Thursday, April 20, 2017 11:13 PM
 > (as an individual contributor)
 > On Apr 20, 2017, at 5:03 PM, Enke Chen <> wrote:
 > > It's not like the issues with software update are new :-)
 > Yes, exactly. That's why I'm so surprised by this discussion.
 > What I still see here is
 > - on one hand, a worked example showing how an implementor could roll out the
 > functionality without causing heartburn for users. (My paraphrase: expose the default in
 > the configuration. When upgrading old->new, automatically create the corresponding
 > configuration line(s) to configure for legacy behavior.)
 > - on the other hand, general statements about how this is a hard problem.
 > I find the specific worked example more convincing.

Good point. Thanks for the useful contribution to the debate.

a) Regarding this specific point, could the draft refer to this point. e.g. add this requirement (if this is a requirement draft, which it looks like it when reading the first sentence of section 2) or add the solution (space) (if the draft define a solution).
e.g. "When the BGP speaker is upgraded to those new default behavior, existing BGP sessions, configured using the old default, must be unaffected".
Or whatever text.

That is indeed the most significant deployment impact, so it's good that it can be addressed/included, rather than silently ignored.

b) Still, this draft introduce new deployment impact to all network operators using EBGP, including the ones not concerned with this problem space, as provisioning tools need to be updated prior to this deployment, otherwise provisioning would fails. Plus silently fails as the session is kept up, silently ignoring the route with no feedback to the EBGP peer). Plus for each plateform, they need to selectively handle both configurations depending on the software version of this plateform.


 > --John
 > _______________________________________________
 > Idr mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.