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

"John G. Scudder" <jgs@juniper.net> Thu, 20 April 2017 18:41 UTC

Return-Path: <jgs@juniper.net>
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 4459E1314FD for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 yS6LhhkkmJhW for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 11:40:59 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0105.outbound.protection.outlook.com [104.47.38.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BBD1314F9 for <idr@ietf.org>; Thu, 20 Apr 2017 11:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3DYXE+S4IN0MnH7b0Ffvobog3ab0V1TV4BskFoX+fgM=; b=UX82B1qf2XIF++PdgtytRw4IP+SFbARJCJRIfLn9NtYWz7HKtPdkYa5KpBmJ18HI9gSKScaO3L7HLTjUen/Hxwr3HAySKqczHfP9mZG7+dXA5LETlypwO0zqiUn+rVMM79P0NUloLdSGAhwy49Dd/KBo2TaB+Ig1O7BVa6D18EE=
Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.33.8] (66.129.241.12) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Thu, 20 Apr 2017 18:40:57 +0000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <b57162ec-f806-6e86-7713-58608f72c468@cisco.com>
Date: Thu, 20 Apr 2017 14:40:52 -0400
CC: Job Snijders <job@ntt.net>, idr@ietf.org, Hares Susan <shares@ndzh.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <68B29403-9AD9-4F06-9FE4-3F077E793D9F@puck.nether.net> <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com> <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com>
To: Enke Chen <enkechen@cisco.com>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN6PR11CA0005.namprd11.prod.outlook.com (10.172.17.15) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4efe2171-a8ab-46d9-fa0a-08d4881cc8cf
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2498;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:LkpfiZNsESY0glwINIX8aWtFjmbbDtp6hm+uaPljuVa0o0vY+hMat5ONHKOeIjR2wwkQ/ZpwbTOSDAQxXoJiJuqxJhu/lHIdLr7adpgIo1ikvZi+VLTeosdexY+q2uo3uZwsBwKUKjVyDWuAJvkLYxex1u+yJeGC+IzCSERrl7Di3XC+d7NERhriq/ACxumm3/B07FRmI2dwEmC7bSi5xvFmP0fofV9+PzfU7Iq/uTwGuAb4Dtcmk3f+F3Rcn7fRaH9sRqh54wI5ewn6DJD4YtcjSYRj7gHWdnKMgrUId/hcZJIpcBGVV3NTBQoJQkJo9BYcyJxFAXPPI7ztm9GFEBeRnBoZvszkgP9q+/gfCPQ=; 25:F5W/DvskVRDqFwy4kPUtip3n+ZDQOHNTZclhwwKs2cJWj8+sP2xlCSnsXQTxFAxUv4GY5TW3Dp+h4CHsw9q7DSwtAzRCi6ae/NY+JWAVPhzPDcU/GPeIjqtA3PGvIwDSGfTdt1CJfKOT4xSfFcngLoTlBm1fCkTN/vHb3cyPfwKp4LAm9RemkfZnO5Pr8SDf9QqgSEdvERgJ6MgA8PZq8y8C/edTK3FaJy/CBVmHXsPpWrguIsYyBCUdsU14B56ENrPVtHwyl4vKK24J55To2NtP4ntZB5LMFHoQpc3eBeSlfUodPJyMh2Vye85bYzaNzKE8jnyvaNnRazbad9DhhAmQwcLrost6by+VCQO5/DACZ3TjRDVMtc9Cm/W2SKTiwQrGTdnIzqXN/V5Ap+RYn3CbEPUrUYyMnOy6zZ3A6WuHuzpL51yYJUgn8RcqQ/f4E3tA+auqySsgFR4j47jJ+b+L6ZBocc412nARzH4rYXA=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:cN4cp0a++/da0Ow7IM2EIKQefKMYwSrJ7J7oWGLSfsSVfU/3mrKHZGlZZ559ESwDRzjOhpKM239lxFOIka1+mi2iUxNchLbJbhY9FcP6paQok/hV0jZe8Kx2I1sWM9Ecs/DewcZiL0+aouRfMKQzww7FtGvknYDpukd1DG9IcqQzGnNn+71mxsiXo2D2zwSt/FtoGLZlVUGypfnlUB69AouwpOCV1xtD+efKjpwMEcmPi8zVrYA02g3jki9qzWQvF5yUHUJJmkUDN2Cof57+sg==; 20:4OP5BEjDp51PQd9Wa5PGVzxEgmoQvPHZliKiHSrIjnzajjhfP6U/mjUEwYyfXTlqpWcLZnhFKhJhm/PqQYQYOD5Y/aQ+RYD6gkBh52gefoXI1P4Lcn+U/YD9xH/GMwuf1HJ5KkaLBW778qzdWmp13nKd3qoWxhyDS701psjm00fAtyFyUBIddltILtSIeeLsa5noez0/mTiFWnh0yWvHB6sEoYUWRL8B9znaImx/DcqNqZ3I8Dax0qsdmmlqtHi+AcaHn5YEMfrOUw++9LddK2AEeJA21L2hBrIECoOZcm3jRcI/GjHbCLT09xxAfrpRVjuNy3nJ4+GbDcR0vUGdmB8An5Rs/WDplSqh1fx5GulDl5hWO4L8H1MOruQ5JH+4CtlmF/HBxuGs+nvlG8c2PKITK9BC9nQcMYqadeVFEHXF7OKf1raaihtNcl51x6XCr+YMklFrBoyO4FpJYeuhAf66/Mj2/7CuY1i+rgZkjPgwd4ZOTeZCW9WP+jyJ9SlWjv2HounwvibxJ8RG+xuIuewHFSqmUVlAUueVxOltPwRQmUYFak3lDkiB83BHJKPbXiMo8iTbBGvnrglIGBBDkWxDfzbw3QeWrpZmJGA6lg0=
X-Microsoft-Antispam-PRVS: <BN3PR05MB2498C4C37BC366512E0AAD55AA1B0@BN3PR05MB2498.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(124276396282122)(192374486261705)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(6072148); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 4:wBIYmr7KNcVC0ICQPv4H5PZHQaaH7UuN+VXzQzqGkEAzmiqbd/1bcvbHrXHKArGqeJvP+xn5+ZdcPNSg2cp8nUhFrPUvlVh0lc3lJVRZ1+SuD45okyqdbjg+xo3oVnAAjKresPTDODbO6yAsBBCzezX1P9bwVvOUz6kfyGmGSBTwIyWiB9zAWLk++CrK7IZFYlYUoQwasIQPRD+qQAqe8grSj2nmhMBN6/+qnd8iwu14Tf1xCaGbN6/NSE9mN/e3EjIvD+RNRomhlqcXqyCOmaZ6fP2DodEG8fTiWfKzHu8wrctYeeFkisA1RhgLgdSl8xGbh/vfZ59+5ntqPS7t4QAdgDXtlPyXkf64+yuFR45p5iMMRRxsyRLNLK5D2PEuLUkPk0NbAAw+tY/qzEMmD0m9vwA81xr/sX+e8TWrp5L92M/Gzp9m1EAYmbnPmfIzRd/FPlsj+/3EXtiZQLzG+MRVh2YW03wWdt4rlRH4I272UxDq0zZiPRNMZQxuYC3He127cODD4WZj3NK19WxCXN3fGmCHWnZ+KVmFh40Rw+3CmbORGNPYV5mygx9qjmsTLdRLSvFD2M32egKFIhV2Pox1xjbSACKIawwkSOv+6sd1ClUrDIBGPKgBtS93VuMhvayKd69tV+LWydJcZrXh3e5rsQ5SaWDt4OKZp9rUNzSchzjQXmB/rPMXcrggbpkmsC9C8uH400QHMJHhp2e9EAz7rlgeKdBgLhO6FYYv55pp3qj2pn3bO938W/LRF7IhN20EHqwoFRjcR6uuDwGqa6Pe0NGruM2mJMUyJApcdOP+UH2BxMsiwyhCqEWj+y6xgJImOjg5oVeNKioAAp29fNlHV3AkqRmDHcf3fWbZuFYuPB5G87QCmLAa5Ud8mQkH
X-Forefront-PRVS: 02830F0362
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39850400002)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(2906002)(229853002)(5660300001)(50986999)(76176999)(6916009)(6666003)(2950100002)(33656002)(23676002)(6116002)(8746002)(7736002)(3846002)(305945005)(81166006)(8676002)(4326008)(42186005)(50226002)(38730400002)(110136004)(50466002)(189998001)(25786009)(230783001)(93886004)(82746002)(47776003)(36756003)(66066001)(83716003)(77096006)(6486002)(57306001)(86362001)(54906002)(53936002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:[172.29.33.8]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2498;23:XUnUxw3P2I8IgGUGXR9haSxKcUVxXVEd1dXG4+w2DmKHjoRCrfugkEf2BHR0QpKOAiHYrG0toDxuoxk5OiitRmArMQlQfDwDWhJgr48nI4VFR62OPCdmkSvyAotbC0PqSA8C3THTeFOMeOB5EH4t93Xy9AbMfDNiUCenOT9A0YpYLPjcpupr16lrP31WaS8PwAU15bY6NDiZBrxCseJR0XE0JTKlPsX5nAGMVY3Xb/m6EEY1ywzVu4wxSxdhz/9eMLDQgWftIEx/Jwky60nXFXeNQWhH9aYauUkKpzQQlM65gFu45C9vPQ5OLSNhYndUQhjRAe/6Z+uEvPl57mQPsi0SD7cXFjiA7zaQFi4ET20avZhhnBwDOI1FiV9H82ypjYd/u1IRv0ioHzUS8rJK0EuAi3AnEv2cswFueXu91qAweZqAXBkE1WZh361A9P4XoM7weOCP7f81o+771m+yAfCH+BjyJOMn4QgqTtJjSvUetF6nEiB5Sy3lcVvJUvcuFcbmV+KmHYSesDDnYPxrzfWbHc8dn/iK0Cw7Ii1QryWmqQrBR64YVvSQbIpa5l8pD+uLwXbN+mQqTBiz4qxxO9iNO/2gYyuqVUhw61jqBj8jacSdykIYwk0NbkbreBe3y/yywKjlvdcvgIWex5PwzdsIlMjwgrfIxdK+Agwz+nlLvNuRxzOf6gkuZMvxamYCwKmMzTlNMsakbD0gn1Z6kibGqPyoikvZnr/ooRVsTDpOFi9DOjiL6ymYEApeQaa1XVXZ6EEjWLt3cD1HC8Lt3kxpQWrgXVhZnhnwi0JeZOMcdYGYs3VF5vn/BL+kBulGogcl4C2/YRByoCWTXfcUkVva7BLXTZUGeb8RW2GN+dnJWex0RVRtmmdnLK/rllxaIJ70aYp8N8lX9+BHg6DzzVqfGy2zu5zbyZjToI7p6hOl5cTVEPSFxB0iB6li5WEBZ012xZ+H+S560H4esuhJDrewpzrcMfRN8jJiv9E4H6PdViYq6HaDafNm/ccIeFe22jJxBPWcArg4SesSwQT6dOE6NRzI04VKWtKLjsERiNjNcFFNDeEjfU53wQBuFSqVBE7w3ZmhBhJtZGKmdrIqznal0JMkioPAU1awwKJJkC3fXgBO8DrKtEdsibj9PP80s4jRhLXbV27LolM0xwME28Nhq0HDBH/2Z4CJdnVfc/LrD3wyH26Uo0AutuUcW9bxXbyW3gAvjCBwMCue1cxnXTx5ShWeayb8Cv5HZLE/5kE=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 6:Si+GH5kmnavqxMsNyIGXI3SYWh3pg8+AUxWedlFWHHLon5y16NZdizmV0Biq0hw1iY0/bw0sEEL0fhzMpH+dvEs55lyOCfDzQwi7WO78+P/Ju0F9ZZ1O3+HOaldw9GQClau/DV16AOXw6d0HKhB8IYcq1cd3IaE+yKse0lqpmjDTWn79GUh3bPsAEFu5bZ5VsbmebP4emhbmLEAZgJdoMj+kF8Cc/QQhR2lk5X3efzbE11Fa16Wvc7M3/UwMGCVpBvw+zCStZPHhAf1CO8NLwM2zOhekeSgLF52IV+dZeIY//d49vL9+ioCM0VH0TzSs58JtzrVh8C6kYAs+4in5iWAYvVNyB2oGu35ngOpwcJp8JbdBLg+OuDbEMa5rxA+Sxg/pTopeWU4AweoctSHxDWmqCtq7J9l0YvDBFAVNfiuvkSREeD3tAGPT2qC6Eo/RpJmLEPUqV51RtuS/Eoz28v1loP6nN9JDDk9Ws324mO3bD4ZuUa2/ittY0UsVj7bSuLS0O12ppD6AVDZMEPAyxSVPAk3uPCd+Dz7VKho1paU=; 5:lntQHWGeJsXV25o40H9mRVqIxdsyQmDfpC+LV4X9iai3nLeqKT+GMc503Kpc8vCww6bO5qlz52RIp3S7uXFjnsd6bZsYnLaWx4RSc+VArfPxg3CaQbGjDmunU0x7DoQt6Um9v3qpXVHDs0I3USLZmw==; 24:HqJhTvUeTqprBwnrLs+jZquf/oqW0lcTO3Uk7gt199KC1CNMSEL2319l6yL4mo7X+0HfHAgUOw7KM3biO+iZy9N+Z5KrJjUzeZZnE9kcHXA=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:L0sB6TqW75WqFvT5KMQXgaLvSr8S6YpL8YOlIuJBav+N2ZaXRLJxS12GdGzsZ18nWpIquSPIe/VrQHn/UvEEErKZCNp5rRs4aeQPCc3kVl0pfT/YzaAXjyap4jhpRvvrt+LBJ0aWzm/NtLB/VUrfuevksvlOI+cRHK2lbJbvD/oNnhfCEdjKneA88U1EaYjOHkUJnRZ+FjwIwoJML+dXZtoKM+v0gDo9pwvBsSgiXMntWIAiI/jdGySaVzMnWApgFl4Lkw0cDwLfqs47zKnphskFucUaRbJ8V9207JIK0R2U1WKlXSz1uE+1GKww/+5ksDj9bJVgS7xwVnJI4epopg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2017 18:40:57.1864 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XWEq5OFQyD0GnGDZSFORfDFFjOk>
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 18:41:01 -0000

Enke,

On Apr 20, 2017, at 11:57 AM, Enke Chen <enkechen@cisco.com> wrote:

> It depends on the customer base and also how long the software has been deployed.
> Just think about the scenario that a large number of customers would lose network
> connectivity unexpectedly due to a default behavior change in the code. Such outages
> could keep happening to different customers for years to come.
> 
> Perhaps, changing "impossible" to "impractical" :-)

Various people have provided worked examples of how they think this change could be effected without causing the disruptions you warn of. I've pasted one example (from Jared) below. I haven't seen any response or acknowledgement from you, to those suggestions, just the repetition of your initial concern. I for one don't understand why you think a scheme such as Jared describes would be either "impossible" or "impractical".

If you are unconvinced about the practicality of such a scheme, it would be great if you could describe why. 

Thanks,

--John

Jared's message:
> On Apr 20, 2017, at 9:40 AM, Jared Mauch <jared@puck.nether.net> wrote:
> 
> 
>> On Apr 19, 2017, at 6:26 PM, Robert Raszuk <robert@raszuk.net> wrote:
>> 
>> Keyur,
>> 
>> You can not set "insecure mode" before you reload the OS as current OS does not have such knob. Unless you delay the deployment across N releases and enforce sequenced upgrade.
> 
> Infact, this is the recommendation that I’ve provided to vendors that have expressed concerns.  There are many defaults that have not always been displayed, but things like IOS have “show run all” so you can see these.  
> 
> Something like the ‘bgp unsafe-ebgp-policy’ could be generated on their respective implementations.  I didn’t think that GROW/IDR needed to tell implementors this level of how to manage their release, so this does seem somewhat out of scope, but a concern I can see needs to be thought about.
> 
>> The only way to prevent massive reachability failure upon reload due to complete silent bgp prefix drop is to configure inbound policy for all EBGP sessions before the reload and run with new image. 
> 
> Since we’re talking about how to operate a network:
> - People who are taking advantage of an undefined behavior will always be surprised
> - 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”.
> 
>> Of course this is all assuming that someone will read carefully the release notes :) 
> 
> Most people don’t, and I’ve always suggested to vendors they implement some sort of incremental approach to resolving this.
> 
> What worries me is that there is a major incumbent provider who doesn’t see this as the serious (and well-documented) security issue that it is for those operating large networks.
> 
>> If they do not the troubleshooting of this will be really painful ! CE will see EBGP session as UP, will get all the routes and will send his routes. CE will have no clue if PE dropped or accepted his routes. Likewise on the other end .. Only imagine a network which has 10s of thousands of VPN CEs as Bruno mentioned and their provider not following all releases CEs are running. 
> 
> 
> If they don’t know how to troubleshoot BGP, that isn’t the vendors fault.
> 
>> 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.
> 
> - Jared
...