Re: [Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Thu, 11 February 2021 08:50 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9186F3A13B1; Thu, 11 Feb 2021 00:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SMy3z1lU9CRK; Thu, 11 Feb 2021 00:50:13 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D08C3A13B0; Thu, 11 Feb 2021 00:50:13 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Dbqsb6S68z67n0x; Thu, 11 Feb 2021 16:43:31 +0800 (CST)
Received: from fraeml736-chm.china.huawei.com (10.206.15.217) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 11 Feb 2021 09:50:09 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Thu, 11 Feb 2021 09:50:09 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.91]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0509.000; Thu, 11 Feb 2021 16:50:07 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "draft-ietf-pce-pcep-extension-for-pce-controller.all@ietf.org" <draft-ietf-pce-pcep-extension-for-pce-controller.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11
Thread-Index: AQHXAADhwluzu55zA0W1S2XLrxRMDapSol4A
Date: Thu, 11 Feb 2021 08:50:06 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE198C62E8@DGGEML532-MBX.china.huawei.com>
References: <161299816586.3686.13209464455039168599@ietfa.amsl.com>
In-Reply-To: <161299816586.3686.13209464455039168599@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.177.62]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/Kl6G-UffJijrXvb5vwmtbt3dNKs>
Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2021 08:50:16 -0000

Hi Gyan, 

Many thanks for your review. Please find my responses inline below. 

I have also uploaded the new version of this draft according to your reviews and suggestions. . 

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12

Please let us know if there is any further comments. 

Thank you!

> -----Original Message-----
> From: Gyan Mishra via Datatracker [mailto:noreply@ietf.org]
> Sent: Thursday, February 11, 2021 7:03 AM
> To: gen-art@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-controller.all@ietf.org;
> last-call@ietf.org; pce@ietf.org
> Subject: Genart last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-11
> 
> Reviewer: Gyan Mishra
> 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-pcep-extension-for-pce-controller-??
> Reviewer: Gyan Mishra
> Review Date: 2021-02-10
> IETF LC End Date: 2021-02-08
> IESG Telechat date: 2021-02-25
> 
> Summary:
> This document is very well written and describes a new PCEP protocol
> extension for using PCE as a centralized controller PCECC for provisioning
> using its own discrete label space for all or discrete parts static LSP ERO
> path.
> 
> Major issues:
> None
> 
> Minor issues:
> 
> For stateful PCE how do you prevent label collisions when both the PCE is
> provisioning using its own label space and the routers also are using their
> own label space as well and have a mix of both.  After the label download
> and sync at each router hop PCE PCC session their maybe some nodes that
> use the router label space  and other nodes using PCE label space.
> 

This is covered in Section 3, I have added text to clarify further -

   As per Section 3.1.2. of [RFC8283], the PCE-based controller will
   take responsibility for managing some part of the MPLS label space
   for each of the routers that it controls, and may take wider
   responsibility for partitioning the label space for each router and
   allocating different parts for different uses.  The PCC MUST NOT make
   allocations from the label space set aside for the PCE to avoid
   overlap and collisions of label allocations.


> It would seem more complicated to have a mix of having both PCE managed
> label space and non PCE managed label space and for this draft since it’s
> about provisioning static LSP using PCE discrete label space I think it would
> make more sense to have entire LSP to be provisioned using PCE label space
> to prevent label collisions.  This caveat I think should be added to the
> considerations section as well.   

OK, I have added -

   It is RECOMMENDED that
   PCE makes allocations (from the label space set aside for the PCE)
   for all nodes along the path.


> I did not see it mentioned but I think it’s
> also worthwhile mentioning what is the advantage of using this extension
> where the PCE uses its own label space.  Also list the disadvantages as well
> so the operator had a clear picture of reasons to use this extension and
> maybe reasons to not use.  It maybe also worthwhile to mention use cases
> where it makes sense to use this extension and others where it is not.


I have added the following text, which includes the correct references -

   [RFC8283] examines the motivations and applicability for PCECC and
   use of PCEP as an SBI.  Section 3.1.2. of [RFC8283] highlights the
   use of PCECC for label allocation along the static LSPs and it
   simplifies the processing of a distributed control plane by blending
   it with elements of SDN and without necessarily completely replacing
   it.  This allows the operator to introduce the advantages of SDN
   (such as programmability) into the network.  Further Section 3.3. of
   [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where
   the PCECC technique could be useful.  Section 4 of [RFC8283] also
   describe the implications on the protocol when used as an SDN SBI.
   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.


> 
> In section 9 I agree it’s a good idea to have mutually authentication and
> encrypted sessions for all PCE PCC sessions to prevent malicious PCE using
> this extension.
> 
> Nits/editorial comments:
> The abstract states the following in the last sentence which I think should
> better describe the goal and purpose of the draft.
> 
> “ This document specifies the procedures and PCEP extensions for using
> the PCE as the central controller.”
> 
> I would say use of PCE as a centralized controller for provisioning RSVP-TE or
> SR-TE static LSP explicit ERO path for all or parts of an LSP using its own
> discrete label space.
> 


Updated to -

   This document specifies the procedures and PCEP extensions for using
   the PCE as the central controller for provisioning labels along the
   path of the static LSP.

Best regards, 
Shuping