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

John Scudder <jgs@juniper.net> Fri, 21 April 2017 01:02 UTC

Return-Path: <jgs@juniper.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 1DFEE12EAB3 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 18:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 TPRHgpGwxxGN for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 18:02:19 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8348E12EA8C for <idr@ietf.org>; Thu, 20 Apr 2017 18:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zjt4qWrXTreFSxpAyP9w7vnyxfrFEg6QEFpF89PXP+U=; b=P/Ma4QCo7hIUffGKvAW7O/TCts9aQHXPwcb+EVAlXyMqiJ9WEHCPisuww4SsVywqpU7rHwcFwjTT7FXycvQBICRnwMn3ET+6/nMiiu/d4FbpeNW65mt1p4vBa0Mz5CPjFuXK2FCwfa0SVN1G3dFVP6iarpCtmVxcXKSa14UZhwY=
Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2505.namprd05.prod.outlook.com (10.167.10.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 01:02:18 +0000
Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1047.008; Fri, 21 Apr 2017 01:02:17 +0000
From: John Scudder <jgs@juniper.net>
To: Enke Chen <enkechen@cisco.com>
CC: John Scudder <jgs@juniper.net>, Job Snijders <job@ntt.net>, "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Thread-Topic: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Thread-Index: AQHSuhrbp3Q+amjrFUC5PeWc81WgJg==
Date: Fri, 21 Apr 2017 01:02:17 +0000
Message-ID: <5342F46A-44B1-4706-951F-588399283439@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> <b754e588-573b-c1a3-aa37-da14e9d5703d@cisco.com>
In-Reply-To: <b754e588-573b-c1a3-aa37-da14e9d5703d@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [75.151.14.9]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR05MB2505; 7:h+XLnnmmhxeiccRuhw+zVpvVi0PyCSiMU+N2nd6s1aScynO0fHMcgwDfNQmrPsLcrnc8kXeKQUm+JLdHX/xz9iQEf5SCpXWZ9o0A318h0d0HnEMxgKnSvXMrYSKFfRCWVEDy4P/QOI9RkE4ATw+oNHWyLd+EfKzKyNYp9GPUAEfDk19/sNaFMYiWHEPuzv2HwfOnHPBaRiFxEog+J60WLXMGIvPrrhV3EK6Q4av3+EFCy1gJwBlS3alPKuJ46dAsY4SvD3dkS+h0YhTlkkmbY5hcy2HOV0/AXSdzAo7UlfXLkJq2MHIvQgUk7hQ0UmF7jLTZ7GScEPErlXWsAwFPYg==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39840400002)(39850400002)(39400400002)(39450400003)(377454003)(24454002)(229853002)(99286003)(2950100002)(66066001)(86362001)(6512007)(33656002)(54356999)(2906002)(76176999)(54906002)(305945005)(50986999)(53546009)(81166006)(7736002)(25786009)(110136004)(6916009)(53936002)(82746002)(6246003)(6486002)(38730400002)(8676002)(230783001)(83716003)(5660300001)(2900100001)(3660700001)(77096006)(3846002)(189998001)(6436002)(122556002)(4326008)(102836003)(8936002)(6506006)(6116002)(3280700002)(36756003)(93886004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2505; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: 91c0b650-229d-44ad-56e9-08d488520e62
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2505;
x-microsoft-antispam-prvs: <CY1PR05MB25054EDB3163F9507D30ED58AA1A0@CY1PR05MB2505.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR05MB2505; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2505;
x-forefront-prvs: 02843AA9E0
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9294CA9E2312AE498B6E75C94F86512E@junipernetworks.onmicrosoft.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 01:02:17.5093 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2505
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/f5fq0NSU0t3kr2i-RZyAeZiTBLc>
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 01:02:21 -0000

(Do I need to keep saying I am writing as an individual contributor? Better safe than sorry I suppose.)

Nah. Generate it in the new releases if you see a config that came from an older version. (You can tell this, among other ways, by noticing that the required new line of configuration is not present).

There is no intermediate version.

Of course, endless variant schemes are possible. This is merely a thought experiment to prove the problem is neither intractable, nor even particularly difficult.

--John

> On Apr 20, 2017, at 8:53 PM, Enke Chen <enkechen@cisco.com>; wrote:
> 
> 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
>>