Re: [RTG-DIR] [Teas] RtgDir Early review: draft-ietf-teas-pcecc-use-cases-11.txt

Boris Khasanov <bhassanov@yandex-team.ru> Tue, 01 November 2022 07:24 UTC

Return-Path: <bhassanov@yandex-team.ru>
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 8BE25C152713; Tue, 1 Nov 2022 00:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.628
X-Spam-Level:
X-Spam-Status: No, score=-1.628 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex-team.ru
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izhF5I9veay6; Tue, 1 Nov 2022 00:24:01 -0700 (PDT)
Received: from forwardcorp1a.mail.yandex.net (forwardcorp1a.mail.yandex.net [178.154.239.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA84C15270D; Tue, 1 Nov 2022 00:23:58 -0700 (PDT)
Received: from vla1-f615dbed14ca.qloud-c.yandex.net (vla1-f615dbed14ca.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3183:0:640:f615:dbed]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTP id 343BA5FF58; Tue, 1 Nov 2022 10:23:56 +0300 (MSK)
Received: from mail.yandex-team.ru (mail.yandex-team.ru [2a02:6b8:b081:7208::1:22]) by vla1-f615dbed14ca.qloud-c.yandex.net (mxbackcorp/Yandex) with HTTP id LNL2b30JxqM1-NuJafDl7; Tue, 01 Nov 2022 10:23:56 +0300
X-Yandex-Fwd: 2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1667287436; bh=s5ROuHWB/C6b+a07wOVk34mjUGXXEWuOc7xu5UFZAEA=; h=References:Date:Message-Id:Cc:Subject:To:From; b=DISCAZ6eo4SvT5kNwUxolYhCiX2hteMmlOiRNUEJ39fn7NKvw/kQh8Gy//mTLowaO fb6gU409fvK1Ea0pgxJJKJDwlXJoCCzbTUU4TIsuDMRdRJg2dERc64tZyY1YqG9GUB m00a1se2Pkw+0aHi6WMNps0QwSlU0TobW3XzsXes=
Authentication-Results: vla1-f615dbed14ca.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru
Received: from ij3urkvf4buhbqq7.myt.yp-c.yandex.net (ij3urkvf4buhbqq7.myt.yp-c.yandex.net [2a02:6b8:c12:3b24:0:640:4e1a:0]) by myt5-23f0be3aa648.qloud-c.yandex.net (mxbackcorp/Yandex) with HTTP id GNLnh40JdOs1-KfUKpTwe for <bhassanov@yandex-team.ru>; Tue, 01 Nov 2022 10:23:45 +0300
Received: by ij3urkvf4buhbqq7.myt.yp-c.yandex.net with HTTP; Tue, 01 Nov 2022 10:23:45 +0300
From: Boris Khasanov <bhassanov@yandex-team.ru>
To: Mach Chen <mach.chen=40huawei.com@dmarc.ietf.org>, "draft-ietf-teas-pcecc-use-cases.all@ietf.org" <draft-ietf-teas-pcecc-use-cases.all@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>
Cc: "teas@ietf.org" <teas@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
References: <0c9225e3c7584872af47cce1a0023520@huawei.com>
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Tue, 01 Nov 2022 10:23:55 +0300
Message-Id: <230211666988275@mail.yandex-team.ru>
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/7qzutlyr8FBKqMkMXmF9OXIUkHA>
Subject: Re: [RTG-DIR] [Teas] RtgDir Early review: draft-ietf-teas-pcecc-use-cases-11.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 01 Nov 2022 07:24:05 -0000

Hi Mach,
 
Thank you very much for the feedback and review.
My comments are inline under BKH>
I cannot upload the new version (-12) now which have corrections (nits, typos etc.) made upon your feedback but will do that right after IETF-115.
 
SY,
Boris
 
 
24.10.2022, 13:29, "Mach Chen" <mach.chen=40huawei.com@dmarc.ietf.org>:

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-teas-pcecc-use-cases/" rel="noopener noreferrer nofollow">https://datatracker.ietf.org/doc/draft-ietf-teas-pcecc-use-cases/

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir" rel="noopener noreferrer nofollow">http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-teas-pcecc-use-cases-11
Reviewer: Mach Chen
Review Date: 24 October 2022
Intended Status: Informational

Summary
This document is basically ready for publication, but has nits that should be considered prior to being submitted to the IESG.

Comments and Questions
1. The grammars throughout make the document hard to read in some places, please check through and correct, maybe the authors can ask a native speaker review to improve the document.

BKH> I re-read once again and made changes in the text. New -12 version will be  posted.


2. Section 1, last paragraph
“This document describes the various other usecases for the PCECC
   architecture.”
The “other” makes me think that there are PCECC usecases defined in other documents, if it's true, it's better to give explicit references on them. Otherwise, remove the "other" here.

BKH> Agree, deleted it.


3. Section 2, Terminology,
" IGP: Interior Gateway Protocol. Either of the two routing
   protocols, Open Shortest Path First (OSPF) [RFC2328][RFC5340] or
   Intermediate System to Intermediate System (IS-IS) [RFC1195]."

IGP includes more OSPF and ISIS. I'd suggest to remove " Either of the two routing
   protocols, Open Shortest Path First (OSPF) [RFC2328][RFC5340] or
   Intermediate System to Intermediate System (IS-IS) [RFC1195]."

BKH> Changed it.
 

4. Section 3 Application Scenarios,
This section is called "Application Scenarios", and there is also a section: "Section 3. Applicability" in RFC8283. What's the relationship between this draft and RFC8283?

BKH> RFC8283 describes general PCECC architecture and very high-level overview of application scenarios. The draft just repeats them for a reference,  because they are explained in the draft in more details. Also RFC8283 has a informative reference for the PCECC Use cases draft.


RFC8283, Section 3 Applicability, says:
"This section gives a very high-level introduction to the
   applicability of a PCE-based centralized controller. There is no
   attempt to explain each use case in detail,..."
Thus, I guess the purpose of this document is to define detailed use cases for PCECC? If so, some text needed to clarify this.

BKH> Yes, exactly. I added explicit text about this.


5. Section 3,
The titles of section 3 and its sub-sections are a bit verbose and repetitive, it's better to simplify them. For example, change the title of section to "Use Cases", change the title of section 3.1 "Label Management", no need to repeat "Use Cases of PCECC for" for each use case.

 

BKH> Changed it.

 

6. Section 3, last two paragraphs;
"Section 3.1 describe the general case of PCECC being in charge of
   managing MPLS label space."
What's so special to mention "managing MPLS label space" but not mention other use cases?

BKH> Corrected this.

"In the following sections, several other use cases are described,
   showcasing scenarios that benefit from the deployment of PCECC."
Here, it mentions "other" again.

BKH> Corrected this.
I'd suggest to remove the last two paragraphs, and instead adding text like "The sub-sections will describe the detailed use cases of above applicability; besides, more use cases will be introduced as well."
BKH> Corrected that according your suggestion.
 

7. Section 3.2.4,
Most of text of this section is used for introducing what's is SR policy, IMHO, this may not be necessary, it's better that the text focuses on the use case itself. This is not just an single issue for this section, instead, it's a common issue for all use case sections. I'd suggest that the authors can review the whole document to make a clean-up.
 
BKH> Agreed, I changes the description of thst case.

8.
Section 3.3,
"... R8 with the path: {R1, link1,
      1001}, {1001, R2, link3, 2003], {2003, R4, link10, 4010}, {4010,
      R3, link8, 3008}, {3008, R8}."
It's better to add some text to describe what's the meaning of "{R1, link1, 1001}", "{1001, R2, link3, 2003]"...
BKH> Changed this case description.

9.
Section 3.3.1,
Abbreviations should be expanded before using, for example, AGG, it suggest the authors to check whole document to make sure that all unwell-known abbreviations/terms are expanded before using.
BKS> Yes, I added the clarification before the diagram.

10.
Section 3.4.1,
OLD:
Step 2: After R2 receives the packet with label 6000, it will
      Forward it to R4 by swapping label to 9001 and by swapping label
      of 9002 towards R5.

NEW:
Step 2: After R2 receives the packet with label 6000, it will
      forward it to R4 by swapping label to 9001, and at the same time,
      it will replicate the packet and swap label to 9002 and forward to R5.

Similar issue with step 2-5, need to check grammars of the text and correct them.
BKH> Yes, corrected all steps.

Nits
1. Section2, Terminology,
s/...Client: As.../...Client. As...
s/ ...Element: As.../ ...Element. As...
s/...controller: Extension/ ...controller. Extension...
 
BKH> Yes, corrected.

2. Section 3.1,
s/may taker/may take
s/[RFC9050] describe a mode where LSPs are.../ [RFC9050] describes a mode where an LSP is...
 
BKH> Corrected.

3.Section 3.2.1
s/label map/label mapping
 
BKH>Corrected.

4. Section 3.2.2
s/In this mode of the solution.../In this use case...
s/The path would be the based.../The path would be based...

5. Section 3.4.2.2,
s/ the back LSP/the backup LSP
BKH> Corrected.

Above just lists some of the nits, there should be more, mainly grammar related, please check and correct.

Best regards,
Mach


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas" rel="noopener noreferrer nofollow">https://www.ietf.org/mailman/listinfo/teas