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 17:15 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 D4D05129ADC for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 10:15:12 -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 Cbo-qDexogrd for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 10:15:11 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 16E66129AD4 for <idr@ietf.org>; Thu, 20 Apr 2017 10:15:11 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id k87so78896431ioi.0 for <idr@ietf.org>; Thu, 20 Apr 2017 10:15:11 -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=oQ79CQYaQwx9Mgw0cNn5LHsAZslW01tJ6Hh/iYPxFPc=; b=iYPLDzuMtdecp07bjQsV9C10k+sgEXTHneSXTgAOiScgZsISygz6tMBQQVOri8M8Ui O5VUkOLsQY1mCGyLcDR7Ynegwzt+3Lzh7j7z4KB13zsbYMwul3F3BHYrgtGP5WQaOTiS Y0Nt6qnU5Cca2SsKSXmBkNm+Qqyk3OK5A08bj7ETRc/1Uz3K7V+uvXoOzCT5LutcDGot 2A7GsWDBBBh//HkTB+i4wFZchfBrvm6bT2NWq9MT72HWzVkjmG3YdUGhLaL7nIX2CRi/ mY7px8pi1sHSu0ahCkK3t3ma8A1K9HZq1lM85Jb33QLi3s777TcYM4U1kgrPiXZKCXzY mSZQ==
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=oQ79CQYaQwx9Mgw0cNn5LHsAZslW01tJ6Hh/iYPxFPc=; b=U9IwSn294GYQw/Od7oA13yleT7o0gNRpyujF0i+TUpRfA04eUzDc3secJEcDn55JKX vnKacxPPE1JxjH8W4AMe7qRRpUJN725OEF/X8Igao08gXVaPrj7I+3u1f7twQruhObmz 4F+Wp7+Qegkdg0rDuVCLpwOJsBqfm6FCks36RRkiut4lfNjdz3f33ADUlwHYYQc4l1ly Dm6ZOMqra8bxdB0ht4Gnbu4vxj5Xyi5jkpZ6fwaG248j9Vtrkq7xhGXv312unKuAKvzX uLYxaowStpivJa8ZhUeu6azLV/wBCSD0EiZgk1C7iaMVVT0McgHFTiYH1H9GMivcRPbm 5jRA==
X-Gm-Message-State: AN3rC/62ywCeFc97ogUDDgygPGqbqtvfm9wF0DGcA3TYVO+6QyCLRU2b Ibbe4T6GJToldXCipjpzZQxx9R9Hlg==
X-Received: by 10.107.33.135 with SMTP id h129mr11207085ioh.57.1492708508783; Thu, 20 Apr 2017 10:15:08 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Thu, 20 Apr 2017 10:15:07 -0700 (PDT)
In-Reply-To: <20170420165757.safd32x2xu5awwxp@hanna.meerval.net>
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> <20170420164314.av26kcxvxglg4oet@hanna.meerval.net> <3b681e50-bf6d-df75-eb61-86be79a2fbb8@cisco.com> <20170420165757.safd32x2xu5awwxp@hanna.meerval.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 19:15:07 +0200
X-Google-Sender-Auth: hpbpiGDnzqrqwseDEmyOrRI7dNI
Message-ID: <CA+b+ER=4gRPGf6rZRvwmB8SX51Pfq5CDQE3p2z=2akFRdettLg@mail.gmail.com>
To: Job Snijders <job@ntt.net>
Cc: Enke Chen <enkechen@cisco.com>, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a1140f5e86b74e8054d9c4899
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2GAfUeJ4McAYG8P8wcqV7Hb3icQ>
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 17:15:13 -0000

Job,

Enke observed a difference between operational outages and vendor
implementation caused outages. Those are different things so I suggest to
separate them.

But as I pointed out two ways already it is doable to implement it in a way
that outage will not happen even if someone would never read release notes
and upgrade routers via web gui with new OS.

So instead this ping pong how about we focus on point what constitutes a
policy and what you expect associated behavior of complaint implementation
to be.  I asked that already but your answer that you left it loosely
defined does not seems good enough for the spec implementer.

*A* Must it be per neighbor ? Can it be per VRF/table/bRIB  ?

*B* Does enabling BGP Origin Validation should be considered as such policy
or not ?

*C* Should received routes still reside in Adj_RIB_In ? Should BMP still
send all routes to collector even if those would be considered not
complaint with RFC ?

*D* If we do eBGP auto discovery in IX env of peers would that overwrite
such RFC ?

*E* If someone does LLDP based eBGP peer discovery on p2p would that also
be exempt from such enforcement ?

Thx a lot,
Robert.


On Thu, Apr 20, 2017 at 6:57 PM, Job Snijders <job@ntt.net>; wrote:

> On Thu, Apr 20, 2017 at 09:50:53AM -0700, Enke Chen wrote:
> > My personal opinion:
> >
> > Vendors are *not* in the business of intentionally creating network
> outages :-)
> > Those that do may not stay in the business for long :-)
>
> You could also argue, that by not implementing the bgp-reject guidance,
> a vendor intentionally creates outages which result from inadvertent
> propagation of full routing tables.
>
> If a vendor implements bgp-reject, the customers enjoy mitigation of the
> risk of hitting the timer penalty on a 'maximum prefix reached'
> shutdown, or perhaps someone configured their router to not
> automatically re-enable the session after maximum-prefix is hit, in this
> case the outage prolongs.
>
> If you are committed to preventing outages, implementing bgp-reject
> seems the right thing to do.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>