RE: Spencer Dawkins' Yes on draft-ietf-rtgwg-backoff-algo-07: (with COMMENT)

<> Thu, 01 March 2018 11:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1370126DEE; Thu, 1 Mar 2018 03:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.629
X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id htxe2xaa7yJD; Thu, 1 Mar 2018 03:06:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08EB212E035; Thu, 1 Mar 2018 03:06:54 -0800 (PST)
Received: from (unknown [xx.xx.xx.11]) by (ESMTP service) with ESMTP id A59F861397; Thu, 1 Mar 2018 12:06:52 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by (ESMTP service) with ESMTP id 81F2618005F; Thu, 1 Mar 2018 12:06:52 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0382.000; Thu, 1 Mar 2018 12:06:52 +0100
From: <>
To: Spencer Dawkins <>
CC: "" <>, Uma Chunduri <>, "" <>, "" <>, "" <>, The IESG <>
Subject: RE: Spencer Dawkins' Yes on draft-ietf-rtgwg-backoff-algo-07: (with COMMENT)
Thread-Topic: Spencer Dawkins' Yes on draft-ietf-rtgwg-backoff-algo-07: (with COMMENT)
Thread-Index: AQHTq0kd001/FrPzeU+gvwYXTbjHpKO22DEQ
Date: Thu, 1 Mar 2018 11:06:51 +0000
Message-ID: <7056_1519902412_5A97DECC_7056_459_4_53C29892C857584299CBF5D05346208A479B5396@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2018 11:06:56 -0000

Hi Spencer,

I've just found out that, for some reason, my email reply to your review had been stuck in my email outbox for 10 days and hence never reached you. Sorry for this and thanks for your patience. (and for still reading all other threads while waiting for you answer)

Thanks for your review and comments.

Please see inline [Bruno]

 > -----Original Message-----
 > From: Spencer Dawkins []
 > Sent: Wednesday, February 21, 2018 8:21 PM
 > Spencer Dawkins has entered the following ballot position for
 > draft-ietf-rtgwg-backoff-algo-07: Yes
 > When responding, please keep the subject line intact and reply to all
 > email addresses included in the To and CC lines. (Feel free to cut this
 > introductory paragraph, however.)
 > Please refer to
 > for more information about IESG DISCUSS and COMMENT positions.
 > The document, along with other ballot positions, can be found here:
 > ----------------------------------------------------------------------
 > ----------------------------------------------------------------------
 > I really like that you've produced this document. It was clear to someone with
 > a minimal routing background. Thanks for that, too.
 > I would support either Alvaro's Discuss or Deborah's Discuss, and maybe both.

[Bruno] Ack. And thanks for your further clarification.
 > - I think the document would still be useful if it was Informational, as an
 > example of the kind of thing that could be done.
 > - If you really want stuff in the same network, or the same level/area, to use
 > the same timers, putting safe-ish default values in the document would be more
 > likely to make that happen.

[Bruno] In order to avoid duplications, this is discussed in Deborah's and Alvaro's email thread.
Quick summary:
- This document aims at specifying one standard SPF Back-off Delay algorithm so we believe STD track is the appropriate status.
- We have proposed Alvaro to add default timers values for the cases where this algorithm is enabled by default. (when it's specifically configured by the network operator, I think we can assume that the network operator would configure consistent value, as recommended in the document). Pending Alvaro's answer on this proposal.
 > I did notice one piece of text that wasn't clear to me. I found this confusing -
 >   In general, when the network is stable, there is a desire to compute
 >    a new Shortest Path First (SPF) as soon as a failure is detected in
 >    order to quickly route around the failure.  However, when the network
 >    is experiencing multiple temporally close failures over a short
 >    period of time, there is a conflicting desire to limit the frequency
 >    of SPF computations.  Indeed, this allows a reduction in control
 >    plane resources used by IGPs and all protocols/subsystems reacting on
 >    the attendant route change, such as ...
 > "this allows" seemed as likely to refer to the desire to limit, as anything
 > else. Perhaps
 >    ... limit the frequency
 >    of SPF computations, which would allow a reduction in control
 >    plane resources used by IGPs and all protocols/subsystems reacting on
 >    the attendant route change, such as ...
 > might be clearer.

[Bruno] ok. change applied in -08. (On the con side, the change creates a long sentence, but as of today I can't think of a better phrasing. Eventually the RFC editor will make a proposition)

Diff from -07 to -08:
FYI, in the meantime, -09 has been uploaded yesterday:



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.