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

Enke Chen <enkechen@cisco.com> Thu, 20 April 2017 03:36 UTC

Return-Path: <enkechen@cisco.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 48A89129412 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 20:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 yoDlb7x79wf1 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 20:36:21 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E92912EAFF for <idr@ietf.org>; Wed, 19 Apr 2017 20:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3025; q=dns/txt; s=iport; t=1492659380; x=1493868980; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Aq9DMZ2RxxkCxzZ974D0ohrT73n/2IYLk3JhY5KO6y8=; b=TCKjjC3qNKt2OSi9/Ud0hDNdz1MDekPJJYuc2Sefr6pK+2I4MtF+wCTy tlzQlNdHeR70GnfQiFEcK79z27gax+cMI5HFjoauZcT1RMeh4aYkoq6iN yWjXPw6Ibx1UkMwLa0Y84e89weLiBDdtxzvrQz3OywbuEdY0imVu7NGcC Y=;
X-IronPort-AV: E=Sophos;i="5.37,223,1488844800"; d="scan'208";a="233270250"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 03:36:19 +0000
Received: from [10.24.96.175] ([10.24.96.175]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3K3aHpd015466; Thu, 20 Apr 2017 03:36:18 GMT
To: Brian Dickson <brian.peter.dickson@gmail.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> <CAH1iCirFhb3HuREBDuuDbC-fuiinSFW6UuSk61MrEj9GEaHtsw@mail.gmail.com>
Cc: John Scudder <jgs@juniper.net>, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>, Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <8a242116-e17b-9c3f-00d4-a2e606a0c5b4@cisco.com>
Date: Wed, 19 Apr 2017 20:36:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAH1iCirFhb3HuREBDuuDbC-fuiinSFW6UuSk61MrEj9GEaHtsw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lGW_PTX1-7E6DBGpzRllW71zLsc>
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 03:36:23 -0000

Hi, Brian:

I think that the backward compatibility concern is more about existing
deployment. For example, say an existing router does not have an inbound
policy and just accepts whatever routes from its provider, but it does 
have an outbound policy.  Let us further assume that the default behavior
in the software is to accept updates from a neighbor without an inbound
policy. 

Assume in the new code the default behavior is changed to drop updates from
a neighbor without an inbound policy.  Then as soon as the new software
is deployed on that router, the updates from the provider would be dropped
without any config changes.

Thanks.  -- Enke

On 4/19/17 7:01 PM, Brian Dickson wrote:
> 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 <mailto: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 <mailto: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 <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
>