Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

<daniel@olddog.co.uk> Mon, 13 May 2019 19:13 UTC

Return-Path: <dk@danielking.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3312012D for <gen-art@ietfa.amsl.com>; Mon, 13 May 2019 12:13:37 -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 GPI4WD_Imqcl for <gen-art@ietfa.amsl.com>; Mon, 13 May 2019 12:13:34 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 68ED11200C5 for <gen-art@ietf.org>; Mon, 13 May 2019 12:13:34 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id i3so443727wml.4 for <gen-art@ietf.org>; Mon, 13 May 2019 12:13:34 -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=dTJ9JX3+eqWTCIUYc56nweG9bl6VUaKtbQsfSy7cRQ8=; b=Qki0s+kitz/p5LGwcMQ19tp4hMXA96MsY3wwPfATb06cHJRyvDYwCTbsG+GBUNGL/v eAN/gdNgm2+2aYguSRUHxQfd5vFuvFy/kVfGeGcf+U5ktHG6RGprHEU4Ulzgmqio0iEe P/zLQ0Efqj4Ig17EG0YDJxyxghWDcGW/ZvnAMqhGJJJUorzHakt46zXewd5NMW0MX/6F 3vyd5S6078/nubgqpU2pjq2OR7fXYgp783YSDfEuh3jl14jzWtiTdSov2J48rEZq7MRF vKZtawNTp7aQrj+YP+fwbS6dt8bSb2DjRE1sYRefhB9iYry8oQ4wBz705R5BOaCu4B/j nz7Q==
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=dTJ9JX3+eqWTCIUYc56nweG9bl6VUaKtbQsfSy7cRQ8=; b=bcik7DdsjQV3lmxYHieUghVNsuRH4lFyl5yoAzWSu94Otu0ekAnDyknGbsFpaptTdz fqY9HQXTnrEaUJzJ1SNr1q02jcgpAgOr3DXRMPNS//cA30Trtiadb2y1f/K3mj8Ef0tH hZzsIpNzUq4a+dKI/vpdgRQaGJug/34aUmrhZa34R1Ux3PgEEljmYP5PyAyz5j4TpaYo KlC4lhydocynJAUFn5DCTQ2aI22la/hZ3VzYKnIvq9S+HGlkBgcRq6DDywPdxZXTkycj AuYdhLMPQcbSS7KXEyDPSrtDBhqE9T87Kob7NKfq0RVPsTuFLvNDwslGNAqJsWC4r7iX euog==
X-Gm-Message-State: APjAAAXEsKG38yZQHHSLVRFugmNob6C0YWHy0TFFwh/7k1uPzxgZx+K2 qtyQLDF7FisAsrOJrXiWZFiIaA==
X-Google-Smtp-Source: APXvYqx8HYgnma0actcMp1cVJDe+6fSpc2aOXLgEnqU9D/PkMqJikAIyDIwqUzQ1e2bXSLZZXeebZw==
X-Received: by 2002:a1c:b4d4:: with SMTP id d203mr16112570wmf.34.1557774812672; Mon, 13 May 2019 12:13:32 -0700 (PDT)
Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id f7sm203153wmc.26.2019.05.13.12.13.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 12:13:31 -0700 (PDT)
Sender: Daniel King <dk@danielking.net>
X-Google-Original-Sender: "Daniel King" <dk@danielking.net>
From: <daniel@olddog.co.uk>
To: "'Alissa Cooper'" <alissa@cooperw.in>, "'Roni Even'" <ron.even.tlv@gmail.com>
Cc: <gen-art@ietf.org>, <draft-ietf-pce-hierarchy-extensions.all@ietf.org>, <pce@ietf.org>, <ietf@ietf.org>
References: <155523854346.29675.15877330669814773282@ietfa.amsl.com> <F1B3F4E8-056F-4099-AF46-BFEF69A0C7A8@cooperw.in>
In-Reply-To: <F1B3F4E8-056F-4099-AF46-BFEF69A0C7A8@cooperw.in>
Date: Mon, 13 May 2019 20:13:30 +0100
Message-ID: <006f01d509bf$f3edf740$dbc9e5c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIWujtCCN4XrPFhwIxqOyq7y/YkkgKBxXpepdH5WuA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/s4Nowq1SMYeklVHf4AxaKN-YVdE>
Subject: Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 19:13:38 -0000

Hi Roni and Alissa, 

Thanks both for the review. We have addressed the comments from you both in
the latest version (11) but have not posted as it was so close to the IESG
telechat. A few comments  (DK>>) below on the specific comments:

Re: Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?

DK>> The draft (section 1.1) now includes the following text. 

>>
      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 very large 
      groups of domains, such as the Internet, is not considered 
      feasible or desirable.
<<

> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.

DK>> According to RFC 5440, the Open message is not a request response
exchange. Both entities send an Open message, and indeed they may even
overlap. In our H-PCE extensions the P flag indicates that the sender wants
the receiver to act as its parent. In the example we give, it should be fine
for one party to not set the P flag in the first Open message seen on the
wire, and for the second part to set the P flag in the second Open message
seen on the wire. Therefore, I don't think this needs to be address as an
implementor should be familiar with the Open message behavior. 

> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"

DK>> Fixed, thanks!

> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.

DK>> In the new version of our I-D (v11) we have three paragraphs for this
section, the first includes text from RFC6805 and uses quotes the reference
text, but we also include some additional discussion (in two further
paragraphs) text not used in 6805 to further define domain diversity. 

DK>> Again, thank you for the reviews. Its very much appreciated. We have a
new version ready which also addresses the above, and comments from Kyle
(secdir) and Mike (rtgdir). 

BR, Dan and the other authors. 

-----Original Message-----
From: Pce <pce-bounces@ietf.org>; On Behalf Of Alissa Cooper
Sent: 13 May 2019 18:23
To: Roni Even <ron.even.tlv@gmail.com>;
Cc: gen-art@ietf.org; draft-ietf-pce-hierarchy-extensions.all@ietf.org;
pce@ietf.org; ietf@ietf.org
Subject: Re: [Pce] [Gen-art] Genart last call review of
draft-ietf-pce-hierarchy-extensions-10

Roni, thanks for your review. I raised your point about the missing OPEN
(error) case in my DISCUSS ballot. One comment below.

> On Apr 14, 2019, at 6:42 AM, Roni Even via Datatracker <noreply@ietf.org>;
wrote:
> 
> Reviewer: Roni Even
> Review result: Almost Ready
> 
> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> Document: draft-ietf-pce-hierarchy-extensions-??
> Reviewer: Roni Even
> Review Date: 2019-04-14
> IETF LC End Date: 2019-04-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is almost ready for publication as a standard track RFC.
> 
> Major issues:
> 
> Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?

This text is the same as what appears in RFC 7399 and I think it captures
the intent clearly enough (although happy to see the authors answer your
question).

Thanks,
Alissa

> 
> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.
> 
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce