Subject: [Pce] Shepherd/LC review of draft-ietf-pce-applicability-actn-08

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Feb 2019 15:07:50 -0000

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.

---

From: Leeyoung <[email-masked]>
Date: Fri, 22 Feb 2019 21:57:54 +0000

Hi Adrian,

Thanks for your shepherd/LC review of this draft. Here's our comment (inline under YL>>). 
Diff file is also provided for your verifications of all the changes between v.8 and v.9.

Let us know if this would make you satisfied. 

Thanks & Best regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, February 21, 2019 9:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Shepherd/LC review of draft-ietf-pce-applicability-actn-08

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

YL>> Agreed.
---

1.2

YL>> Corrected.
---

Is Figure 1 any different from Figure 2 of RFC 8453?  If it is the same, why do you need to repeat it here?

YL>> Perhaps adding the text would clarify: 

OLD: The ACTN reference architecture identified a three-tier control
   hierarchy as depicted in Figure 1:

NEW: The ACTN reference architecture is shown in Figure 1 for the convenience. It identifies a three-tier control hierarchy as depicted in Figure 1:

---

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.

YL>> Agreed and done. 
---

2.
s/ACTN [RFC8453] architecture/The ACTN architecture [RFC8453]/ s/Operator may choose/Operators may choose/

YL>> Done.
---

2.1

OLD

YL>> Corrected as such. 
---

2.3

YL>> Done. 

---

2.3

The first paragraph has a couple of cases of ambiguously assigned actions that could be fixed.

YL>> "by the MDSC" is added.

YL>> s/it/the MDSC
---

YL>> s/network slice/VN slice
---

4.
s/the Figure 2/Figure 2/

YL>> Corrected.

OLD
o  VN Instantiate: MDSC is requested
NEW
o  VN Instantiate: When an MDSC is requested END

YL>> Done. 
---

6.

YL>> Done
---

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.

YL>> I would add a sentence as follows in the end of the first paragraph.

NEW: The security considerations discussed in [RFC5440] are relevant for
   this document, this document does not introduce any new security
   issues. 

The section also only mentions PCEP on the MPI, but the document also describes using PCEP on the CMI.

YL>> Added CMI; s/PCEP on the MPI/PCEP on the CMI and MPI

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 23 Feb 2019 04:29:05 -0000

Hello,

Speedy reply from you: thanks.

> Diff file is also provided for your verifications of all the changes between

OK. But (obviously?) please wait until the end of last call as other people may be reviewing and don't want a moving target.

> Let us know if this would make you satisfied. 

Satisfied? Me?
I think you may be mistaking me for someone with a sunny disposition and positive outlook 😊

Snipped and in line...

> NEW: The ACTN reference architecture is shown in Figure 1 for the convenience.
> It identifies a three-tier control hierarchy as depicted in Figure 1:

I see your intent. How about...

The ACTN reference architecture is shown in Figure 1 which is reproduced here from [RFC8453] for convenience. [RFC8453] remains the definitive reference for the ACTN architecture. As depicted in Figure 1, the ACTN architecture identifies a three-tier hierarchy.

---

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

Weeeeeeeeell, I see what you want to do, but I don't quite buy this approach. It is true that it doesn't of itself introduce any security issues, but does it leave the ACTN security issues unresolved or not?

You say that RFC8453 "lists various security considerations such as request and control of resources, confidentially of the information, and availability of function which should be taken into consideration." So you really should take them into consideration. 8453 has a very substantial security section, and what you have to do is pick the points that it identifies and for each say...
- This consideration is not relevant to the use of PCE because it applies to a component that is remote from the PCE
- This consideration applies to the use of PCE and can be addressed through the use of <foo>
- This consideration applies to the use of PCE, but is not currently addressed. New features will need to be developed.

I know this is a bit of work, but the Security reviewers will (should?) require us to do it, so it is better to try now.

Thanks for all the work.
Adrian