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

<bruno.decraene@orange.com> Tue, 25 April 2017 07:46 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60F128B90 for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 00:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAmgN0ahWSaD for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 00:46:36 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04D8128B93 for <idr@ietf.org>; Tue, 25 Apr 2017 00:46:35 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 2CA141605C3; Tue, 25 Apr 2017 09:46:34 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 0152C180066; Tue, 25 Apr 2017 09:46:34 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Tue, 25 Apr 2017 09:46:33 +0200
From: bruno.decraene@orange.com
To: Christopher Morrow <morrowc.lists@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
CC: Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
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: AQHSvSzT/UOdCRuRk06fXrEppErHB6HVrpgggAAGwVA=
Date: Tue, 25 Apr 2017 07:46:32 +0000
Message-ID: <1250_1493106394_58FEFEDA_1250_2544_1_53C29892C857584299CBF5D05346208A31CCAE1C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com> <D51D67E4.A9782%acee@cisco.com> <AF07526F-F08B-4084-937B-A9A2D2DD2813@juniper.net> <D51D6AD2.A9795%acee@cisco.com> <CAL9jLaa1UQ5A1FwRKVw5RJCBQO+0j0BW4vUNaPXHB0_JB0j76Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A31CCAE1COPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mzYxg9ieGdEnxc7OR_4ADSGzXsg>
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-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2017 07:46:39 -0000


From: DECRAENE Bruno IMT/OLN  Sent: Tuesday, April 25, 2017 9:26 AM

From: Christopher Morrow Sent: Monday, April 24, 2017 8:59 PM
On Wed, Apr 19, 2017 at 7:30 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:


On 4/19/17, 7:25 PM, "John Scudder" <jgs@juniper.net<mailto:jgs@juniper.net>> wrote:

>(As an individual contributor)
>
>On Apr 19, 2017, at 7:18 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
>> the draft is conspicuously missing a “Backwards Compatibility” section.
>
>Seriously? "Backwards compatibility" in this case is "configure your
>router to do what it used to", right? We need a section to say that?

Anytime one proposes to change the default behavior of a decades old
protocol to be more restrictive, I would expect this to be discussed.

a few times in this discussion people say: "the protocol", but the draft doesn't propose changing the protocol, it proposes that implementations stop being wide-open with respect to send/receive conditioning/filtering.

There's no default behavior change in the protocol (which I think doesn't really talk about filtering prefixes at all, not in the sense of 'prefix-list foo in' anyway).

[Bruno] There seem to be various opinions about this. This is a bit of a concern at this stage. In particular, some previous comments/support may have used the wrong assumptions.
If this is indeed the goal to make no protocol change, including no default behavior change in the protocol, could the document be updated to state this. In which case, Standard Track may be required.

[Bruno2] I meant: in which case, Standard Track may _not_ be required.

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

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.