[PANRG] Some comments on draft-irtf-panrg-questions-11

["Y. Richard Yang" <[e-mail]>]

Hi Brian, all,

Thank you for this wonderful IRTF document, which summarizes open
questions in the field of path-aware networking. I have read this document
quickly before and today I read the latest version from the beginning to
Sec. 2.4 with great interest. Below are some comments, whose goals are to
help with understanding, not to slow down the publications of the document.

Sec.  1
- "In the current Internet architecture, ...": Add a citation to give a
snapshot of current?
- "the network layer provides an unverifiable": the meaning of verifiable
is not clear at an early stage. I can think of source address verification,
path property verification, ... It helps to give a citation or list some
example properties. From the second paragraph, it introduces IPSec and TLS.
It helps to clarify early.
- " ... and Software-Defined Wide Area Network (SD-WAN) approaches": give a
citation, such as the B4 paper?
- "In this environment ...": It is not clear what this environment is. To
use the topical sentence, does it mean "Under this architecture"?

- "A transport layer protocol such as TCP ... a protocol above the network
layer ..." It is clear that this sentence is describing existing
extension services on the basic network layer, but it takes effort to
parse.
- "... explicit information about the path is available to the endpoint,
..." This is the first time that the word "path" appears. It helps to
introduce the word path before this. One possibility might be the last
sentence of the preceding paragraph, e.g., "In this environment, an
application can assume that a packet with a given (unicast) destination
address will eventually be forwarded toward that destination along a path, "
- "... about the path is available to the endpoint" -> endpoint(s).
- " assumptions about that path often do not hold ": A reader may wonder
what assumptions they are, and it is not clear who is making the
assumptions. I would put it in a slightly different way: first state the
applications which make assumptions and then state the impacts.

- The next two paragraphs: "... endpoints have the ability to select or
influence the path through the network used by any given packet or flow."
and "Path selection provides explicit visibility and control of
network treatment to applications and users of the network." can be
slightly confusing to read. One suggestion is to move the definitions early
to clarify the concepts and terms, path aware networking and path aware
internetworking.

Sec. 1.1
- "For purposes of this document, "path aware networking" describes
endpoint ": Do want to limit to endpoint (e.g., it can be the controller of
an application consisting of endpoint) or here endpoint is a generic term?
If so, it helps to clarify.
- I spent some time trying to understand the differences between "path
aware networking" and "path aware internetworking". The latter is specified
as "expanding" the former. From the wording, the former consists of
"discovery" and "reaction", and the latter "discovery" and "selection". Is
this the right way to understand? If so, it helps to pinpoint this key
difference.
- "Research into path aware networking..." Does this imply restricting to
"path aware networking", not "path aware internetworking", or it is a
general term from this point on (see first sentence of Sec. 2)?

Sec. 2.1
This is an excellent open question. Some detailed comments:
- "A Vocabulary of Path Properties" => "A Vocabulary of Paths and
Properties"

- 2nd paragraph: Since the focus is cross domains, it helps to add this
aspect in the paragraph to highlight the challenge, e.g.,
"The elements of this vocabulary could include terminology for components
of a path and properties defined for these components, for the entire path,
or for subpaths of a path."
=>
"The elements of this vocabulary could include terminology for components
of a path and properties defined for these components, for the entire path,
for subpath inside each network, or for the interconnection of these
subpaths defining a global path."

- I will see challenges in addition to expressiveness, and it may help to
connect back to the original question (how to represent). Hence, one
suggestion:
"This vocabulary must be defined carefully, as its design will have impacts
on the expressiveness of a given path-aware internetworking
 architecture."
=>
"This vocabulary and its representation must be defined carefully, as its
design will have impacts on properties (e.g., expressiveness,  scalability,
security) of a given path-aware internetworking architecture."

It might be that only paths and path properties are not enough in the basic
vocabulary. For example, with adaptive flows such as TCP/Reno/Cubic, the
congestion control algorithm of the flows can have impact on the path
properties, e.g., path bandwidth share. It might be helpful to include a
sentence in this paragraph.

Sec. 2.2
- A minor point: "how do endpoints and applications get access to accurate,
useful, and trustworthy path properties?" This reads that there is a fixed
path (with contrast to Sec. 2.3).  It helps to clarify that this is the
case.
- A key challenge is composing a single property from segments spanning
multiple networks.
"Once endpoints and networks have a shared vocabulary for expressing path
properties, the network must have some method for distributing those path
properties to the endpoint."
=>
"Once endpoints and networks have a shared vocabulary for expressing path
properties, the network*s* must have some method for distributing those
path properties to the endpoint. Either the networks or the endpoints need
to aggregate subpath properties from multiple networks"

"Regardless of how path property information is distributed to the
endpoints, the endpoints require a method to authenticate the properties --
to determine that they originated from and pertain to the path that they
purport to."
=>
"Regardless of how path property information is distributed to the
endpoints, the endpoints require a method to authenticate the properties --
to determine that they originated from and pertain to the path that they
purport to, even when the path spans multiple networks."

"Possible dimensions in the space of distribution methods include in-band
versus out-of-band, push versus pull versus publish-subscribe, and so on."
=>
"Possible dimensions in the space of distribution methods include in-band
versus out-of-band, push versus pull versus publish-subscribe,
application-aggregation vs network aggregation, and so on."

At this point, I feel that it may help to add an open question from the
network operator's point of view, e.g., how to protect network operator
privacy?

Sec. 2.3
This is a good open question but can be quite broad, in particular in a
cross-domain setting. To me, it includes PCE and QoS routing as special
cases, and hence can be quite challenging. I would limit the scope but
broad scope may be what this document is intended.

Sec. 2.4
Is the interface for applications/endpoints or more broadly?

Thanks for writing the document guiding the community.

Richard