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

Enke Chen <> Thu, 20 April 2017 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E01521316B0 for <>; Thu, 20 Apr 2017 14:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b24cjn6hqtJm for <>; Thu, 20 Apr 2017 14:03:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21A361316B5 for <>; Thu, 20 Apr 2017 14:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4373; q=dns/txt; s=iport; t=1492722205; x=1493931805; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5o+hApi6jnFob/VvkCUdEeNnb9mdqLNWNZdAG7q9Y/o=; b=HLeT3msJyxFK5iceCT9vrD/ByZ/fJwIYEalmB2LK3oc2+/FRntnD3c1I thVgn9kBHrN3JXBtgVCD/FNrWIXXiEgJ9GOA9oF6i4AktCniblKlG+AcX Y5xElZo61sZ18X8RbZyq0FNvPdz1UwDpwYJ2BE2HYqY+cqiozpj17S+4C g=;
X-IronPort-AV: E=Sophos;i="5.37,227,1488844800"; d="scan'208";a="410306070"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 21:03:24 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id v3KL3NPA004707; Thu, 20 Apr 2017 21:03:24 GMT
To: "John G. Scudder" <>
References: <> <> <> <> <> <> <>
Cc: Job Snijders <>,, Hares Susan <>, Enke Chen <>
From: Enke Chen <>
Message-ID: <>
Date: Thu, 20 Apr 2017 14:03:23 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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 21:03:27 -0000

Hi, John:

It's not like the issues with software update are new :-)

As we all know, there is a complete lack of uniformity (on a global scale) with
the procedures for software update. As a result, a proposal that assumes certain
procedures is bound to be incomplete, and will not work for some.

As Eric summarized,

Phasing in a change of behavior over several releases is not a practical solution, because:

a) Customers will still be surprised when the default behavior finally changes, and
b) Many customers won't deploy all the releases anyway.

Thanks.  -- Enke

On 4/20/17 11:40 AM, John G. Scudder wrote:
> Enke,
> On Apr 20, 2017, at 11:57 AM, Enke Chen <> 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 <> wrote:
>>> On Apr 19, 2017, at 6:26 PM, Robert Raszuk <> 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
> ...