Hi,
I'm the document shepherd for this draft and I have done my review to
coincide with the working group last call in the hope that we can
streamline the process a bit.
This document is very well written and clear. Thanks to everyone who has
contributed to get it to this level. I have only a few nitty comments
that should be addressed along with any other last call comments that
you receive.
Thanks,
Adrian
---
Title
I think this should be
Applicability of the Path Computation Element (PCE) to the
Abstraction and Control of TE Networks (ACTN)
---
1.2
[RFC8453] describes the high-level ACTN requirements and the
architecture model for ACTN including the following entities:
Customer Network Controller(CNC), Multi-domain Service
Coordinator(MDSC), and Provisioning Network Controller (PNC) and
their interfaces.
Missing a couple of spaces before the brackets.
---
Is Figure 1 any different from Figure 2 of RFC 8453? If it is the same,
why do you need to repeat it here?
---
I like section 1 and its subsections, but they are quite long for an
Introduction. I think you might rename this to something like
"Background", and add a new, short Introduction that is like the
Abstract but with a few more words. You could fold your section 1.3
into that.
---
2.
s/ACTN [RFC8453] architecture/The ACTN architecture [RFC8453]/
s/Operator may choose/Operators may choose/
---
2.1
OLD
[RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of
PCE with Parent PCE coordinating multi-domain path computation
function between Child PCE(s). It is easy to see how these
principles align, and thus how stateful H-PCE architecture can be
used to realize ACTN.
NEW
[RFC6805] and [I-D.ietf-pce-stateful-hpce] describe a hierarchy of
PCEs with a Parent PCE coordinating multi-domain path computation
function between Child PCEs. It is easy to see how these
principles align, and thus how the stateful H-PCE architecture can
be used to realize ACTN.
END
---
2.3
s/into network provisioning/into a network provisioning/
---
2.3
The first paragraph has a couple of cases of ambiguously assigned
actions that could be fixed.
....customer requests/commands are mapped...
Mapped by what/whom?
....it provides mapping and translation...
What is "it"?
---
2.2 sort of defines "network slice" and that is OK.
2.4, however, uses "VN slice" without explanation.
Can you make this consistent?
---
4.
s/the Figure 2/Figure 2/
OLD
o VN Instantiate: MDSC is requested
NEW
o VN Instantiate: When an MDSC is requested
END
---
6.
s/It also list/It also lists/
---
6.
I think you need to do a little more work. The first paragraph nicely
lists the relevant security requirements. I think you need to say how
each of these is met by security in PCEP. The second paragraph does
mention how to secure PCEP, but doesn't make it clear whether this
addresses the requirements.
The section also only mentions PCEP on the MPI, but the document also
describes using PCEP on the CMI.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
