progress of draft-ietf-rtgwg-uloop-delay

Jeff Tantsura <jeff.tantsura@ericsson.com> Wed, 02 March 2016 19:06 UTC

Return-Path: <jeff.tantsura@ericsson.com>
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 69F311B2D50 for <rtgwg@ietfa.amsl.com>; Wed, 2 Mar 2016 11:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 5KUMOqR7btnV for <rtgwg@ietfa.amsl.com>; Wed, 2 Mar 2016 11:06:13 -0800 (PST)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA8B1B2D52 for <rtgwg@ietf.org>; Wed, 2 Mar 2016 11:06:09 -0800 (PST)
X-AuditID: c618062d-f79dd6d000003091-3e-56d7351c4a00
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 6B.1E.12433.C1537D65; Wed, 2 Mar 2016 19:46:52 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 14:06:07 -0500
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: Routing WG <rtgwg@ietf.org>
Subject: progress of draft-ietf-rtgwg-uloop-delay
Thread-Topic: progress of draft-ietf-rtgwg-uloop-delay
Thread-Index: AQHRdLaTUBnLF488O0addQKm5OQtLQ==
Date: Wed, 02 Mar 2016 19:06:07 +0000
Message-ID: <103AF684-41C8-495D-B2E5-C13322B7EEEF@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_103AF68441C8495DB2E5C13322B7EEEFericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt66M6fUwg7ZrBhYX3vxmdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtave5kKWt0rJs3/wNjA2ObaxcjJISFgInFszxkmCFtM4sK9 9WxdjFwcQgJHGCUazlyEcpYxSnR1zWYFqWITMJD4/+04C4gtIiAv8WzlCrBuYQEjiaZb/4Fs DqC4ucSuqRUQJXoS+899BithEVCRaFi3A6yEV8Be4sEkG5AwI9De76fWgJUwC4hL3HoyH+oe AYkle84zQ9iiEi8f/wO7QFRAV+LF3bUsEHEliTmvrzFD9CZLTGy/ww5i8woISpyc+YRlAqPw LCRjZyEpm4WkbBbQRcwCmhLrd+lDlChKTOl+yA5ha0i0zpkLZVtLTJjzjhFZzQJGjlWMHKXF BTm56UYGmxiBUXJMgk13B+P96Z6HGAU4GJV4eD/IXQsTYk0sK67MPcQowcGsJMLbYXE9TIg3 JbGyKrUoP76oNCe1+BCjNAeLkjjv+reXw4QE0hNLUrNTUwtSi2CyTBycUg2MGX8WGIW7v/t0 POqM98N1lnPTH+gXxYdU7b9WvV1VxOaNUnoAk+H6TdonFu85e/1+uGLiFLfLu6adehD4PaM0 xuf1Y7nAgMccLrMY1wbxF618c+7p0oQ/V+ONvnNGT3RiEOTf/uKQ1LfDQkL/S4z8TSMlZC6s 2q5fW3Lu3raJ3KUq77LXOR+cosRSnJFoqMVcVJwIAM9M4A2OAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/wrlkF2_YbpaWGn_pIgUtx9CyrTU>
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: Wed, 02 Mar 2016 19:06:15 -0000

Hi RTGWG,

Chris and I wanted to get a sense of how the working group would like to proceed regarding  draft-ietf-rtgwg-uloop-delay
For sake of simplicity – anyplace further in the email - any changes to  proposed to the existing IGP timers behavior by uloop–delay draft will be called - "uloop–delay algorithm"

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 uloop-delay algorithm?

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

The uloop-delay 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 uloop-delay timers 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 defaults, 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.

Cheers,
Jeff