[RTG-DIR] Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 27 April 2017 12:24 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80B1288B8; Thu, 27 Apr 2017 05:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.59
X-Spam-Level:
X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 ObPo0yuwab0H; Thu, 27 Apr 2017 05:24:48 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFAC1273B1; Thu, 27 Apr 2017 05:24:47 -0700 (PDT)
Received: from [85.158.138.179] by server-4.bemta-3.messagelabs.com id 98/5F-02192-C03E1095; Thu, 27 Apr 2017 12:24:44 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSf0gTcRTf9+7mLvP0nJrPYYTTIAstUWhEiWW FFKURBIZSt7rcaJuym7qCyvJH+SPQitS1mdmQ0qlhv2cFGhKOpLAkjFY5LacYQlKmgnXbzbL/ Pu993ufz3gceiUsH/WQkazSweh2jkfv5E0lRKdlxASMoc8NcTaiizXpCYb+8WzFxYRZTVF1cp +gz/8IVjbYvEsXryXlcMfVyGk8h0x6bnJI0q3UWS+sdsuAZ+EGxWqfMNR4Wq94NzeN5PwaRse hWEypCJW9QBfInCboMhzFHg7eQ0pcweHH3DSYUnxF03y+WVKBlpB+9BTpbnX4eHEpz0Hr+ple B058w6JwbQB4ihN4K50q7xcLQTrC4rxICjoeBLqsXE/RquD371WtE0VkwM+fwYkSvgBmHDfNg nA6H96PXvRhoGqxPXuECDoPxkQWxMF+JoKsxWehHQd1Hs8RzENBVONhbppFA7IFrNaO8gORxN NxzZwuQ17oKhYnjMPnU7ZvWwPepNiTYvMegvKvZd0MkXLNU+Pw7xNDXXCYWAsvA+bbcFz4S3B +eioUAOhh77iKEkMHQVz9KLBp96zX7wqSDu6qHqEYxpiWZTUvkpiVyE383TsdCh329MBIFVyq HJQJeA6Vmi2RpvxFJWtAajtUXsPq4hA3xSr06R2XQMmoNXyXGa1mOY3JYDaPk4o/kajsR/25n RCL0CD2oSO1BESQmD6NWdqNMaaAy9+gJFcOpDunzNSzXgyJJUg5UhIvngvVsDms8ptbwP7tIA xkgD6WUHpri8hgtp84RKAeKkoVTd4Z5gvYQqnzdX9nitw+glbIQColEImlAHqvXqg3/8xMonE TyECrRYx+g1hn+uk/wizF+MbFd5FlsYP5RsiIUY2M2zWTXm2sKg5yHBu8/m35b3NCf28w6T8U 1ZW1rj4i1aVz9B0L2JlMFho1p9+zbah3RQSd7kyofKg2BXcPzrqPV6c9ulEnHDbXH1oXvOhK8 f98yx1Dk5lhqx9UO5dl2++Tp5IzNq4yZz39ObV1QW7S/0ycTFoLrynf2p5Zk65bLCU7FJKzF9 RzzB9Ot41LoAwAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-2.tower-169.messagelabs.com!1493295880!112854805!1
X-Originating-IP: [52.33.64.93]
X-StarScan-Received:
X-StarScan-Version: 9.4.12; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 4639 invoked from network); 27 Apr 2017 12:24:43 -0000
Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-2.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 27 Apr 2017 12:24:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZICJtn6qIJeeCFO8GlFRaoVF9OQ5tr59GuqtRZ6COGE=; b=RVIMoV/UlmgRGKgEJTIjfG/mFUrbeyH09E3OeBgnMZ6yqDsK4GOcUilarl6t53I+lEjaN/Sh8EXiXhKPEeToWZFB7q3kzzPJhnuy0fSOo3yjz2oKMMok3gD9Dg1NxaR4WmR9fnI7Q75PZu0//xR7h50U2xYh/+RAZqUmNM4qa8s=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by DB4PR03MB0846.eurprd03.prod.outlook.com (10.161.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 12:24:39 +0000
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737%14]) with mapi id 15.01.1047.019; Thu, 27 Apr 2017 12:24:38 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "jefftant.ietf@gmail.com" <jefftant.ietf@gmail.com>, "chrisbowers.ietf@gmail.com" <chrisbowers.ietf@gmail.com>
CC: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" <Jonathan.Hardwick@metaswitch.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-rtgwg-backoff-algo@ietf.org" <draft-ietf-rtgwg-backoff-algo@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "vainshtein.alex@gmail.com" <vainshtein.alex@gmail.com>
Thread-Topic: Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04
Thread-Index: AdK8QEEK4unKSUKcREikSjn35QwsHw==
Date: Thu, 27 Apr 2017 12:24:38 +0000
Message-ID: <AM4PR03MB1713386BB8649B3813B8E24E9D100@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-microsoft-exchange-diagnostics: 1; DB4PR03MB0846; 7:tRL/FiN6zrBM6clcEGX6+BDnehNMYR0eP1exSEkX94sXd4BLmqll2mHWr4fbYYKWIgdWj8UVy6+yZd020LaiLS9O9sV6Kg052DXBWcbJq0IfrLzR8hKmTlXEd6GPl1qHhA4xa6bI1QU/0mdnYWhkrLuQa7aOOMyEoVdiH/Pq9vqvoLY+a+p1I0kgejjJuAwW11GjNkHLvyLka/1yoN5zkF0CxLRCm1gEQktBwKuEROKQHrW7mMkZP5G7QDEXsJU/32sg6xyRUZMrVrH4eSwMfL5Yt65FJ88VdYgk1ktDc5eaOJ0UGH+bFb2VUpyRuTlnlHovv/v8u5lsG6XUmnqHBg==
x-ms-office365-filtering-correlation-id: b2417ce9-cd9f-4a2e-d08d-08d48d685fc0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR03MB0846;
x-microsoft-antispam-prvs: <DB4PR03MB08465791DF1FC237292C221D9D100@DB4PR03MB0846.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(44800604510135)(120809045254105)(21748063052155)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DB4PR03MB0846; BCL:0; PCL:0; RULEID:; SRVR:DB4PR03MB0846;
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39840400002)(39850400002)(252514010)(2900100001)(8676002)(2906002)(3660700001)(606005)(6436002)(6116002)(790700001)(8936002)(3280700002)(3846002)(102836003)(54896002)(6306002)(9686003)(236005)(54906002)(55016002)(99286003)(53936002)(2501003)(50986999)(7696004)(54356999)(189998001)(86362001)(5250100002)(6506006)(81166006)(33656002)(74316002)(5660300001)(106356001)(7906003)(25786009)(4326008)(39060400002)(66066001)(9326002)(38730400002)(230783001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB0846; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 12:24:38.7208 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB0846
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/QYtccPtnx5FYn0Nl_I5dc7_1j-o>
Subject: [RTG-DIR] Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 12:24:51 -0000

Hello,

I have been selected as the Routing Directorate as an early reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. In this case an early review has been requested by Jeff Tantsura – one of the co-chairs of the RTGWG.
The purpose of the review is to provide assistance to the Routing ADs.   For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-rtgwg-backoff-algo-04
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 27-Apr-17
IETF LC End Date: N/A
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that, from my POV, should be resolved before publication.

Comments:
The draft is very well written, and, with one notable exception, easy to understand.
It represents an attempt to standardize one aspect of behavior of link-state routing protocols: delay between the first IGP event that triggers new SPF computation and the SPF calculation. Until now, this been left for the implementers to play with freely. The resulting differences have been known for quite some time to result in some case in transient micro-loops.

The resolution proposed in this draft includes a well-defined FSM and a full set of tunable parameters (timers) used in this FSM.
The range and granularity of all the tunable parameters are explicitly defined in the document so that the operator would be able to tune its network to use exactly the same SPF delay algorithm with exactly the same parameters. (The default values are not defined because one size does not fit all in this case).

It should be noticed that the draft does not intend to provide a comprehensive solution of the micro-loop problems.
Rather, it provides a common baseline upon which specific solutions for these problems can be built (e.g., see draft-ietf-rtgwg-uloop-delay<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/?include_text=1>;).

Major Issues: None found.

Minor Issues:

1.       The exception to good readability of the draft refers to the term “proximate failures/IGP events” that appears 4 times in the draft. English is not my mother tongue, and the reference<https://www.merriam-webster.com/thesaurus/proximate> I’ve looked up did not help much. “Temporally close” (or something along these lines) looks like a suitable alternative. (Does this comment run strictly against the recommendation for the RTG-DIR reviewers “to avoid raising esoteric questions of English usage”?)

2.       Section 5 mentions starting the SPF_TIMER (with one of the 3 values defined for it) as part of the response to some FSM events if it was not already running -  but it does not specify what happens when this timer expires. I assume that its expiration leaves the FSM in its current state and results in running the SPF computation – if this is correct, it would be nice to say that explicitly.

3.       Section 7 recommends that,  in order to mitigate micro-loop problems using the proposed algorithm, “all routers in the IGP domain, or at least all the routers in the same area/level, have exactly the same configured  values” of the relevant timers . However, the draft does not specify whether these timers should be configured just at the protocol instance level or also at the level of each specific area/level. From my POV, the granularity of configuration should be defined in this draft – one way or another.

4.       The latest versions of the YANG data model drafts for IS-IS and OSPF already define the timers introduced in this draft. But there are no references to these drafts in the document. From my POV such references (Informational and therefore non-blocking) would be useful for the readers, and I suggest to add them.

5.       I have some concerns regarding incremental introduction and activation of the proposed algorithm. The operator that runs a well-tuned network may experience transient problems when some of its routers are already upgraded and use the proposed back-off algorithm while some others still cannot do that. Some text explaining potential issues in this scenario and, if possible, their mitigation, would be most helpful.

6.       The explanatory text in the draft seems to strongly suggest that  SPF_INITIAL_DELAY <= SPF_SHORT_DELAY <=  SPF_LONG_DELAY –  but this is not formalized as a requirement anywhere in the text. From my POV satisfying this relationship should be RECOMMENDED to the operators.

NITS:

1.       Section 3 lists 3 possible values for the SPF_DELAY variable called INITIAL_SPF_DELAY, SHORT SPF_DELAY and LONG_SPF_DELAY. Then, in the last para, it refers to a previously undefined value, INITIAL_WAIT. This is an obvious typo and should be replaced with INITIAL_SPF_DELAY

2.       One of the parameters of the algorithm is called HOLD_DOWN_INTERVAL (in Section 3 and Section 6)  vs. HOLDDOWN_INTERVAL in Section 5. This also looks like an obvious typo, and the same name should be used across the document.

I have discussed my concerns about the draft with the authors who have been most cooperative.
I believe that we have reached an agreement on acceptable resolution of all concerns listed above.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________