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> Fri, 21 April 2017 00:53 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 538E3128B90 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 17:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, URIBL_BLOCKED=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 dvBAAioOAhgd for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 17:53:32 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB4712EA95 for <idr@ietf.org>; Thu, 20 Apr 2017 17:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1688; q=dns/txt; s=iport; t=1492736011; x=1493945611; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=dYjqt2fPs6qZCd6Q558hBUENT3UdT+YQyCb8IPmHTQI=; b=jUCgXirM73UiBg0jHIl8jvrVkSJVABqZ/ajGSSogJIZBiSjKs5+Mdket 7zwdTNpI3GwU7kb1qKceyW4n9kuD7qWkJsZMuw/W6PCiA0BDDUn47f9c1 /gaCbCGM6tIBenzJz4di8yo9LL86ZhFj5Xzsfv0J2i92JFYlux8dND9kR s=;
X-IronPort-AV: E=Sophos;i="5.37,227,1488844800"; d="scan'208";a="415406002"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2017 00:53:30 +0000
Received: from [10.41.56.234] ([10.41.56.234]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3L0rUZL018081; Fri, 21 Apr 2017 00:53:30 GMT
To: "John G. Scudder" <jgs@juniper.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> <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net> <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com> <4CE4AF1E-0C80-423E-B19D-5750FCAFAD89@juniper.net> <11b08110-26e7-d67b-55f1-1f8cb777605e@cisco.com> <67EBB9EF-A3C0-44DC-936E-B6F1687B2094@juniper.net>
Cc: Job Snijders <job@ntt.net>, "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>, Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <b754e588-573b-c1a3-aa37-da14e9d5703d@cisco.com>
Date: Thu, 20 Apr 2017 17:53:30 -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: <67EBB9EF-A3C0-44DC-936E-B6F1687B2094@juniper.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XEhblFFLRNL1MmuhP31srK_9PdY>
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 00:53:33 -0000

As I understand, the scheme requires the config to be generated in the intermediate
releases.  Once you lose the config and then try to upgrade (and skipping the
intermediate releases), we are back to the original state and problem.

So it is the same issue, that is, upgrading to a new release without going
through the intermediate releases that generate the configs.  The routes
accepted by the old release would be rejected by the new release.

-- Enke

On 4/20/17 5:08 PM, John G. Scudder wrote:
> (still as an individual contributor)
> 
>> On Apr 20, 2017, at 5:25 PM, Enke Chen <enkechen@cisco.com>; wrote:
>>
>>> - on one hand, a worked example showing how an implementor could roll out the
>>>  functionality without causing heartburn for users. (My paraphrase: expose the
>>>  default in the configuration. When upgrading old->new, automatically create
>>>  the corresponding configuration line(s) to configure for legacy behavior.)
>>
>> Change of software may involve both upgrade and downgrade and combination (e.g.,
>> when a serious issue is seen).
>>
>> When the software is downgraded, the config may not be recognized and may be
>> lost.
> 
> Sure. What of it? Presumably the downgraded software has the legacy behavior.
> When and if you re-upgrade it, the logic quoted above to emulate the legacy
> behavior is re-applied just like with the first upgrade. The net result is
> legacy behavior continues through upgrade and downgrade. (The next step in
> this argument is "but if you always maintain legacy behavior, what's the point?"
> but that's already been answered -- by Jared, IIRC -- much earlier in the thread.)
> 
> --John
>