[PANRG] Two thoughts about draft-irtf-panrg-questions

[Adrian Farrel <[e-mail]>]

Hi PANRG,

I recently had cause to read draft-irtf-panrg-questions (apologies for
coming late to this as a tourist) and it raised two issues for me. You may
already have discussed these, in which case fine and good. On the other
hand, this may give you pause for thought.

1. What is a Path?
I know this is a somewhat fundamental question in the context of this work,
but that probably means it should be front and centre of the document. As
I'm sure you know, the term "path" means so many different things to
different people. A lot depends upon the layer of the stack you are
operating in. A fair amount depends on the virtualisation/abstraction model
you are using and how your overlays are built.
draft-irtf-panrg-questions is pretty clear about what "path-aware
networking" is, but makes no mention of what a "path" is.
Conversely, draft-irtf-panrg-path-properties relies on
draft-irtf-panrg-questions for an explanation of "path-aware networking",
but provides a reasonable explanation of "path" setting the concept in
general and abstract terms.
It wasn't clear to me, reading draft-irtf-panrg-questions, whether the work
was intended to apply at the routing layer, in transport terms (such as
MPTCP), in a tunnel overlay, etc., etc., and that significantly limited the
value I could get from the document. It is also possible (probable?) that
many readers and reviewers bring their own definition of "path" to the
document and so are subjecting the work to their own world-view and not
picking up on the intended meaning.
This is probably resolved quite simply by adding a normative reference to
draft-irtf-panrg-path-properties for the definition of "path".

2. Excluding the Path Computation Element
draft-irtf-panrg-questions makes a single mention of PCE right at the top of
the Introduction.
I fear that the context ("the interfaces to these are generally
administrative as opposed to endpoint-exposed") expresses a fundamental
misunderstanding of what a PCE is and how it can be used. A PCE is an
abstract functional element that enables its user to make choices between
available paths based on a set of constraints. The underlying data sets are
nodes, links, and metrics, and they can be subjected to any algorithm and
any set of constraints in order to determine the chosen path. (To give an
example, I am aware of a use of PCE that determines the best paths through a
sewerage system - sadly not publicly documented.)
The architecture being considered by PANRG seems to assume (Section 2.2)
that the available paths will be presented to the application as complete
things. That is, that some entity will have constructed these paths
presumably by processing the information about nodes, links, and metrics
within the network. But you haven't asked the question: How will those paths
be computed? Of course, my answer would be, "By a PCE".
This may be a reasonable architectural compromise, but it begs the question:
How does the entity supplying the application with paths know what sort of
paths the application wants? That question even extends to knowledge of the
destination the application is trying to reach! An option here is clearly
that the application makes a request to the PCE for a set of potential
paths. This would fit within the issues raised in Section 2.3, since if the
PCE is operated by the network, the paths offered can be limited to only
those that the network trusts the application to use.
There is, however, an architectural alternative where the application has
access to more detailed information: not just the paths it can use, but a
network topology over which it is allowed to operate. That topology could be
the whole network (that is, the actual nodes, links, and metrics of the
network) but it could also be an abstraction of the network (as a filter of
the full network, or as a virtual overlay). The application is able to
process this topology to derive its own preferred paths (by using its own
internal PCE, or by invoking an external PCE). The paths that it generates
and selects will be trusted by the network because they can only use the
resources of the abstracted network that were supplied to the application by
the network.
I'd like to observe that many years' work has been spent considering these
issues in the PCE and TEAS working groups. While some people might prefer to
think of PANRG not overlapping with Traffic Engineering, I have to point out
that steering traffic onto one path or another is a fundamental aspect of TE
in the Internet (see draft-ietf-teas-rfc3272bis).

Hope this helps.

Best,
Adrian