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

Robert Raszuk <robert@raszuk.net> Thu, 20 April 2017 21:05 UTC

Return-Path: <rraszuk@gmail.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 AE5A61316B7 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3l0NgT3DVtC1 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:05:29 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 5C9C21316B0 for <idr@ietf.org>; Thu, 20 Apr 2017 14:05:29 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id r16so83326467ioi.2 for <idr@ietf.org>; Thu, 20 Apr 2017 14:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qwKA1YYE+bKXBdl1/w0Zr8xXs8a+LNoHUQYcKq7LlmI=; b=bpcJgSllSlxGe4wGQTPW8AJLfZaUvo1zqdyRWM7Db4ADrS9KeqCDV6wVG6/C3jS8ct LYE+6iEVIZhfzSGva7NmcVdfEgAZNDP8YF+VuJILTfjmhWY32qQKGIJkYVSdb3kAj93R 1Z8zyIPYBT1suVpaWINUM2XYaZadiX+YnoZvQv6siVMULD7dVel69ujYQsiQvOuBKBPt 7vkDkKK1giGO2WYZNzN80DGESsQ4/fKr6Owczn2vR5D8/PblFAVEBkvBuP/dZcAjLe8P enDT0D9Gi5JxKhEHbX+vMvFlGIax0t5j9UrKyOF3OudeTUN5HgdRnSU5YdiQfrOm70Ei tYqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qwKA1YYE+bKXBdl1/w0Zr8xXs8a+LNoHUQYcKq7LlmI=; b=jztNLuMO3JrWr5PiS6ITVHyEt0w3smQvCbSjzYB54vl1Z+tOc8wF3EzWmo8WMGiQwB lMqFxFql96dOPyFRmn87dpgwYoVEpHNifhIfOp8H/8G87Bbp1V6UR02GX9VogiwcvUg6 CHAsF/UfwjPNKDLfcspv2AoLe4Sn6XNpHcLpqWETrXCXucy25TkfhBg7MKgOlpkknyus SVKD1XrEpm6gfRtayH7pNlT01CMf8Uv+/w6ZDzRVNZ97yJntVrxkxLtoPE1jn+Me8oQj FP29ui7pkRZnZYK0oKHfNIh/wE5poGNgcdVI8l21pi3ag+aEi0sQll6EeFhEVAjbdlQ5 +zww==
X-Gm-Message-State: AN3rC/4gse7zs+LQVNpvvJnXeIrikVTVkJdkqIyHtX4qZLBEWy7vkf9D LmCKmOCInKE2AA1kXnXKsM1Ogqk3CURp
X-Received: by 10.36.115.12 with SMTP id y12mr6272344itb.24.1492722325997; Thu, 20 Apr 2017 14:05:25 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 14:05:24 -0700 (PDT)
In-Reply-To: <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com>
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>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 23:05:24 +0200
X-Google-Sender-Auth: 3NPx25aXY_OmTMs2DYGM-cNn2vc
Message-ID: <CA+b+ER=ee6Q59mbctO06P8x2QsTz_me9mL9YcB25O2Ey4+kpdA@mail.gmail.com>
To: Enke Chen <enkechen@cisco.com>
Cc: "John G. Scudder" <jgs@juniper.net>, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a11444dcafd52b2054d9f7f8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5CMp7adkPHjPwjKSkD9RoQlZI1Y>
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:05:31 -0000

+

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
>