Re: [PANRG] I-D Action: draft-irtf-panrg-questions-04.txt

["Rayhaan Jaufeerally (IETF)" <[e-mail]>]

Hi panrg,

I write down some notes / thoughts on the recently updated "Current open
questions in path aware networking", and I thought I'd post it to the list
in case someone is interested:

> 1.  Introduction to Path-Aware Networking

Could also add other examples such as path selection for specific
applications like low jitter for voice or low bandwidth SSH connection over
a stable link with low packet loss.

> 2.1.  A Vocabulary of Path Properties

Everything which is exposed will be (ab?)used and may be difficult to
change in the future (e.g. ossification of the network itself), so there's
a fine line here.

We want to come up with some kind of network agnostic properties which is
still useful to applications.

> 2.2.  Discovery, Distribution, and Trustworthiness of Path Properties

This could be a good opportunity to mention other systems which are also
built upon the trust model of interdomain routing, specifically the
Resource PKI. RPKI is a central part of the effort to secure routing via
ROAs and eventually BGPSEC but there are other proposals such as SEcure
Neighbor Discovery (SEND) which could be bootstrapped from the same trust
root. By the same token, a mechanism for distributing path information
could share the same root of trust. Moreover, if the path information is
contained in a ICMPv6 RA using SEND then such authentication comes for
free. (Note: support for SEND is very lacking but that can be fixed).

> 2.5.  Implications of Path Awareness for the Data Plane

I think that it depends what is meant by a flow and how the path awareness
is implemented in this section.

In a simple scenario where limited path control is given to end hosts it
may be sufficient to implement path control by giving endpoints an address
in various subnets which are routed differently. In this scenario the
traditional 5 tuple would not change since path control is done by choosing
a 5 tuple which corresponds to the desired route.

In this model there is still one route per 5 tuple. I agree however that if
other out of band mechanisms are used such as having a flow server with
which a client can pre-program in a route, or especially multiple routes
then the single route property will no longer hold.

I wonder if there are any instances in the current internet where traffic
is taking multiple paths at the same time for the same flow, and if this is
being manifested in user visible things like ICMP, it would make an
insightful RIPE Atlas experiment.

> 2.6 What is an Endpoint?

I think in this context an endpoint would be perhaps the thing which
receives path information and makes a selection of what path to use based
on that? Endpoints can be at different layers too, for instance if a CPE
router exposes multiple uplinks to the clients of a LAN then at that layer
it is an endpoint, but for a TCP connection which goes over that CPE device
the endpoint could be the ends of that connection i.e. the client and
server.

> 2.7.  Operating a Path Aware Network

It's not clear to me how increasing path control could decrease
connectivity. If a certain link does not have a route to the destination
then the client cannot use it to reach that destination, but it seems to me
that providing the path diversity should result in the number of paths
being greater than or equal to the number with no path diversity.

> 2.8

s/clear than/clear that/

Happy holidays,
Rayhaan

On Tue, Dec 24, 2019 at 10:02 AM <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Aware Networking RG RG of the IRTF.
>
>         Title           : Current Open Questions in Path Aware Networking
>         Author          : Brian Trammell
>         Filename        : draft-irtf-panrg-questions-04.txt
>         Pages           : 8
>         Date            : 2019-12-24
>
> Abstract:
>    In contrast to the present Internet architecture, a path-aware
>    internetworking architecture has two important properties: it exposes
>    the properties of available Internet paths to endpoints, and provides
>    for endpoints and applications to use these properties to select
>    paths through the Internet for their traffic.  This document poses
>    questions in path-aware networking open as of 2019, that must be
>    answered in the design, development, and deployment of path-aware
>    intetnetworks.  It was originally written to frame discussions in the
>    Path Aware Networking proposed Research Group (PANRG), and has been
>    published to snapshot current thinking in this space.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-panrg-questions-04
> https://datatracker.ietf.org/doc/html/draft-irtf-panrg-questions-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>