IETF Logo Mail Archive

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, 27 April 2017 10:02 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 7C80B12894A for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 03:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 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, URIBL_BLOCKED=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 EPJULhOJCWvu for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 03:02:06 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 CC08D1204DA for <idr@ietf.org>; Thu, 27 Apr 2017 03:02:06 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id r16so19444122ioi.2 for <idr@ietf.org>; Thu, 27 Apr 2017 03:02:06 -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=FbcDsnEJI6iyJcwggl28Auov5i8RJ/+h3tlSiY0LmdQ=; b=nxdnU7fa7SMsk3oFWlF5aUniaB3jGYQ8S+tgB2vuJczfkm51VJTccFXaGwu+2AvAKG 2HTecDTijDhjTXKWkOdGHWm2PFPTl8giWxqjhxHt6LUjtJSeOMMk2tqlTuVOd0dbTBsh Hgs4zq9umairB91jthvVddngPJwaVjGnjdnRf1PSvrdogQWb4kd727UOGptI2anvWkKL XUgAKjhq3YgQRMcdkT8Ij/rZnIokVOeA92ST3mIv/qlO2hbEedD/imdVbYVH9cNk9+SC wPYOLVTI4uTdG5Q5VKv9OGdJMOIOJ6OnXpd1WFjMHiKImR4T2kf1LCTSm9av4XK07fZ1 w3tw==
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=FbcDsnEJI6iyJcwggl28Auov5i8RJ/+h3tlSiY0LmdQ=; b=ChfOEvpyQICtkkB6BqUfOfoVUx512EYf4WKio3ENZzgF2VmyeESNgjhGUJXzFXJX6+ itoT52CdjbiCdvpIXpuF9ny/2yY1xWGX0YaxmluJZco66SOcy471ZlE9icg7Cp/wvtM1 00lji2ZcZXfnjrvTt7Mxcek3yYdk8uociPZpKdnkYf2sPe+aHMtJN4B/iBbzG7ceW4Ih +uYieickDL/2wDfbXs24oZWdwLtcP2kq3ZZvIw6ZH5WG5nMC0EYu3WHrphpjtMLmYt06 FkRO8D3y+Vk38HqrROU2WVEvBkTWC0ni7fZcosEkkf8PKiwjqMomhYqx4xzn0duo58A7 YDHA==
X-Gm-Message-State: AN3rC/6HkJmwFCHgzBaqcqEoOsdDrPTHJNiV1HG3XTA/pddSTPQtks3n poZiHWcuthxMVtwIowPGihJOOG2apKw0
X-Received: by 10.107.5.207 with SMTP id 198mr3598237iof.186.1493287326123; Thu, 27 Apr 2017 03:02:06 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Thu, 27 Apr 2017 03:02:03 -0700 (PDT)
Received: by 10.79.62.24 with HTTP; Thu, 27 Apr 2017 03:02:03 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1704270653291.5591@uplift.swm.pp.se>
References: <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> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com> <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com> <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com> <alpine.DEB.2.02.1704270653291.5591@uplift.swm.pp.se>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 27 Apr 2017 06:02:03 -0400
X-Google-Sender-Auth: -dBEODQrrypEmdCm_Fa8FhdNjDw
Message-ID: <CA+b+ER=tmfqANDb1-uE8UAgMD0fnSwbrYrXr27_oFwuc47Xvew@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Warren Kumari <warren@kumari.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ebcb89f0a19054e230c4b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sXmyHZjXlkxN5JhBOrHiHhQeCJ4>
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, 27 Apr 2017 10:02:08 -0000

> Why can't we dynamically add or
> remove address families from a
> running session?

On your last point ... has been tried via dynamic capabilities ... Failed
to get properly implemented by multiple vendors ;(

https://tools.ietf.org/html/draft-ietf-idr-dynamic-cap-14

//R.

PS. Btw multisessions attempt falls into same category.

https://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07




On Apr 27, 2017 12:57 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

On Wed, 26 Apr 2017, Warren Kumari wrote:


> I was turning up Global Naps as a peer, so I log on and type:
> router bgp 8120
> neighbor 192.0.2.1 peer-as 1784
>
> ... and, as I press enter, one of the sysadmin folk turns around and
> asks me to hand him a sharpie. While doing so I bump my coffee mug,
> spilling 3 week old coffee (and a very cool mold colony I was
> culturing) all over my desk. What with the cursing and running to find
> paper towels and similar I don't come back to the router for a minute
> or two... by which time I can mysteriously no longer reach it. Turns
> out that becoming transit between 2 (at the time) large providers over
> a T1 makes your router unavailable. Eventually BGP falls down (because
> keepalives get starved), and then, before you are able to login again,
> it comes up.
>

This is a perfect example from the real world why a fail-close design is
needed. What you described, we all have happened to us if we've worked long
enough in this field.

Trains have brakes that need air pressure to release them. If hose breaks,
compressor breaks, whatever breaks, the brakes are applied.

A BGP session should never come up and pass prefixes any direction without
a policy.

Oh btw, another story. I've had happen to me several times that all my
sessions were flapped causing large outage, because I added or removed
address family from a peer-group. Why is this still a thing? Why can't we
dynamically add or remove address families from a running session?


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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email