Hi Adrian, Thanks for approving the changes. The revision has been published.
Best regards, Young From: Adrian Farrel [mailto:[email protected]] Sent: Wednesday, December 5, 2018 12:10 PM To: Leeyoung <[email protected]>; [email protected] Cc: [email protected]; 'Dhruv Dhody' <[email protected]>; 'Daniele Ceccarelli' <[email protected]> Subject: RE: Review of draft-ietf-pce-applicability-actn Young, Thanks for a very speedy response. Looks like you captured all of my comments. Please post. Then we can pursue the chairs for WG last call 😊 Cheers, Adrian From: Leeyoung <[email protected]<mailto:[email protected]>> Sent: 05 December 2018 17:14 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dhruv Dhody <[email protected]<mailto:[email protected]>>; Daniele Ceccarelli <[email protected]<mailto:[email protected]>> Subject: RE: Review of draft-ietf-pce-applicability-actn Hi Adrian, Thanks for your comments. Please see inline for our response to your comment. Please also see the attached diff file that compares the old version with new version. If you approve, we will upload the revision. Thanks. Young & Dhruv & Daniele From: Adrian Farrel [mailto:[email protected]] Sent: Monday, December 3, 2018 4:32 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Review of draft-ietf-pce-applicability-actn Hi all, It seems like draft-ietf-pce-applicability-actn is probably approaching ready to go forward, so I did a review. The document looks to be in pretty good shape: I found a list of nits (below), but with these fixed I think the draft would be ready for last call. Thanks, Adrian -- It's Christmas. Buy someone you love a book of fairy tales. https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. ====== Abstract I would replace the second paragraph with something about PCE, as well as about PCEP. That is, the document is about the applicability to PCE to ACTN, as well as the applicability of PCEP to ACTN. Something like... The Path Computation Element (PCE) is component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP). --- YL>> Agreed with the suggested abstract. Introduction First paragraph is a bit jumbled. OLD The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to perform path computations in response to Path Computation Clients (PCCs) requests. NEW The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Clients (PCCs) to request a Path Computation Element (PCEs) [RFC4655] to perform path computations. END YL>> Accepted. --- 1.1 para 3 s/computed paths,/computed paths)/ --- YL>> Done. 1.1.2 and onwards... Can you tidy up the capitalisation of the section headings? --- YL>> Yes, captalization was done for all section headings. 1.1.2 s/environments require/environments requires/ --- YL>> Corrected. 1.1.2 s/Backward recursive/Backward Recursive/ --- YL>> Corrected. 1.1.2 However, both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. I don't think this is right. Of course, BRPC can work best with a known domain sequence, but it will also work nicely with a small set of interconnected domains. What it doesn't work well for is a large set of interconnected domains (but note that is "doesn't work well" rather than "doesn't work"). YL>> How about the following: Old: However, both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. NEW: However, per-domain technique assumes that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. BRPC can work best with a known domain sequence, and it will also work nicely with a small set of interconnected domains. However, it doesn't work well for is a large set of interconnected domains. --- 1.1.3 s/an hierarchy/a hierarchy/ --- YL>> Corrected. 1.2 I think it would be best to not include a reference to [I-D.ietf-teas-actn-requirements] because that document has almost certainly been abandoned. How about... OLD [I-D.ietf-teas-actn-requirements] describes the high-level ACTN requirements. [RFC8453] describes the architecture model for ACTN including the entities (Customer Network Controller(CNC), Multi- domain Service Coordinator(MDSC), and Provisioning Network Controller (PNC) and their interfaces. NEW [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. END --- YL>> Agreed. 1.2 Just a little clarity of text. OLD The two interfaces with respect to the MDSC, one north of the MDSC (CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A hierarchy of MDSC is possible with a recursive MPI interface. NEW There are two interfaces with respect to the MDSC: one north of the MDSC (the CNC-MDSC Interface : CMI), and one south (the MDSC-PNC Interface : MPI). A hierarchy of MDSCs is possible with a recursive MPI interface. END YL>> Agreed. --- Section 2 A little of the confusion between PCE and PCEP here. How about... OLD It should be noted that, this document lists all possible ways in which PCEP could be used for each of the above functions, but all functions are not required to be implemented via PCEP. Operator may choose to use the PCEP for multi domain coordination via stateful H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the topology and support abstraction function. NEW It should be noted that, this document lists all possible ways in which a PCE could be used for each of the above functions, but not all functions are required to be implemented using a PCE. Similarly, this document presents the ways in which PCEP could be used as the communications medium between funcitonl components. Operators may choose to use PCEP for multi domain coordination via a stateful H-PCE, but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get access to the topology and the support abstraction function. END YL>> Accepted with adding a word “alternatively” in the last sentence between “but” and “use”. --- 2.1 OLD [I-D.litkowski-pce-state-sync]" describes NEW [I-D.litkowski-pce-state-sync] describes END YL>> Corrected. --- 2.1 Please expand E2E on first use. YL>> OK. Done. --- 2.2 s/This also include/This also includes the/ YL>> Done. --- 2.2 s/another approaches/another approach/ YL>. Done. --- 2.3 s/In which case after parent PCE/In which case, after the parent PCE/ YL>. Done. --- 2.3 Please expand LSR on first use YL>> Expanded to Label Switching Router --- 3. s/The Section 4 describe how/Section 4 describes how/ YL>> Correct. --- Section 3 has, "The two ACTN interfaces are", but this is followed by three bullet points. I think that the third one is supposed to be ordinary indented paragraph text. YL>> Yes, corrected. --- Section 4 * Topology Change: When the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. This is dependent on the level of abstraction between the MDSC and the PNC. I'd add to that something about thresholding changes as well. YL>> Reporting thresholding changes would be a good capability; however, this require additional enhancement to PCEP or other mechanisms. --- 4. s/the resulted E2E/the resultant E2E/ YL>> Changed. --- Maybe use more common text in Seciton 5. Such as... This document makes no requests for IANA action. --- Section 6 uses upper case RECOMMENDED. Maybe... OLD When PCEP is used on the MPI, this interface needs to be secured, use of [RFC8253] is RECOMENDED. NEW When PCEP is used on the MPI, this interface needs to be secured. That can be achieved using the procedures described in [RFC8253]. END YL>> Agreed and done. --- I think 4655 might be a normative reference. YL>> OK. Moved to the normative reference section.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
