[Teas] Benjamin Kaduk's Discuss on draft-ietf-teas-native-ip-scenarios-09: (with DISCUSS and COMMENT)

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-teas-native-ip-scenarios-09: Discuss

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-native-ip-scenarios/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have two points for discussion:

(1) If this document was subject to the approval requirements for
standards action, it would basically be suffering from "death by
abstain"; this seems like a good signal for the IESG to discuss whether
it makes sense to approve this document even though the more-lenient
document-action requirements would otherwise let it go forward.

(2) The document seems incomplete to me.  It has some aspects of being
all/any of a use-cases document, an architecture document, and an
applicability analysis, but does not seem to have a complete treatment
for any of them.  To be clear, there is enough in the document to
indicate that the topic merits further work, and there are some
interesting results, but I'm not sure that publication as an RFC is
appropriate for this document in this form.  Specifically:

(2a) use-cases: we see the examples of star topology with BRAS/SR and
the simulated network in Figure 6, but there is not much discussion of
where these (or similar) scenarios arise in practice, how common they
are, and how closely the simulation reflects actual usage.

(2b) architecture: a very high-level picture is given ("use a PCE to
engineer some of the IP traffic on a network and improve overall
efficiency"), but we don't see much about how PCCs will be involved and
apply the computed paths or what requirements will need to be met by the
protocols and components used to instantiate the architecture

(2c) applicability: we see some scenarios where the proposed technology
shows drastic improvement over the alternative selected for comparison,
but there is little to give confidence that this reflects a broad maxima
that is robust to environmental variations.  Is the alternative selected
for comparison an appropriate one for the cases in question?  How would
the propsal react in the face of changes in the environment it runs in,
such as link or node failure, changes in the baseline usage, or traffic
spikes?  What timescale can it react in and what level of visibility
does the PCE need into current conditions in order to be reliable?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

If we're using a PCE in a native IP network, how do the computed routes
get applied; are we using source routing or just being careful about
the prefixes in use?  (Are there going to be any scaling concerns?)

Section 3.1

I don't understand what Figure 1 is intending to convey.  Are "Private
Cloud Site" and "Public Cloud Site" supposed to be separate boxes on the
edge of the distributed control network?  Why is the "Cloud Based
Application" in neither of the named clouds?

Section 3.2

   Network topology within a Metro Area Network (MAN) is generally in a
   star mode as illustrated in Figure 2, with different devices

"Generally" within what scope, commercial ISPs?  I know of things that
could be called MANs that use a different topology.

Section 4.1

nit: several sentences are missing spaces after the full stop.

Section 4.2

Is a fully-linked core of 100 nodes representative of typical
deployments?  That's a lot of links not going to customers!

Section 4.3

   The traffic matrix is generated based on the link capacity of
   topology.  [...]

I don't know how to interpret this statement.
It does sound like the traffic matrix is generated in a somewhat
arbitrary fashion, with no stated effort to keep it aligned with
real-world traffic patterns.