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

<daniel@olddog.co.uk> Mon, 13 May 2019 19:25 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 3F7361200C5 for <rtg-dir@ietfa.amsl.com>; Mon, 13 May 2019 12:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8qAyFkiUfShf for <rtg-dir@ietfa.amsl.com>; Mon, 13 May 2019 12:25:07 -0700 (PDT)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 9F89F120228 for <rtg-dir@ietf.org>; Mon, 13 May 2019 12:25:06 -0700 (PDT)
Received: by mail-wr1-x443.google.com with SMTP id r4so16535429wro.10 for <rtg-dir@ietf.org>; Mon, 13 May 2019 12:25:06 -0700 (PDT)
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=Z1rZOxaR8m4wE3Ne1BsELybquWnG7337Cuboy1A2ZpY=; b=u/KY4kX6B6FryTMtI/pNzX4Rg9rq/J/YLVLGnfpLsOjiywM+zfhOrlb/uk0adcwEWa oTtg/4pJyDCq3iFoNhYKOeC7PpvArzxpBtppulBG3a0RPPCFyzMjRrPhr9Fq2EHGt2tR VUcmBbTfc35ytqDq0a8I4iQJusO8t/Mt0wUk4KVceAKqHkJRpPKw03HUW8UkuphgdeYo pS9Yx/Ij/F6eUcyiwn8HCFy1QcU7Smu8XH0iwcYv3JzL6v4GXskgEE1fOEo9uTVu9aQ1 wdo89PJoSGcL1icy5mPk5PKD8rI1gNL+xqCwOB+4jpeqV7DhM18Q/d4ykIKShaqNfVVw I6hw==
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=Z1rZOxaR8m4wE3Ne1BsELybquWnG7337Cuboy1A2ZpY=; b=KDy5b3WO2e4c7xvsJwIZKCmB5/QluyfGBdLT6GBcc9QmnIr2POHQvlBbt8vbt2IBtp kcvq5LUEBqWCIUK5whvBF8PFza7RR8V4UTnhJ5SJf4dy9jtwHot47BaMTEz6ljoZlZro hfolKt+1UDMwG8OsZeuapCo/6nUFHeJ8wvyjeYQi9VslcJbRdYeCs/LOEHOZY56A1DUg 7z+z1dnV0JxLY6ZjjUyWgQkczFGyCe/RNepO1JHurrkwngyEiyDQYJE6nnrdUTUTqYOK JQRakQyWSRSjYPu7PAexApJECakbSuXVS1h+lTFx5mzHeRx01ukAZR5S1zz8YWCG6NSF 7Yzw==
X-Gm-Message-State: APjAAAXI0JI0Z3sdl6d5G8jmHP78wkJlnoCxemEHWd5mhmU3nXZeN4lX eNyyIGwnjLb2X+W/aI6TF+gvH03i2q9sZA==
X-Google-Smtp-Source: APXvYqylmLxI84MEgsxjCEU6/mThkHm+GeNNkmv6DRhkNh9F0ggsuUzQjVPclwhbOLd6uxYofKc0Yg==
X-Received: by 2002:adf:d081:: with SMTP id y1mr18517719wrh.283.1557775504793; Mon, 13 May 2019 12:25:04 -0700 (PDT)
Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id f81sm374609wmf.10.2019.05.13.12.25.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 12:25:03 -0700 (PDT)
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>, <oscar.gonzalezdedios@telefonica.com>
References: <155113646185.10637.8298004858075315120@ietfa.amsl.com>
In-Reply-To: <155113646185.10637.8298004858075315120@ietfa.amsl.com>
Date: Mon, 13 May 2019 20:25:02 +0100
Message-ID: <007801d509c1$90966090$b1c321b0$@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+ES6JhOVysTjiKqeoh3yJTvsHhaaXYCyg
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/cG7kRtDo4kkTcFAiRiWqI5UaKNM>
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: Mon, 13 May 2019 19:25:10 -0000

Thanks again Mike for all your thorough review, and valuable comments/suggestions, and especially text changes! 

All of these NITS have been squashed in our latest version (v11) which will post once the IESG telechat is complete. 

BR, Dan and the other 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