Re: [Pce] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

Dhruv Dhody <> Wed, 21 August 2019 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA08C120912; Wed, 21 Aug 2019 04:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQDhagrW4nGw; Wed, 21 Aug 2019 04:27:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1A6A12009C; Wed, 21 Aug 2019 04:27:08 -0700 (PDT)
Received: by with SMTP id s21so3826441ioa.1; Wed, 21 Aug 2019 04:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XS5uKce8yW9DVsxfFE6Epj4X0lwsF6nXl08S2Yep3e4=; b=aldsoIoO1Q7oGkiCfLlZYNPzELcc4MCcOqZar2hKjeEdybftkuy9LW7vmqV391Re50 albYiTeEQncNzUI3PC4SG6uehAIjsc26/RHTY3k7qVevCPCLowDxUdyqGWWEJSZP5iVz jKttA2YmGDGarwK39T3wftVQTXNBQfrwYkrSBsyK+sIb8UOPvdlCoNs6n+glcymmWF5g LJT6P3N79qsJq4OgH8o87nl499gJJGgyCg5Yn1KM106vY9Uv2PCszITfeAVtR9ckc97e uaWyMTvUzpYEv6D/FysZnyW+2NFIi1zIhrslG5ICfxUJr09iLzjqtqRyhcQCBdluX8Qx 1MjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XS5uKce8yW9DVsxfFE6Epj4X0lwsF6nXl08S2Yep3e4=; b=sLReK/ZX/kmeQ9H/bmsfdd0uaxlRp6qO2s7lQfv6vDJmgX/v12hqB2pKVxUSb4gQfW AlA43e4pZRDTyUmcIcYLeSD6LUu26iImtLBk0kClRHA1ziFm23bcSlVfytGDF05+RcCp CUeEnxvn2h+LxRHWATO3l9M+8FbvN3DEoO8Nn/VLFlJdSIUJQZXZacK20m4Dql0NYdAU ZcxJdiKdy4+KwBavySJ+ofHXQ8XFWoDfov8Zzc/jMnXcWCfE4FplpRWs8mXvjUDT5CiB 2nP4K6ZAup4hmd/Fxt2yFcfVWN1ZCX0MsC2VEz/hoRFoyKAGYUccNsT+wwBqLfZ+AbpX Cg0g==
X-Gm-Message-State: APjAAAWzyeMntFmPL+QiSfq695sPJnCC5Qet4Rhm1AVdNn9kUdgSIAnW c/otWg92s6OO6X3FqL6Rkg1ia48zKXVzQYu2e08=
X-Google-Smtp-Source: APXvYqwHyqRyVHCsF7eQxukPFZv7g/suQk5d+SdospJSROwh1Sd43C9Sl9n4o1N72Eq/O06+Sa+gad6SB9ep/QmHQZs=
X-Received: by 2002:a02:a405:: with SMTP id c5mr9343010jal.54.1566386827602; Wed, 21 Aug 2019 04:27:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Wed, 21 Aug 2019 16:56:31 +0530
Message-ID: <>
To: Paul Kyzivat <>
Cc:, General Area Review Team <>,, Daniel King <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Pce] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Aug 2019 11:27:11 -0000

Hi Paul,

Thanks for your review, please see inline...

On Tue, Aug 20, 2019 at 9:58 PM Paul Kyzivat <> wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-pce-stateful-hpce-11
> Reviewer: Paul Kyzivat
> Review Date: 2019-08-20
> IETF LC End Date: 2019-08-28
> IESG Telechat date: ?
> Summary:
> This draft is basically ready for publication, but has nits that should
> be fixed before publication.
> Issues:
> Major: 0
> Minor: 0
> Nits:  7
> 1) NIT: No glossary
> Since I am not familiar with the subject domain, when I started reading
> this document I felt I was lost among the acronyms. While you are good
> at defining these at first use, I couldn't keep them all in mind as I
> read. I had to create my own glossary to support me while reading. I
> would really appreciate having a glossary in the document.


> 2) NIT: Inconsistent terminology
> In section 3 two pairs of terms are introduced: (C-E / E-C) and (EC-EP /
> EP-EC). IIUC in the first pair "E" stands for "PCE" while in the second
> pair "E" seems to stand for "Extended", while "P" stands for PCE. I
> found this very confusing. I think it would be better to allow "E" to
> mean the same thing in both pairs. Perhaps you could use "X" to stand
> for "eXtended". Then there would be clear parallels:
> C -> XC
> E -> XE
> Please consider doing something relieve the confusion.

The use of notation C-E and E-C is as per RFC 8231 where PCC to PCE is
(C-E) and PCE to PCC is (E-C). In this document we wanted to represent
messages between C-PCE (child PCE) to P-PCE (parent PCE) and we used
EC-EP for it and the reverse EP-EC for P-PCE to C-PCE communication.

This was discussed during shepherd review as well (as we were using CE
and PE before but that was causing confusion because of the well known
meaning of those terms in routing).

I would like to keep the existing notations that has WG support.

> 3) NIT: Badly formed sentence
> I can't parse this sentence in section 3.1:
>     Procedures as described in [RFC6805] are applied and where the
>     ingress C-PCE (Child PCE), triggers a path computation request for
>     the LER in the domain where the LSP originates, sends a request to
>     the P-PCE.
> Can you rephrase it?


> 4) NIT: Unclear text
> In section 3.1 are steps A/B/C/D to be added at the *end*, after step
> 11? It would help to be explicit.
> In step (C) of section 3.2, can you please be explicit about which node
> is to execute these elements? I think it is PCE5, but I'm not certain.


> 5) NIT: Unlinked references
> Some RFC references (e.g. [RFC8051] and [RFC8231] in section 1.1, and
> [RFC8232] in section 3.1) are not linked in the HTML version. I suggest
> a global search for all such unlinked references in the source.

The HTML version of the draft is automatically generated from the text
version. The `rfcmarkup` is used to render the HTML of the I-D/sRFCs.
Specifically, rfcmarkup produces the final HTML using heuristics from
the source TXT and this is beyond the control of the authors.

> 6) NIT: Bad reference link
> In the following from section 3.1:
>     Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical
>     PCE End-to-End Path Computation Procedure) of [RFC6805], the
> the "section 4.6.2" is linked to the non-existent section 4.6.2 of
> *this* document rather than RFC6805.
> A similar link to the same spot in section 3.2 is ok.

I arranged the words so that rfcmarkup works.

> 7) NIT: Outdated references:
> IdNits reports outdated references. I trust these will be updated in due
> course.


Working Copy: