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

Jared Mauch <jared@puck.Nether.net> Wed, 26 April 2017 11:39 UTC

Return-Path: <jared@puck.nether.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 A736D129B5C for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 04:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7QAKfZqlZx-3 for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 04:39:55 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 355AF129B55 for <idr@ietf.org>; Wed, 26 Apr 2017 04:39:55 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id E9B07540A6B; Wed, 26 Apr 2017 07:39:54 -0400 (EDT)
Date: Wed, 26 Apr 2017 07:39:54 -0400
From: Jared Mauch <jared@puck.Nether.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Gert Doering <gert@space.net>, idr wg <idr@ietf.org>
Message-ID: <20170426113954.GA18318@puck.nether.net>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Bpuq3yRP4FOO1c14GeWoncgPzqI>
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:39:56 -0000

On Wed, Apr 26, 2017 at 01:28:49PM +0200, 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.

	I've only cited CLI as an example of how others have addressed
the concerns raised in the thread.  For the purpose of IDR I don't
wish to mandate that part of a solution, but cite other viable
operational alternatives.

	Saying that a BGP operator needs some "auto-cli" to know how
to do BGP stuff tells me these people should not be trusted with BGP
outside their own labs.

	The pollution here is real, when I was at NTT we worked to
mitigate it via a variety of methods.

	We also had executive escalations that reached my desk where people
didn't do their simple homework of "we had two links, redundancy
didn't work, you took us down big bad $ISP".  

	Once I said "Hi, you are only sending 2/3 of your routes on
your backup session, do you want to fix that now while I observe" they
quickly settled down on their escalation issues.

	Things break, people need to learn how to debug the technologies
they are using.  We should be working to make it simple, yes but not
by foregoing an operator developing their own skills to identify problems
and using their supported vendor paths to triage it.

	Putting text in the draft that it must take the form of
"show bgp neighbor 2001:db8::1 " would favor one vendor over another
and perhaps open the draft up to IPR claims.  I do not welcome these
suggestions.

	The reality is many of the operational leaks we see today are
because of one or multiple failures in the routing ecosystem, be it
a network link, NLRI filter, AS_PATH filter or otherwise.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.