Re: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-hierarchy-extensions-09

<daniel@olddog.co.uk> Tue, 26 February 2019 06:19 UTC

Return-Path: <dk@danielking.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB8130E77 for <rtg-dir@ietfa.amsl.com>; Mon, 25 Feb 2019 22:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.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 KRcvFx0P-d9P for <rtg-dir@ietfa.amsl.com>; Mon, 25 Feb 2019 22:19:21 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 617AE130E78 for <rtg-dir@ietf.org>; Mon, 25 Feb 2019 22:19:21 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id f14so12551637wrg.1 for <rtg-dir@ietf.org>; Mon, 25 Feb 2019 22:19:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=n2Qqksi5pm04va5KPA6tTjAigYRa5QQ3O7WFQj6nAcY=; b=12JmNHfToWRY+YTMI5ZSmLVaiKqkEzB1fNhMNR9cB9UGvIrk/FmtM4IqZj+9v0tt1P b4qiqu1Ei3OFPcNuevlnN9soSEfe7opEV3niNXPID2Hw5Ud4czcT9pn1WGh1lvjV+4lk RZqjMbYZQmLW4tDOv3QMcigD+xNqW3Ouywrzi8P7evb72/fSMf/sXBvdJKIjTyYjGE5S pCqi45NJhhEh9yDsQOmk9cHOxS3YpDl0SKElOkq+e9Ul1njXt24YgKNPqk0yw6P7jcIJ HnMdSnQ+gL488D6DH6C9sPhTum1g9+8WeUdkZDQACw63tONfCmJE6duMNXFmJtFokX2s 7qcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=n2Qqksi5pm04va5KPA6tTjAigYRa5QQ3O7WFQj6nAcY=; b=EY4fGrTUFgDangCv2XsSJGZxyjZNQuCCwt3UizR5gYxKlm6HjZ8jzGu1f3SCMbp+Jg cuTNjDiOQsY/yoKephaHpdiuWD+yRK9g7eKVg/MTbv+aN2P1xF6/oEtLcL0yJF3dYfkH y0xi0xBo3dFJDT6AKRfgC58jZTU86VYi4+9ZW4x0uoiOUYlG491qM6v3/KGNuQRkZwnq 0wgNHRZHKi2BQ8uhb09BY02ET6e9zwq5iT3gatv4KtPbBlmuJ3ccjnZG/Fmv0IzraIP1 LEN+3XmakqaiZxub8gMt68rTljkdCHbsHedlWFjc7I0tTxj0ypCW9THJN8if6eZ8KUam H1uA==
X-Gm-Message-State: AHQUAuZLSK77Fh3NueDTN8afzOX8gYwy/Fpkdry52n532qbXY4mzleJc /lJLAbVo6lU837rOM8ZZs2dg4A==
X-Google-Smtp-Source: AHgI3IYTYiYuFGwpmYgeR9ZV7J4+tKq978ZKA/NJ16X3QVuA4bE5gxW8MwuS/PRlhnYISQYC0PjdEQ==
X-Received: by 2002:a5d:44c3:: with SMTP id z3mr14582702wrr.329.1551161959137; Mon, 25 Feb 2019 22:19:19 -0800 (PST)
Received: from CIPHER (host109-150-87-180.range109-150.btcentralplus.com. [109.150.87.180]) by smtp.gmail.com with ESMTPSA id t18sm12018971wmt.8.2019.02.25.22.19.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 22:19:18 -0800 (PST)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: <daniel@olddog.co.uk>
To: "'Mike McBride'" <mmcbride7@gmail.com>, <rtg-dir@ietf.org>
Cc: <draft-ietf-pce-hierarchy-extensions.all@ietf.org>, <pce@ietf.org>
References: <155113646185.10637.8298004858075315120@ietfa.amsl.com>
In-Reply-To: <155113646185.10637.8298004858075315120@ietfa.amsl.com>
Date: Tue, 26 Feb 2019 06:19:16 -0000
Message-ID: <018601d4cd9b$33c39e30$9b4ada90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG+ES6JhOVysTjiKqeoh3yJTvsHhaYfE4wg
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Hwk1TW9LtTEM9luxf1p9xF8bNcg>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-hierarchy-extensions-09
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 06:19:28 -0000

Hi Mike, 

Thanks for your detailed review and comments! 

We will squash those NITS and post an update shortly.

BR, Dan (and the other draft-ietf-pce-hierarchy-extensions authors)  

-----Original Message-----
From: Mike McBride <mmcbride7@gmail.com> 
Sent: 25 February 2019 23:14
To: rtg-dir@ietf.org
Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org; pce@ietf.org
Subject: Rtgdir last call review of draft-ietf-pce-hierarchy-extensions-09

Reviewer: Mike McBride
Review result: Has Nits

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-pce-hierarchy-extensions-09
Reviewer: Mike McBride
Review Date: 25 February 2019
IETF LC End Date: N/A (in preparation for IETF LC)
Intended Status: Standards Track

Summary:

This document is near ready for publication. It has nits that should be
considered prior to publication.

Comments:

Great job on the draft and congrats on near publication. It was a tad difficult
to follow certain areas of the document and I therefore offer suggestions to
improve the readability.

Major issues:

No major issues found.

Minor Issues:

No minor issues found.

Nits for your consideration:

1. Page 4:

Replace:
A child PCE may be responsible for a single domain or multiple domains, it is
used to compute the intra-domain path based on its own domain topology
information.

With:
A child PCE may be responsible for single or multiple domains and is used to
compute..."

2. Page 4:

Replace:
In addition, the parent PCE may be requested to provide only the sequence of
domains to a child PCE so that alternative inter-domain path computation
procedures, including Per Domain (PD) [RFC5152] and Backwards Recursive Path
Computation (BRPC) [RFC5441] may be used.

With:
The parent PCE may be requested to provide only the sequence of domains to a
child PCE so that alternative inter-domain path computation procedures,
including Per Domain (PD) [RFC5152] and Backwards Recursive Path Computation
(BRPC) [RFC5441], may be used.

3. Page 5:

Replace:
This could be done via

With:
Move formatting to the right to remain consistent in this section. Under
"Learning".

4. Page 5:

Replace:
The hierarchical relationship model is described in [RFC6805]. It is applicable
to environments with small groups of domains where visibility from the ingress
LSRs is limited. As highlighted in [RFC7399] applying the hierarchical PCE
model to large groups of domains such as the Internet is not considered
feasible or desirable.

With:
Move formatting to the right to remain consistent in this section. Under
"Stateful".

5. Page 10:

Replace:
The Domain-ID TLV when used in the OPEN object, identify the domains served by
the PCE.

With:
Add a comma after TLV
s/identify/identifies

6. Page 12:

Replace:
The usage of Domain-ID TLV carried in an OPEN object is used to indicate a
(list of) managed domains and is described in Section 3.3.1. This TLV when
carried in an RP object, indicates the destination domain ID.

With:
Use of commas. Comma after 'Domain-ID TLV' and 'object'. And after 'This TLV'.

7. Page 12:

Replace:
If a Domain-id TLV is used in the RP object, and the destination is not
actually in the indicated domain, then the parent PCE should respond with a
NO-PATH object and NO-PATH VECTOR TLV should be used, and a new bit number is
assigned to indicate "Destination not found in the indicated domain" (see
Section 3.7).

With:
End the sentence after the second 'used' and then start the new sentence with
'And a new bit...'

8. Page 14:

Replace:
The domain count metric type of the METRIC object encodes the number of domain
crossed in the path.

With:
change the second 'domain' to 'domains' or maybe 'domain's'.

9. Page 14:

Replace:
A PCC or child PCE MAY use these metric in PCReq message for an inter-domain
path computation meeting the number of domain or border nodes crossing
requirement.

With:
Change 'these' to 'the'

10. Page 15:

Replace:
The Parent PCE MAY use these metric in a PCRep message along with a NO-PATH
object in the case where the PCE cannot compute a path meeting this constraint.

With:
change 'these' to 'the' or change to 'PCRep messages'.

11. Page 16:

Replace:
The child PCE MAY also report its list of domain IDs to the parent PCE by
specifying them in the Domain-ID TLVs in the OPEN object carried in the Open
message during the PCEP session initialization procedure.

With:
This is a tough sentence to follow. With the following punctuation changes is
the intention still correct?: "The child PCE MAY also report its list of domain
IDs, to the parent PCE, by specifying them in the Domain-ID TLVs in the OPEN
object. This object is carried in the OPEN message during the PCEP session
initialization procedure."

12. Page 16:

Replace:
When a specific child PCE sends a PCReq to a peer PCE that requires parental
activity and H-PCE capability flags TLV was not included in the session
establishment procedure as described above, the peer PCE should send a PCErr
message to the child PCE and specify the error-type=TBD8 (H-PCE error) and
error-value=1 (H-PCE capability was not advertised) in the PCEP-ERROR object.

With:
Again, a hard, and long, sentence to follow.  I'm not certain if its the child
or peer PCE that is doing the requiring, I'll go with the peer.  See if this is
still correct after adding some commas: "When a child PCE sends a PCReq to a
peer PCE, which requires parental activity and H-PCE capability flags TLV but
which were not included in the session establishment procedure described above,
the peer PCE should send a PCErr message to the child PCE and should specify
the error-type..."

13. Page 17:

Replace:
When a specific child PCE sends a PCReq to a peer PCE that requires parental
activity and the peer PCE does not want to act as the parent for it, the peer
PCE should send a PCErr message to the child PCE and specify the
error-type=TBD8 (H-PCE error) and error-value=2 (Parent PCE capability cannot
be provided) in the PCEP-ERROR object.

With:
strategically placed commas for clarity:
"When a specific child PCE sends a PCReq to a peer PCE, that requires parental
activity and the peer PCE does not want to act as the parent for it, the peer
PCE..."

14. Page 17:

Replace:
ERO

With:
first time ERO is being used in the document. Please call out Explicit Route
Object somewhere.

15. Page 17:

Replace:
o The parent PCE do not hear from a child PCE for a specified time;

With:
'does not' instead of 'do not'

that's it! ;-) I'm suggestion many changes but it'll go quick and make it much
more readable.

thanks,
mike