File: rfc9217.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (1793 lines) | stat: -rw-r--r-- 67,272 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9217: Current Open Questions in Path-Aware Networking</title>
<meta content="Brian Trammell" name="author">
<meta content='
       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 it provides
      for endpoints and applications to use these properties to select paths
      through the Internet for their traffic. While this property of "path
      awareness" already exists in many Internet-connected networks within
      single domains and via administrative interfaces to the network layer, a
      fully path-aware internetwork expands these concepts across layers and
      across the Internet. 
       This document poses questions in path-aware networking, open as of
      2021, that must be answered in the design, development, and deployment
      of path-aware internetworks. It was originally written to frame
      discussions in the Path Aware Networking Research Group (PANRG), and has
      been published to snapshot current thinking in this space. 
    ' name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="9217" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9217.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9217" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-panrg-questions-12" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9217</td>
<td class="center">PAN Questions</td>
<td class="right">March 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Trammell</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Research Task Force (IRTF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9217" class="eref">9217</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-03" class="published">March 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">B. Trammell</div>
<div class="org">Google Switzerland GmbH</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9217</h1>
<h1 id="title">Current Open Questions in Path-Aware Networking</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">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 it provides
      for endpoints and applications to use these properties to select paths
      through the Internet for their traffic. While this property of "path
      awareness" already exists in many Internet-connected networks within
      single domains and via administrative interfaces to the network layer, a
      fully path-aware internetwork expands these concepts across layers and
      across the Internet.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document poses questions in path-aware networking, open as of
      2021, that must be answered in the design, development, and deployment
      of path-aware internetworks. It was originally written to frame
      discussions in the Path Aware Networking Research Group (PANRG), and has
      been published to snapshot current thinking in this space.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Path Aware Networking
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            candidates for any level of Internet Standard; see Section 2 of RFC
            7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9217">https://www.rfc-editor.org/info/rfc9217</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction-to-path-aware-" class="xref">Introduction to Path-Aware Networking</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-definitions" class="xref">Definitions</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-questions" class="xref">Questions</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-a-vocabulary-of-path-proper" class="xref">A Vocabulary of Path Properties</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-discovery-distribution-and-" class="xref">Discovery, Distribution, and Trustworthiness of Path Properties</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-supporting-path-selection" class="xref">Supporting Path Selection</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-interfaces-for-path-awarene" class="xref">Interfaces for Path Awareness</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-implications-of-path-awaren" class="xref">Implications of Path Awareness for the Transport and Application Layers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-what-is-an-endpoint" class="xref">What is an Endpoint?</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.7">
                <p id="section-toc.1-1.2.2.7.1"><a href="#section-2.7" class="xref">2.7</a>.  <a href="#name-operating-a-path-aware-netw" class="xref">Operating a Path-Aware Network</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.8">
                <p id="section-toc.1-1.2.2.8.1"><a href="#section-2.8" class="xref">2.8</a>.  <a href="#name-deploying-a-path-aware-netw" class="xref">Deploying a Path-Aware Network</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-security-and-privacy-consid" class="xref">Security and Privacy Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction-to-path-aware-">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction-to-path-aware-" class="section-name selfRef">Introduction to Path-Aware Networking</a>
      </h2>
<p id="section-1-1">In the current Internet architecture, the network layer provides a
      best-effort service to the endpoints using it, without verifiability of
      the properties of the path between the endpoints. While there are
      network-layer technologies that attempt better-than-best-effort
      delivery, the interfaces to these are generally administrative as
      opposed to endpoint exposed (e.g., Path Computation Element (PCE) <span>[<a href="#RFC4655" class="xref">RFC4655</a>]</span> and Software-Defined Wide Area
      Network (SD-WAN) <span>[<a href="#MEF70" class="xref">MEF70</a>]</span> approaches), and they are often restricted to single
      administrative domains. In this architecture, an application can assume
      that a packet with a given destination address will eventually be
      forwarded toward that destination, but little else.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">A transport-layer protocol such as TCP can provide reliability over
      this best-effort service, and a protocol above the network layer, such
      as Transport Layer Security (TLS) <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, can authenticate the remote endpoint. However,
      little, if any, explicit information about the path is available to the
      endpoints, and any assumptions made about that path often do not hold.
      These sometimes have serious impacts on the application, as in the case
      with BGP hijacking attacks.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">By contrast, in a path-aware internetworking architecture, endpoints
      can select or influence the path(s) through the network used by any
      given packet or flow. The network and transport layers explicitly expose
      information about the path or paths available to the endpoints and to
      the applications running on them, so that they can make this
      selection. The Application-Layer Traffic Optimization (ALTO) protocol
      <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span> can be seen as an example of a
      path-awareness approach implemented in transport-layer terms on the
      present Internet protocol stack.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Path selection provides explicit visibility and control of network treatment to
applications and users of the network. This selection is available to the
application-, transport-, and/or network-layer entities at each endpoint. Path
control at the flow and subflow level enables the design of new transport
protocols that can leverage multipath connectivity across disjoint paths through
the Internet, even over a single physical interface.  When exposed to
applications, or to end users through a system configuration interface, path
control allows the specification of constraints on the paths that traffic should
traverse, for instance to confound passive surveillance in the network core
<span>[<a href="#RFC7624" class="xref">RFC7624</a>]</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">We note that this property of "path awareness" already exists in many
      Internet-connected networks within single domains. Indeed, much of the
      practice of network engineering using encapsulation at layer 3 can be
      said to be "path aware" in that it explicitly assigns traffic at tunnel
      endpoints to a given path within the network. Path-aware internetworking
      seeks to extend this awareness across domain boundaries without
      resorting to overlays, except as a transition technology.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This document presents a snapshot of open questions in this space that will need
to be answered in order to realize a path-aware internetworking architecture; it
is published to further frame discussions within and outside the Path Aware
Networking Research Group, and is published with the rough consensus of that
group.<a href="#section-1-6" class="pilcrow">¶</a></p>
<div id="definitions">
<section id="section-1.1">
        <h3 id="name-definitions">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-definitions" class="section-name selfRef">Definitions</a>
        </h3>
<p id="section-1.1-1">For purposes of this document, "path-aware networking" describes endpoint
discovery of the properties of paths they use for communication across an
internetwork, and endpoint  reaction to these properties that affects routing
and/or data transfer. Note that this can and already does happen to some extent
in the current Internet architecture; this definition expands current techniques
of path discovery and manipulation to cross administrative domain boundaries and
up to the transport and application layers at the endpoints.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">Expanding on this definition, a "path-aware internetwork" is one in
        which endpoint discovery of path properties and endpoint selection of
        paths used by traffic exchanged by the endpoint are explicitly
        supported regardless of the specific design of the protocol features
        that enable this discovery and selection.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">A "path", for the purposes of these definitions, is abstractly
        defined as a sequence of adjacent path elements over which a packet
        can be transmitted, where the definition of "path element" is
        technology dependent. As this document is intended to pose questions
        rather than answer them, it assumes that this definition will be
        refined as part of the answer to the first two questions it poses
        about the vocabulary of path properties and how they are
        disseminated.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">Research into path-aware internetworking covers any and all aspects of
designing, building, and operating path-aware internetworks or the networks
and endpoints attached to them. This document presents a collection of
research questions to address in order to make a path-aware Internet a
reality.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="questions">
<section id="section-2">
      <h2 id="name-questions">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-questions" class="section-name selfRef">Questions</a>
      </h2>
<p id="section-2-1">Realizing path-aware networking requires answers to a set of open
      research questions. This document poses these questions as a starting
      point for discussions about how to realize path awareness in the
      Internet and to direct future research efforts within the Path Aware
      Networking Research Group.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="a-vocabulary-of-path-properties">
<section id="section-2.1">
        <h3 id="name-a-vocabulary-of-path-proper">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-a-vocabulary-of-path-proper" class="section-name selfRef">A Vocabulary of Path Properties</a>
        </h3>
<p id="section-2.1-1">The first question: how are paths and path properties defined and represented?<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">In order for information about paths to be exposed to an endpoint,
        and for the endpoint to make use of that information, it is necessary
        to define a common vocabulary for paths through an internetwork and
        properties of those paths. 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. These properties may be relatively static, such as the presence
        of a given node or service function on the path, as well as relatively
        dynamic, such as the current values of metrics such as loss and
        latency.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">This vocabulary and its representation must be defined carefully,
        as its design will have impacts on the properties (e.g.,
        expressiveness, scalability, and security) of a given path-aware
        internetworking architecture. For example, a system that exposes
        node-level information for the topology through each network would
        maximize information about the individual components of the path at
        the endpoints, at the expense of making internal network topology
        universally public, which may be in conflict with the business goals
        of each network's operator. Furthermore, properties related to
        individual components of the path may change frequently and may
        quickly become outdated. However, aggregating the properties of
        individual components to distill end-to-end properties for the entire
        path is not trivial.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="discovery-distribution-and-trustworthiness-of-path-properties">
<section id="section-2.2">
        <h3 id="name-discovery-distribution-and-">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-discovery-distribution-and-" class="section-name selfRef">Discovery, Distribution, and Trustworthiness of Path Properties</a>
        </h3>
<p id="section-2.2-1">The second question: how do endpoints and applications get access to accurate,
useful, and trustworthy path properties?<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">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 endpoints. Regardless of how path
        property information is distributed, the endpoints require a method to
        authenticate the properties in order to determine that they originated
        from and pertain to the path that they purport to.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">Choices in distribution and authentication methods will have impacts on the
scalability of a path-aware architecture. Possible dimensions in the space of
distribution methods include in band versus out of band, push versus pull
versus publish subscribe, and so on. There are temporal issues with path
property dissemination as well, especially with dynamic properties, since the
measurement or elicitation of dynamic properties may be outdated by the time
that information is available at the endpoints, and interactions between the
measurement and dissemination delay may exhibit pathological behavior for
unlucky points in the parameter space.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="supporting-path-selection">
<section id="section-2.3">
        <h3 id="name-supporting-path-selection">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-supporting-path-selection" class="section-name selfRef">Supporting Path Selection</a>
        </h3>
<p id="section-2.3-1">The third question: how can endpoints select paths to use for
        traffic in a way that can be trusted by the network, the endpoints,
        and the applications using them?<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">Access to trustworthy path properties is only half of the challenge
        in establishing a path-aware architecture. Endpoints must be able to
        use this information in order to select paths for specific traffic
        they send. As with the dissemination of path properties, choices made
        in path-selection methods will also have an impact on the trade-off
        between scalability and expressiveness of a path-aware
        architecture. One key choice here is between in-band and out-of-band
        control of path selection. Another is granularity of path selection
        (whether per packet, per flow, or per larger aggregate), which also
        has a large impact on the scalability/expressiveness trade-off. Path
        selection must, like path property information, be trustworthy, such
        that the result of a path selection at an endpoint is
        predictable. Moreover, any path-selection mechanism should aim to
        provide an outcome that is not worse than using a single path or
        selecting paths at random.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">Path selection may be exposed in terms of the properties of the path or the identity
of elements of the path. In the latter case, a path may be identified at any of
multiple layers (e.g., routing domain identifier, network-layer address, higher-layer
identifier or name, and so on). In this case, care must be taken to present
semantically useful information to those making decisions about which path(s)
to trust.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="interfaces-for-path-awareness">
<section id="section-2.4">
        <h3 id="name-interfaces-for-path-awarene">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-interfaces-for-path-awarene" class="section-name selfRef">Interfaces for Path Awareness</a>
        </h3>
<p id="section-2.4-1">The fourth question: how can interfaces among the network,
        transport, and application layers support the use of path
        awareness?<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">In order for applications to make effective use of a path-aware
        networking architecture, the control interfaces presented by the
        network and transport layers must also expose path properties to the
        application in a useful way, and provide a useful set of paths among
        which the application can select. Path selection must be possible
        based not only on the preferences and policies of the application
        developer, but of end users as well. Also, the path-selection
        interfaces presented to applications and end users will need to
        support multiple levels of granularity. Most applications'
        requirements can be satisfied with the expression of path-selection
        policies in terms of properties of the paths, while some applications
        may need finer-grained, per-path control. These interfaces will need
        to support incremental development and deployment of applications, and
        provide sensible defaults, to avoid hindering their adoption.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="implications-of-path-awareness-for-the-transport-and-application-layers">
<section id="section-2.5">
        <h3 id="name-implications-of-path-awaren">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-implications-of-path-awaren" class="section-name selfRef">Implications of Path Awareness for the Transport and Application Layers</a>
        </h3>
<p id="section-2.5-1">The fifth question: how should transport-layer and higher-layer
        protocols be redesigned to work most effectively over a path-aware
        networking layer?<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">In the current Internet, the basic assumption that at a given time all
traffic for a given flow will receive the same network treatment and traverse
the same path or equivalent paths often holds. In a path-aware network,
this assumption is more easily violated. The weakening of this assumption
has implications for the design of protocols above any path-aware network layer.<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<p id="section-2.5-3">For example, one advantage of multipath communication is that a given
end-to-end flow can be "sprayed" along multiple paths in order to confound
attempts to collect data or metadata from those flows for pervasive
surveillance purposes <span>[<a href="#RFC7624" class="xref">RFC7624</a>]</span>. However, the benefits of this approach are
reduced if the upper-layer protocols use linkable identifiers on packets
belonging to the same flow across different paths. Clients may mitigate
linkability by opting to not reuse cleartext connection identifiers, such as
TLS session IDs or tickets, on separate paths. The privacy-conscious
strategies required for effective privacy in a path-aware Internet are only
possible if higher-layer protocols such as TLS permit clients to obtain
unlinkable identifiers.<a href="#section-2.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="what-is-an-endpoint">
<section id="section-2.6">
        <h3 id="name-what-is-an-endpoint">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-what-is-an-endpoint" class="section-name selfRef">What is an Endpoint?</a>
        </h3>
<p id="section-2.6-1">The sixth question: how is path awareness (in terms of vocabulary and
interfaces) different when applied to tunnel and overlay endpoints?<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<p id="section-2.6-2">The vision of path-aware networking articulated so far makes an assumption
that path properties will be disseminated to endpoints on which applications
are running (terminals with user agents, servers, and so on). However,
incremental deployment may require that a path-aware network "core" be used to
interconnect islands of legacy protocol networks. In these cases, it is the
gateways, not the application endpoints, that receive path properties and make
path selections for that traffic. The interfaces provided by this gateway are
necessarily different than those a path-aware networking layer provides to its
transport and application layers, and the path property information the
gateway needs and makes available over those interfaces may also be different.<a href="#section-2.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="operating-a-path-aware-network">
<section id="section-2.7">
        <h3 id="name-operating-a-path-aware-netw">
<a href="#section-2.7" class="section-number selfRef">2.7. </a><a href="#name-operating-a-path-aware-netw" class="section-name selfRef">Operating a Path-Aware Network</a>
        </h3>
<p id="section-2.7-1">The seventh question: how can a path-aware network in a path-aware internetwork
be effectively operated, given control inputs from network administrators,
application designers, and end users?<a href="#section-2.7-1" class="pilcrow">¶</a></p>
<p id="section-2.7-2">The network operations model in the current Internet architecture
        assumes that traffic flows are controlled by the decisions and
        policies made by network operators as expressed in interdomain and
        intradomain routing protocols. In a network providing path selection
        to the endpoints, however, this assumption no longer holds, as
        endpoints may react to path properties by selecting alternate
        paths. Competing control inputs from path-aware endpoints and the
        routing control plane may lead to more difficult traffic engineering
        or non-convergent forwarding, especially if the endpoints' and
        operators' notion of the "best" path for given traffic diverges
        significantly. The degree of difficulty may depend on the fidelity of
        information made available to path-selection algorithms at the
        endpoints. Explicit path selection can also specify outbound paths,
        while BGP policies are expressed in terms of inbound traffic.<a href="#section-2.7-2" class="pilcrow">¶</a></p>
<p id="section-2.7-3">A concept for path-aware network operations will need to have clear
        methods for the resolution of apparent (if not actual) conflicts of
        intent between the network's operator and the path selection at an
        endpoint. It will also need a set of safety principles to ensure that
        increasing path control does not lead to decreasing connectivity; one
        such safety principle could be "the existence of at least one path
        between two endpoints guarantees the selection of at least one path
        between those endpoints."<a href="#section-2.7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="deploying-a-path-aware-network">
<section id="section-2.8">
        <h3 id="name-deploying-a-path-aware-netw">
<a href="#section-2.8" class="section-number selfRef">2.8. </a><a href="#name-deploying-a-path-aware-netw" class="section-name selfRef">Deploying a Path-Aware Network</a>
        </h3>
<p id="section-2.8-1">The eighth question: how can the incentives of network operators and end users
be aligned to realize the vision of path-aware networking, and how can the
transition from current ("path-oblivious") to path-aware networking be managed?<a href="#section-2.8-1" class="pilcrow">¶</a></p>
<p id="section-2.8-2">The vision presented in the introduction discusses path-aware
        networking from the point of view of the benefits accruing at the
        endpoints, to designers of transport protocols and applications as
        well as to the end users of those applications. However, this vision
        requires action not only at the endpoints but also within the
        interconnected networks offering path-aware connectivity. While the
        specific actions required are a matter of the design and
        implementation of a specific realization of a path-aware protocol
        stack, it is clear that any path-aware architecture will require
        network operators to give up some control of their networks over to
        endpoint-driven control inputs.<a href="#section-2.8-2" class="pilcrow">¶</a></p>
<p id="section-2.8-3">Here, the question of apparent versus actual conflicts of intent
        arises again: certain network operation requirements may appear
        essential but are merely accidents of the interfaces provided by
        current routing and management protocols. For example, related (but
        adjacent) to path-aware networking, the widespread use of the TCP wire
        image <span>[<a href="#RFC8546" class="xref">RFC8546</a>]</span> in network monitoring
        for DDoS prevention appears in conflict with the deployment of
        encrypted transports, only because path signaling <span>[<a href="#RFC8558" class="xref">RFC8558</a>]</span> has been implicit in the
        deployment of past transport protocols.<a href="#section-2.8-3" class="pilcrow">¶</a></p>
<p id="section-2.8-4">Similarly, incentives for deployment must show how existing network
        operation requirements are met through new path selection and property
        dissemination mechanisms.<a href="#section-2.8-4" class="pilcrow">¶</a></p>
<p id="section-2.8-5">The incentives for network operators and equipment vendors need to
        be made clear, in terms of a plan to transition <span>[<a href="#RFC8170" class="xref">RFC8170</a>]</span> an internetwork to path-aware operation, one
        network and facility at a time. This plan to transition must also take
        into account that the dynamics of path-aware networking early in this
        transition (when few endpoints and flows in the Internet use path
        selection) may be different than those later in the transition.<a href="#section-2.8-5" class="pilcrow">¶</a></p>
<p id="section-2.8-6">Aspects of data security and information management in a network that explicitly
radiates more information about the network's deployment and configuration, and
implicitly radiates information about endpoint configuration and preference
through path selection, must also be addressed.<a href="#section-2.8-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iana">
<section id="section-3">
      <h2 id="name-iana-considerations">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-3-1">This document has no IANA actions.<a href="#section-3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
<section id="section-4">
      <h2 id="name-security-and-privacy-consid">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-security-and-privacy-consid" class="section-name selfRef">Security and Privacy Considerations</a>
      </h2>
<p id="section-4-1">
 This document poses questions about path-aware internetworking; the
 answers are a matter for future research, and security considerations
 for those answers would be included in the corresponding RFCs that
 describe them. While each of these questions is to a lesser or greater
 degree relevant to the security and privacy of users of a path-aware
 network, questions of discovery and trustworthiness (<a href="#discovery-distribution-and-trustworthiness-of-path-properties" class="xref">Section 2.2</a>)
 are most security-relevant.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5">
      <h2 id="name-informative-references">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="MEF70">[MEF70]</dt>
      <dd>
<span class="refAuthor">MEF</span>, <span class="refTitle">"SD-WAN Service Attributes and Services"</span>, <span class="refContent">MEF Standard</span>, <span class="seriesInfo">MEF 70</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.mef.net/wp-content/uploads/2019/07/MEF-70.pdf">https://www.mef.net/wp-content/uploads/2019/07/MEF-70.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4655">[RFC4655]</dt>
      <dd>
<span class="refAuthor">Farrel, A.</span>, <span class="refAuthor">Vasseur, J.-P.</span>, and <span class="refAuthor">J. Ash</span>, <span class="refTitle">"A Path Computation Element (PCE)-Based Architecture"</span>, <span class="seriesInfo">RFC 4655</span>, <span class="seriesInfo">DOI 10.17487/RFC4655</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7285">[RFC7285]</dt>
      <dd>
<span class="refAuthor">Alimi, R., Ed.</span>, <span class="refAuthor">Penno, R., Ed.</span>, <span class="refAuthor">Yang, Y., Ed.</span>, <span class="refAuthor">Kiesel, S.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Roome, W.</span>, <span class="refAuthor">Shalunov, S.</span>, and <span class="refAuthor">R. Woundy</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Protocol"</span>, <span class="seriesInfo">RFC 7285</span>, <span class="seriesInfo">DOI 10.17487/RFC7285</span>, <time datetime="2014-09" class="refDate">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7285">https://www.rfc-editor.org/info/rfc7285</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7624">[RFC7624]</dt>
      <dd>
<span class="refAuthor">Barnes, R.</span>, <span class="refAuthor">Schneier, B.</span>, <span class="refAuthor">Jennings, C.</span>, <span class="refAuthor">Hardie, T.</span>, <span class="refAuthor">Trammell, B.</span>, <span class="refAuthor">Huitema, C.</span>, and <span class="refAuthor">D. Borkmann</span>, <span class="refTitle">"Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement"</span>, <span class="seriesInfo">RFC 7624</span>, <span class="seriesInfo">DOI 10.17487/RFC7624</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7624">https://www.rfc-editor.org/info/rfc7624</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8170">[RFC8170]</dt>
      <dd>
<span class="refAuthor">Thaler, D., Ed.</span>, <span class="refTitle">"Planning for Protocol Adoption and Subsequent Transitions"</span>, <span class="seriesInfo">RFC 8170</span>, <span class="seriesInfo">DOI 10.17487/RFC8170</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8170">https://www.rfc-editor.org/info/rfc8170</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8546">[RFC8546]</dt>
      <dd>
<span class="refAuthor">Trammell, B.</span> and <span class="refAuthor">M. Kuehlewind</span>, <span class="refTitle">"The Wire Image of a Network Protocol"</span>, <span class="seriesInfo">RFC 8546</span>, <span class="seriesInfo">DOI 10.17487/RFC8546</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8546">https://www.rfc-editor.org/info/rfc8546</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8558">[RFC8558]</dt>
    <dd>
<span class="refAuthor">Hardie, T., Ed.</span>, <span class="refTitle">"Transport Protocol Path Signals"</span>, <span class="seriesInfo">RFC 8558</span>, <span class="seriesInfo">DOI 10.17487/RFC8558</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8558">https://www.rfc-editor.org/info/rfc8558</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">Many thanks to <span class="contact-name">Adrian Perrig</span>, <span class="contact-name">Jean-Pierre Smith</span>, <span class="contact-name">Mirja Kühlewind</span>,
      <span class="contact-name">Olivier Bonaventure</span>, <span class="contact-name">Martin       Thomson</span>, <span class="contact-name">Shwetha Bhandari</span>, <span class="contact-name">Chris Wood</span>, <span class="contact-name">Lee Howard</span>, <span class="contact-name">Mohamed Boucadair</span>, <span class="contact-name">Thorben Krüger</span>,
      <span class="contact-name">Gorry Fairhurst</span>, <span class="contact-name">Spencer       Dawkins</span>, <span class="contact-name">Reese Enghardt</span>, <span class="contact-name">Laurent Ciavaglia</span>, <span class="contact-name">Stephen Farrell</span>,
      and <span class="contact-name">Richard Yang</span> for discussions leading to
      questions in this document and for feedback on the document itself.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">This work is partially supported by the European Commission under
      Horizon 2020 grant agreement no. 688421 Measurement and Architecture for
      a Middleboxed Internet (MAMI) and by the Swiss State Secretariat for
      Education, Research, and Innovation under contract no. 15.0268. This
      support does not imply endorsement.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brian Trammell</span></div>
<div dir="auto" class="left"><span class="org">Google Switzerland GmbH</span></div>
<div dir="auto" class="left"><span class="street-address">Gustav-Gull-Platz 1</span></div>
<div dir="auto" class="left">CH-<span class="postal-code">8004</span> <span class="locality">Zurich</span>
</div>
<div dir="auto" class="left"><span class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ietf@trammell.ch" class="email">ietf@trammell.ch</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>