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:14 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 3F0321316C1 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:14:01 -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 iP1gShDgzM_k for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 14:13:58 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 5F3421316B7 for <idr@ietf.org>; Thu, 20 Apr 2017 14:13:58 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id k87so87491502ioi.0 for <idr@ietf.org>; Thu, 20 Apr 2017 14:13:58 -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=KG3GH17EzN83/NbUj8xbYxENJBZKGiIoGdoYIKLlN6s=; b=SHErfvVepgJLVe2Jm28abHUMXOCRgBEKT7fb0JA/b8DYD8Ww5qqMsLxRo3dMn8PiGm IjirEf1fjab3WOrTMS46CwvpN5YP6N5LDRdN+r/nMbyC87XKaksRgX/UHl76o+FMlOBI xQ5hwk9/yYZhDu4jFAHYVK1bvA8Bz8vNTdte0zXf0UNNHle8umdqTtwA0CNICf4T9Qn2 yjPC2lltJgpl8LAcX3AGikWlZoYP8pkkC+RMxD/RJiORrPjAbgdfE9zGFm3u/j80dgsH eG5FOIVjHGS+QU7FMKUrmPANI71he7C7ynC6s9R9Jg+EzOiz1Bx72dPfeVfBigeRGzV4 B2ng==
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=KG3GH17EzN83/NbUj8xbYxENJBZKGiIoGdoYIKLlN6s=; b=FiqZKsU0LMXUlsgUFcLMrv64FifjOxtjq5vj0Cja7416gbtxkm4i1Bm3ZuXOivyvPp 2bE9k0Pflc58lZmzc4NZHIWi1hLylSF/dQOHXbgpVsk3lhZ6EXqmBjRI00f8EmrE6k1d UHZ+DywUwYZMYPz9LuLsPGo/9jUOKndeURNxuy8kRoLq/1FePeNjZnIH7apZ+DNizvdN 7ThrmzntM5CTqL+9ca8ecOgVP1XLslp1BblgLmaUAjBplbx1H1lUXVqJ7D/iGyLqE8om XpMo0o65GG6HCvmeyEzD3tgLLObQNFyUHVGojOezCPo8XHx6GZSYNGvy7u1i3VvhzAX7 BYXQ==
X-Gm-Message-State: AN3rC/7Axt+pPdPJA0uvSDbxByYMchbVCuiBDYnqDT1MnkNbtMI1dI9N Q7TGAxmOVy1zncTsd5YpSkktHuk5og==
X-Received: by 10.36.115.12 with SMTP id y12mr6327732itb.24.1492722837086; Thu, 20 Apr 2017 14:13:57 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 14:13:55 -0700 (PDT)
In-Reply-To: <CACWOCC-Gusv1Jk1OXfVAZuWbMJxrzq=dEAdWGVSAPg0AjujhXA@mail.gmail.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> <CA+b+ER=ee6Q59mbctO06P8x2QsTz_me9mL9YcB25O2Ey4+kpdA@mail.gmail.com> <CACWOCC-Gusv1Jk1OXfVAZuWbMJxrzq=dEAdWGVSAPg0AjujhXA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 23:13:55 +0200
X-Google-Sender-Auth: g-2BIeB2n_0-Md8eRKB0NU8LbdY
Message-ID: <CA+b+ERmOF+7k1OJuJ3paXNGemEr9F_ZKUvb_VsP6h4vjHQHC4Q@mail.gmail.com>
To: Job Snijders <job@instituut.net>
Cc: Enke Chen <enkechen@cisco.com>, Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a11444dca73ea4f054d9f9e06
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cDUnjviKEL0TWeoU2RwI0Tm_et4>
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:14:01 -0000

Hey Job,

At least I am not seeing that much of a problem for large networks with
bgp-reject. We can collectively go around and educate folks at various NOGs
what is coming well before any vendor publishes code with that change,

The worry is about little guys with one or two routers which never attend
NOGs and which in fact still want to send everything and get default out
from upstream. I am feeling a bit sorry to expose them to such pain
regardless if they use cisco, quagga, ubiquiti, goBGP, snaproute ... you
name it.

//R



On Thu, Apr 20, 2017 at 11:08 PM, Job Snijders <job@instituut.net>; wrote:

> 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
>>
>