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). --- 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 --- 1.1 para 3 s/computed paths,/computed paths)/ --- 1.1.2 and onwards... Can you tidy up the capitalisation of the section headings? --- 1.1.2 s/environments require/environments requires/ --- 1.1.2 s/Backward recursive/Backward Recursive/ --- 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"). --- 1.1.3 s/an hierarchy/a hierarchy/ --- 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 --- 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 --- 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 --- 2.1 OLD [I-D.litkowski-pce-state-sync]" describes NEW [I-D.litkowski-pce-state-sync] describes END --- 2.1 Please expand E2E on first use. --- 2.2 s/This also include/This also includes the/ --- 2.2 s/another approaches/another approach/ --- 2.3 s/In which case after parent PCE/In which case, after the parent PCE/ --- 2.3 Please expand LSR on first use --- 3. s/The Section 4 describe how/Section 4 describes how/ --- 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. --- 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. --- 4. s/the resulted E2E/the resultant E2E/ --- 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 --- I think 4655 might be a normative reference.
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
