Early Review of draft-ietf-teas-pcecc-use-cases-11
review-ietf-teas-pcecc-use-cases-11-rtgdir-early-chen-2022-11-07-00

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/

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

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.

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.

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]."

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?

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.

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.

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?

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

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."

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.

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]"...

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.

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.

Nits
1. Section2, Terminology,
s/...Client: As.../...Client. As...
s/ ...Element: As.../ ...Element. As...
s/...controller: Extension/ ...controller. Extension...

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...

3.Section 3.2.1
s/label map/label mapping

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

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

Best regards,
Mach