IETF Logo Mail Archive

progressing draft-ietf-rtgwg-backoff-algo

Chris Bowers <cbowers@juniper.net> Tue, 01 March 2016 23:33 UTC

Return-Path: <cbowers@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67731B4365 for <rtgwg@ietfa.amsl.com>; Tue, 1 Mar 2016 15:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 AxOazcUwN5lr for <rtgwg@ietfa.amsl.com>; Tue, 1 Mar 2016 15:33:32 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E3B1B4360 for <rtgwg@ietf.org>; Tue, 1 Mar 2016 15:33:32 -0800 (PST)
Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) with Microsoft SMTP Server (TLS) id 15.1.415.20; Tue, 1 Mar 2016 23:33:30 +0000
Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0415.022; Tue, 1 Mar 2016 23:33:30 +0000
From: Chris Bowers <cbowers@juniper.net>
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: progressing draft-ietf-rtgwg-backoff-algo
Thread-Topic: progressing draft-ietf-rtgwg-backoff-algo
Thread-Index: AdF0EpXcYBgPfn29Q5i2U0Ri/lcTEg==
Date: Tue, 01 Mar 2016 23:33:30 +0000
Message-ID: <BY2PR05MB6140279F8AD863BDED27FF5A9BB0@BY2PR05MB614.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.239.15]
x-microsoft-exchange-diagnostics: 1; BY2PR05MB614; 5:NKZZ07w7D8QnHBlJSVSq+pB2XL0HrspshqjBhjHq3jg/c9lzaBj8CmohqEGdkMK9DMtWfET0Reo1NZpCMqzrZ8E8nPhLA02fOIbScJZHozLcffkjQCAqZAJJjpm/y0ZBITHd7pkiThtPBG2RbaPQAw==; 24:Ranz388BFXbGW+QBlVRuT3HRuiG31fh+S5Kq+/QD1ukQpYJ0/d5/g/EWQIOD70s6jDzpBDK8WpO4kttDQg7tFWXMuntlOcmGqLrPnbAcBrE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB614;
x-ms-office365-filtering-correlation-id: 9651c172-8276-4ef2-c5c3-08d34229e5ca
x-microsoft-antispam-prvs: <BY2PR05MB614D26BF35E4CB6645FBAD9A9BB0@BY2PR05MB614.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB614; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB614;
x-forefront-prvs: 086831DFB4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(6116002)(1220700001)(11100500001)(102836003)(1730700002)(3846002)(586003)(450100001)(122556002)(66066001)(5004730100002)(76576001)(5003600100002)(33656002)(189998001)(1096002)(3280700002)(74316001)(2501003)(3660700001)(54356999)(230783001)(92566002)(5008740100001)(2351001)(229853001)(77096005)(50986999)(99286002)(5002640100001)(40100003)(19580395003)(10400500002)(2900100001)(15975445007)(2906002)(110136002)(107886002)(5001960100004)(86362001)(87936001)(81156009); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB614; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR05MB6140279F8AD863BDED27FF5A9BB0BY2PR05MB614namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 23:33:30.4485 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB614
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/3ME55XaYvRokjywzzRqvnmliUfM>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2016 23:33:44 -0000

RTGWG,

Jeff and I wanted to get a sense of how the working group would like to proceed regarding draft-ietf-rtgwg-backoff-algo.

The basic question for the working group is:   Should we proceed towards publication of the draft more or less as is, or should we wait to incorporate feedback from one or more implementations of the SPF back-off algorithm?

As far as we know, there haven't been any implementations of the proposed SPF back-off algorithm.  It would be good to get an understanding if any implementations are in progress or planned.

The common SPF back-off algorithm proposed in the document seems quite reasonable.  However, it is also quite possible that a single implementation would uncover some unforeseen issues or suggest improvements for the functioning of the algorithm in a single vendor network.  Testing with two or more implementations may provide feedback to improve the algorithm with respect to the goal of having common SPF delays in a multi-vendor network.  But we won't know until that work is done.

If there are implementations in progress or planned, then we think it would be worth waiting to incorporate feedback from those implementations before publishing.

Instead, if there are no implementations planned, we have several options.  We can proceed towards publication more or less as is, with WG last call in the near future.  Or we can explicitly decide to wait to publish the document, leaving it either as an active WG document or as a parked WG document, and wait for one or more implementations.  With the last option, we could leave open the option of publishing at some point in the future, even if no implementations appear.

Personally, I am quite hopeful that there will be at least prototype implementations in the not too distant future.  While it is very unlikely that a vendor would change their default SPF back-off algorithm to this new algorithm, it can easily be implemented with a knob to activate this algorithm.   This gives a simple way to try out the new algorithm incrementally, lowering the bar significantly for at least a prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the draft.

Thanks,
Chris

v2.23.0 | Report a Bug | By Email