Dear Shepherd, Thank you for the constructive treatment of our I-D.
Indeed, the document would benefit from the text updates and we absolutely agree the need to remove any ambigiouty in the procedure text defined. Also, the ASCII art optimisation is always greatfully received. We (the authors) will update the I-D and respond to the list/Shepherd on how we addressed the comments. BR, Dan. -----Original Message----- From: Adrian Farrel <[email protected]> Sent: 25 March 2019 17:32 To: [email protected] Cc: [email protected] Subject: Review of draft-ietf-pce-stateful-hpce Hi, Good afternoon. My name is Adrian and I'll be your Document Shepherd for this journey. As this draft is progressing through working group last call, I thought I would do my review now and save a little time later. These comments may seem a little negative, but I hope you can address them with small changes. Thanks, Adrian === Abstract s/deployment of Stateful PCE(s)/deployment of Stateful PCEs/ --- Section 1 para 1 needs a reference to 5440 --- 1. s/for stateful PCE(s) in/for stateful PCEs in the/ --- 1. The initial section of the document focuses on end to end (E2E) inter-domain TE LSP. Section 3.3.1 describe the operations for the Per Domain LSP that could be stitched. Maybe... Sections 3.1 and 3.2 focus on end to end (E2E) inter-domain TE LSPa. Section 3.3.1 describes the operations for stitching Per Domain LSPs. --- I am not certain that you need to use upper case terms in this document. I found "SHOULD" in sections 6 and 7.2, and "MAY" twice in seciton 3.1 and once in section 3.3.1. Also "RECOMMENDED" in section 6. Is this really appropriate in a document that is describing an approach, not specifying bits on the wire or implementation behavior? That would allow you to dispose of section 1.1 and the two references. --- Section 3 While the terms PE and CE are defined and used unambiguously, I suspect that they will cause some confusion because they are such well known terms in networking. --- 3. All PCE types herein (i.e., PE or CE) are assumed to be 'stateful PCE'. Is it not plausible to have a stateless C-PCE working with a stateful P-PCE? I think that the relationship of child to parent is similar to the relationship of PCC to PCE, but when we talk about a stateful PCE we don't also talk about a stateful PCC. So when you say that the C-PCE must be stateful, you are necessarily talking about its relationship with its PCCs. If you are determined to limit the scope of this document to PCE hierarchies where both the parent and child are stateful (you are allowed to make this choice if that's what the WG wants) then you need to make this clear in the Abstract and Introduction. --- Am I confused about delegation? You have... The P-PCE has no information about the content of the child domains. Clearly the C-PCE will report the path of the LSP (segment) that crosses the domain for which it is responsible, but how can the P-PCE make any change to that LSP without visibility into the child domain? But you go on to talk about delegation as if it could work: such as... LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs When you draw the similarity between PCC-PCE and C-PCE-P-PCE delegation as... Note that this hierarchy is recursive and thus a Label Switching Router (LSR), as a PCC could delegate the control to a PCE, which may delegate to its parent, which may further delegate it to its parent (if it exist or needed). Similarly update operations could also be applied recursively. .... I think that you miss that the PCC and PCE can both see the TED, but the C-PCE and P-PCE have very different visibility into the domain. --- 3. Just clarity... OLD [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE capability TLV that should be used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the stateful PCE capability TLV. The presence of both TLVs represent the support for stateful H-PCE operations as described in this document. NEW [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV that is used in the OPEN message to advertise the H-PCE capability. [RFC8231] defines the Stateful PCE Capability TLV used in the OPEN message to indicate stateful support. The presence of both TLVs in an OPEN message indicates the support for stateful H-PCE operations as described in this document. END --- 3. I feel that this paragraph is confusing. I think the referenced draft also needs some work on the terms stateful and synchronization, but we can focus on the document at hand. OLD [I-D.litkowski-pce-state-sync] describes the procedures to allow a stateful communication between PCEs for various use-cases. The procedures and extensions as described in Section 3 of [I-D.litkowski-pce-state-sync] are also applicable to Child and Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP object to identify the Ingress (PCC). The PLSP-ID used in the forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the PCC. NEW [I-D.litkowski-pce-state-sync] describes the procedures to allow communication between stateful PCEs that serve the same domain. The procedures and extensions as described in Section 3 of [I-D.litkowski-pce-state-sync] are also applicable to Child and Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP object to identify the Ingress (PCC). The PLSP-ID used in the forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the PCC. END However, this has made [I-D.litkowski-pce-state-sync] a normative reference. I suspect you don't want to go there. That will mean you need to write the normative text here (which may be a bit more of a rewrite) and simply add... Similar procedures are used in [I-D.litkowski-pce-state-sync] to synchronize state between stateful PCEs that serve the same domain. Furthermore, the term "Ingress" in unclear. You probably do not mean the ingress of the LSP, per se. You probably mean the ingress of the LSP in the domain that the C-PCE serves. You also have the term "ingress PCE" (in 3.1) which is such a useful term that you should probably call it out with a definition. --- 3.1 s/applicable to PCEP session/applicable to a PCEP session/ --- 3.1 OLD Taking the sample hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. NEW We use the sample hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. It is shown in Figure 1. END --- 3.1, 3.2, 3.3, and 3.3.1 It is confusing to have steps 1 to 11 as per 6805 and then introduce new steps 1 to 4 in 3.1. We need to: - not confuse these with steps 1 to 4 of 6805 - understand where in the sequence the steps are preformed Furthermore, "initial" steps 1 to 8 are introduced in 3.2. Are these in place of steps 1 to 4 in 3.1 or in addition? And where in the sequence are they performed? How do they relate to steps 1 to 8 of 6805. There is some slightly better description in 3.2, but only steps 1 and 2 seem to be truly "initial". It all needs some more clarity. By the time I got to 3.3.1 I really couldn't work out the steps at all. --- 3.2 OLD To update an LSP, a PCE send to the PCC, an LSP Update Request using a PCUpd message. NEW To update an LSP, a PCE sends an LSP Update Request to the PCC using a PCUpd message. END --- 3.3. PCE Initiation Operation Maybe... 3.3. PCE Initiation of LSPs --- 4.1 How about this for a slightly tidier figure 2? +----------+ | Parent | /| PCE | / +----------+ / / Stateful / / P-PCE / / / / Stateful+-----+ / / C-PCE | PCE |/ / Hi | Hi | / +-----+ / +---+ +---+ / +---+ +---+ + LSR +--+ LSR +........................+ LSR +--+ LSR + + H1 + + H2 + / + H3 + + H4 + +---+ +---+\ +-----+/ /+---+ +---+ \ | PCE | / \ | Lo | / Stateful \ +-----+ / C-PCE \ / Lo \+---+ +---+/ + LSR +--+ LSR + + L1 + + L2 + +---+ +---+ --- 4.1 You have... All procedures described in Section 3 are applicable to inter-layer path setup as well. I wonder if you want to explain that the layers are considered as separate domains. --- 4.2 OLD [RFC8453] describes framework for Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to C-PCE and P-PCE is the Multi-Domain Service Coordinator (MDSC). The Per domain stitched LSP as per the Hierarchical PCE architecture described in Section 3.3.1 and Section 4.1 is well suited for ACTN. NEW [RFC8453] describes a framework for the Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC). The Per Domain stitched LSP as per the Hierarchical PCE architecture described in Section 3.3.1 and Section 4.1 is well suited for ACTN. END --- 4.2 OLD In ACTN framework, Customer Network Controller (CNC) can request the MDSC to check if there is a possibility to meet Virtual Network (VN) requirements (before requesting for VN provision). The H-PCE architecture as described in [RFC6805] can supports via the use of PCReq and PCRep messages between the P-PCE and C-PCEs. NEW In the ACTN framework, a Customer Network Controller (CNC) can request the MDSC to check whether there is a possibility to meet Virtual Network (VN) requirements before requesting for the VN to be provisioned. The H-PCE architecture as described in [RFC6805] can support this function using PCReq and PCRep messages between the P-PCE and C-PCEs. END --- 5.1 I think you need to rephrase this section. I don't think there is any clear meaning to an LSP being involved in H-PCE. But some of this issue can't be resolved until you have worked out what it is that a stateful H-PCE actually does. As previously noted, it would not appear to have access to the per-domain TEDs, so what is it doing with an LSP that is reported or delegated to it? Given what 5.2 says, reporting LSPs (not for delegation, but simply reporting them) seems entirely pointless! --- I noticed that the Table of Contents doesn't match the actual sections starting from Section 5. Possibly sections 4 and 5 were supposed to be merged --- 6. says The LSP state in the PCRpt message SHOULD continue to use this. Can you explain when a PCRpt might deviate from this "SHOULD"? --- 6. Thus securing the PCEP session (between the P-PCE and the C-PCE) using mechanism like TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. What does 'like' mean? Is there anything specific you have in mind? --- You have I-D.ietf-pce-pcep-yang in your references section, but no actual reference to it. --- A number of references need to be promoted to Normative consistent with how you have used them in this document. RFC 4655 RFC 5520 RFC 5925 RFC 8232 RFC 8253 I-D.litkowski-pce-state-sync I-D.ietf-pce-hierarchy-extensions I-D.dugeon-pce-stateful-interdomain _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
