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

Job Snijders <job@instituut.net> Thu, 20 April 2017 21:09 UTC

Return-Path: <job@instituut.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 C3B0C129C5C for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 9DnNiMGouucq for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:09:09 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103FC1316B7 for <idr@ietf.org>; Thu, 20 Apr 2017 14:09:08 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id z52so2020918wrc.2 for <idr@ietf.org>; Thu, 20 Apr 2017 14:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ja8GTBs3OeMXSml3RmPKS6HM/5pGZBTGiXtIu7TGYZA=; b=DvcDPNEbUfVyxbMpnYfZgme457oVMLV95CuZfEpgtuF58WpEba9xiiOSbfqRiH1YEW 1TTj0rgcviukJB6ws+o3ftebtqiCLf+DNG94Xl/ys4UGMHrHjZctu3PDovNxrHFy8jtN 0c/RMkw6H6Kdsz3u7mpYcnI9kaYzSZAWDPPxmY5X5o9U68RiYDyKvSojdUAdut0biFZl lH/JfPTA48PLE/X7ceqrqh5yLbSwFEPVbMnhJTxJLvuH4Q1EOhmqizQNKCcjRIXXA/vs 4rnFXS6xzJs2MyRmYIKN2RNjUizx8cm2OXgI9MULj6sY8YdsCxkt7btqVtZ20PusmuoW AWHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ja8GTBs3OeMXSml3RmPKS6HM/5pGZBTGiXtIu7TGYZA=; b=bWAw9i0tQpncSX9AhMEflE6FdIDe5sr1JCOSieWBaHRVkwIbTLEjGTKVvk8PWc4ERK caLNaP7F7bjSOdFdqYry3JKiJ3z2+q0xAr2tbOXkUHc4bpQe3XSbSbqmjM17MbIdHoI0 GJvb0iRrN+s87zazvoohq/TKQJYnf1yzYGrbxmQop6IMcWqp0jH5HS1OCCjnWjsgt283 iBXdHFJaZsvh+BzwYyQrLTDhOH1Jx27TS2VEE3KJ99qnerDVEJfAfVuzY2HpheRggciG OdPtEVnVdPM0qrDQ1jdGfwe5tfGVFTCPzIuiYbb7JJhmPp2i161TibPL8PxwypplQMA8 DreA==
X-Gm-Message-State: AN3rC/4a222gHBjQCr0sBdqvgEqgvMtKIbBoL0+ZkBGgK7cfxQTY2zoP E73JD2KWZYq0t3byNJjrNoKf2GI14w==
X-Received: by 10.223.134.132 with SMTP id 4mr9630394wrx.82.1492722547406; Thu, 20 Apr 2017 14:09:07 -0700 (PDT)
MIME-Version: 1.0
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> <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net> <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com> <CA+b+ER=ee6Q59mbctO06P8x2QsTz_me9mL9YcB25O2Ey4+kpdA@mail.gmail.com>
In-Reply-To: <CA+b+ER=ee6Q59mbctO06P8x2QsTz_me9mL9YcB25O2Ey4+kpdA@mail.gmail.com>
From: Job Snijders <job@instituut.net>
Date: Thu, 20 Apr 2017 21:08:55 +0000
Message-ID: <CACWOCC-Gusv1Jk1OXfVAZuWbMJxrzq=dEAdWGVSAPg0AjujhXA@mail.gmail.com>
To: Enke Chen <enkechen@cisco.com>, Robert Raszuk <robert@raszuk.net>
Cc: Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114918a82fd098054d9f8d7c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sqQoT3jssm9Z0Boy2rYPZ-CEqno>
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 21:09:12 -0000

So a change like bgp-reject will take many years to be deployed within a
single network, how can that be reconciled with the perceived "surprise"?

Kind regards,

Job

On Thu, 20 Apr 2017 at 23:05, Robert Raszuk <robert@raszuk.net>; wrote:

> +
>
> c) deployment of new code release in large network takes months if not
> years
>
> On Thu, Apr 20, 2017 at 11:03 PM, Enke Chen <enkechen@cisco.com>; wrote:
>
>> 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 <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
>> > ...
>> >
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>