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
- [RTG-DIR] Rtgdir last call review of draft-ietf-p… Mike McBride
- Re: [RTG-DIR] [Pce] Rtgdir last call review of dr… Dhruv Dhody
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… daniel
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… daniel
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… daniel