Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 22 January 2021 01:16 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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" <wangaijun@tsinghua.org.cn>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-teas-pce-native-ip@ietf.org>, <teas-chairs@ietf.org>, <teas@ietf.org>, <lberger@labn.net>
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: <https://mailarchive.ietf.org/arch/msg/teas/nYegw9VhzzTDIpkFP0MOP0bUoQ8>
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 <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=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 <teas-bounces@ietf.org> On Behalf Of Benjamin Kaduk via Datatracker
Sent: Thursday, January 21, 2021 5:41 PM
To: The IESG <iesg@ietf.org>
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. 

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 §6), 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