<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<style>
html {
line-height: 1.2;
font-family: serif;
font-size: 0.9em;
color: black;
background-color: white;
}
body {
margin: 0;
margin-right: auto;
max-width: 36em;
padding: 1em;
hyphens: auto;
overflow-wrap: break-word;
text-rendering: optimizeLegibility;
font-kerning: normal;
}
@media print {
body {
background-color: transparent;
color: black;
font-size: 11pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
p {
margin: 1em 0;
}
a {
color: black;
}
a:visited {
color: black;
}
img {
max-width: 100%;
}
h1, h2, h3, h4, h5, h6 {
margin-top: 1.4em;
}
h5, h6 {
font-size: 1em;
font-style: italic;
}
h6 {
font-weight: normal;
}
ol, ul {
padding-left: 1.7em;
margin-top: 1em;
}
li > ol, li > ul {
margin-top: 0;
}
blockquote {
margin: 0.5em;
padding-left: 0.5em;
border-left: 2px solid #e6e6e6;
color: #444;
}
code {
font-family: 'Lucida Console', monospace;
font-size: 95%;
margin: 0;
}
pre {
margin: 1em 0;
overflow: auto;
max-width: unset;
width: fit-content;
}
pre code {
padding: 0;
overflow: visible;
overflow-wrap: normal;
max-width: unset;
white-space: pre-wrap;
}
pre code span {
white-space: pre;
}
.sourceCode {
background-color: transparent;
overflow: visible;
}
code.diff span.kw,
code.diff span.dt {
font-weight: bold;
}
code.diff span.va {
background-color: rgba(192, 255, 192, 64);
color: rgb(0, 64, 0);
}
code.diff span.st {
background-color: rgba(255, 192, 192, 64);
color: rgb(64, 0, 0);
}
pre.diff {
background-color: rgb(240, 240, 240);
padding: 0.4em;
border: 1pt solid grey;
}
hr {
background-color: black;
border: none;
height: 1px;
margin: 1em 0;
}
table {
margin: 1em 0;
border-collapse: collapse;
width: 100%;
overflow-x: auto;
display: block;
font-variant-numeric: lining-nums tabular-nums;
}
table caption {
margin-bottom: 0.75em;
}
tbody {
margin-top: 0.5em;
border-top: 1px solid black;
border-bottom: 1px solid black;
}
th {
border-top: 1px solid black;
padding: 0.25em 0.5em 0.25em 0.5em;
}
td {
padding: 0.125em 0.5em 0.25em 0.5em;
}
header {
margin-bottom: 4em;
text-align: center;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
q { quotes: "„" "”" "»" "«"; }
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
</head>
<body>
<p>Hello Ralph,</p>
<blockquote>
<p>Issue #1) There is no way to tell the difference between a transit
entry and an “AS0” entry.</p>
</blockquote>
<p>There is no difference between a transit entry and an AS0 entry. The
<code>transit</code> keyword is just a syntactic shortcut for
<code>provider 0</code>.</p>
<blockquote>
<p>The treatment of AS0 providers is mentioned in section 5 of
draft-ietf-sidrops-aspa-verification-19. It is a mechanism for people
to announce that “no one should announce this AS”. I’ve attached a
snapshot of the global ASPA table as “bird-aspa-v2.16.conf”. There is
one AS0 announcement as of today.</p>
</blockquote>
<p>No, it isn’t. It’s a mechanism to say “I have no providers”, as
written in section 5 of the draft:</p>
<blockquote>
<p>Registering as AS0 ASPA is a statement by the registering AS that it
has no transit providers (…)</p>
</blockquote>
<p>This effectively means that in a valid AS Path, there may be:</p>
<ul>
<li>no AS with AS0 ASPA</li>
<li>a single AS with AS0 ASPA</li>
<li>two adjacent AS’s with AS0 ASPA</li>
</ul>
<p>I fell probably exactly into the same trap when reading the drafts
first time, and the draft authors had to explain the principles to me
several times in person for me to get it right. I tried to fix that by
suggesting a different wording, please check this (long) message in
sidrops:</p>
<p>https://mailarchive.ietf.org/arch/msg/sidrops/LE_nPFL6XFnIKE-25O9WIfZ-YFI/</p>
<blockquote>
<p>Issue #2) Changes in static ASPA tables are not reflected until
entries are removed and re-added.</p>
</blockquote>
<p>Thanks, fixed:
https://gitlab.nic.cz/labs/bird/-/commit/1e685bbc2a7411c09b6c80404c49a410d6c47a2a</p>
<blockquote>
<p>This problem does not occur when the ASPA elements are
customer-provider pairs. I believe this is an overall design issue, not
a simple bug. I will be bringing this issue up with ietf-sidrops.</p>
</blockquote>
<p>There were massive data consistency problems in BIRD 3 when the ASPA
elements were customer-provider pairs, and we won’t go back there.</p>
<p>Also, both the configuration and the in-table storage is more
memory-greedy with the pairs storage.</p>
<p>Have a nice end-of-the-year! Maria</p>
<p>–<br />
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</body>
</html>