From nobody Thu Jan 21 17:16:58 2021 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4659F3A0E9D; Thu, 21 Jan 2021 17:16:57 -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 yLMaPSt-5nOW; Thu, 21 Jan 2021 17:16:55 -0800 (PST) Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719953A0EA5; Thu, 21 Jan 2021 17:16:53 -0800 (PST) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 6908F1C0017; Fri, 22 Jan 2021 09:16:50 +0800 (CST) From: "Aijun Wang" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , , References: <161122207478.15929.16738641328951708142@ietfa.amsl.com> In-Reply-To: <161122207478.15929.16738641328951708142@ietfa.amsl.com> Date: Fri, 22 Jan 2021 09:16:49 +0800 Message-ID: <006901d6f05c$42894c40$c79be4c0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHgxGH+Qy+LJqYCRco3SImUn+hAw6ofI/jQ Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZS0NNSUpMGU5LQxofVkpNSkpJTENJSktMSkxVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hNSlVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NRg6Axw6TT8WGEM2SUw8SDgZ FBBPCzxVSlVKTUpKSUxDSUpKSklDVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU1LTkg3Bg++ X-HM-Tid: 0a7727aa5641d993kuws6908f1c0017 Archived-At: Subject: Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 01:16:57 -0000 Hi, Benjamin: Thanks for your review. I have updated the draft according to your = comments/suggestions, will uploaded it in recent days after resolve the = comments from other experts together. Detail responses inline below [WAJ] Best Regards Aijun Wang China Telecom -----Original Message----- From: teas-bounces@ietf.org On Behalf Of = Benjamin Kaduk via Datatracker Sent: Thursday, January 21, 2021 5:41 PM To: The IESG Cc: draft-ietf-teas-pce-native-ip@ietf.org; teas-chairs@ietf.org; = teas@ietf.org; lberger@labn.net Subject: [Teas] Benjamin Kaduk's No Objection on = draft-ietf-teas-pce-native-ip-15: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-teas-pce-native-ip-15: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Even if this is no longer characterized as "experimental" I agree with = the rtgdir reviewer that it would be interesting to eventually see a = report of the results of the not-experiment, when known. Section 4 When the priority traffic spans a large scale network, such as that illustrated in Figure 2, the multiple BGP sessions cannot be established hop by hop, for example, the iBGP within one AS. nit: what is "the iBGP within one AS" an example of? If it's "a large = scale network" that priority traffic spans, this clause should probably = be relocated. [WAJ] Has changed the description to "When the priority traffic spans a = large-scale network, such as that illustrated in Figure 2, the multiple = BGP sessions cannot be established hop by hop within one AS. For such a = scenario, we propose using a...", as the reply to comments from Murray.=20 Section 5 For Prefix Set No.1, we can select the shortest distance path to carry the traffic; for Prefix Set No.2, we can select the path that has end to end under loaded links; for Prefix Set No.3, we can let nit: hyphenate "under-loaded links". [WAJ] Done. Section 6 o Advertised prefixes and their associated BGP session. Is conveying BGP session information via PCEP going to introduce an = additional layer of statefullness to the system? [WAJ] The states are kept at BGP subsystem layer. Or will the PCEP be able to determine and configure everything in a = single pass as it currently does? [WAJ] Three steps are needed, because there may be need only one step in = some scenario. For example, if one just add some additional prefixes, = only "Advertised prefixes and their associated BGP session" step should = be processed. Section 7.1 I agree with Alvaro that the comparison to flowspec is not serving a = useful purpose in its present form. [WAJ] Have removed the sentences includes the flowspec. Section 8 Increasing the number of BGP sessions (and router loopback addresses, = routes, etc.) seems like it would incrementally add to the baseline load = on such systems, and thus the risk that transient spikes in load could = lead to denial of service. [WAJ] Does Traffic Engineering always requires the transient spikes in = load? Before downloading the PCEP control messages, PCE should have some = simulation for the intended action. Section 11.1 It's not entirely clear to me that, at least based on where we currently = reference it, RFC 4655 needs to be characterized as normative. I also don't think that RFC 8735 needs to be normative; we seem to = replicate the key list of requirements and not rely on the reference for = them. [WAJ] Put them to the "Informative References" in the next version. Section 11.2 On the other hand, if the extensionns from = draft-ietf-pce-pcep-extension-native-ip are truly necessary for the = system to work (per =C2=A76), then it needs to be characterized as = normative. [WAJ] Will try to decouple this architecture document with the PCEP = extension draft. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas