Re: [Pce] Barry Leiba's No Objection on draft-ietf-pce-stateful-hpce-13: (with COMMENT)

[Barry Leiba <[e-mail]>]

Great!  Thank you, Dhruv.

Barry

On Sun, Sep 15, 2019 at 1:00 AM Dhruv Dhody <[e-mail]> wrote:
>
> Hi Barry,
>
> Thanks for your detailed review. The working copy is updated with your
> suggestions.
>
> Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-hpce-13&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-hpce-14.txt
>
> Thanks!
> Dhruv
>
> On Sun, Sep 15, 2019 at 12:58 AM Barry Leiba via Datatracker
> <[e-mail]> wrote:
> >
> > 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
> >
> >