Ops Dir review comments of draft-ietf-rtgwg-uloop-delay-08

Linda Dunbar <linda.dunbar@huawei.com> Fri, 13 October 2017 23:41 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9A133341; Fri, 13 Oct 2017 16:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hcIDzsmxRVWN; Fri, 13 Oct 2017 16:41:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBD81331F2; Fri, 13 Oct 2017 16:41:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXR56291; Fri, 13 Oct 2017 23:41:08 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Oct 2017 00:41:10 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Fri, 13 Oct 2017 16:40:57 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "ops-dir@ietf.org" <ops-dir@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, "draft-ietf-rtgwg-uloop-delay@ietf.org" <draft-ietf-rtgwg-uloop-delay@ietf.org>
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: Ops Dir review comments of draft-ietf-rtgwg-uloop-delay-08
Thread-Topic: Ops Dir review comments of draft-ietf-rtgwg-uloop-delay-08
Thread-Index: AdNEfLc/F0J8LJiFSfOvzGL5wFkLEA==
Date: Fri, 13 Oct 2017 23:40:57 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6594AF4A7@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.78]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6594AF4A7SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E14F15.0057, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e764d5026701475ea526b30223484d81
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Jls4r79gwkT2cjKPc9cNMdlxakU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Oct 2017 23:41:14 -0000

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-rtgwg-uloop-delay-08

Reviewer: Linda Dunbar

Review result: Have Questions.


Section 6.1 gives an example of when to use the scheme of the proposed delay: Traffic from G to F:  G->D->C->E->F. Your document states: When link C-E fails, if C updates its forwarding entry for F before D, a transient loop occurs.  Therefore, "For traffic from G to F, C delaying the update of its forwarding entry to F."

Question:

For reverse traffic, i.e. from F to G, the primary path is F->E->C->D->G
Does it mean that if D updates its forward entry for G before C, a transient loop occurs? Does D need to delay its forwarding entry to G?   i.e. C delaying update of its forwarding entry to F, but D delaying update of its forwarding entry to G. How about to other destinations?

Does it mean that C & D have to delay its forwarding entry based on destinations?

Thank you very much.

Linda Dunbar