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

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 26 April 2017 11:40 UTC

Return-Path: <swmike@swm.pp.se>
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 59D74129B59 for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 04:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=swm.pp.se
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 nkmCkZMW8Wqd for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 04:40:06 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CA8129B65 for <idr@ietf.org>; Wed, 26 Apr 2017 04:40:03 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 42150A4; Wed, 26 Apr 2017 13:40:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1493206801; bh=s0MAZ6q1IHYNNC5L7MVSDULAwPqRbCD5FfDECVaqmSI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=xSw2YN5liQEIo0ncSGnCmdqMtkJIRB5WZUMBa9CazwVUPB9i346VWp/KzTTL6VHNj Lgw3AhmfNRgMCuWdiYAZR0cQgTkqbx3o1VDJ/Ew/WdfMQR0nx3mIWkz/Bh4BQYeGK7 FY9/5mK7EVisb+8p9f4ZG/XiVZl3/1QaEmDcdDrc=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F818A3; Wed, 26 Apr 2017 13:40:01 +0200 (CEST)
Date: Wed, 26 Apr 2017 13:40:01 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Robert Raszuk <robert@raszuk.net>
cc: Gert Doering <gert@space.net>, idr wg <idr@ietf.org>
In-Reply-To: <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1704261333080.5591@uplift.swm.pp.se>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <D51D46A7.A9732%acee@cisco.com> <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zl-MWIEGDTTv8Kft1tliSV2b1M8>
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: Wed, 26 Apr 2017 11:40:15 -0000

On Wed, 26 Apr 2017, Robert Raszuk wrote:

> Hi Gert,
>
> Unless the result is not lost of connectivity but lost of BGP path
> redundancy from your AS.
>
> It is quite often and in fact good idea to have dual vendors as your ASBRs.
>
> So unless proper cli is automagically added the problem may only  surface
> weeks and months after upgrade and in fact far from given ASBR when
> external link from still operational ASBR breaks.
>
> Document should discuss that as well and recommend such auto cli.

Let me just understand the reasoning here:

Operator today deploys ASBR without neighbor policy. It sends all routes 
to peer/transit and accepts all routes. This is not noticed by other end 
maximum-prefix and they have filtering in place to drop the "erraneous 
prefixes", so everything is working fine.

Now the router is rebooted with new version of software, that is 
default-deny, and vendor didn't provide CLI parser to migrate config to 
assure consistent behaviour in the new version. After the reboot, all 
routes are denied in/out. Operator doesn't check this now unused link, so 
this state is prolonged for an extended amount of time, all traffic is 
traversing other path, only. Still nobody notices.

Now other link goes down for some reason. Now these ASNs are isolated from 
each other, because there is no backup over transit for some reason, or 
transit becomes congested.

This is the scenario you want analyzed? Or is the scenario you want to 
protect against more non-Internet related, no DFZ amount of routes etc?

Because I find the behaviour I describe above as implausible for any 
decently professionally run network.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se