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

Job Snijders <job@instituut.net> Fri, 21 April 2017 10:11 UTC

Return-Path: <job@instituut.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 B0D0E129B09 for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 03:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 E0vKOqxKBSlS for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 03:11:21 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 313A412953D for <idr@ietf.org>; Fri, 21 Apr 2017 03:11:21 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id z52so10282020wrc.2 for <idr@ietf.org>; Fri, 21 Apr 2017 03:11:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SC/idD+r/x5E8Pepcbud0O0rwLktwYpDLeO7uTMAp0Y=; b=dqNFtpZrpJGUnMtErOgE2Ofx/tcHhmkrmWYnqafb58aruJHE3eyH5La+38482vTWBl /tCwjHJEgt1jeiSM5nTrWlKGzrkRChsbTtteIHkNUk/6mKZbwrTZZOZPedpOS74y8KFz ITHLyacG4KuE9irFtmz9FkT4HJaE+9e651uxa2cfHr5POvQZrfeVXbaCN4X0clXU6Rft kKnIkuyTL7D6WYB7iaLnumRP8Hu35b4QnWRWfJjuJo1x4PGBfYxvXTch0fl4/Q16QQmO JtW4EsYgd3afTgB7wtyyvWFLQaLFtHn+PD/NIGUXIkrLNbBJ+fk/mMK36gd3ZewJQWiO IXhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SC/idD+r/x5E8Pepcbud0O0rwLktwYpDLeO7uTMAp0Y=; b=CMTFCt3UhzSur5ctuLuSmWoqKO1Vcc1bKYLFFr6+WA+xb4/fO/mDVQzj6sDEwRDEwT IuuOTO689uQXeUi//m1ax8iXgR9xTHvPLrAAw2pUoEnvMWwxJQbTBiDenX+dL24HVzVk TFdxzJVngXtnWdXEgj2F4ejvAC1GK/zvmIxarGkghlNQFduL25NRvF5wp+P+1rtH32Vx 28jLNA4mkQHmow1msBi/y4VPuQGCffxzg2iPaOybTxcJY7ZMKDI2fchIOtNQZoeYr1Od rS9CkF3/nCnAt6xLH1hgEQD+BkX0BTCj6WtQRjY0UUzFRTlqgfw3Us6WjECWGnMQJHxL kT2g==
X-Gm-Message-State: AN3rC/4ZFGCH9FYNHatK2igv8OwvLIXpRqrEWVKBruxYZMFSCj2MgOl2 bZyQeUPKgqqaOeSF6QA=
X-Received: by 10.223.176.37 with SMTP id f34mr6413136wra.93.1492769479518; Fri, 21 Apr 2017 03:11:19 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:154d:67d1:53a6:3be]) by smtp.gmail.com with ESMTPSA id b15sm304135ede.8.2017.04.21.03.11.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 03:11:16 -0700 (PDT)
Date: Fri, 21 Apr 2017 12:11:16 +0200
From: Job Snijders <job@instituut.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170421101116.vutc5vn3idt4s46y@Vurt.local>
References: <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com> <20170420160736.GB15676@puck.nether.net> <75AC1A50-3DF8-4852-8FC6-BC302B121946@cisco.com> <CAH1iCirf=ha1mrw8EUzPp34R-DF=4J+=aFyMwVn2udi1UKNifw@mail.gmail.com> <CA+wi2hMPYcwbNhHtuWKWUXb4Lg3x81p786yLqeNEHFV1okGRvg@mail.gmail.com> <dc04fe80-f844-29b1-2676-8f2bbda0ecbe@juniper.net> <28014_1492762849_58F9C0E0_28014_6541_1_53C29892C857584299CBF5D05346208A31CC3773@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421090145.f5yuhimb4qg7knrf@Vurt.local> <CA+b+ERkw39d3E3wsceVWQAb05peEmt=qgBkYdN5j8T_5XzSZ7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERkw39d3E3wsceVWQAb05peEmt=qgBkYdN5j8T_5XzSZ7Q@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qgGpfeR7wmGCV69PFYk0p_vMVz8>
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: Fri, 21 Apr 2017 10:11:24 -0000

On Fri, Apr 21, 2017 at 11:35:06AM +0200, Robert Raszuk wrote:
> > Did you review Alvaro's suggested changes which prompted the third IDR
> > consultation on this topic? They are viewable here:
> >
> >     http://htmlpreview.github.io/?https://github.com/jaredmauch/
> > draft-mauch-bgp-reject/blob/alvaro/draft-ietf-grow-bgp-
> > reject-06-from-5.diff.html
>
> Do we really have consensus among all authors of this document (leave
> alone rest of IETF) that it should apply to all AFI/SAFIs ?

Feel free to double check with the GROW chairs or the assigned OPS Area
Director.

> Last ... what's your take on multiple comments regarding build in
> silency of this ?
> 
> See session will be established just fine ... even incoming prefix
> count will be incremented just fine.

The perceived 'silency' is a misnomer. Vendors are free implement
feedback mechanisms (such as a syslog or terminal warning: "you did not
configure a policy"), and some already provide feedback like this.
Nothing in this draft precludes vendors from ensuring the operation of
their BGP implementations a pleasant experience.

No feedback is required for the other side of the EBGP session, after
all the ownership of the change event lays with the side that upgrades
their software (same applies when the 'changing side' removes a policy,
or applies a deny-all policy, or any other standard operating
procedure).

You also fail to acknowledge that today's deployed BGP speaking software
presents a myriad of behaviours: some already follow bgp-reject, some
apply the concept in one direction and some operate in an promiscuous
insecure mode. This draft provides guidance to unify those behaviours
and provide a safe, consistent experience across multiple
implementations. 

> Last time I checked until you display bgp table there is no separate
> counter in any implementation to indicate in BGP summary how many out
> of received paths were best path eligible.

I encourage you to continue your studies on how today's routers work and
what counters are available.

Kind regards,

Job