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

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