Return-Path: 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 0258A1200B3; Fri, 21 Jun 2019 10:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Yk_ea6ySM7bw; Fri, 21 Jun 2019 10:30:06 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 4053E120041; Fri, 21 Jun 2019 10:30:06 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v18so6657605ljh.6; Fri, 21 Jun 2019 10:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=stF0qPad1YgnwThdKd86UU7w/D7fz3mysrm5g2P/MN0=; b=fqZtH31jgcuw41NQGBaTiKpudA/sNJ9eVjPUUCwYknkwNqym8xZsg4AnB7wwuX13Eb 0iHshPXE2P+6j+S5zEMWUpNu95wDGL0nKut6ZGeHN30hNgw1Oupp9x6iYDUTt7+wVTAZ PIkN2wTDNO3DXBX112b1PDUWq35xyS1u4c4aMVWaoRHLr/fmpYM32fBSj7gadwSURiCu Rf9CgIdqBPEodjQTnA7oqN53FmvLcmt/JGzoDkzj9dUWIvXBVbsHq6xwe9uUIgd5JjEy hQLKuBbk0VRPkWspo6/2UcewX59oZrSkxEwNMK8kyjGv3CyOpf7zZuql68tY1GE0TI4t Tqng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=stF0qPad1YgnwThdKd86UU7w/D7fz3mysrm5g2P/MN0=; b=i6Z6xb1ZHV72aT5iiu1hMRcmi1f8l+AIp86gSACMXAjhszPn59IgMpLUEzrMFJrcz4 M82uYpKjnc8BkkHICOW9YkEGWMCnApCdHUAQcUFwOcx3I+qDJdkfZVcC8CBHrsdrGZOG i2yH/X+p6S6/gpAdfoEUum7RkLEDbECI/HwGgNF1t8Egz08dj4kReR1wuRaUvNXMkM9u wPptRI7VWkQDF5xIgXvH7ioNDY54sy3GN8CDCq/u/yrPEGa8YNpiwAEiI9DTAwtpfoM+ 2o6SqCaGr6j1RfFTR0M4xOo5sixj+S/lvrZER9ucOtInLOTbBEYlEaYj98WvR1nXVwBn B92w== X-Gm-Message-State: APjAAAWw14vBjEbd1aQQC65pDxK5s6gF1SC/nsMCtJ+z2/UOJ+paQNml YbpJ46IHxCPp0pxwzhqPpcLlSpMmtcAGfamETMzGdmCVtmMg X-Google-Smtp-Source: APXvYqxn8qwm+oYCYzs+wlU+RQ/RAs1xAzidlhldn7FNd9a9K79NLHvvMT2mLDpFryzUs+ggAAokg/yeYuJolegtItA= X-Received: by 2002:a2e:9857:: with SMTP id e23mr26161242ljj.217.1561138204374; Fri, 21 Jun 2019 10:30:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Fri, 21 Jun 2019 13:29:53 -0400 Message-ID: To: Jonathan Hardwick Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "pce@ietf.org" , "draft-ietf-pce-stateful-pce-auto-bandwidth.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001dfbba058bd8d021" Archived-At: Subject: Re: [RTG-DIR] [Pce] Routing directorate review of draft-ietf-pce-stateful-pce-auto-bandwidth-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 17:30:09 -0000 --0000000000001dfbba058bd8d021 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you for the review comments. Please see inline with ... On Tue, Jun 18, 2019 at 5:53 AM Jonathan Hardwick wrote: > Hi there > > > > I have reviewed this draft for the routing directorate as part of > preparing it for IETF last call and IESG review. > > > > I was familiar with this document from the time that I chaired the PCE > working group, but this was the first time I read it all the way through > and paid attention to all details. I found it easy to read and > understand. I think it is basically ready to go with a few small > clarifications and nits, below. > > > > Cheers > > Jon > > > > Document: draft-ietf-pce-stateful-pce-auto-bandwidth-09 > > Reviewer: Jon Hardwick > > Review Date: 18 June 2019 > > IETF LC End Date: LC not started yet > > Intended Status: Standards Track > > > > Comments > > Section 3 is somewhat redundant IMO. > We can keep it given the Figure showing the extensions unless there is a preference to remove it. 4.1 you should ideally provide a reference for how to do MBB signalling. > Added [RFC3209]. 4.3 =E2=80=9CSimilarly, if a PCC gets overwhelmed due to signaling churn, i= t can > notify the PCE to temporarily suspend new LSP setup requests.=E2=80=9D I= think > this is covered by 5.7 as well as the PCE case, but you only refer to 5.7 > for the latter. Please point to 5.7 for both cases. > Added. 5.1 Not a big deal, but I wonder if there is any practical reason to > differentiate the final two bullets. > There is a precedence for the second bullet error message in [RFC 8231] (e.g. error-value 2). The first bullet error message just comes from the existing behaviour without this extension. 5.6 Why are AUTO-BANDWIDTH-ATTRIBUTES required (MUST) in the LSPA object of > a PCRpt? If the LSP is PCE-initiated, then the PCE already knows what > attributes were specified. If the LSP is PCC-Initiated, then the > attributes are the PCC=E2=80=99s business =E2=80=93 the PCE can=E2=80=99t= change them (per 5.5) and > I don=E2=80=99t think the PCE even needs to know what they are. > Agree. Removed the sentence. > 7.2 Misuses RFC 2119 language to request an action from a working group. > In other documents (when there is not already a draft in progress to do i= t) > we have reworded this as =E2=80=9Cthe YANG / MIB could be updated=E2=80= =9D etc. > Updated the text. > > Nits > > 5: =E2=80=9CExtensions to the PCEP=E2=80=9D would sound better as =E2=80= =9CPCEP Extensions=E2=80=9D > Fixed. 7: In RFC 6123 it says =E2=80=9CThe Manageability Considerations section SH= OULD be > placed immediately before the Security Considerations section in any > Internet-Draft.=E2=80=9D =E2=80=93 but here, it comes after. > Updated. Thanks, Rakesh _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --0000000000001dfbba058bd8d021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jon,

Thank you for the review comm= ents. Please see inline with <RG>...

On Tue, Jun 18, 2019 at 5:53 AM = Jonathan Hardwick <Jonathan.Hardwick=3D40metaswitch.com@dmarc.ietf.org> wrote:
=

Hi there

=C2=A0<= /font>

I have reviewe= d this draft for the routing directorate as part of preparing it for IETF l= ast call and IESG review.

=C2=A0<= /font>

I was familiar= with this document from the time that I chaired the PCE working group, but= this was the first time I read it all the way through and paid attention t= o all details.=C2=A0 I found it easy to read and understand.=C2=A0 I think it is basically ready to go with a few small clarifications and ni= ts, below.

=C2=A0<= /font>

Cheers<= /font>

Jon

=C2=A0<= /font>

Document: draf= t-ietf-pce-stateful-pce-auto-bandwidth-09

Reviewer: Jon = Hardwick

Review Date: 1= 8 June 2019

IETF LC End Da= te: LC not started yet

Intended Statu= s: Standards Track

=C2=A0<= /font>

Comments

Section 3 is s= omewhat redundant IMO.

=C2=A0

<RG> We can keep it = given the Figure showing the extensions unless there is a preference to remove it.


4.1 you should= ideally provide a reference for how to do MBB signalling.


<RG> Added [RFC3209].
=

4.3 =E2=80=9CS= imilarly, if a PCC gets overwhelmed due to signaling churn, it can notify t= he PCE to temporarily suspend new LSP setup requests.=E2=80=9D =C2=A0I thin= k this is covered by 5.7 as well as the PCE case, but you only refer to 5.7 for the latter. Please point to 5.7 for both cases.


<RG> Added.

5.1 Not a big = deal, but I wonder if there is any practical reason to differentiate the fi= nal two bullets.

=C2=A0

<RG> There is a prec= edence for the second bullet error message in [RFC 8231] (e.g. error-value 2). The first bullet error message = just comes from the existing behaviour without this extension.



5.6 Why are AU= TO-BANDWIDTH-ATTRIBUTES required (MUST) in the LSPA object of a PCRpt?=C2= =A0 If the LSP is PCE-initiated, then the PCE already knows what attributes= were specified.=C2=A0 If the LSP is PCC-Initiated, then the attributes are the PCC=E2=80=99s business =E2=80=93 the PCE can=E2=80=99t change them= (per 5.5) and I don=E2=80=99t think the PCE even needs to know what they a= re.


<RG> Agree. Removed the sen= tence.

=C2=A0

7.2 Misuses RF= C 2119 language to request an action from a working group.=C2=A0 In other d= ocuments (when there is not already a draft in progress to do it) we have r= eworded this as =E2=80=9Cthe YANG / MIB could be updated=E2=80=9D etc.


<RG> Updated the text.

<= /font>

=C2=A0<= /font>

Nits

5: =E2=80=9CEx= tensions to the PCEP=E2=80=9D would sound better as =E2=80=9CPCEP Extension= s=E2=80=9D

=
<RG> Fixed.
=

7: In RFC 6123= it says =E2=80=9CThe Manageability Considerations section SHOULD be placed= immediately before the Security Considerations section in any Internet-Dra= ft.=E2=80=9D =E2=80=93 but here, it comes after.


<RG> Updated.
=C2=A0=
Thanks,
Rakesh


=

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