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

Greg Hankins <ghankins@mindspring.com> Tue, 25 April 2017 20:23 UTC

Return-Path: <ghankins@mindspring.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 09464129511 for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 13:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mindspring.com; domainkeys=pass (2048-bit key) header.from=ghankins@mindspring.com header.d=mindspring.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 3hdvTdf96O52 for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 13:23:41 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFBF1294FD for <idr@ietf.org>; Tue, 25 Apr 2017 13:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mindspring.com; s=dk12062016; t=1493151819; bh=nV33gzo55NnjmOKp8yekSki+hvzpf3wai+PF lCmJB2o=; h=Received:Received:Received:X-Authentication-Warning: Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To:User-Agent: X-ELNK-Trace:X-Originating-IP; b=rO4bUblrS//fU+Duy9tBjSvXugHQ2BBZM ZHLKFtsH/JQzJXzwyRIwsy7I5cwwGezFK4r/ScB15a3h+SIUCZLpMGK98WeJmFq/ifO UOY8ddhGjrMWlspLSmY5zbP1kXTD+hGqKNutxQuOHQvldwfCeOWDqE16wRh/R8/b1T0 2c2eiuQyT33Knxg+ShH61Nr2G0XLK76idUxfbwJ7ymIfW6GzGHwMJe9Zi4Wv9t2vNF4 8YhtvEirO8UWF5WBlSrJdxs7l+d4jrvLXV25hvwETJnOV6dhRtxF//oQVvF474cjAb9 AzdTH8vMiURUEDKtOsSAtqPpOudY4/93DcFJ1Z0gQ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=mindspring.com; b=n088kNCNFhhPVnDkVU3xydlCPzZCl+Y6/tAjEaMZ16NK2gfpDA1+R230admDscd/WQMoRnaF1o4oifHj9Y9Ihv52wn1YA60s7lORAeK6mq7EzV9/dMLZbELwkwvLcGFp/AL5gTDwcWrnFFYm7NjlzGSxGVYjUjtoNE9ETDWUXZFVCUH/kMNJqQYk4m706P3p/JHO1cDVjZGq1ixsi2lrLKfWukCPb5M6kTHBOxRqE9sZmanXMoTnDIBIshwlb5KjEnyb4+50bSj2KxKYTCcGdj+2yUmEF77QvISqtG1e6gpNEUNU+0i5bgs1TBWnNUzXEyJjNVkOGRsbzp0cC0+FxA==; h=X-Authentication-Warning:Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-ELNK-Trace:X-Originating-IP;
Received: from [76.8.75.174] (helo=doom.twoguys.org) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <ghankins@mindspring.com>) id 1d36zp-0001y7-51 for idr@ietf.org; Tue, 25 Apr 2017 16:23:37 -0400
Received: from doom.twoguys.org (localhost.twoguys.org [127.0.0.1]) by doom.twoguys.org (8.14.4/8.12.11) with ESMTP id v3PKNegQ009209 for <idr@ietf.org>; Tue, 25 Apr 2017 16:23:40 -0400
Received: (from ghankins@localhost) by doom.twoguys.org (8.14.4/8.14.4/Submit) id v3PKNeMS009205 for idr@ietf.org; Tue, 25 Apr 2017 16:23:40 -0400
X-Authentication-Warning: doom.twoguys.org: ghankins set sender to ghankins@mindspring.com using -f
Date: Tue, 25 Apr 2017 16:23:40 -0400
From: Greg Hankins <ghankins@mindspring.com>
To: "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170425202340.GD8237@mindspring.com>
References: <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421084638.l6pbvtznfsxnq2wy@Vurt.local> <23291_1492766305_58F9CE61_23291_9725_1_53C29892C857584299CBF5D05346208A31CC399E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421095839.sralcy7aos5mzzic@Vurt.local> <d57ed214-945a-54b8-e04f-cb8610f789e4@cisco.com> <alpine.DEB.2.02.1704231447550.5591@uplift.swm.pp.se> <ee6e3ad8-d5c2-16c5-4464-3473d9a6443a@cisco.com> <alpine.DEB.2.02.1704240928120.5591@uplift.swm.pp.se> <09173019-86ee-4f81-d57f-f664d642f633@cisco.com> <58FE590A.9050302@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <58FE590A.9050302@foobar.org>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4dc6af6b0834bc74acc0b4940823697b9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.8.75.174
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kgl6etbjUuR3jLHVeDSi4LLIs50>
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: Tue, 25 Apr 2017 20:23:43 -0000

I would like to add a couple of points to this discussion wearing my Nokia
Product Manager hat, and specifically as the person who is responsible
for managing this feature in our routing product line.

Our current BGP defaults in Nokia SR OS are insecure, and we are going to
implement this secure behavior because our customers are asking us for it.
Jared, Job, Mikael, Nick, and others have expressed their demand directly
on the GROW and IDR lists as operators, and we are seeing this same demand
as a router vendor too.

Defaults can be changed, it's not an impossible problem.  We put considerable
thought into changing configuration defaults a long time ago, and have
quite a bit of infrastructure support to make sure that changes are handled
correctly between different software releases during an upgrade or downgrade.
This allows us to change a command syntax or default behavior, and preserve
the intended functionality during various software change scenarios.  First,
we are strict about only introducing changes in major releases, unless for
example there is a security issue that needs to be addressed immediately.
Changing defaults or deprecating a command is a multiyear process that
spans multiple major releases, where we first mark a command as deprecated
and eventually remove it as a configuration option.  Our configuration
infrastructure knows how to translate commands between releases if the
syntax changed, or knows how to handle the cases where a default changes
or a command has been removed.

We also have a clear documentation process for communicating changes
to customers in multiple sections of release notes and documentation.
Each version of the release notes has a detailed section ordered by release
that describes new features, deprecated features, and changed or deprecated
commands.  As people have pointed out, operators may not read the available
information, but this doesn't mean that we don't make careful decisions
to change defaults when necessary.  In addition to the documentation,
we communicate roadmap information during customer interactions such as
EBC visits, planning meetings, training sessions, our customer conferences
and even over social media.

There are a number of scenarios we have considered for changing the insecure
default.  This is not an exhaustive list, but here are some examples:
o ISSU upgrade: old behavior
o ISSU downgrade: old behavior
o Reboot: new behavior
o Device that ships with preloaded software in 2017: old behavior
o Device that ships with preloaded software in the future: new behavior

Lastly, we explicitly added the option to the I-D to have a configuration
knob that configures the insecure behavior:
   o  A BGP speaker MAY provide a configuration option to disable the
      preceding behaviors, but it MUST implement them by default.
So if our customers want the old behavior, then we have a way for
them to enable it.

Greg

-- 
Greg Hankins <ghankins@mindspring.com>;