Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13
Alissa Cooper <alissa@cooperw.in> Wed, 08 July 2020 14:26 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A93A0C39; Wed, 8 Jul 2020 07:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=iu12JkY6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AoDAWzc+
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 8-Fbu5JYgZ_X; Wed, 8 Jul 2020 07:25:58 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0324A3A0C5A; Wed, 8 Jul 2020 07:25:57 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5029F5C0103; Wed, 8 Jul 2020 10:25:57 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 08 Jul 2020 10:25:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=Ljy63sVW+wNt3Gp4zJ8Ai3N BvaMQMlwwp3V3o8NXiE0=; b=iu12JkY6tXmcXcyuO9rG1T1YSk6MV6FqkEfmZSw yVOrnPxa0VYlnA2iTG+2yDffxzlaSvyDEdK62h1Z/hudkTxDu/8CpQKdsnm/zYQy dv5+uZb2DNI2kR9AThbgtxhvRuMZmjQamuOVKHA3MWEV9VoXxrd6ODh9rsHPnGYP 9I4QKSHjZrx3HIdjOzeRwhynYpoufQ8byqsqiH6kfYUWxQWxhfBZEOKiJxpXJ9fw Irlet9f2F/m2hUnRNdxJmlQw99Nknd6S6kW0AyYQJnSPQys0PYdEXwDRDL6F4o1q Fg8GowNbwHKlWbECowIepsATpc4FJI6OePJDDTbRcxSKARA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ljy63s VW+wNt3Gp4zJ8Ai3NBvaMQMlwwp3V3o8NXiE0=; b=AoDAWzc+7/zesgOECJj4y1 Jpr48RQdR4pD/HAQQ9m7aP3i+ebhLORLEorhKdQ/z3D2Q6Aiqly2yCNuEzcBvCI+ vCMX7bpqSmze8X2NJWfgfha1HWAfpiNIQfgCLwzC3uOZirQBdEGnR+fDd3gBvp5o r4i5jzXxWT+qPR9+7+GbzNwWYOdJDnwiCecZ9R0pNaWFOgU46iNEA8YZY1vXn0+N CqZVom/sTfws8lefRqCg/zsB7eWVr7lm+C8gObl8FvNt2UZcl4KgAH+gt6+tSORq rSQ/F14g/OO8vuI8QeDo1RAxCOXq1hxY7Rw0LocMJEZkyAMZ65oAfAhEavgpFQYw ==
X-ME-Sender: <xms:ddcFX-0CaDOtZFGhXK6r2Gtv3RZGb4eXD0olGPYcMu8RBLuVO3K_wA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpedtjedtgedtveefuddthfeugfduffduiedvgeeljeetffeghfegteejjeegveej teenucffohhmrghinhepihgvthhfrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppe dutdekrdehuddruddtuddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:ddcFXxFJXNYr3awCVaW0iP2Q2sGtZ_UQwlrOhh2TdptDR1-yZzP-_g> <xmx:ddcFX266_D9RnugyQUCzPlV55NoW0dprQVhj1nG8hwaUht_X8UrJeA> <xmx:ddcFX_2gZdSPX0JRtSYt2IkhZG2RjUl9POLrPyxQAsz3QDDGhtscKw> <xmx:ddcFX2T86BQosN7mOZ0XAn97fsNYTyXbaPx2kZZBLUguM7HVzdiTaw>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id BC2E2306005F; Wed, 8 Jul 2020 10:25:56 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <C826DC85-6C3D-4044-AF97-12EE90887E8C@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F163AEB7-60D4-427E-A718-86ED69C6BB6F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Date: Wed, 08 Jul 2020 10:25:55 -0400
In-Reply-To: <MN2PR13MB31174573F266C8BBB54F8385F2810@MN2PR13MB3117.namprd13.prod.outlook.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org" <draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org>, "pce@ietf.org" <pce@ietf.org>
To: Huaimo Chen <huaimo.chen@futurewei.com>, Robert Sparks <rjsparks@nostrum.com>
References: <159173888777.20611.18058918121871985684@ietfa.amsl.com> <MN2PR13MB31173E62DE6EDEF9D8E92772F2800@MN2PR13MB3117.namprd13.prod.outlook.com> <33e569da-059e-b250-78ca-ba2bd639ddeb@nostrum.com> <32ec172d-3112-08bf-333c-851cd73df290@nostrum.com> <MN2PR13MB31174573F266C8BBB54F8385F2810@MN2PR13MB3117.namprd13.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/00TQqI9JFkijDTGFFsjQa6SxtBs>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 14:26:01 -0000
Robert, thanks for your review. Huaimo, thanks for addressing Robert’s comments. I entered a No Objection ballot. Alissa > On Jun 12, 2020, at 11:49 AM, Huaimo Chen <huaimo.chen@futurewei.com> wrote: > > Hi Robert, > > Thank you very much for your suggestion. > We have updated the document (version 16 uploaded) according to your suggestion. > > Best Regards, > Huaimo > From: Robert Sparks <rjsparks@nostrum.com <mailto:rjsparks@nostrum.com>> > Sent: Friday, June 12, 2020 11:32 AM > To: Huaimo Chen <huaimo.chen@futurewei.com <mailto:huaimo.chen@futurewei.com>>; gen-art@ietf.org <mailto:gen-art@ietf.org> <gen-art@ietf.org <mailto:gen-art@ietf.org>> > Cc: last-call@ietf.org <mailto:last-call@ietf.org> <last-call@ietf.org <mailto:last-call@ietf.org>>; draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org <mailto:draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org> <draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org <mailto:draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org>>; pce@ietf.org <mailto:pce@ietf.org> <pce@ietf.org <mailto:pce@ietf.org>> > Subject: Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13 > > > On 6/11/20 9:12 AM, Robert Sparks wrote: >> Thanks! Some initial replies inline (I haven't looked at the updated draft yet, but will do so soon): > I've looked at the diffs between -13 and -15 and my comments have been addressed except for one point. > > Only one of them (i.e., elastic range and grace periods) is used for an LSP. > > Isn't strong enough. I think you need normative language here. > > I suggest > A TLV can configure a non-zero grace period or elastic bound, but it MUST NOT provide both. >> On 6/10/20 7:35 PM, Huaimo Chen wrote: >>> Hi Robert, >>> >>> Thank you very much for your time and valuable comments. >>> >>> My answers/explanations are inline below with prefix [HC]. >>> >>> Your comments have been addressed in the updated document >>> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca22642eaef594f08eb0308d80ee5e221%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637275727802251333&sdata=O2EvYJTW9ns6OFBSqAHwZSAp5qPgGGWUC3oQCFzLBw8%3D&reserved=0> >>> >>> Best Regards, >>> Huaimo >>> From: Robert Sparks via Datatracker <noreply@ietf.org> <mailto:noreply@ietf.org> >>> Sent: Tuesday, June 9, 2020 5:41 PM >>> To: gen-art@ietf.org <mailto:gen-art@ietf.org> <gen-art@ietf.org> <mailto:gen-art@ietf.org> >>> Cc: last-call@ietf.org <mailto:last-call@ietf.org> <last-call@ietf.org> <mailto:last-call@ietf.org>; pce@ietf.org <mailto:pce@ietf.org> <pce@ietf.org> <mailto:pce@ietf.org>; draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org <mailto:draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org> <draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org> <mailto:draft-ietf-pce-stateful-pce-lsp-scheduling.all@ietf.org> >>> Subject: Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13 >>> >>> Reviewer: Robert Sparks >>> Review result: Ready with Issues >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C009e6885956a4c1957c908d80cbde38d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637273356999321440&sdata=x1%2BeFVCwSKtx16TqY5ycJgjrXK%2Bb%2Be4ttO0SuBrPStY%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca22642eaef594f08eb0308d80ee5e221%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637275727802261328&sdata=891whMYACGrZ%2BzKXEmhvwpimP6wkNjd%2BL70QOehV9WQ%3D&reserved=0>>. >>> >>> Document: draft-ietf-pce-stateful-pce-lsp-scheduling-13 >>> Reviewer: Robert Sparks >>> Review Date: 2020-06-09 >>> IETF LC End Date: 2020-06-12 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary: Essentially ready for publication as a Proposed Standard RFC, but with >>> issues to consider before progressing >>> >>> Minor Issues: >>> >>> Section 4.2.2: It's not clear when the computation for a path satisfying the >>> constraint happens. Is this done once when the periodical LSP arrives, or at >>> each scheduled interval? If the former, what happens if there is no path >>> solution for only one of the multiple intervals? >>> >>> [HC]: We have made it clear in the document through revising the texts. >>> When a periodical LSP is configured, the paths for all the scheduled >>> intervals of the LSP is computed once. >>> If there is no path for some (e.g., one) of the intervals, >>> the constraints for the periodical LSP is not satisfied and >>> the LSP will not be set up at all. >>> >>> Section 4.4, second paragraph, last sentence: If the path cannot be set, is the >>> previous LSP left in effect? Or does the failure result in no there being no >>> scheduled LSPs in effect? >>> >>> [HC]: We have added the texts explicitly stating that >>> the previous LSP will not be impacted if the path for new >>> requirements cannot be set. >>> >>> Section 5.1 first paragraph: Why is TCP called out here? >>> >>> [HC]: We have removed TCP. >>> >>> You should be explicit about whether it's ok to have both grace periods and >>> elastic bounds at the same time. The TLV allows that to happen. I'm not sure >>> what it would mean, and I suspect it's unlikely that you would have two >>> implementers compute the consequences the same way. >>> >>> [HC]: We have added some texts to say that only one of them is used. >>> >>> Section 5.2.1, definition of the R bit: You should call out that relative time >>> is in seconds (I think?) when the R bit is 1, and you need a discussion >>> somewhere about the necessity of synchronized clocks and potential problems >>> with transmission delay when the R bit is 1. >>> >>> [HC]: You are right. The relative time is in seconds. >>> We have explicitly stated this and had some discussions about >>> synchronizing clocks and potential problems with transmission delay. >>> >>> Section 5.2.1, definition of Start-Time: Why must a value of 0 not be used? Is >>> this true for both R=1 and R=0? For R=1, a start time value of 1 vs a start >>> time value of 0 may, in practice, be indistinguishable (because of transmission >>> or processing delay). >>> >>> [HC]: When R=1, Start-Time=0 means right now. >>> Because of transmission and processing delay, this cannot be achieved. >> And you don't have the same problem (or at least a race condition) for R=1, Start-Time=1? >> (And perhaps other small values of Start-Time?). This isn't a big deal, but it looks like a rough >> edge, and I want to make sure it's been thought through. >>> For R=0, Start-Time=0 means the epoch (i.e., 1 January 1970 at 00:00 UTC). >>> So for both R=1 and R=0, a value of 0 must not be used in Start-Time. >>> >>> In section 5.2.2 at the definition of Repeat-time-length: Please be explicit >>> about whether this is the interval between the start time of two repetitions or >>> the interval between the end-time of one repetition and the start of the next >>> repetition. I think you mean the former. >>> >>> [HC]: It is the interval between the end-time of one repetition and >>> the start of the next repetition. We had added some texts to >>> state this explicitly. >> That surprises me. All the other values are start-start and not end-start. >> With REPEAT-EVERY-DAY, you're aiming for the same time every day. >> Suppose you didn't have REPEAT-EVERY-DAY and had to express that with REPEAT-EVERY-TIME-LENGTH. >> If it were start-start, you could set the interval to 86400 (as you compute in 9.1) and be done. >> With it being end-start you have to calculate the value by subtracting the Duration field value from >> 86400. >> I think that's likely to surprise implementors trying to achieve something like "every other day". >> >>> >>> At section 5.2.1 you say this TLV SHOULD NOT be included unless both PCEP peers >>> have set the B bit. But in section 6.6, you say MUST NOT. Please choose one.. I >>> think you want both places to say MUST NOT. >>> >>> [HC]: We have changed SHOULD NOT to MUST NOT. >>> >>> Nits: >>> >>> Introduction, paragraph 3, second sentence: This is hard to read. I suggest >>> trying to break it into more than one sentence. >>> >>> [HC]: We have split and rephrased it. >>> >>> Introduction, paragraph 4, third sentence: This is hard to read. Please >>> simplify. >>> >>> [HC]: We have rephrased it. >>> >>> The document uses both "database" and "data base". Please pick one. >>> >>> [HC]: We have changed "data base" to database. >>> >>> Top of page 7: "In case of former" does not parse. Please clarify.. >>> >>> [HC]: We have rephrased it. >>> >>> Section 4.2.2, second paragraph, first sentence: Does not parse. I think it is >>> missing more than articles. >>> >>> [HC]: We have revised it. >>> >>> Section 4.3 at "In both modes": It's not clear what "modes" means here. >>> >>> [HC]: We have added some details. >>> >>> It would be worth calling out in section 5.1 that setting PD requires setting B >>> as specified in 5.2.2. >>> >>> [HC]: We have added some texts to state this. >>> >>> It would be helpful in 5.2.2 at the definition of Opt: to point forward to the >>> registry you are creating for its values. It would also be good to be explicit >>> about what to do if an element receives a TLV with a value here it does not >>> understand yet. >>> >>> [HC]: We have added some descriptions about these. >>> >>> Section 9.1 ignores leap-years and leap-seconds. It's worth explicitly noting >>> that. >>> >>> [HC]: We have added some texts about this. >>> >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org <mailto:Gen-art@ietf.org> >> https://www.ietf.org/mailman/listinfo/gen-art <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgen-art&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca22642eaef594f08eb0308d80ee5e221%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637275727802261328&sdata=ldR8LmGjXkxY%2Fw5J%2BrAIh%2FtUjRHgf5TsS7G8COZURSc%3D&reserved=0> > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>
- [Gen-art] Genart last call review of draft-ietf-p… Robert Sparks via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Huaimo Chen
- Re: [Gen-art] Genart last call review of draft-ie… Robert Sparks
- Re: [Gen-art] Genart last call review of draft-ie… Huaimo Chen
- Re: [Gen-art] Genart last call review of draft-ie… Robert Sparks
- Re: [Gen-art] Genart last call review of draft-ie… Huaimo Chen
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper