shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt
Chris Bowers <cbowers@juniper.net> Tue, 08 August 2017 01:01 UTC
Return-Path: <cbowers@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75BE131D1E; Mon, 7 Aug 2017 18:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 4I6qxpw_EIdc; Mon, 7 Aug 2017 18:01:12 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281C2131CEA; Mon, 7 Aug 2017 18:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mEt+ttE77StdLuPPFh3IxyL51yI5SZ0dzwg278BL+9s=; b=JA76E8belDEGEeE8wP5ofF/tzrMLIZcQfedqxcWuXZtrvqfR4/LSBpgMoaSDZWCn3IKRoatddKTOxA0dXw8QYiE538SwmzxKP3cSS5Nbokn5GZexbIx80IH5N7skKJqnnyeoBOHSRHTZT+lL48iNDwRPiwmFSibXa9Es1Kq9sGM=
Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB3551.namprd05.prod.outlook.com (10.174.250.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Tue, 8 Aug 2017 01:01:06 +0000
Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.1341.010; Tue, 8 Aug 2017 01:01:06 +0000
From: Chris Bowers <cbowers@juniper.net>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "draft-ietf-rtgwg-uloop-delay@ietf.org" <draft-ietf-rtgwg-uloop-delay@ietf.org>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt
Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt
Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/w==
Date: Tue, 08 Aug 2017 01:01:06 +0000
Message-ID: <MWHPR05MB2829961037B7A03049D677E0A98A0@MWHPR05MB2829.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net;
x-originating-ip: [66.129.239.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR05MB3551; 6:5H2dSgtY5RhVSNZBuRKejch76ue1SOi5DRxrdp41kheQwfOYd6ZQlmG3HAc7LasteuIaqUktE6z0uSFJGVx524pVmFdphENeVUp54T681rn9fhcocu+BH31+Z2NBQxIRlwL77u7ZOoP8ZXY2CCktAclhDFbo19xAGwL2+u5gHQAvCp5XXH4xBuzNr4lyWrCqq+nj7HU7tlqZtyyTyn3O5rtCWJ0pcYhsD+nfWp8W1urXQegdQK6L5RZDM88Q5FAZlNauzLcho9YY0rK00p0TrWi2QzrusK+0L4flHYSrzg/0Lxb7F1jxDpaX++Cjs5YswyMothpq8fAK8UH+nZbFDg==; 5:qInXFNLjtWdsx+j/qupErmWll5++JJji+xfVmz/AUWqxoDjToqlUh+zsgwc+yLJCizVOfK8/z1I8ZKAmK1KokAd+Gv5NoBXRO3ErI0lFD0N9PFcr4vP+mA+1q+S14N5iUOe/QX5lIcevQ59wiq5MWA==; 24:wjhObCtxCIAU/GLdtRcY01QujvzjASEU95B8E5U8+WU02WnCt0n35t+S1Amr7/EsBLnddXsG2xdVEZu6irfUDEc1fAQclL1jQ6WLTiVJpQE=; 7:ASqCWj4yQG0CjH3Ni79a7nrZdUQ7nhVrCOLPnVFGIg0pi/bRwuwVacEj7CnuXOggd9p2W/8kl7KzS9oHIetVZHhvj/hBC7SWRx02vjb7ab/kzXTtg7lFBd0XvWkzja8X1pXNmySkIWpZkaEUivlYtntj91OvLLdAsMDFTZyJxXjETFH2QiYBgbgg6MaoNJ7uMlmee3A3j4bfXuzx0Hwrg5sxHkPtcn/x5hgTGSyppbU=
x-ms-office365-filtering-correlation-id: 2339dfcd-a34b-45cb-a93c-08d4ddf8f342
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3551;
x-ms-traffictypediagnostic: MWHPR05MB3551:
x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155)(211171220733660);
x-microsoft-antispam-prvs: <MWHPR05MB3551F92E608E3F1D7B62F4CAA98A0@MWHPR05MB3551.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3551; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3551;
x-forefront-prvs: 03932714EB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(39400400002)(189002)(37854004)(199003)(7696004)(99286003)(3846002)(55016002)(102836003)(3660700001)(966005)(6116002)(25786009)(230783001)(5660300001)(4326008)(38730400002)(66066001)(2906002)(2900100001)(53366004)(53936002)(9686003)(6306002)(86362001)(68736007)(3280700002)(53376002)(105586002)(106356001)(8936002)(50986999)(54356999)(101416001)(81156014)(81166006)(8676002)(6436002)(33656002)(14454004)(2501003)(97736004)(189998001)(478600001)(74316002)(6506006)(77096006)(305945005)(7736002)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3551; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR05MB2829961037B7A03049D677E0A98A0MWHPR05MB2829namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 01:01:06.7536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3551
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/m7gKAb-y8LdIn2rb5hs1UEpLVIo>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Aug 2017 01:01:17 -0000
Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =========== [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in general. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suffers from micro-looping, but the text currently reads that way. The assertion of the last paragraph should be qualified to talk about how microloops will still affect traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has not been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumstances. In particular, if traffic to a given destination can be protected for a given failure by the PLR using a local LFA that is the same as the post convergence path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR. ====== Section 4.4 [CB] It would be good to write out exactly what the modified version of step 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. ========= Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. ========= [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? ========= I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative to informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris
- shepherd feedback and idnits on draft-ietf-rtgwg-… Chris Bowers
- RE: shepherd feedback and idnits on draft-ietf-rt… stephane.litkowski
- RE: shepherd feedback and idnits on draft-ietf-rt… Chris Bowers
- RE: shepherd feedback and idnits on draft-ietf-rt… stephane.litkowski
- RE: shepherd feedback and idnits on draft-ietf-rt… Sikhivahan Gundu
- RE: shepherd feedback and idnits on draft-ietf-rt… stephane.litkowski
- RE: shepherd feedback and idnits on draft-ietf-rt… Sikhivahan Gundu