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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.