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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 21 Jan 2021 01:41:15 -0800

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.

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".

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?  Or will the PCEP be
able to determine and configure everything in a single pass as it
currently does?

Section 7.1

I agree with Alvaro that the comparison to flowspec is not serving a
useful purpose in its present form.

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.

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.

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.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 22 Jan 2021 09:16:49 +0800

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: [email-masked] <[email-masked]> On Behalf Of Benjamin Kaduk via Datatracker
Sent: Thursday, January 21, 2021 5:41 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

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.)

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

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

[WAJ] Done.

Section 6

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
[email-masked]
https://www.ietf.org/mailman/listinfo/teas