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

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 20 April 2017 02:02 UTC

Return-Path: <brian.peter.dickson@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 1E99612940A for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 19:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 0xWSgGSWQkqw for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 19:02:02 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 4F0EA124D68 for <idr@ietf.org>; Wed, 19 Apr 2017 19:02:02 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id k87so48171410ioi.0 for <idr@ietf.org>; Wed, 19 Apr 2017 19:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CZMPzzATL9lp31wQM+3HeYxHinLByLsauiF6NGP7AuQ=; b=ZvbjD76qb0X9xpzmREY8L7fzIDHoQgH/yiYQnxZEGJ+GW1ovveo8xbbpljELSRx8cM U+tBvwX9YMsOlJ+t6L6ywN0MzZnR5IZgLr7D92czm1D7jo1Y+fGN9DO0XPHIx2uHbArP YQ1JxqiRBL5T9yh3hSpKpy9s7UdlkvYWVH1QNJEDwwxUk5rZQderf1e1j9CawaomdhXj PZOEz/wjMqBNK5gOa22cdVoic3D05EgeWtVU8fTeZgHskJ8oEVOPCrwQ6/6T00+JRdBM RLWLwqJwUF2l20naEciWLEP0o4INwDLDLQVrkBgUkpFpJdz9O6TLds8tkYL15xgoMZth 3tDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CZMPzzATL9lp31wQM+3HeYxHinLByLsauiF6NGP7AuQ=; b=QgZ8J3d9bZDVrI/1uCxNA5m6PjnVErUmir5F2b585BSUFpGe/NZKXJImCuzF1VuHDv U0dSNaAZDNM24FIiXW5hM7p4DSqnmrKYeNK0FtUlg2ozDKFI4G+POK3z/3AXhYt7eb94 0BE5mlghA3wv3BreIyroFap3C15vPvQB9D5SGAIP2hz3AUB3flTuJu7i67/AqFlY3YuZ 4/42hKy/ROgDXh0L/OoowWYlI/GyVvjIdLvX7FbioiYSP8TygRAkNlNtxAx3fF8moCty 5GO2KwpHkcZyw3IVc4Q9fOt048woEX7JxRWGMl12M5kcwf/qPswuso/LOKJzwvOyDg4R 39hA==
X-Gm-Message-State: AN3rC/5yWRj0wYy1PggiNVhno6nBdUJBf+71QQE+k62QtAyIs998ibbP SvzI9R3jx6zxQqEX/jrF6uxNb7QVKg==
X-Received: by 10.107.146.139 with SMTP id u133mr7352670iod.160.1492653720541; Wed, 19 Apr 2017 19:02:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.46.151 with HTTP; Wed, 19 Apr 2017 19:01:59 -0700 (PDT)
In-Reply-To: <2b8a94bb-4f40-6c1d-05ff-9cf11ad93646@cisco.com>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com> <D51D67E4.A9782%acee@cisco.com> <AF07526F-F08B-4084-937B-A9A2D2DD2813@juniper.net> <2b8a94bb-4f40-6c1d-05ff-9cf11ad93646@cisco.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 19 Apr 2017 19:01:59 -0700
Message-ID: <CAH1iCirFhb3HuREBDuuDbC-fuiinSFW6UuSk61MrEj9GEaHtsw@mail.gmail.com>
To: Enke Chen <enkechen@cisco.com>
Cc: John Scudder <jgs@juniper.net>, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="94eb2c055f4ec9226e054d8f8639"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1sVyNBMv4G6c5kNk45Tpd77M8jM>
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 02:02:04 -0000

Hi, everyone,

I think the distinction is between "default" and "default", i.e. clearly
communicating what is meant by "default" in this document.

I think it would be perfectly fine for implementers to provide copious
"release notes" detailing what has changed, AND to apply whatever policy
gunk is necessary, on performing a software upgrade, to ensure no adverse
effects.

In other words, "default" here would mean the out-of-the-box behavior of an
otherwise unconfigured device, when BGP is enabled (regardless of AFI/SAFI
combinations).

By definition, a new deployment of a router can't cut off connectivity,
since it cannot come into existence with said connectivity.

Would making that distinction suffice, for everyone?

Brian

P.S. While I do applaud the vendor(s) for finally deciding not to break
things when code gets upgraded, separating upgrade from new deploy is all
that is required.

On Wed, Apr 19, 2017 at 4:34 PM, Enke Chen <enkechen@cisco.com> wrote:

> John,
>
> I had "in this case" with the statement "the default can not be changed".
> The reason is that the behavior change may completely cutoff connectivity
> in this case.
>
> Thanks.  -- Enke
>
> On 4/19/17 4:25 PM, John Scudder wrote:
> > (As an individual contributor)
> >
> > On Apr 19, 2017, at 7:18 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
> >> the draft is conspicuously missing a “Backwards Compatibility” section.
> >
> > Seriously? "Backwards compatibility" in this case is "configure your
> router to do what it used to", right? We need a section to say that?
> >
> > I must be missing something.
> >
> > Also, to Enke's "we can't ever change our defaults" point -- there are
> many RFCs. Some you probably comply with. Some you probably don't. How
> would this be different, assuming you elect not to change your
> implementation to comply?
> >
> > Thanks,
> >
> > --John
> >
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email