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

[Boris Khasanov <[e-mail]>]

Hi Mach!

FYI: I just posted the new version to address your comments and suggestions.

 

Thank you.

 

SY,

Boris

 

07.11.2022, 13:35, "Mach Chen" <[e-mail]>:

Hi Boris,

 

OK, thanks for considering my comments, looking forward to seeing the revision.

 

Best regards,

Mach

 

From: rtg-dir <[e-mail]> On Behalf Of Boris Khasanov
Sent: Tuesday, November 1, 2022 3:24 PM
To: Mach Chen <mach.chen=[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [RTG-DIR] [Teas] RtgDir Early review: draft-ietf-teas-pcecc-use-cases-11.txt

 

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=[e-mail]>:

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
[e-mail]
https://www.ietf.org/mailman/listinfo/teas" rel="noopener noreferrer nofollow">https://www.ietf.org/mailman/listinfo/teas