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> Thu, 20 April 2017 12:11 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 47831130154 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 05:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 enCdfIy_j36L for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 05:11:21 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FA81294B9 for <idr@ietf.org>; Thu, 20 Apr 2017 05:11:21 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id EAA86100282; Thu, 20 Apr 2017 14:11:19 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id CE8F4160065; Thu, 20 Apr 2017 14:11:19 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 14:11:19 +0200
From: bruno.decraene@orange.com
To: Job Snijders <job@ntt.net>
CC: Hares Susan <shares@ndzh.com>, "idr@ietf.org" <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: AQHSubQ1Fx6qnNOc8UaJCUOYEKex/KHOBVj8gAAiHiA=
Date: Thu, 20 Apr 2017 12:11:18 +0000
Message-ID: <5886_1492690279_58F8A567_5886_16468_1_53C29892C857584299CBF5D05346208A31CC08A3@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <19878_1492639968_58F7E0E0_19878_13298_1_53C29892C857584299CBF5D05346208A31CBE742@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170420085755.sbzdtcjhirdoi3b3@hanna.meerval.net> <8442_1492680540_58F87F5C_8442_1101_11_53C29892C857584299CBF5D05346208A31CBFD43@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27506_1492681817_58F88459_27506_7804_1_0c74078d-a304-441b-9dbf-abb5d5e4eca2@OPEXCLILM5D.corporate.adroot.infra.ftgroup> <20170420095624.zwhw6ypm7zwgtfsy@hanna.meerval.net>
In-Reply-To: <20170420095624.zwhw6ypm7zwgtfsy@hanna.meerval.net>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BCVMHWgRMpz6rkrwcsByJkpQ8tw>
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: Thu, 20 Apr 2017 12:11:24 -0000

> From: Job Snijders [mailto:job@ntt.net]  > Sent: Thursday, April 20, 2017 11:56 AM
> 
 > On Thu, Apr 20, 2017 at 09:50:13AM +0000, bruno.decraene@orange.com wrote:
 > >  > Can this document define what he means by "configured export
 > >  > policy".  Possibly by referring to standardized yang models.
 > >
 > > Because I think the document means "configured route
 > > (re)distribution/advertisement policy".  Possibly this was implied by
 > > the word "export" but one could read this as any outbound policy,
 > > while a policy setting some communities would probably not help much.
 > 
 > We purposefully did not specify what the contents of a policy
 > constitute, or whether policies should have an implicit 'accept'
 > terminal clause or an implicit 'deny' terminal clause.
 > 
 > All we try to accomplish, is that if you configure _nothing_ for an EBGP
 > peer, the software will not advertise any routes or use any routes which
 > it receives.

People do not establish EBGP session for the pleasure of the OPEN message. They enable it to get and receive routes. So without any additional thinking, they will type whatever additional keyword that you may require.

e.g. 
OLD:  neighbor 10.1.1.1 remote-as 65124 
NEW: neighbor 10.1.1.1 remote-as 65124 send-routes receive-routes
Or NEW2 
neighbor 10.1.1.1 remote-as 65124
neighbor 10.1.1.1 send-routes receive-routes

People will just blindly use the new CLI. So this would only address the situation where the CLI interprets the command on a line per line basis and send all routes without waiting for the policy/whole BGP session configuration to be configured. (e.g. waiting for the ending delimiter).
If so, this looks like a CLI/vendor specific issue. Not a BGP / IETF one.
And definitely, we don't need to impact/change the behavior for the BGP sessions which are already configured.

Kind regards,
--Bruno

 > Kind regards,
 > 
 > Job

_________________________________________________________________________________________________________________________

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.