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

Dhruv Dhody <dhruv.ietf@gmail.com> Sun, 15 September 2019 05:00 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7D31200B8; Sat, 14 Sep 2019 22:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYyWhvkCVtyR; Sat, 14 Sep 2019 22:00:29 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F36120048; Sat, 14 Sep 2019 22:00:29 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id r26so71265848ioh.8; Sat, 14 Sep 2019 22:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dmleub1J4fVUvNmzB3InUWouigBUCsT6MRcyJ3zDLzI=; b=Mc0Mr8/ldSAJCr/rw2ALSSwEHh1gyVRPiLXRM5QyZJy3aH5JLVHrfqEjshgyBfjFjZ sQeBAktnHidpfqxP6P9OQXeCtSJxRaHoXvQf6DHFE9I1qaE7RNLUDoxjuh5HOiUnZJPD BrJA6cZB2WqYOzxCEZTMiQeh+rhN0ZTd2W26up+jFvxdah1FHiIwj30TvdwhNTfJCYRh D6nbTqVF2nmz811oBdZ8RZliKcyk9BhM+HWREV8GlWKNnyzEISnQO1g7khgdO6S5ibm0 5lQSAzUJdT2tzLI5rnhVu/cSPZNKYfX6gTZxXAHhu4ODvB/q1Bn6SKb91gA2XG1WQrCP nKMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dmleub1J4fVUvNmzB3InUWouigBUCsT6MRcyJ3zDLzI=; b=PmS/ap6HQmGcVMVyu2P5gSQx8ioounSmXRClI6eO+cIU5FT66zi95isP7LwwENtdta UD/I+H1tzbb0q8WlCvG4C4XkItVUFLRpZbyOHF0nAVqCQIt3/9KSnkKTZmMTpdZzuxGE 9bKx3EJFHXvHRh1tF/yCPNpgxpI2LVz8XWRrRpRcBK35VGGqSNXyzHpu8JZYG+LIoA2T rB+KJR9bRHjp7TgNAQJ/Oq3aOenpV9n15xi+L/Mf8aiI7SiGJEK3ro/TInM7o/RNg1nW QXFIJJl+yMUSEln6IPwKG0vxiQVQ2Xb2jhblRGkD3PMI2UlYE8PVZhDk3lIJCv3NvkhG ZXLA==
X-Gm-Message-State: APjAAAXtEM5ZNCot5W+7xowVcv3QDILpi45wCHJ3pJ3SsYWyh8So2WFW UNu1jbMRhrepkHVHhYuhXDHBuVPVxsHfnKZrfqbQGQZj
X-Google-Smtp-Source: APXvYqxtlrSJdU84PjPxbrc7nAZZC4S+go8J+gUzhSIYaQ/RUm6MGY1jVkOFKRAVPAPVvVxubC2xn2YcK0Fpa8S0/MY=
X-Received: by 2002:a02:1ac5:: with SMTP id 188mr8113045jai.71.1568523628471; Sat, 14 Sep 2019 22:00:28 -0700 (PDT)
MIME-Version: 1.0
References: <156848932743.2904.14662217533512732107.idtracker@ietfa.amsl.com>
In-Reply-To: <156848932743.2904.14662217533512732107.idtracker@ietfa.amsl.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Sun, 15 Sep 2019 10:29:51 +0530
Message-ID: <CAB75xn5FSnCq4XF+n0HH_MLH9sjSGiH1_=N2xaZqLfzqbLUk4g@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-stateful-hpce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/fbGOIW6JcsRoj7oAqV7P-N_1fLk>
Subject: Re: [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
Precedence: list
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: Sun, 15 Sep 2019 05:00:33 -0000

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
<noreply@ietf.org> 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
>
>