[Pce] Barry Leiba's No Objection on draft-ietf-pce-stateful-hpce-13: (with COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Sat, 14 September 2019 19:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA4112001E; Sat, 14 Sep 2019 12:28:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-hpce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, pce-chairs@ietf.org, adrian@olddog.co.uk, pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156848932743.2904.14662217533512732107.idtracker@ietfa.amsl.com>
Date: Sat, 14 Sep 2019 12:28:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/642eR3iGJ6OM6Qi2aYs6Pa40shM>
Subject: [Pce] Barry Leiba's No Objection on draft-ietf-pce-stateful-hpce-13: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 19:28:48 -0000
Barry Leiba has entered the following ballot position for draft-ietf-pce-stateful-hpce-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have only editorial suggestions (albeit, a lot of them). There's no need to reply in any detail; just please consider adopting these suggestions. Thanks. — Abstract — computing new traffic engineered LSPs, and for associated and Need a hyphen in “traffic-engineered”. — Section 1.1 — This document presents general considerations for stateful PCEs, and not Stateless PCEs, in the hierarchical PCE architecture. In particular, the behavior changes and additions to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active PCE usage) in the context of networks using the H-PCE architecture. The second “sentence” is not a complete sentence. One way to fix that is by changing “In particular,” to “It focuses on”. stitching Per Domain LSPs. Throughout, “Per-Domain” needs a hyphen. — Section 1.2 — In the title, “Use Cases” should *not* be hyphenated (it’s a noun, and not being used as a modifier). There’s also an instance of this in Section 3. As per [RFC6805], in the hierarchical PCE architecture, a P-PCE The second comma doesn’t belong. It could also be a change in topology at the P-PCE such as inter-domain link status change. You could take that extra comma and put it here, after “P-PCE”. Additionally a per-domain stitched LSP And then make a copy of that comma and put it after “Additionally”. setup, whereas Section 3.3.1 describe the per-domain stitching. “describes” — Section 1.2.1 — support the function of multi domain coordination via hierarchy, Hyphenate “multi-domain”, or make it one word (“multidomain”). Virtual Network (VN) requirements before requesting for the VN to be provisioned. That sounds odd using “for” and “to be”. It should be “…requesting that the VN be provisioned.” P-PCE and C-PCEs. When the CNC requests for VN provisioning, the MDSC Remove “for”. decompose this request into multiple inter-domain LSP provisioning “decomposes” — Section 1.2.2 — In case of a stateful P-PCE, the stateful P-PCE has to be aware of You don’t have to say “stateful P-PCE” twice. You can either remove the word “stateful” the second time, or (better, I think) simply remove the first clause and say, “A stateful P-PCE has to…” For example, a domain diverse path from another LSP. That’s not a sentence; please make it one or merge it into an adjacent sentence (I can’t figure out the right way to do that from the text you have). The other LSP could be an associated LSP (such as protection) or an unrelated LSP whose I don’t understand the use of “protection” here; can you clarify? — Section 1.2.3 — Similarly, a P-PCE could also request for delegation if it needs to Remove “for”. — Section 3 — All PCE types herein (i.e., EC-EP or EP-EC) are assumed to It should be “and”, not “or”, and I suggest removing the “i.e.” and just saying “(EC-EP and EP-EC)”. A number of interactions are expected in the Hierarchical Stateful PCE architecture, these include: This is called a “comma splice”. Make it a period instead (and have “These” start a new sentence). Alternatively, change “these include” to “including”. 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. This has a number of problems, so let me just fix it here: NEW Note that this hierarchy is recursive, so a Label Switching Router (LSR), as a PCC, could delegate control to a PCE, which may in turn delegate to its parent, which may further delegate to its parent (if it exists). Similarly, update operations can also be applied recursively. END an Open message indicates the support for stateful H-PCE operations as described in this document. Remove “as”. procedures to minimise computational loops. “minimize” — if you use British spelling you need to be consistent about it, and you’re otherwise using American spelling throughout the document. — Section 3.1 — It then sends computation requests to the C- PCEs responsible for each of the domains on the candidate domain I think it’s better not to allow “C-PCE” (and other such terms) to be hyphen-split across lines. A local policy at C-PCE may dictate which LSPs to be reported to the P-PCE. “to be” is not right here. I’d make it “are” (or “should be”). State synchronization mechanism as described in [RFC8231] and [RFC8232] are applicable “mechanisms” We use the sample hierarchical domain topology example from [RFC6805] I’d remove “sample”, because “example” covers it. Or remove “example”… either way. following additional steps are added for stateful PCE to be executed at the end: Comma after “PCE”, please. — Section 3.2 — As per [RFC8051], Delegation is an operation to grant a PCE, temporary rights Remove the comma after “PCE”. The C-PCE may further choose to delegate to P-PCE based on a local policy. To any P-PCE? Or “to its P-PCE”? The PCRpt message with "D" (delegate) flag is sent from C-PCE to P-PCE. ‘with the “D” (delegate) flag’ (add ‘the’) For LSP delegated to the P-PCE via the child PCE, the P-PCE can use the same PCUpd message to request change to the C- PCE (the Ingress domain PCE), the PCE further propagates the update request to the PCC. Again, multiple issues: NEW For an LSP delegated to a P-PCE via the child PCE, the P-PCE can use the same PCUpd message to request a change to the C-PCE (the Ingress domain PCE). The PCE further propagates the update request to the PCC. END — Section 3.3 — In case of inter-domain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the P-PCE. In which case after P-PCE finishes the E2E path computation, it can send the PCInitiate message to the C-PCE There are articles missing here. I think it should be “an inter-domain LSP” and “after the P-PCE finishes”. The following steps are performed, for PCE initiated operations, Remove the first comma and hyphenate “PCE-initiated”. — Section 3.3.1 — operation is possible, where multiple intra-domain LSPs are initiated in each domain which are further stitched to form an E2E LSP. Needs a comma after “each domain”. The following steps are performed, for the Per Domain stitched LSP Remove the comma. Note that each per-domain LSP can be setup in parallel. “set up”, two words. — Section 5.1 — If a parent PCE receives report from an unauthorized child “a report” All mechanism as described in [RFC8231] and [RFC8281] continue to apply. “mechanisms” — Section 5.2 — The PCEP YANG module [I-D.ietf-pce-pcep-yang] may be extended to include details for stateful H-PCE deployment and operation, exact attributes to be modeled is out of scope for this document. Who will (or may) extend it, and when might that happen? And change the comma to a period and capitalize “Exact” (another comma splice). — Section 6.3 — Along with the confidentiality during path computation, the child PCE could also conceal the path information, a C-PCE may replace a path segment with a path-key [RFC5520], effectively hiding the content of a segment of a path. Combination of problems: NEW Along with maintaining confidentiality during path computation, the child PCE could also conceal the path information. A C-PCE may replace a path segment with a path-key [RFC5520], effectively hiding the content of a segment of a path. END
- [Pce] Barry Leiba's No Objection on draft-ietf-pc… Barry Leiba via Datatracker
- Re: [Pce] Barry Leiba's No Objection on draft-iet… Dhruv Dhody
- Re: [Pce] Barry Leiba's No Objection on draft-iet… Barry Leiba