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:29 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 C1C7E129B9E for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 18:29:12 -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_H3=-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 wMwermobupjY for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 18:29:11 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0101.outbound.protection.outlook.com [104.47.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E910128B90 for <idr@ietf.org>; Thu, 20 Apr 2017 18:29:10 -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=6TTgPuCj576MuiNHOt22TqCsMYRJ+oLudtLm5aTTZw8=; b=XDuxPHw20DXDG/ZEPHxtorTQpdmCGQBbkGLX81+Z4hKkg0f+RmeQghnCK466kIO38sVLYCYim32qjfG7PmaQ+Z4a4JqmsusNcf2G9JCsE/N1WvPue7ElfM4DrAZ2/oCRkGnCwRJrS36RvbF8dSGoOyVaKjbo9h3oDKWdnDGlQsI=
Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2506.namprd05.prod.outlook.com (10.167.10.27) 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:29:10 +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:29:09 +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:29:09 +0000
Message-ID: <513CB54C-1312-47EA-9EF0-7BADB681F2D3@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> <5342F46A-44B1-4706-951F-588399283439@juniper.net> <30bf398c-b453-f676-394e-5b5ad9a50356@cisco.com>
In-Reply-To: <30bf398c-b453-f676-394e-5b5ad9a50356@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; CY1PR05MB2506; 7:6UyRn74QHPa5hjaEF+MJGRcHTWd5GVZtr2Bgllz65KYdbztsEsdqB0WV9taZN+z4Xr+MA8kG94NTghXEKAAiKE7QtIPAqdvrGoW72vapFcPAEdMwb6CiRAFVDlaHlDxCJcqivs8p2ueafKDxzPowB6jb5HcDshBWVSHtMb3DhJa/zYVrlMVTPDxdjj2R/xR3ikZqnGPAVp/6B9c+gEVBxqZiUv/2w1LuZAFczb5KGQrzWr3yKkS7PX5TSXJXjPfOQ52MrDFKF3uUCwW0JOFmRCsb+SP9YjF5q/Mv/CvdMeQgJmh2ItL3vzDcHru5UWAFhb094kTdhWQRRM8HETNYug==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(24454002)(377454003)(122556002)(6512007)(54906002)(6506006)(6436002)(53936002)(99286003)(86362001)(6916009)(2950100002)(229853002)(50986999)(76176999)(54356999)(66066001)(189998001)(81166006)(8936002)(33656002)(8676002)(6486002)(77096006)(230783001)(36756003)(2900100001)(93886004)(83716003)(2906002)(4326008)(25786009)(6246003)(6116002)(102836003)(3846002)(82746002)(3660700001)(5660300001)(305945005)(110136004)(3280700002)(7736002)(38730400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2506; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: bfc2e068-882a-486e-fd85-08d48855cf4b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR05MB2506;
x-microsoft-antispam-prvs: <CY1PR05MB2506F5DBCDC25C9C8C3CA46BAA1A0@CY1PR05MB2506.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)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR05MB2506; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2506;
x-forefront-prvs: 02843AA9E0
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5CFC07D6F5BB4648A9803C17B4E2C5F7@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:29:09.6663 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2506
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5-N8N19-Lu-lUiIbqMMa-_iKdmo>
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:29:13 -0000

#include individual contributor disclaimer

> On Apr 20, 2017, at 9:08 PM, Enke Chen <enkechen@cisco.com> wrote:
> 
> So *all* the new releases would generate "permit all" for any neighbor that does
> not have an inbound policy?  

Something like that. We are into minutiae here but in my imagined case it's not a per-peer option, it's a global "emulate legacy defaults" option. (I think Jared called it "set bgp insecure-mode on" or something similarly provocative.)

The global is only generated if (a) there is an existing config being upgraded and (b) it doesn't already have the command present (so, the way you turn it off is... configure it off). 

> I am confused - how is this "permit all" different
> from today?

It's not. That's the point. I had hoped to avoid rehashing this since it was already covered in the thread but as I recall the claimed advantages vs. "do nothing" included

- there are no surprises for legacy deployments as you've been warning of, since as you say the black-box behavior is unchanged,
- at least the default is explicit in the config so if you call it "insecure-mode" or something, maybe people will have incentive to flip it from "on" to "off",
- new deployments (where a legacy config is not being upgraded) would start with the default "off" -- this is probably the most important point. 

--John